Short version:     I think we all agree about the definition of
                   "namespace".

                   I still hope to encourage someone to explain how
                   LISP could use separate namespaces for EIDs than
                   for RLOCs within the constraint that this form of
                   LISP is part of a practical scaling routing
                   solution: one which must be voluntarily adopted on
                   a wide scale, and therefore must be fully
                   functioning without any changes to hosts or to the
                   interdomain routing system.

Hi Noel,

You wrote:

>> The most notable document making frequent references (44 at least) to
>> "namespace" in ways which entirely accord with the definitions I found,
>> was Noel Chiappa in an unfinished draft of an I-D, which is nonetheless
>> cited quite frequently
> 
> I have to admit there's a certain droll humour in having _my own flipping
> document_ being cited to tell me I don't know what the hell I'm talking
> about...
> 
> But I see the irony has escaped you.

Not at all - I just didn't mention it.

I think you have a perfectly good understanding of what "namespace"
means.

However, I think you are mistaken if you support the view that LISP,
as a practical solution to the routing scaling problem, could involve
separate namespaces for RLOCs and EIDs.  (I know LISP could do this,
but not in a way which is part of a practical solution at the time of
introduction and in the years which follow.)

Neither you nor anyone else has yet described, by way of an example,
exactly what this "LISP involves separate namespaces for RLOC vs.
EID" claim means and why it is valid for a practical routing scaling
problem.  There are inferences about this in two current LISP I-Ds,
as noted at the end of:

   http://www.ietf.org/mail-archive/web/lisp/current/msg00273.html

This also links to an IETF Journal article which is explicit about
separate namespaces.  Also, two presentations currently linked to
from http://www.lisp4.net:

  http://www.lisp4.net/docs/lisp-crc-aam-workshop.ppt (2008-03)
  http://www.lisp4.net/docs/lisp-ripe-long.pdf (2008-05)

both state:

   Why Separate Location from ID?
     Level of Indirection allows us to:
       Keep either ID or Location fixed while changing the other
       Create _separate_namespaces_ which can have different
       allocation properties


This is the big distinction between LISP and HIP (and I guess some
other potential solutions to the routing scaling problem which also
involve separate namespaces for EIDs and RLOCs):

  HIP is not a practical solution because it requires hosts use
  a different kind of address for EIDs, involving a different
  namespace from what IPv4 or IPv6 hosts use today.  This requires
  modifications to hosts.  (For HIP to a practical solution for
  the routing scaling problem, first all existing hosts would need to
  be converted to IPv6, with the HIP extensions.  Then they would all
  need IPv6 connectivity - and their applications would need to be
  rewritten for IPv6 and I think for HIP.)

  LISP does not require separate namespaces: It can work nicely with
  both RLOCs and EIDs sharing the one namespace.  Therefore, it can
  be used with existing IPv4(6) hosts and the existing IPv4(6)
  interdomain routing system.

So LISP could be practical for widespread voluntary deployment while
HIP or any other system which requires a new namespace for EIDs
and/or RLOCs could never become useful without a wholesale upgrade to
all hosts and/or all DFZ routers.

As I wrote:

  http://www.firstpr.com.au/ip/ivip/namespace/

in your document:

  http://ana.lcs.mit.edu/~jnc/tech/endpoints.txt

    (BTW, I hope that site is stable, because this page seems to
     be cited by dozens of other documents, and other pages at this
     site are also frequently cited in discussion lists, papers,
     I-Ds etc.)

I counted 44 or so usages of "namespace", all of which accord with
the meaning you describe below, and which I have found is the only
meaning ever associated with the term in the context of computer
science and network addressing.  No other document I found in the
networking field comes close to this number of uses of the term
"namespace".


> An important defining characteristic of a namespace is the _semantics_ of the
> names, not just their _syntax_. Two namespaces may have similar syntax, but
> different semantics (e.g. disk block numbers and memory locations). 

This exactly accords with my understanding of "namespace" - and as
far as I can tell with everyone else's understanding, including
your's now and in the past.


