kwe@buit13.bu.edu (Kent England) (10/03/90)
In article <9010021049.AA06180@WLV.IMSD.CONTEL.COM> mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes: >... > 1. Do routers generally have the capability to re-route traffic over > an alternate circuit? ... > 4. Would fudging IP, TCP, or TELNET timers by a "crypto resync constant" > alleviate problems? > One problem with routing fallback has to do with the time constants of the routing protocols (and link level fault protocols, if any) and the time constant of the failure. Sounds to me like crypto sync loss is a fast time constant sort of error. This begs the question of whether the routing protocol should spend the time required to re-route or whether it should hold off and wait for the link to come back up. With the advent of open link state protocols which converge "instantly", perhaps this point is becoming moot, but with distance vector protocols it is very hard to deal with link level state "flapping" side effects and still keep routing traffic down. Same thinking applies to TCP or Telnet timers. Should they wait a short time or a long time? How should they treat redirects and black holes? I think that should be up to the application, since mail usually has a different idea than telnet would. Put me in the "hate TCP/IP keepalives" camp. --Kent