There are things that people want to do (e.g. control inbound traffic, multi-homing) which are _perfectly reasonable things to want to do_ - the only problem being that the current Internet architecture doesn't provide any good tools to do them. So we wind up with ugly kludges, and routing tables which grow rapidly. Maybe we should provide better tools (technology) to do those things... As I understand it, DV provides inbound traffic control comes for free (if I don't tell some neighboring AS that I have reachability xyz then he cannot use me as a transit towards xyz. However, the price to be paid is this scalability problem: the FIB, the RIB, the update churn. I know that an architecture which is based on knowing the (evtl. well filtered) network topology rather than on collecting routes must do some extra work for the sake of inbound traffic control. That would be worth the sweat of the nobles. I am sure that would be a) feasible and b) not too extensive. So far this argument has always been used as a killer argument whithout showing the contrary, i.e. that without DV such inbound traffic control is a) not feasible and b) not too extensive. Heiner -----Ursprüngliche Mitteilung----- Von: Noel Chiappa <[email protected]> An: [email protected]; [email protected] Cc: [email protected] Verschickt: Mo., 26. Apr. 2010, 6:11 Thema: Re: [rrg] Next pass > From: Russ White <[email protected]> > I can give you examples where loc/id will reduce the table size. ... > Anecdotal evidence doesn't provide an answer, though. Those 'examples' weren't individual examples, but examples of _classes_ of scenarios where separation of location and identity can, if the engineering details of the location/identity scheme used are appropriate, provide reduced routing table sizes. In the second (site multi-homing) case I mentioned, this reduction is over a global scope - which is of particular interest as it seems to be a fairly common one. Your original statement was "I don't know that loc/id separation 'solves' any sort of 'table size' issue." Well, I don't know about you, but to me, significantly reducing routing table sizes globally does indeed count as 'solv[ing a routing] 'table size' issue". > 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? Presumably because use of those mechanisms precludes doing something else people want to do, which they cannot otherwise do because _there is no mechanism available to do it in a way that also meets other goals they have_. So perhaps if we provide such an alternative mechanism, things will be different. > 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 ... 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." And a appropriately designed location/identity separation system does provide inbound traffic control (in fact, that was my _first_ example). So if it's really inbound traffic control that needs to be provided, then I'm happy, because an appropriately engineered location/identity separation system does provide that capability - and at least one existing system does provide it. > Well, there is a third--just deal with the additional state. You missed #4 - be smarter about who has to get what state. > 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?). What's a 'locator table'? Do you mean the routing table (which is exactly the same in location/identity separate architectures as it is now)? Exactly what kind of size evolution it will see is hard to predict, but to the extent that site multi-homing is driving growth, another way to do site multi-homing would presumably slow down that growth. And I'm not certain what the 'ID table' might be; I'm assuming it's the {identity->location} mapping database. It might be 'large' in the abstract sense (because it will never be agglomerated together in one place, unless someone does a tree-walk to build a complete local copy of the database), but DNS is also 'large', and that doesn't seem to be an issue because... we're smarter about who has to get what DNS state. (This has all been explored in some depth, including being modelled in considerable detail, using full-scale simulations. See the papers I mentioned in a previous post today.) > the state is now externalized in such a way that advertising an IPv4 > /32 doesn't really "cost" anything any longer, does it? Not really - which is why mobility is another potential application for location/identity separation. The cost is a mapping cache entry in only those entities the mobile entry is communicating with, and a small amount of control traffic to distribute those mapping entries, and keep them up to date as the mobile node moves. > The roots of this problem are policy and economics, not technical. So then what causes the common (so common it has a name) hammer-nail syndrome, if not _not providing appropriate tools (i.e. technology) to do what people need to do_ (and which they need to do for political and economic reasons)? There are things that people want to do (e.g. control inbound traffic, multi-homing) which are _perfectly reasonable things to want to do_ - the only problem being that the current Internet architecture doesn't provide any good tools to do them. So we wind up with ugly kludges, and routing tables which grow rapidly. Maybe we should provide better tools (technology) to do those things... > I just that I don't think reality will curve the way we want it to just > because we think it should. True. As Feynman said, "For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled." But again, if all you give them is a hammer... Noel _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
