Short version:  "RLOC" and "EID" are not, and never have been,
                separate namespaces.

                They are two sets into which addresses may be
                classified, where the addresses are all interpreted
                according to the one namespace: that which applies
                to the set of addresses known as global unicast.

                Before LISP Mobile, and still according to
                draft-farinacci-lisp-12, "RLOC" and "EID" are
                disjoint sets.

                LISP Mobile can use one address as both an EID and
                an RLOC, so these sets are no longer disjoint, but
                are potentially overlapping.

                LISP and the other core-edge separation schemes do
                not involve separate namespaces for the RLOC and EID
                addressing functions.  If they did (as HIP does) then
                we would not be able to have them voluntarily
                deployed on a wide enough scale to solve the routing
                scaling problem.


Hi Noel,

Thanks for your speedy response, in which you wrote:

> > A namespace is a context within which a number or name is interpreted.
> 
> Exactly.

OK!


> > the remainder of the global unicast space cannot be used for routing
> > packets in the BGP core. 
> 
> Not necessarily.
> 
> LISP is a long process, and things that are true at one phase are not true at
> another. Remember the big debate some months back about whether a LISP EID
> was a 'true' EID or not? Well, now, with LISP Mobile, they are (i.e. the
> LEIDs of mobile nodes contain absolutely no location information whatsoever).
> 
> So I expect that some day we may well see instances of the same 32-bit number
> being the RLOC of one place, and the EID of a host somewhere else.

An example of this appears in draft-meyer-lisp-mn-00.  Please see my
previous message which is a critique of this I-D:

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

The ITR encapsulates a traffic packet so it will be tunneled to and
ETR function of the MN, which can be on an EID address.  If so, then
the ITR adds a second layer of encapsulation so the resulting packet
is tunneled to the ETR of the LISP site to which this EID prefix is
currently mapped.

    Header 3:  To ZZ, the ETR at the ISP which is being used by the
               LISP end-user network within which the MN is currently
               located.

    Header 2:  To YY, the MN's address within that LISP end-user
               network.

    Header 1:  The original packet - to XX, the MN's own EID address.

Here the one address YY is used in both an EID role and an RLOC role:

   1 - As the RLOC address of the MN's ETR function: that is, YY is
       the address at which the MN is currently located - which in
       this example happens to be in an end-user network network
       which is using LISP-mapped EID space.  (This would generally
       be known as the MN's Care-of Address, but this terminology
       is not used in the LISP-MN draft.)

       The ITR got this address YY by looking up the mapping for
       the MN's own EID address: XX.

   2 - YY is used as an EID because the MN's current address is
       within a LISP-mapped EID prefix.

       The ITR looks up its mapping for this and from that
       mapping decides on a particular ETR address to which this
       packet must be encapsulated.  This is the ETR address
       of the ISP the LISP site is using - an RLOC address ZZ.


> > This includes any end-user network where a mobile device might have its
> > care-of address.
> 
> LISP Mobile does not have care-of addresses.

OK - but it has an address on the network to which it is currently
attached.  In mobile IP the same concept is known as a "care-of
address" and I suggest this be used in Mobile LISP too.  MNs will
often have multiple care-of addresses (or whatever you want to call
them) on multiple networks.  For instance the MN could have an
address on a 3G network and another via WiFi to a completely
different network.  Some of these addresses will be on RLOC addresses
and others on EID addresses.


> > how can a LISP MN act as its own ETR without an RLOC address of its
> > own? 
> 
> It has an RLOC: whatever IPvN address it has been assigned by DHCP, etc, on
> the network to which it is currently attached.

As I mentioned in my critique, Mobile LISP can't work with the MN on
an address behind NAT.


> > If the MN is in an end-user network, and that end-user network is using
> > EID addresses .. then its address can't be within an RLOC prefix.
> 
> If a LISP MN is behind an existing xTR (e.g. at a site boundary), then
> packets to it from elsewhere in the network have to be
> double-LISP-encapsulated when the arrive at the site's ETR (i.e. by the
> encapsulating ITR). The site xTR strips the first layer, and then the xTR in
> the LISP MN strips the second. 

I have now read and commented on the LISP Mobile I-D.  I had not
anticipated that anyone would propose double encapsulation.


