> I can give you several examples where it can reduce the table size. I can give you examples where loc/id will reduce the table size. I can give you examples where simply aggregating will reduce the table size. I can give you examples (and mechanisms) that will reduce the table size through filtering of unneeded routes at the point where they're no longer needed (remember the old "inbound route summarization" draft?).
Anecdotal evidence doesn't provide an answer, though. 1. We have mechanisms we could use to reduce the table size today, already in the protocols coded and deployed. 2. Such mechanisms are not used today. 3. Why? I'm sorry to say I disagree with the general consensus that multihoming is the problem... Every enterprise I've asked about using PI space, and every SP I've ever asked about aggregation has told me longer prefixes are important to control the way traffic _enters_ their networks. The degree of control here is rather find grained, in fact, based on where and how particular customers are attached, and even where specific services live in the customer's network. Given all the above, some major part of the answer to "why," in #3 above, seems to me to be, "because we want to control inbound traffic flow." Now, let's consider this: There's an economic incentive to control inbound traffic flow, in terms of additional link/equipment costs, etc. The economic cost of injecting new state to control inbound traffic flow is small, incremental, and mostly externalized. Two costs, one of which is immediate and observable, the other of which is incremental, included in the first cost anyway, and mostly apparently externalized. I don't have to guess at which cost wins. There are only two real solutions: 1. Change the economic model somehow--internalize the cost, reduce the cost of bandwidth, etc. 2. Stop switching packets. Well, there is a third--just deal with the additional state. Splitting locs and ids doesn't change the underlying fundamental model here--the cost of adding new state is still small, incremental, and mostly externalized, the cost of adding new bandwidth is still large, immediate, and mostly internal. I suspect you just end up with a locator table that's generally about the same size as the current routing table (my guess is it will end up being at least one loc per PE, possibly more, depending on your model), and an ID table that's absolutely _flooded_ with new state (after all, the state is now externalized in such a way that advertising an IPv4 /32 doesn't really "cost" anything any longer, does it?). I'm not a betting man, but if I were, I'd bet a loc/id split will probably reduce the table for a few years, everyone will declare victory, and then in seven or ten years the table sizes will be unbearable again. The first stab at "fixing" it will be to slow down the propagation of the id table, so it's closer to DNS... And then we're right back to where we are today, only with two naming systems instead of one. The network will be more complex, and hence the problem will be more intractable. The roots of this problem are policy and economics, not technical. A technical solution might provide a mechanism people can employ to resolve the problem (if there is a problem in the first place), but a technical solution isn't going to convince people to change their economic behavior--at least I don't think it is. :-) Russ P.S. I'm on vacation for the next two weeks, so I won't be following this for a bit. None of the above is to say I find some of the solutions proposed interesting (and some of them give me the heebie-jeebies). I just that I don't think reality will curve the way we want it to just because we think it should.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
