Hi Bill, You wrote:
> 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. Depending on how the end-user network does its reachability testing - which is their choice - I would hope that Ivip would restore connectivity in much less than 2 minutes. The mapping change should only take a few seconds to propagate to all the ITRs which need it. > 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. Yes - with Ivip, I think that the continual reachability testing which each end-user network would have done for their network, probably by some company which specialises in such services, would need to detect the actual working state of of the link as far as user traffic is concerned. Since none of this is specified in Ivip, and since end-user networks and companies they hire can use any probing and techniques they like, and any decision making algorithm, they are free to devise the reachability testing system which suits them best. > 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. I can't see how every multihomed host could be required to continually test reachability with extra packets, or that it would be good to have each host sending out packets through multiple ISP links as a means of detecting an outage. I think that the technique you describe relies on the the application getting ACKs, and recognising when they don't arrive - and then telling the stack about it. This doesn't sound robust to me. Also, any one host doesn't necessarily have multiple sessions going on to be spread round-robin style over multiple ISP links, each involving a different IP address for this host. Overall, I think the prospect of having hosts figuring out themselves what is happening with their the multiple ISP links of their own network, and of the networks of all hosts they are communicating with, is a bad idea - for all the reasons I mentioned. > 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. Yes, but AFAIK, mobile IP is based on the notion of relatively stable IP addresses, including for the home agent router. With the type of host-based scalable routing solution I was criticising, there would be no such stable IP addresses in any end-user network - so Mobile IP would need to be rewritten from its very foundations. Alternatively, Mobile IP could not work in end-user networks. > 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. ;) OK - I hadn't read the other strategies, but F (do nothing) is clearly not an option. - Robin http://www.firstpr.com.au/ip/ivip/ _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
