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

From: [email-masked]
Date: Fri, 18 Jun 2010 02:37:00 -0400

Sorry for that; I hope this time it comes out clear
Heiner

in einer eMail vom 17.06.2010 14:48:16 Westeuropäische Sommerzeit schreibt [email-masked]:

On 17  Jun 2010, at 06:21 , [email-masked] wrote:
> I always thought you would come up with some
> hierarchical location value space when ILNP
> will be processed.

IP routing prefixes already are heirarchical, 
at least since CIDR was widely deployed 
(which almost 20 years ago at this point).

For IPv6 specifically, please see 
[RFC-4291, Section 2.5] and elsewhere.

So I'm confused by your statement above.

> Now I realize, you will (re)use IPv6-prefixes (restricted to 64  bits)

IPv6 routing prefixes are already restricted to 64-bits,
with the low-order 64-bits being an *interface* identifier.
[RFC-4291, Section 2.5.1 & elsewhere]

> that are uniquely assigned to so-called point of attachments
> of any particular ISP's subnetwork, right?

They might or might not be "any particular ISP's subnetwork",
depending a great deal on how one defines "ISP".

Purely as an example, the US Defense Information Systems
Agency (DISA) <http://www.disa.mil>; has direct allocations
of both IPv4 and IPv6 address blocks.  Different people
have different opinions about whether DISA is an "ISP".

On the one hand, DISA is a government agency, and 
its users (i.e. other US DoD activities) are required 
to use DISA for IP connectivity.  So some view DISA 
as analogous to the IT group for a very large enterprise.   

On the other hand, DISA bills other DoD organisations 
for their IP connectivity, and it provides transit services 
for its users, so other folks view DISA as an ISP.

> BTW, why prefix ? why not address of precisely 64 bits?

Hmm.  ILNP does not have addresses at all.  

An "address" is an object that has mixed ("overloaded") 
semantics.  An "address" is sometimes used for location 
(e.g. with IP routing) and other times is used for identity 
(e.g. in the TCP or UDP pseudo-header checksum).  

The entire concept of an "address" is deprecated with ILNP, 
in favour of separate Locator and Identifier objects, 
each having distinct and very crisp semantics.

> Hosts communicate via DNS their point-of-attachments' prefix
> (whereby  multiple hosts may share the same such prefix).

I find the sentence above confusing.  

I think the above might be trying to say that an ILNP node 
advertises its Locator value(s) via the DNS, which is 
precisely true, but incomplete.  An ILNP node will also 
use the ICMP Locator Update message to advertise changes 
to its working set of Locators to existing correspondents,
for example.

> All these point-of-attachment routers communicate
> to the outside that they have reachability to such a prefix.
> This is the same as what a BGP router is doing.
> I.e. this doesn't reduce the number of prefixes. 

Ah.  

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.

-------------------------
Heiner:
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
 
   Due to the increased IPv6 address size over IPv4, a full immediate
   transition to IPv6 is estimated to lead to the RIB and FIB sizes
   increasing by a factor of about four.  The size of the routing table
   based on a more realistic assumption, that of parallel IPv4 and IPv6
   routing for many years, is less clear.  An increasing amount of
   allocated IPv6 address prefixes is in PI space.  ARIN [ARIN] has
   relaxed its policy for allocation of such space and has been
   allocating /48 prefixes when customers request PI prefixes.  Thus,
   the same pressures affecting IPv4 address allocations also affect
   IPv6 allocations.
-----------------------

Today it is nearly impossible to aggregate much, simply
because upper-layer protocols, notably TCP and UDP, 
use the IP address -- including the upstream routing
prefix -- for identity.  ILNP eliminates this semantic
overloading inherent in today's IP address, permitting
high-availability multi-homing to different upstream
providers while also permitting significantly more
prefix aggregation than is possible today.

----------------
Heiner:
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).
-------------------

This was answered recently by several other folks,
notably Chris Morrow, who has extensive ISP experience.
I'll point to some of his previous notes here:

<http://www.ietf.org/mail-archive/web/rrg/current/msg06762.html>;

<http://www.ietf.org/mail-archive/web/rrg/current/msg06783.html>;

<http://www.ietf.org/mail-archive/web/rrg/current/msg06824.html>;

