> 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.
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.
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.
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
> 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.
> 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.
Yours,
Ran
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
