Subject: Re: [lisp] LISP does not involve separate namespaces

From: [email-masked] (Noel Chiappa)
Date: Wed, 29 Jul 2009 23:15:36 -0400 (EDT)

> From: Robin Whittle <[email-masked]>

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

Exactly.

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

    > This includes any end-user network where a mobile device might have its
    > care-of address.

LISP Mobile does not have care-of 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.

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

	Noel

---

From: Robin Whittle <[email-masked]>
Date: Thu, 30 Jul 2009 22:54:58 +1000

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,

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

OK!

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

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

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

> 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,

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

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 30 Jul 2009 06:31:38 -0700

> Short version:  "RLOC" and "EID" are not, and never have been,

Let me give you an example where EIDs and RLOCs are separate namespaces.

Today, the LISP test network uses 2610:00d0::/32 as a global unique  
EID-prefix. IPv6 sites will have devices assigned from this global  
prefix. This is a PI-prefix because it is not assigned to any service  
provider. This prefix is not injected into the underlying routing  
system, be it the /32 itself or any more specifics.

RLOCs will be assigned out of the 2002::/16 (among possibly other high- 
level prefixes). They can be PA-assigned prefixes. They will be  
assigned to the LISP ETR CE/PE link. They will appear in locator-sets  
of LISP map-cache entries.

So, architecturally, the 2 address spaces are separate and can  
implemented that way. It could be desirable to have an EID address out  
of the 2002::/16 space or a RLOC address out of the 2610:00d0::/32  
space. But it may not be needed with such a large address space.

For IPv4, life is harder because of the vast install base, so the  
clear separation is harder to appreciate. But you could have the same  
address assigned from each namespace.

Just an FYI, in the prototype implementation, we use another VRF  
called "the LISP VRF" which stores solely EID-prefixes so we can  
operate the BGP-ALT in this namespace. And the default VRF has both  
namespaces so you can run underlying BGP at the site as well as having  
EID-subnets in your IGP.

Dino

---

From: Scott Brim <[email-masked]>
Date: Thu, 30 Jul 2009 15:42:34 +0200

Dino Farinacci allegedly wrote on 07/30/2009 15:31 GMT+02:00:
> For IPv4, life is harder because of the vast install base, so the clear
> separation is harder to appreciate. But you could have the same address
> assigned from each namespace.

Suppose a nameserver or some other piece of critical infrastructure is 
in RLOC space, and an endpoint wants to talk to it.  What happens?  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?

Scott

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 30 Jul 2009 06:54:08 -0700

>> clear
> Suppose a nameserver or some other piece of critical infrastructure  
> is in RLOC space, and an endpoint wants to talk to it.  What  
> happens?  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?

The ALT tells you if the destination is in EID space or RLOC space.  
But that is not sufficient. You have to consider other cases based on  
the source address of the packet.

If the source address of the site host is not from a list of  
configured EID-prefixes for the site, the ITR "natively forwards" the  
packet (which means it does not encapsulate it). So this would be RLOC- 
to-RLOC communication. If the source address of the site host is from  
a list of configured EID-prefixes for the site, the ITR will natively  
forward based on the first paragraph above. So this would be EID-to- 
RLOC communication.

When an ITR is not attached to the ALT, which is the default setting  
for a LISP site router (because we want it to be as low-opex as  
possible), it will have "negative cache entries, which are coarse  
prefixes that reside in the map-cache, with an action of "natively  
forward". The map-resolver sends these "negative Map-Replies" when it  
finds out that the destination of a Map-Request is not in the ALT.

The negative cache entries are very coarse so we can keep the smallest  
number as possible in the map-cache. I have included some "show ip  
lisp map-cache" output from an ITR on the LISP test network. Notice  
the bit patterns and prefix mask-lengths used based on a single EID- 
prefix block of 153.16.0.0/16 allocated to LISP sites.

Dino

----

LISP IP Mapping Cache for VRF "default", 9 entries

0.0.0.0/1, uptime: 1d07h, expires: 23:54:43, via map-reply
   Negative cache entry, action: forward-native

128.0.0.0/4, uptime: 1d06h, expires: 23:54:43, via map-reply
   Negative cache entry, action: forward-native

152.0.0.0/8, uptime: 20:26:25, expires: 03:33:34, via map-reply
   Negative cache entry, action: forward-native

153.16.10.0/24, uptime: 1d07h, expires: 23:58:49, via map-reply, auth
   Locator          Uptime    State     Priority/Weight  Data|Control  
in/out
   xxx.xxx.xxx.xxx  1d07h     up        1/50             0/0  |  909/910
   xxx.xxx.xxx.xxx  1d07h     up        1/50             0/0  |  910/910

153.16.19.0/24, uptime: 1d02h, expires: 23:58:49, via map-reply, auth
   Locator       Uptime    State     Priority/Weight  Data|Control in/ 
out
   xxx.xxx.xxx.x 1d02h     up        5/100            3/4  |  3065/3066

154.0.0.0/7, uptime: 06:58:14, expires: 17:01:45, via map-reply
   Negative cache entry, action: forward-native

160.0.0.0/3, uptime: 06:50:32, expires: 17:09:27, via map-reply
   Negative cache entry, action: forward-native

192.0.0.0/3, uptime: 06:49:30, expires: 17:10:29, via map-reply
   Negative cache entry, action: forward-native

----

---

From: Robin Whittle <[email-masked]>
Date: Fri, 31 Jul 2009 11:32:20 +1000

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:

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:

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