> Put differently, anycast addresses are no different than, and arguably > worses than, PI addresses. A whole lot of our work is to get PI addresses > out of the core table. Getting PI out, but allowing unlimited anycast in > would not be progress.
Several of you have made comments like the above. In my head I can almost see the rest of you behind your screens, sagely nodding your heads in agreement that anycast shouldn't be a first-class citizen in the architecture. Before anyone nods his way into a mistake, I'd ask you to consider a simple question: What might anycast look like in the various approaches we've discussed to solving the routing problem? Let's look at a map-encap strategy A system first. What can't it do adequately without anycast? And how can it provide routeless anycast? First off your non-local packets need to find an ingress router. The more specific local routes will keep local packets away. The rest will follow a default route to the ingress router. Or is there some other way you'll find the ITR? Somehow force it inline with all packets routed? You'll no more run your network on just one ingress encoder than you'd run it on a single DNS server or a single T1. Okay, well, some of you will but those of you who are serious about reliability won't. No, you'll have two or several ingress routers. And each one will ANYCAST the default route so that if one of them fails the packets seamlessly reroute to the other. What about the transition period? For a while there'll be both legacy routing and the ITR/ETR routing. How will you bridge the legacy systems in? Well, every one of us who has come up with a strategy-A solution has posited some sort of ITR in the core that advertises short prefixes out to the legacy system and encodes the packets it gets for delivery in the new system. Will we have one for all the ETRs serving 192.0.0.0/8 and one for all the ETRs serving 193.0.0.0/8? Yeah right. We'll have 20 geographically distributed ITRs for 192.0.0.0/4, each of which will announce 192.0.0.0/4 via ANYCAST. And if you plan to go out and query a distributed map database (as more of you do now than did two years ago when I proposed it) then you'll announce your map roots via ANYCAST too. But that's only half the equation. Strategy A systems don't just consume anycast routes, they provide them. And unless you do something really bone-headed in your design, they do it in the map without consuming slots in the routing table. You do a map lookup on the destination. You get a prioritized list of of egress routers. Though presumably multiple entry points into the same system, this is no more a rule than with routes in the BGP table. Make each egress an entrance to a different, geographically and topologically diverse, host. The akamai-like map server dynamically reorders the list based on its heuristic guess as to which of the hosts are closer or further from you. Presto! You connect to the nearest server through minor magic in the map. Give the ingress router a mild resistance to change during relookups and you even get anycast with a very high probability of packets reaching the same respondent over time -- rather handy for anycast TCP which isn't really practical in the current routing system. Stable TCP over anycast would, by the way, be fantastic news for the CDNs and their customers which include, oh, just about every major content provider on the web. Of course, you might implement strategy A badly. You can build a rigid design where the map is static and the ingress router has no discretion whatsoever for which egress it sends to. But none of you made that mistake in your designs, right? Strategy B systems alter or replace TCP with a protocol that doesn't use the layer-3 address for its transport identity. They use a map to find the current set of "locators." Routeless anycast here works in much the same way as strategy A. The map is like an enhanced DNS SRV record. Better really: not only do the endpoints know which set of locators to try first, they know which locators match each of the multiple hosts returned by the lookup. You're actually guaranteed to get the same respondent for the duration of the layer-4 connection. It's SO easy. And, of course, anycast and unicast routes are identical in every respect in strategy D, E and F systems since the routes on those RIBs function identically to what we have today. With this in mind, I propose a statement which is, on its face, absurd. Yet each time you consider it in the coming months and years, you'll find it makes more and more sense: Unicast is a special case of anycast in which there is only one destination endpoint. Food for thought. 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
