Hi Tony,

Do you think ILNP can be widely enough deployed in the IPv4 Internet
to solve its scaling problem?  If so, how could this be true since a
dual-homed network would chew 3 times the amount of global unicast
space it actually uses?

I understand you don't care at all about solving the IPv4 scaling
problem (msg06192 2010-03-08), but most other people do.  Your and
Lixia's current text:

   We recommended ILNP because we find it to be a clean solution for
   the architecture.  It separates location from identity in a clear,
   straightforward way that is consistent with the remainder of the
   Internet architecture and makes both first-class citizens.  Unlike
   the many map-and-encap proposals, there are no complications due
   to tunneling, indirection, or semantics that shift over the
   lifetime of a packets delivery.

implies that there is a single "architecture".  Yet the IPv4 and IPv6
Internets have significant differences, whether these are
characterised as "architectural", "practical" or whatever.

Your "clean solution" and lack of mention of any complications would
lead readers to believe that ILNP is useful for solving the IPv4
scaling problem.  But it isn't.


You wrote:

>> When revising your text, can you add something to indicate that ILNP
>> is not suitable for widespread adoption in IPv4?
> 
> This seems like this is more suitable for the section on the ILNP critique.
> Perhaps you should collaborate with those authors?

In early January I wrote critiques of ILNP to the list and then tried
to collaborate with Joel.

On 7 and 8 January I corresponded extensively with Joel on what he
would put in the ILNP critique he was preparing, and which became the
critique in the current RRG draft report.  As far as I know, my
efforts did not result in any change to what he wrote.

In that correspondence I didn't mention that ILNP wouldn't be useful
for IPv4 because I considered this to be an obvious fact which was
not in dispute.

A problem with some of the critiques in the draft RRG report is that
they were written by people who were either part of the proposal
project, or who supported it.  This, and the 500 word limit, means
there's reason to believe these critiques may not mention all
concerns anyone has about the proposal.  I am not sure that Joel
previously indicated his support for ILNP, but today in (msg06526) he
wrote that he supports your recommendation - so I guess that means
that now, at least, he supports ILNP.

Below my signature are links to the 7 list messages in which I
mentioned the fundamental problem of ILNP - or CEE (Locator /
Identifier Separation) architectures in general not being suitable
for IPv4 due to their wastage of global unicast address space.

Ran (msg06487) asserts he has already answered this critique - but he
hasn't.


 - Robin




  http://www.ietf.org/mail-archive/web/rrg/current/msg05610.html
  2010-01-06   ILNP critique 4

                 Splitting the 32 bits into 16 bit sections for
                 Locator and Identifier obviously results in too few
                 of one, the other or both.

                 There are no details of how ILNP would work with
                 IPv4.


  http://www.ietf.org/mail-archive/web/rrg/current/msg05865.html
  2010-01-01   CES & CEE are completely different (graphs)

                 ILNP is a CEE (Locator / Identifier Separation)
                 architecture.

                 "CEE can't be useful for IPv4, since multihoming a
                 /18 network would require a /18 of PI space from
                 one ISP and another /18 from another ISP.   So it
                 would at least double address consumption."  (This
                 should be "triple".)


  http://www.ietf.org/mail-archive/web/rrg/current/msg06125.html
  2010-02-25   Re: [rrg] Various misunderstandings - ILNP; CEE/CES;
               Loc/ID Sep. = "revolutionary"

                 "will never be practical as a routing scaling
                 solution for IPv4 because multihoming a network
                 with X IPv4 addresses requires X other IPv4
                 addresses for each of the two or more ISPs.


  http://www.ietf.org/mail-archive/web/rrg/current/msg06162.html
  http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html
  2010-03-04/08   Recommendation suggestion from RW/(v2)

                 "This doubling or more of each end-user network's
                 address requirements is one of the reasons CEE
                 architectures are impractical for IPv4."


  http://www.ietf.org/mail-archive/web/rrg/current/msg06250.html
  2010-03-11   Re: [rrg] Why won't supporters of Loc/ID Separation
               (CEE) argue their case? (Summary of differences)

                 "CEE architectures are only practical for IPv6, for
                 multiple reasons but always including the fact that
                 CEE requires each multihomed end-user network to use
                 at least twice the number of addresses (host
                 locators) from the global unicast address space.
                 Each of its ISPs needs to provide the number of
                 addresses the network needs.


  http://www.ietf.org/mail-archive/web/rrg/current/msg06473.html
  2010-04-20   ILNP cannot provide scalable routing benefits for IPv4

                 For each dual-homed end-user network with S global
                 unicast IP addresses, the system requires a total of
                 S*3 global unicast IP addresses:

                   S IP addresses for the hosts in the end-user
                     network

                   S IP addresses for the PA prefix from ISP-A

                   S IP addresses for the PA prefix from ISP-B

                This is impractical for widespread adoption, given
                the IPv4 address space shortage.


_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg

Reply via email to