In einer eMail vom 18.06.2010 15:54:08 Westeuropäische Sommerzeit schreibt [email protected]:
> Much earlier, Ran Atkinson wrote: >> I am not sure, but I think the question is how ILNP enables >> the number of DFZ RIB/FIB prefixes to be reduced. The >> shortest answer is by aggregation of routing prefixes. Afterwards, Heiner Hummel wrote: > This is precisely the technique that led to the current situation. > Read also this (copied from RFC4984 IAB RAWS report): > 3.2. IPv6 and Its Potential Impact on Routing Table Size I believe that you are mis-reading and mis-quoting RFC-4984. That RFC actually says that prefix aggregation through elimination of the need for PI address space is strongly desirable. The RFC also expresses concern that if the RIRs continue to issue PI address space, then the current issues with DFZ entropy due to site multi-homing (see paper referenced below) will become more severe. ILNP eliminates the value in, and need for, PI address space, by providing improved site/node multi-homing and improved site/node mobility features. HH:as does TARA. The bit you quoted simply observes that a 128-bit address is 4x larger than a 32-bit address, which is precisely true -- and as the RFC itself says that is not tremendously realistic. For openers, the IPv6 Address Architecture says that routing prefixes are 64-bits and the "IPv6 Interface Identifier" is 64-bits. > I submitted multiple emails pointing out that the attempt > to aggregate is one cause of the problem. Routing can be > done much more efficient without building any single aggregate > (=Prefix). It would appear those email messages have not been very persuasive. HH:Do you think the objectives are not persuasive enough? In total, they go far beyond the objectives of ILNP. Not long ago, Lixia asked for them, I wrote them up, and yes, since then, I got no response. I don't want to stipulate, why. Is this my fault ? TARA is based on routing algorithm no one else has ever built, and which neither IETF folks nor University teachers have ever imagined to be possible. In fact, all the evidence to date indicates that the reverse is true: Inability to aggregate routing prefixes is a primary cause for growth in the number of DFZ RIB/FIB entries. HH:What is this evidence? The stubborness to stick to prefix aggregation ? That can't be a purpose in itself, can it? There are a number of published refereed papers that support the above claim. To pick an example, this paper by Zhang, Huston, and others is very good: "IPv4 address allocation and the BGP routing table evolution" ACM SIGCOMM Computer Communication Review archive Volume 35, Issue 1, January 2005, ISSN:0146-4833 HH: I'm not impressed. All my concept is based on algorithm which are far beyond Dijkstra. E.g. algorithm to compute (consistently/ identical) well-skimmed higher-zoom topologies. > And I don't understand why you are so keen on building prefixes. I'm actually keen on cleaning up the Internet's naming architecture, which is known to have been deficient at least since the publication of IEN-1. Enabling prefix aggregation is a happy side effect of having a cleaner naming architecture. In turn, prefix aggregation is one of the few ways that actually work to reduce entropy in the DFZ RIB/FIB. HH: and TARA would eliminate all scalability problems even if it were thousand times tougher. Adding an additional zoom would do. > I am convinced that any native English speaking person would agree > that a locator of a node should be something that denote where > something is, rather than what something is. I am a native English speaking person. A subnetwork IS a location. > By knowing the TARA-locator of some particular node > you would be able to identify the neighboring nodes, > or more precisely the nodes located in the neighborhood. > > Can you do that with ILNP-locators ? Not only would comparing Locator values indicate which nodes are on the same subnetwork, but *due to prefix aggregation* one can also learn which other subnetworks are in the general area and use that information in evaluating Locator values of other nodes to discover which ones are nearby. > With DV you only get half of the possible routes. This is extremely poor, > because the earth is a globe and therefore the internet doesn'teven have > a rim (only stubs). Due to the DV mechanism you cut off those detouring > routes which would pass any more remote BGP-router. Indeed, with respect > to any particular destination node the more remote part of the internet > stays in the dark (although you collect millions of routes, while not > a single one needs to be collected). > > Hence, wrt to a given destination you don't know the upstream topology. > Hence you will never be able to communicate with the nodes thereof, > e.g. wrt congestion notification. Just look what lousy job re-ECN > is doing. Notifying the source :-( !!! What a bad solution! > The right solution would be to notify those upstream nodes > which could easily forward the packet along a different route. > > The entire CPU performance is eaten up by observing the current > reachabilities of the internet. This could be reduced to almost zero. > It would be much better to use the time as to observe the dynamic > traffic Sorry, but I have no idea what any of those paragraphs just above are trying to say, so I really can't comment. HH:DV means Distance Vector. I gave examples multiple times. If no bell rings, is this my fault? Yours, Ran _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
