I am replying to 5 sequential messages here - 2 from Dino, 2 from
Noel and 1 from Scott.

Dino's message:

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

2610:00d0::/32 and 2002::/16 are two separate subsets of the set of
addresses which are global unicast.  There is nothing about these
which accords with the definition of "namespace" Noel and I agree on:

  msg00748:

  RW:  A namespace is a context within which a number or name is
       interpreted.

  NC:  Exactly.

Dino - what is your definition of "namespace"?

When an ordinary router receives a packet with a destination address
matching either of these prefixes, it doesn't have any concept of
LISP or of the EID or RLOC role the address may be playing.

With Mobile LISP, the destination address could be in an RLOC role
(of the MN's internal ETR function) at the same time as being in an
EID role since it is a LISP-mapped EID address.

So there is no such different interpretation of addresses in these
prefixed by ordinary routers.

Nor would an ITR which supports Mobile LISP treat them any differently.

If an ITR receives, or generates within itself (as in Mobile LISP), a
packet with an address which the mapping system returns one or more
RLOCs for, then it will encapsulate the packet with one of those
RLOCs as the destination address of the outermost header.

So these are just subsets of the global unicast address space.
Before Mobile LISP they were non-overlapping (disjoint) subsets.
Now, with Mobile LISP, they are potentially overlapping sets.  These
sets - the fact that an address could be playing an EID and/or an
RLOC role - have nothing at all to do with separate namespaces.



Noel wrote:

  RW: > "RLOC" and "EID" are not, and never have been, separate
      > namespaces.

  Yes, that's why we don't need a translation service to map from one
  to another. Got it.

Rather than just blowing me off, please respond to my messages
msg00747 and msg00751 by showing in detail how LISP, as currently
defined or as it could be introduced in any practical manner,
involves separate namespaces for an address depending on the EID or
RLOC role it is playing.

There no such thing as translation from one namespace to another.

There is no translation between namespaces for the Cisco phone number
526-4000.  That number on its own is useless unless you happen to be
calling from close to Cisco's head office.  The namespace within
which this number can be interpreted to identify the Cisco head
office phone service is the US area code (400) namespace.

There is no such thing as translating the meaning which 526-4000 has
in the (400) namespace into an identical, similar or related meaning
in the (399) namespace, the (401) namespace or any other namespace.

RLOC and EID are roles an address can play within the LISP system.
Sometimes an address plays both roles, as does the YY address in
msg00751.


Scott wrote in msg00747, responding to Dino:

> How does the endpoint's site network, or xTR, tell whether the
> destination address is an RLOC or an EID if the address spaces
> overlap?

Before Mobile LISP, and as LISP as currently defined by
draft-farinacci-lisp-12 EID and RLOC address spaces are disjoint sets:

  EIDs MUST NOT be used as LISP RLOCs.

therefore, it would be possible for an xTR (ITR or ETR) to determine
which set a given address YY falls into.  It would do this by sending
a map request for YY.  If it receives mapping, then YY is an EID.  If
not, YY is an RLOC.   Before Mobile LISP, if a packet was addressed
to an EID, then the ITR would encapsulate it.  Then, since the
resulting outer header was and RLOC address, and since an RLOC
address could not also be an EID address, there was no need to
examine the packet further.  So the ITR simply forwards it.

With Mobile LISP, the set of addresses which are playing an EID role
can overlap with the set which are playing an RLOC role.  So there is
no clear notion of an address being "an EID" or "an RLOC".

An address might be playing the EID role in one relationship and an
RLOC role in another.  Please see my attempt to explain how Mobile
LISP works, with addresses XX, YY and ZZ in the double-encapsulation
system, in msg00751.

YY plays both roles at once.  It is a member of both the EID and the
RLOC subsets, which overlap.

There is no separate namespace for handling addresses which are
playing one role or another.  Ordinary routers treat packets just the
same, oblivious to LISP and the role the destination address might be
playing in various parts of the LISP system.

ETRs treat them just the same.  If an ETR receives a packet with the
outer destination address matching one of its ("RLOC") addresses, it
strips off that outer header and then processes the packet according
to the next header.

ITRs treat them just the same.  If an ITR receives, or generates
within itself, a packet with YY as the destination address, it looks
up the mapping for YY.  It makes no difference whether or not YY was
playing the RLOC role for an ETR which happens to be the internal ETR
function of a MN.  If the ITR receives mapping for YY, this tells it
that YY is part of the set of addresses which are playing an EID
role, so it encapsulates the packet with another set of headers (IP,
UDP and LISP) with an outer destination address selected from the one
or more "RLOC" addresses returned in the mapping.

None of this involves separate namespaces.


Noel wrote in msg00755:

> People seem to be forgetting the words 'incremental' and
> 'practical' here.  Yes, if we were doing a 'clean sheet' design, we
> could make a clear separation between the two. HELLO! We don't have
> that luxury. Some ugliness is therefore inevitable.

>From the perspective of architectural purity, I agree, ideally we
would have separate namespaces so we could re-use the entire global
unicast address space in an "RLOC" role without upsetting the
existing "EID" role.

On this basis, not having separate namespaces for addresses being
used in these roles is indeed "ugly".  On this basis, HIP is
beautiful and LISP, APT, Ivip and TRRP are ugly.


The routing scaling problem is a practical matter involving billions
of dollars and the capacity of the Internet to work efficiently -
including matters of economics, address space utilisation and access
for new entrants.  Billions of people depend on the Internet for
business, interpersonal, emergency and political communications.  The
Internet is of vast practical value.

As an academic exercise, the routing scaling problem probably would
be best solved with a clean-slate design, separate namespaces or
whatever.

Our task is a practical one, and the constraints imposed by the need
for very widespread voluntary adoption:

  http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/

mean that practical considerations are more important than
theoretical ideals.

LISP, APT, Ivip and TRRP all share the important attribute that they
can work with all devices - existing hosts and routers - continuing
to use the same single namespace for interpreting the meanings of
addresses which are used in both the RLOC and EID roles.  HIP can't
do this.

I am sure there could be a version of LISP with separate namespaces
for the EID and RLOC functions.  However, this would have nothing to
so with LISP as a potentially practical solution to the routing
scaling problem, which is what we are discussing on this list.

With billions of dollars and the fate of one of humanity's greatest
creations at stake, the fact that LISP, APT, Ivip, TRRP and any other
core-edge separation scheme does not involve separate namespaces for
EIDs and RLOCs is *beautiful*.


Dino, in msg00756, demonstrates how an ITR treats destination
addresses the same way irrespective of whatever EID or RLOC role they
may be playing in some part of the LISP system.  (I am assuming here
that the ITR supports Mobile LISP.)

The prefixes which are flagged "Negative cache entry" are flagged in
effect: "Don't bother looking up the mapping for any address which
matches this prefix - the ITR has already been told there is none.
Therefore, treat this address as if it is playing an RLOC role and
forward the packet, as it is, to the destination".

Prefixes which have "Locator ..." are in effect: "Any destination
address matching this prefix will be regarded as an EID by the ITR,
and so its packet will be encapsulated, with the outer destination
address being one of the "RLOC" addresses (xxx.xxx.xxx.xxx in Dino's
listing) which have already been cached from a previous map request.

If a packet arrives, or is generated internally, with a destination
address which does not match any of the prefixes in the cache, then
the ITR will request its mapping and a new entry will be added to the
cache.  Then, it will treat the package as described in one of the
two previous paragraphs.

The ITR doesn't know or care whether the destination address is
playing an EID or an RLOC role.  There is no separate namespace for
EIDs and RLOCs.

  - Robin