<http://www.ietf.org/mail-archive/web/rrg/current/msg06754.html>;

Several other folks, including tli, fred, and Joel Halpern
(all of whom have EXTENSIVE experience with Internet routing)
have also addressed this issue in the past. 

-------------------
Heiner
Non of them  ever raised his voice when I tried to fan a discussion about the truly
miserable routing paradigms applied in internet routing.
------------------

I don't want
to cite every prior note to the RRG list explaining this,
but as another example, this note from fred is quite clear:

<http://www.ietf.org/mail-archive/web/rrg/current/msg06755.html>;

> By assuming that today's network administrator do a good job while trying  
> to come up with reasonable prefixes, I cannot see what is the ILNP's 
> reduction  of prefixes to be spread all over.

I am sure I do not understand what the above is trying to say.

-------------
Heiner:
And I don't understand why you are so keen on building prefixes. TARA eliminates the scalability problem once and for ever AND: does need a single  prefix.
------------------

> A different syntactical point: 
> You camouflage your design by using the term locator although you do not  
> intend that to be a denotion of location.

Incorrect on two counts.

1) I am killing myself trying to be clear, which is rather
   the opposite of "camoflage".  

   (One might argue that your note indicates I am not fully
    succeeding in being as clear as I'd like, but I'm 
    certainly not 'camoflaging' anything.)

2) The Locator absolutely does denote location, and never identity.

> Granted, you just continue with this bad habit which indeed comes  from the 
> "loc/id"-split discussion, where also at no point in time "loc"
> expressed anything like location.

The ILNP Locator precisely specifies a subnetwork,
so it is precisely specifying a location.

> You hereby play foul to those who want location-based routing, because you  
> educate people to understand something else than a locator ought to mean.

Au contraire.  

My usage is both quite clear, and is also the long-standing 
usage in the Internet community.

---------------------
Heiner:
If a ghost driver on a highway calls out: the hell, there are hundreds of ghost drivers out there.
then he is most probably the ghost driver himself. You certainly think that I am the ghost driver myself.
Well, I agree, you stay within the IETF tradition. But I think that - apart from the IETF routing experts- everyone else
would agree that location is a question of WHERE and not of WHAT. I.e. where is this point of attachment instead of WHAT subnetwork is it.
--------------------

JNC has observed on this list in the past that the general 
usage of "locator", which is the same as with ILNP, goes back 
over 10 years now -- including to published RFCs from some
years back.  JNC has written several notes about this.

-------------------------
Heiner:
Well the huge number of false usage of the term locator does not make it any better.
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.
---------------------

Purely as an example, consider this note from him:
  <http://www.ietf.org/mail-archive/web/rrg/current/msg06842.html>;

> And you pave the ground such that people would get confused when someone  
> uses the word locator in its true meaning.

I have no idea what that is trying to say.

--------------------
Heiner:
I can give you an example: the TARA-locator would tell you WHERE that node is.
This is not only an immense win wrt the scalability problem but also in addition for IP mobility.
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 ?
---------------------

I will note that my usage is entirely consistent with 
the common usage within the Internet community.

> I am convinced that you would say NO if a straw poll statement states: "A  
> node's locator" denotes the location of that node".

Your crystal ball appears to be broken.

[Aside:  The Terminology Straw Poll (interim) results are public,
so folks can see my views about the terminology statements
that are on the table for the poll.]

> You provide (via DNS) a different way to learn about the mentioned prefix,  
> but that's it. I accredit to you that you won't worsen the stretch-of-path  
> behavior.

> You still do the same, only slightly changed. But you also won't improve  
> routing capabilities (extending to numer of alternative detours, 
> selecting the right alternative based on actual traffic sizes).

------------------
Heiner:
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
----------------

I don't understand those words either, terribly sorry.

Yours,

Ran

---

From: Ran Atkinson <[email-masked]>
Date: Fri, 18 Jun 2010 09:53:55 -0400

> Much earlier, Ran Atkinson wrote:

Afterwards, Heiner Hummel wrote:
> This is precisely the technique that led to the current situation. 
> Read also this (copied from RFC4984 IAB RAWS report):

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.
>  

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
> The entire CPU performance is eaten up by observing the current 
> reachabilities of the internet. This could be reduced to almost zero.

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