Subject: Re: [rrg] issue#1 from Heiner Hummel

From: [email-masked]
Date: Fri, 18 Jun 2010 14:44:49 EDT

In einer eMail vom 18.06.2010 15:54:08 Westeuropäische Sommerzeit schreibt  
[email-masked]:

>  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-masked]
http://www.irtf.org/mailman/listinfo/rrg

---

From: Steven Blake <[email-masked]>
Date: Fri, 18 Jun 2010 15:20:15 -0400

On Fri, 18 Jun 2010 14:44:49 EDT, [email-masked] wrote:

> go far beyond the objectives of ILNP. Not long ago, Lixia asked for
them,
> I  

> University teachers have ever imagined to be possible.

[snip]

> E.g. algorithm to compute (consistently/ identical) well-skimmed  

Heiner, please send a pointer to an internet-draft/journal
article/whitepaper describing TARA.

Speaking only for myself, I'm not interested in or willing to reverse
engineer your scheme based on a long series of cryptic emails distributed
over time.

[snip]

> A subnetwork IS a location.

Ran is talking about location within a network's topology graph.  You seem
to be talking about location in terms of geographic coordinates, correct?

>> or more precisely the nodes located  in the neighborhood.

If by "neighboring" you mean physical proximity, it's not clear to me why
that is practically useful.  What good is knowing that two nodes are 100
meters apart if they are each attached to separate networks whose closest
peering point is 1000 km away?

Regards,

// Steve