> I'm not sure if this is covered in the draft,
> but it happens pretty naturally: the EID maps to an RLOC which happens to be
> an EID (i.e. there's a valid mapping for it), and gets mapped and
> encapsulated again.
> 
> (This is an instance of a circumstance where the two namespaces do in fact
> overlap. There is some complex hair I won't go into where if 'core' RLOCs are
> being allocated out of a namespace with another syntax, e.g. some new
> variable-length locator-spare, the source ITR can tell when it can stop
> looking up the RLOC, on the offchance it's also an 'EID', because RLOCs with
> that syntax cannot be an EID, but that's a long way down the road so I'm
> going to ignore it for now.)

OK.

I think you are using the term "namespace" far too loosely.

A few days ago, you wrote:

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

    The scalability of LISP fundamentally derives from the addition
    of a new namespace (or, to be a tad more precise, splitting an
    existing namespace - addresses - into two separate ones: routing
    locators, and endpoint identifiers); and there is a layer of
    binding (i.e. associations of names from one namespace to names
    in the other) between the two namespaces.

A namespace cannot be split.  It is a context by which the meaning of
a number or name is evaluated.

The set of addresses to which a namespace applies can be split, but
the result is not separate namespaces - it is just separate subsets
of numbers within the original namespace.

The set of numbers 0000 0000 to 9999 9999 has a particular set of
meanings in the namespace of the Australian 03 telephone area code
(Victoria and Tasmania).

We can split this set of numbers in various ways.  For instance, we
can split it numerically, such as all the numbers starting with 7,
all the numbers starting with 8 etc.

We could also split this set it into subsets according to whether the
number referred to an active telephone service or not.  That subset
could be further split into subsets for homes, business and
government etc.

None of these subsets are to be interpreted by separate namespaces.

They are all interpreted according to a single namespace: the logic
by which numbers in the 03 part of the Australian telephone number
system are interpreted.

There is another namespace for 8 digit numbers which are within the
Australian 02 area code (New South Wales - daft name for an
Australian state 38 times bigger than Wales . . .)

A particular number/name 3344 5566 has one meaning in the 02
namespace and another, completely separate and independent, meaning
in the 03 namespace.

With Mobile LISP, even when the MN's internal ETR function is on an
EID address, that address is still interpreted according to one
namespace by which all global unicast addresses are interpreted.

However, it is used for two purposes:

  Firstly, it is used as an address of an ETR.  In that case, we
  think of it as an RLOC.

  Secondly, it is used as the address of something where that
  address is mapped by the LISP mapping system, and the system
  returns an "RLOC" address (rather than a response saying it is not
  mapped).  In this case, the address is being used as an EID.


When LISP was designed, and still according to the latest version:

  http://tools.ietf.org/html/draft-farinacci-lisp-12

it was not contemplated that any address would be used for both roles
at once.  Consequently, there is an edict to this effect:

  EIDs MUST NOT be used as LISP RLOCs.

This will need to be revised in order to be compatible with
draft-meyer-lisp-mn-00.

The original LISP arrangement was not separate namespaces for RLOCs
and EIDs - it was simply separating the set of addresses which the
global unicast address space applies to into two separate subsets.
Any address which is used as an EID is a member of the "EID" set and
is prohibited from being used as an RLOC, so it can't be in the
"RLOC" set.

Now, with Mobile LISP, "EID" and "RLOC" become descriptions of roles
which an address could perform.

An address YY can be the RLOC of XX when XX is being used in its EID
role.  The same value YY can be used an EID role, for which an
address ZZ is the RLOC of YY.

I think it is neither accurate nor helpful to portray these separate
roles or sets as separate namespaces.  To do so would degrade the
important and otherwise clear meaning of "namespace" and/or present
LISP in a confusing and inaccurate manner.

When an ITR gets mapping for a packet's destination address and
therefore encapsulates the packet, it will at that point be using the
inner (original) destination address as an EID and the results of the
mapping lookup, for the outer destination address, as an RLOC.

An ITR will always find a mapping for, and therefore will
encapsulate, any packet whose address is within the EID subset of the
 global unicast address space.

There is no separate namespace.  All packets are treated the same
way.  If they arrive at or are generated within the ITR their outer
header's destination address is examined to see whether the mapping
system returns an RLOC.  If it does, the packet is encapsulated with
that RLOC address as the outer header's destination.

Before the LISP Mobile I-D, and still according to
draft-farinacci-lisp-12, these subsets of the set of global unicast
addresses:

   RLOC     EID

were disjoint sets.

Now, according to LISP Mobile, they are potentially overlapping sets.

They are not separate namespaces.

When a router or an ITR processes a packet with a given address NN in
the destination field, it always does the same thing.  There is
nothing to say "interpret this as an EID" or "interpret this as an
RLOC".  (If there was, and if the ITR's behavior for NN changed as a
result, then there would be separate EID and RLOC namespaces.)

In all cases ordinary routers forward packets according to the
destination address.

In all cases the ITR looks at the destination address and if it can
find mapping for that address as an EID, then it will encapsulate the
packet.

While it is technically possible to use an IPv6 RLOC address to
tunnel a packet which is addressed to an IPv4 EID, this is not
separate RLOC and EID namespaces, since the number ranges of IPv4 and
IPv6 are incompatible.

Here is how LISP could have separate namespaces for EIDs and RLOCs,
using IPv4 addresses in the example.

   44.55.66.77 when interpreted according to the EID namespace
   identifies a particular host.

   44.55.66.77 when interpreted according to the RLOC namespace
   identifies an ETR address, which has no relationship whatsoever
   with the host just mentioned.

   This would be handy, since the entire set of global unicast
   addresses could be devoted to EID purposes and the same set could
   be used independently as RLOCs to identify billions of ETR
   addresses.

However, to implement this, every router, including every DFZ router,
would need to be modified to somehow identify the packets and decide
which namespace within which to interpret the destination address.
This could be done by looking past the IP header, finding a UDP
header of the right sort and then finding a LISP header.
Alternatively, the IPv4 header format could be changed to tell each
router which namespace to use.

This would be great except . . . . except we would have to
re-engineer every router in the world before LISP could be used.

The most important thing about the core-edge separation schemes
(LISP, APT, Ivip and TRRP - maybe SixOne Router too) is that they do
NOT use separate namespaces for identifying hosts and ETRs.  This
means they can be deployed globally without altering IP packet
formats or modifying all routers.  Also, there is no need to modify
hosts.

HIP has separate namespaces.  It only works with modified hosts.  HIP
cannot be a solution to the routing scaling problem, because we need
a system which can be introduced widely on an entirely voluntary
basis.  This rules out any system which only works with upgraded
hosts, such as HIP.

The requirement for widespread voluntary adoption may also rule out
any system which requires upgrades to all DFZ routers.  However I
remain optimistic that the alterations to packet formats and DFZ
router functions I suggest in draft-whittle-ivip4-etr-addr-forw-01
and especially http://www.firstpr.com.au/ip/ivip/ivip6/ could be
introduced easily before Ivip is deployed.


I tried to formalise these constraints due to the need for voluntary
adoption:

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

no-one seemed to have a significant disagreement with them.

 - Robin