On Mon, Nov 24, 2008 at 12:08 AM, Robin Whittle <[EMAIL PROTECTED]> wrote: > Here is a list of objections to any routing scaling > solution which pushes work relating to multihoming, > TE and changing ISPs onto hosts. This is in > addition to the objections regarding the > impracticality of introducing such upgrades to the > great majority of host stacks and applications.
Hi Robin, Your observations are more or less on target with two major exceptions: 1. Responsiveness to multihoming failure. BGP convergence takes a long time and the time is growing with the number of entries in the table. 2 minutes is not unreasonable. While this activity is ongoing, some or all of the Internet is unavailable to to hosts behind the impacted router. What's more, purely network-based recovery is vulnerable to a number of errors. For example, a link with 70% packet loss or which drops all packets over 500 bytes can get enough packets through to keep the routing session up. If your route goes through that link, you're dead in the water until a network administrator manually disables or fixes the link. By contrast, a multiple-LOC multihomed host could detect the failure of one of its LOCs (the one associated with the failed link) within a few hundred milliseconds and switch to using just the LOCs which still work. Detection is straightforward: if you're round-robining through the available LOCs as you send packets, the failed LOC sets are the ones that stop reliably returning responses. 2. Mobile complexity. Mobile-IP is already very complex. If anything, host-based solutions make it less so by implementing protocols which are designed to survive changes in the network topology from the ground up instead of being back-hacked into a protocol that isn't designed that way. Mobile IP extensions then become a just question of how to implement a seamless transition where no packets are lost instead of a question of how to implement a transition at all. By the way, before I complete the solutions universe document, I plan to ask for "motions to exclude." That is, I'll ask the group whether we have a strong consensus that a particular strategy is unacceptable for one reason or another. If we do have a strong consensus (unanimous or nearly so) then I'll mark the fact that the strategy was considered but excluded by strong consensus. I at least plan to object to strategy F. ;) Regards. Bill Herrin -- William D. Herrin ................ [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
