On Thu, Apr 23, 2009 at 12:09 AM, Robin Whittle <[email protected]> wrote: > Core-edge separation, using anycast ETRs. > > Works about as well as the conventional approach, but is > equally unscalable for the same reasons. Since it is more > complex, it is probably best to avoid it and use the > conventional BGP approach instead.
Hi Robin, I think maybe you're missing the forest for the trees here. The functional equivalent of anycast in a strategy-A system is a 1-to-many address-to-ETR map where the ETRs in question are entries into distinct networks instead of entries into the same network. The anycasting functionality happens entirely in the ITR when it chooses the ETR. The ETR's character is that it has only one attachment in the topology, not multiple attachments. Giving the ETR multiple attachments would defeat the purpose. As for anycast ETRs, I haven't thought of a single sensible use case. > Core-edge elimination > > Could be made to work, but is more complex than the > conventional approach and is just as bad in terms of > scaling. However, if the Internet was somehow converted > to a core-edge elimination approach, it would be impossible > to do the conventional BGP approach, in which there was no > distinction between identifier and locator (the IP address > means both). Strategy B is like strategy A except we replace layer 4 with a protocol suite that handles the ITR/ETR functionality internally, eliminating the need for ITRs and ETRs. The anycasting decision happens in the originating host, after which the packet travels (or fails to travel) to one specific network attachment associated with the destination. The origin may have selected from be different attachments for the same host or it could have been attachments for multiple hosts all of which are capable of responding to the service request. >The main, perhaps only, reasons people are interested in >conventional BGP-based host anycast are (AFAIK) as follows. >These are all dependent on the normal behaviour of the BGP >routing system. > >a - "Shortest" (generally, in BGP terms) path to the nearest > router which advertises the prefix of its anycast host. This is the "speed" case. The premise is that the closest one will have the shortest round trip time and the lowest probability of packet loss. >b - Automatic failure recovery as long as the router stops > advertising the prefix if the one or more hosts using > this prefix dies. If so, the other BGP routers will > soon get the packets which would have gone to this one. Yes. >c - Load sharing over many hosts, in geographically and > topologically diverse sites, which gives the system > a high capacity and a great resistance to failure > without involving DNS in any way, since it always > responds to the one IP address. This is also extremely > important as a way of achieving high total bandwidth > to survive DoS attacks with floods of incoming packets. Yes. Point being that while DNS would work for this in theory, in practice it runs into trouble. >It may also be desired and possible to: > >d - Imply something about sending host location from which > of the anycast BGP routers got the packet (as you are > doing with your project which you mentioned at the end > of msg04894) - but AFAIK this information is not used for > the most prominent BGP-based host anycast usage: root > nameservers. I suppose that's possible though I'm not sure what the use case is. It seems like much of the rest of what you wrote here is based on the faulty premise of having some kind of anycast ETRs. The only response I can offer is: of course anycast ETRs don't make sense. Anycast ITRs make sense. ITRs making anycast decisions while resolving the map make sense. But ETRs are supposed to be single points of attachment in the network topology; it wouldn't make any kind of sense for them to be anycast. 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] http://www.irtf.org/mailman/listinfo/rrg