> It is the difference in the semantics of legacy IPvN addresses,
> LISP EIDs, and RLOCs that make them separate namespaces, even
> though they are identical syntactically.

As I have argued before, and will argue again below, if LISP is to be
a practical solution to the routing scaling problem, it _can't_ use
separate namespaces for RLOCs and EIDs.

If a practical application of LISP to the routing scaling problem did
involve separate namespaces for RLOCs and EIDs, then it would be
possible for the one numeric address, such as 11.22.33.44, to be
usable as an RLOC and as an EID at the same time.

But this is impossible because for global communications, the ITR
needs to work within the IPv4 Global Unicast namespace for both
traffic packets (an EID usage of an address) and for getting packets
to ETRs (an RLOC usage of an address).

There's no way an ITR could emit a packet tunneled to 11.22.33.44 and
have it get to the destination RLOC while it regards 11.22.33.44 as
being an EID address.  The latter would involve it looking up the
mapping for 11.22.33.44 and encapsulating it to some RLOC address.


> Look, you don't like LISP. We get that. You think it's a bad idea. We get
> that. So why don't you go start your own WG, create your own documents, write
> your own code? Being obstructive about LISP is not doing anyone any good at
> all.

I do create my own documents and would be glad of some critiques, on
the RRG list:

  http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf
  http://tools.ietf.org/html/draft-whittle-ivip-db-fast-push-01
  http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw-01
  http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf
  (With Steve Russert.)

My critiques are well intentioned and constructive.  I am trying to
draw you and other LISP folks into genuine discussion and help other
people understand what I think are the limitations of the approaches
you have chosen.

I am not making broad-brush, disrespectful comments about LISP-ALT.
Nor am I ignoring it as unworthy of discussion.


Discussing these things helps me and hopefully other people
learn about scalable routing.  You or anyone else can point out why
my critique doesn't apply to LISP-ALT or why the critique is faulty
in its logic, value judgements etc.

My list of LISP critiques is not complete, but it is a good starting
point for people who want to understand LISP-ALT and the reasons why
some people, not just me, think it is not going to be the best or
even a practical solution to the routing scaling problem in anything
like its current form.

  http://www.firstpr.com.au/ip/ivip/lisp-links/


Please describe a situation in which LISP could be a practical
solution to the routing scaling problem in which LISP introduces
separate namespaces for EIDs and/or RLOCs: that is separate semantics
for the one individual name (the one particular IP address) with the
one address being usable as both an EID and an RLOC.



For the mathematically inclined, here is my argument about why LISP
or any other scalable routing system cannot be both practical (for
smooth adoption without completely revising the routing system and/or
all hosts) and use separate namespaces for RLOCs and EIDs.

Initially I will consider the IPv4 Internet, which is the only one
which matters at present, since it is the only one with global reach
and which 100% of all actually used hosts are connected to.  (Not
counting experimental networks.)

  1 - There are two aspects of the Internet which any potentially
      practical core-edge separation scheme such as LISP, APT
      or Ivip absolutely relies upon:

        a - The current behavior of all hosts.

        b - The current behavior of the internal and interdomain
            routing systems - especially the interdomain system,
            since it is conceivable that an ISP adopting the
            scheme could upgrade its internal system.


  2 - The current state of the IPv4 Internet is that all hosts
      and routers use the one address space: IPv4.  Broadly
      speaking we can think of this address space having a single
      namespace.  In fact, within the 2^32 address range, there
      are sections such as 10.0.0.0/8 where there is a separate
      namespace for each network which uses such addresses.  What
      really matters for any scalable routing solution is the
      "IPv4 Global Unicast" namespace.  This is because the
      only existing global IP network with universal host
      connectivity uses this namespace for all its off-site
      communications and for all its routing system.


  3 - A practical scalable routing solution can't be introduced
      by force or require upgrading all hosts or all the
      routers in the DFZ. (A possible exception to the latter
      restriction is [1].)


  4 - A practical scalable routing solution for IPv4 therefore
      must have its EID addresses be 100% compatible with
      existing hosts.  (At least for offsite communications.)


  5 - A practical scalable routing solution for IPv4 therefore
      must have its RLOC addresses be 100% compatible with
      existing DFZ routers.


  6 - Since both the DFZ and all existing hosts rely on the
      IPv4 address range and, for all offsite communications,
      use this address range according to the IPv4 Global
      Unicast namespace, it follows that any practical
      scalable routing system must have both its RLOC and
      EID addresses using the same IPv4 Global Unicast namespace.

