Subject: [rrg] Issue #1 from Heiner Hummel

From: RJ Atkinson <[email-masked]>
Date: Wed, 16 Jun 2010 14:00:14 -0400

Earlier, Heiner Hummel wrote:
> draft-rja-ilnp-intro-03, Section 1, Page 4, says in part:
> % The high-order 64-bits of the IPv6 address become the Locator.
> % The Locator indicates the subnetwork point of attachment for
> % a node.  In essence, the Locator names a subnetwork.  Locators
> % are also known as Routing Prefixes.
> 
> Yes, this was all that I had found before asking my question.
> Now Tony tells me, it is simply the IPv6 address space.

Tony's response is fine, if slightly imprecise, but apparently 
his comment was made with respect to ILNPv6 rather than 
in general.  

(I mean "imprecise" above in that an IPv6 Address is a
128-bit object that includes a 64-bit routing prefix;
meanwhile an ILNPv6 Locator is a 64-bit object that
is a 64-bit routing prefix).

For ILNPv4, Locators are formed from IPv4 routing prefixes.

While the engineering of ILNPv4 and ILNPv6 are necessarily
different (in order to be backwards compatible with IPv4
and IPv6 respectively), the ILNP architecture is identical.

> What is here any better/different from LISP-2 ?
> 
> I am confused. This sounds like Karl Valentin.
> Though the left spotlight (IPv4) on a stage was down,
> he tried to repair the right one (IPv6).

Opinions vary on whether ILNPv6 will be widely deployed.
Opinions vary on whether ILNPv4 will be widely deployed.

ILNP is an architecture, that can be applied to a range
of networking protocols.  As an example, one could also
apply the ILNP architecture to OSI CLNP.

I've taken an action to more clearly describe how ILNP 
could be applied to IPv4 in my in-process editing of 
draft-rja-ilnp-intro.  I hope that will clarify any 
confusion.

Yours,

Ran

---

From: [email-masked]
Date: Thu, 17 Jun 2010 18:27:24 EDT

sorry for the mix up before
   
Ran, see my inserted responses below,
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.

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.

I submitted multiple emails pointing out that the attempt to aggregate is  
the cause of the problem.
Routing can be done much more efficient without building a 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. 
 
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.
 
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.
 
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.

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.

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

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.

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

Yours,

Ran

_______________________________________________
rrg  mailing  list
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg

---

From: [email-masked]
Date: Thu, 17 Jun 2010 18:34:24 EDT

In einer eMail vom 17.06.2010 21:55:19 Westeuropäische Sommerzeit schreibt  
[email-masked]:

On  17  Jun 2010, at 15:03 , Paul Jakma wrote:
> On Thu, 17 Jun 2010,  Tony Li wrote:
>> In order for ILNP to be backward compatible and  interoperable with 
legacy IPv6 hosts, it must use the exact same  namespace.
> 
> The exact same, or a subset?  Anyway..

Exactly the same.

Ran

Every potential solution MUST be backwards compatible, but this does not  
imply that it cannot come up with a different namespace. ILNP's dependency  
on using the current IPv6 namespace is rather a reason for being grounded 
than  for flying (that's what RFC4984 expresses too).
 
Heiner