Answering several points in one email, so the thread doesn't get scattered all over the place...
> No, but as we've discussed before, traffic engineering through deaggregation > is a self-inflicted problem. When ISPs feel that this is worth addressing, > I'm sure that we'll see requests for prefix scoping or longer prefix > filtering. Or even retraction of longest-match. Agreed--and a loc/id split doesn't solve this problem. If we are causing a self-inflicted table size issue today by refusing to aggregate in order to engineer traffic flows, then we are just as likely to get into the same position at some point in the future. > More to the point, it will simply be against policy to get PI allocations. But that doesn't stop people from deaggregating the locator space. I know that's not the _intent_, but the reality is that all systems are eventually deployed up to, and beyond, their technical limits, not the way we think they "should" be deployed. The next to worst case is probably the best estimate of where things will turn out. > We could go on for another 6 years and try to find out whether AS numbers > are better suited for aggregation rather than IP numbers (or NOT). I would point out that AS numbers as aggregation points isn't something I've advocated, or am likely to advocate. The reality is that aggregating at the AS level is just another "forced traffic engineering" scheme that people are likely to either reject, or simply work their way around, in order to control what they want to control--the points at which traffic enters and exits their AS. Beyond which, I don't think AS' aren't situated in any way where aggregating to the AS level would actually be something useful, at this point. Perhaps 10 years ago it might be arguable, but today I'd guess we're far beyond the point of gaining anything with such a design (of course, I don't have hard facts, this is just an intuitive guess). > TARA is the only approach which everyone can study just by using Google-map, > e.g. by trying to find a route from NY, Time Square to Sun Francisco Golden > Gate Bridge. Geographic routing doesn't present any more, or less, _possible_ information than any other routing system. I could inject a locator for every person in the world (each person's "home address"), and wind up with a locator table of about 6 billion--still pretty large, I think, even by Internet standards. :-) The only thing geographic routing systems provide is a possibly well defined set of points at which to aggregate location information--given everyone agrees to those points, and as long as there's no economic gain to be made from gaming the system. The reality is no-one has ever devised a routing system (that I know of) where it's better, economically, to inject less information rather than more purely on data plane/forwarding considerations. More information always provides less stretch and more efficient routing. Until links are free, or less than free (you are paid to install more bandwidth), the economics will always drive more optimal routing, and hence more state. It's just the way routing works. > Not sure I completely understand what you're asking here? The abstract > incentive to aggregate locators is to minimize routing overhead; I understand > that at the moment there's no practical incentive descendant from that, but > perhaps if more-specifics start getting filtered, or something, there will > bey a real incentive. If there's no incentive to reduce the routing table size today, then what will the incentive be when it's just locators? I would argue the incentive is in the opposite direction, that there will be a definite disincentive to deaggregate locators just as there is routes today. > The problem is that the architecture does not give them a better > tool to do traffic engineering with; hammer-nail. I'm not certain it has anything to do with the technology. Rather, it's a matter of reality: if you want steer traffic, you must have more state. Either that state must be in the packet header (source routing), in the construction of a tunnel (semi-permanent circuit), or in the forwarding table. You can't get better traffic flow control with less information; it's just a logical impossibility. So, going back to my original email, the point is that while loc/id split might be neat, and I actually don't disagree with the concept (some of the proposals on the table give me the willies, but that's another issue), I don't know that loc/id separation "solves" any sort of "table size" issue. So long as we understand this up front... :-) Russ
signature.asc
Description: OpenPGP digital signature
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