Of course the technology of LISP or APT or Ivip or whatever could be
used for other purposes, including separate namespaces for RLOCs and
EIDs.  Also, over time, it is possible and probably desirable for the
scheme to be able to support separate namespaces.  However, during
introduction (say 10 years or more) it is absolutely essential that
the RLOC addresses and EID addresses work with all hosts and all DFZ
routers, which means they both must use the same IPv4 Global Unicast
namespace.

It so happens that there is another network which is potentially
capable of being used by hosts and for ITR <--> ETR communications:
IPv6.  It is far from being available to all ISPs, and it is only
used by a tiny fraction of hosts.

A scalable routing solution could use IPv6 DFZ communication between
ITRs and ETRs when carrying packets addressed to IPv4 EIDs.  This
would be an instance of using separate namespaces for:

   EID:   IPv4 Global Unicast namespace
   RLOC:  IPv6 Global Unicast namespace

However, this must be an option and cannot be assumed as part of the
introduction of the scalable routing system.  The scalable routing
system needs to be easily adoptable for all ISPs.  Not all ISPs use
IPv6.  LISP requires the ETRs and ITRs to be run by the end-user
network, and not every end-user network necessarily wants to be
messing with IPv6 either.

AFAIK, there is no advantage whatsoever in using IPv6 for RLOCs.
Every ISP which could use IPv6 already has IPv4 - and for a long time
there would be no problem finding a few RLOC addresses for every
end-user network which adopted LISP.

So you *could* use LISP with separate namespaces for RLOCs and EIDs -
but only as an option, with no obvious benefit.  These separate
namespaces are not the creation of LISP, it is just a choice to use
two separate networks, with two separate global unicast namespaces.

Likewise, LISP, or any other scalable routing solution, could carry
traffic packets addressed to IPv6 EIDs using IPv4 RLOCs.  As above,
it would need to be an option, rather than a requirement of the basic
system for mass voluntary adoption.  In this case, there could be an
advantage, since it would enable an end-user network to communicate
with IPv6 without a native IPv6 connection, (assuming there were
well-placed IPv6 PTRs able to tunnel to the IPv4 RLOC ETRs in its
network.


You could easily invent some other namespaces for RLOCs and/or EIDs.
However, for LISP to be practical (widely voluntarily adopted
without the need to change hosts or the DFZ routers), those
namespaces are of no use at all.  LISP as a practical solution to the
routing scaling problem, there are only two "global" networks which
matter (and IPv6 is only potentially global).  The namespaces used in
these two networks are:

  IPv4 Global Unicast namespace:  All DFZ routers and all hosts -
                                  AKA the IPv4 Internet.

  IPv6 Global Unicast namespace:  Some DFZ routers and a few hosts -
                                  AKA the IPv6 Internet.


If you think my critique is wrong, please explain why.

  - Robin



[1]  It is possible (I think highly likely) that by the time we
     really need a scalable routing solution for IPv6 that there
     will have been time to upgrade all DFZ routers to implement the
     IPv6 version of Modified IP Header Forwarding:

       http://www.firstpr.com.au/ip/ivip/ivip6/

     Maybe we could upgrade the DFZ and some other routers in time
     for introducing an IPv4 scalable routing, according to:

       http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw

     Doing so would save a lot of complexity in ITRs and ETRs, since
     there would be no PMTUD problems to solve.  Also, these
     approaches involve no encapsulation overhead.