Subject: [RRG] Not separate namespaces: Loc-ID-separation, map-encap etc.

From: Robin Whittle <[email-masked]>
Date: Fri, 27 Jun 2008 10:17:15 +1000

Hi Dino,

In a recent message in the "Long term clean-slate only for the RRG?"
thread, you wrote, in part:

> The sort of management issues I see what LISP are:
>
> 1) There is a new namespace.
> 2) There is encapsulation.
> 3) There is a mapping database.

Map-encap (map and encapsulate) schemes including LISP, APT, Ivip
and TRRP are often referred to as "Loc-ID-Split" or "Locator -
Identifier Separation" schemes or similar.

I think that "Split" and "separate" on their own are valid terms for
the concept of having a subset of the IPv4/6 addresses managed by
the map-encap scheme as Identifier space ("EID" - Endpoint
IDentifier in LISP).

But I am sure there is no new namespace in LISP or any other
map-encap system.

In a map-encap system, some IP addresses refer to address space
which is managed conventionally by BGP.  LISP terminology for this
is "RLOC" space.  ETRs and ITRs need to have RLOC addresses.

Other IP addresses are within the subset of the address space which
ITRs and ETRs manage.  These are "EID prefixes" in LISP, or
"micronets" in Ivip.

However, "RLOC" and "EID" are not separate namespaces.

If they were separate namespaces, then the address 12.34.56.78 would
mean one thing when used in the RLOC namespace and another thing
entirely when used in the the EID space.

But that is not the case.  12.34.56.78 may be an EID address or an
RLOC address - but it can't be both.

I believe that all public IPv4 addresses - those outside 10.0.0.0/8,
172.16.0.0/12, 192.168.0.0/16 and 127.0.0.0/8 - are in the one
namespace, with or without LISP etc.

I wrote more about this on 19 March:

  Re: [RRG] On "jack-down" models - independent namespaces
  http://psg.com/lists/rrg/2008/msg00856.html

   - Robin

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 27 Jun 2008 10:29:12 -0700

> But I am sure there is no new namespace in LISP or any other

I think there is. You can have a host assigned an address out of EID  
space and the locator for the ETR *could* use the same bit-value. And  
a site might do this if it has PA addresses and can't or won't change  
to PI when they want to deploy LISP. But I think in practice, it  
should be suggested that if locator addresses for the ETRs should not  
also be assigned to any devices at the site (but both could come out  
of the same subnet).

Since, at any given hop in the network, you look at one DA versus the  
outer DA, you do a lookup in a single RIB/FIB.

> ITRs and ETRs manage.  These are "EID prefixes" in LISP, or

Right, and each are in their own routing table. That is, for IGP  
routers the EID-prefixes are in a single routing table the router  
maintains. For core routers, the RLOC-prefixes are in a single routing  
table the router maintains. In the LISP prototype, the ITR keeps the  
site EID-prefixes (the site's subnets) in the default VRF routing  
table but the external EID-prefixes learned and advertised by LISP-ALT  
in a "lisp" non-default VRF. And the ITR also keeps external RLOCs in  
the default VRF routing table.

> However, "RLOC" and "EID" are not separate namespaces.

I view they are since they are allocated from different allocation  
entities.

> entirely when used in the the EID space.

And I believe it does.

> RLOC address - but it can't be both.

But 12.34.56.78/24 could be the host address and 12.34.56.79/24 could  
be the ETR's address. But the point is that they clash only when PA  
addresses are assigned to the site. I think there will be a trend  
(which already exists) to keep or obtain PI addresses for it's  
advantages.

> namespace, with or without LISP etc.

Without LISP they all, including the private addresses, are in one  
address space. The reason that private addresses don't clash is  
because the clouds that use them don't overlap and when they merge you  
have to fix the address conflicts.

Dino

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 28 Jun 2008 09:47:11 +1200

> I view they are since they are allocated from different allocation

They're separate if they don't overlap. Even Lewis Carroll knew that.
So if the allocation mechanism guarantees that they don't overlap,
we're good.

However, they aren't self-identifying unless we add a format prefix.
(Pouzin proposed that in 1974, but was not listened to.)

   Brian

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 27 Jun 2008 16:57:50 -0700

> So if the allocation mechanism guarantees that they don't overlap,

That is true Brian, but to be specific, they will probably overlap for  
IPv4 if and only if we allow PAs to be EID-prefixes. If we require EID- 
prefixes to be PIs that could take longer for a site to upgrade to  
LISP. So we could have a tradeoff dilemma. For IPv6, we can and would  
like to plan on have different spaces. Draft draft-meyer-lisp-eid- 
block-03.txt requested and received 2610:00d0::/32 for this purpose.

> (Pouzin proposed that in 1974, but was not listened to.)

Right. There is a big advantage (at the detail level, sorry RRG, have  
to talk about a bit of detail for a moment) if we have self  
identifying EIDs. It's when an ITR decides if a destination is LISP  
capable or not. Right now, we have spec'ed out that if the EID is in  
the mapping database, then the destination is in a LISP site. It would  
be nice to decouple this, avoid lookups and database mapping service  
dependencies by just looking at the address.

Just like we do with different packet types:

	if (ip_header->destination == unicast) {
             ip_unicast_forward();
         } else if (ip_header->destination == multicast) {
             ip_multicast_forward()
         } else {
             log("class E or F address");
         }

Dino

---

From: Robin Whittle <[email-masked]>
Date: Sat, 28 Jun 2008 13:59:13 +1000

I am replying to Dino and Brian.

Dino, you wrote:

> space and the locator for the ETR *could* use the same bit-value. 

I don't understand how this could work.  Lets say LISP's mapping
database says that 12.34.56.0/24 is an EID prefix.  This means any
packet found in any edge network with an ITR (except perhaps the
edge network where the destination host resides), or any packet
found in the DFZ (where it will be routed to a Proxy Tunnel Router)
which has an address such as 12.34.56.78 will be encapsulated by an
ITR (PTRs are ITRs) and tunneled to an ETR.

But in the DFZ and in the edge networks, how could you use for an
ETR address some address which is part of an EID prefix?  One of the
first things the original LISP drafts state is that ETRs need to be
in RLOC space - and therefore can't use an address which is within
an EID prefix.

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

    Routing Locator (RLOC):   the IPv4 or IPv6 address of an egress
    tunnel router (ETR).  It is the output of a EID-to-RLOC mapping
    lookup.

    LISP uses PI blocks for EIDs; such EIDs MUST NOT be used as LISP
    RLOCs.

> And a
> site might do this if it has PA addresses and can't or won't change to
> PI when they want to deploy LISP. But I think in practice, it should be
> suggested that if locator addresses for the ETRs should not also be
> assigned to any devices at the site (but both could come out of the same
> subnet).
> 

I don't understand how this could work.  The encapsulated packet
would have an outer address of 12.34.56.78 or some other address
which is within an EID prefix, so it would be forwarded to an ITR (a
PTR if the packet is in the DFZ) and promptly encapsulated again.
This process would repeat itself until some packet size limit was
reached.

> Right, and each are in their own routing table. That is, for IGP routers
> the EID-prefixes are in a single routing table the router maintains. For
> core routers, the RLOC-prefixes are in a single routing table the router
> maintains. In the LISP prototype, the ITR keeps the site EID-prefixes
> (the site's subnets) in the default VRF routing table but the external
> EID-prefixes learned and advertised by LISP-ALT in a "lisp" non-default
> VRF. And the ITR also keeps external RLOCs in the default VRF routing
> table.

I find this very confusing.  This is not the first time where I
thought I knew how LISP worked, but I find what you wrote reveals a
whole bunch of stuff which does not accord with what I recall from
the LISP IDs.

Can you or anyone else explain this better?

Brian, you responded to this with:

> They're separate if they don't overlap. Even Lewis Carroll knew
> that. So if the allocation mechanism guarantees that they don't
> overlap, we're good.

They are separate, non-overlapping, subsets of the IPv4 address
space, but they are not separate namespaces.

I stand by what I wrote about EID space being a subset of the entire
 IPv4 global unicast address space, and that most or all of the
remaining space is conventional BGP-managed space, which in LISP is
known as RLOC space.  Except perhaps in the edge network in which
the destination host resides, all packets with an EID address will
be encapsulated by an ITR.  They new outer destination address must
be an RLOC address.

What is your formal definition of "namespace"?

This seems pretty good to me:

  http://en.wikipedia.org/wiki/Namespace

     In general, a namespace is an abstract container providing
     context for the items (names, or technical terms, or words)
     it holds and allowing disambiguation of items having the same
     name (residing in different namespaces).

So if I give you a number 8765 4321 on its own, you don't really
know what to do with it, since you can think of many namespaces
within which it might be used.

If the number is accompanied by a second body of information which
specified a namespace, then you can use it in a particular way and
derive a particular meaning or utility from it.  If I tell you this
is a Melbourne phone number, you now have the information you need
to use this number in the correct namespace.   If I tell you it is a
Sydney number, that is a separate namespace, in which this same
number means something completely different.

Packets in TCP/IP networks which have a destination address in the
global unicast subset of the address range are all in the same
namespace, unless the device which receives the packet somehow has
extra information about packets indicating something else.

LISP and Ivip etc. do not enable a router or a host to have any
extra information about a packet which arrives (except for internal
routers in LISP, which know they are in a particular edge network
and may forward directly some packets addressed to the EID address
of destination hosts in that network, rather than encapsulating them).

All the router or host can do is look at the destination address as
the first part of deciding what to do with it.  It typically use
that to look up a mapping database (or a locally cached subset or
complete set of what the mapping database returns) to decide whether
this address is an EID or an RLOC address, but that is not the same
as having two different namespaces.

>> entirely when used in the the EID space.

I hope you will be able to explain how LISP could work with PTRs
(the only way LISP could support multihoming etc. for packets coming
from non-upgraded networks) if ETRs could be on addresses which ITRs
regard as being within an EID prefix.

> But 12.34.56.78/24 could be the host address and 12.34.56.79/24 could be
> the ETR's address. 

That is fine - the first prefix is EID space and the second RLOC.

> But the point is that they clash only when PA
> addresses are assigned to the site. 

I don't understand this.

> I think there will be a trend (which already exists) to keep or
> obtain PI addresses for it's advantages.

Yes, but map-encap provides a new kind of address space which is
also provider independent, and supports multihoming, TE etc.  Maybe
that new kind of address space should have a different name to
distinguish it from conventional BGP-managed "PI" space.

> address space. 

They are all part of one 32 bit address range, but they are not in
the same namespace.

> The reason that private addresses don't clash is because
> the clouds that use them don't overlap and when they merge you have to
> fix the address conflicts.

If my LAN emitted packets in these RFC 1918 prefixes to my ISP, they
would probably be dropped.

Within my LAN, packets addressed to RFC 1918 arrive at a host in a
context all the hosts, routers, Ethernet switches etc. assume: where
all these RFC 1918 addresses have meanings which are unique to to my
LAN.  Since it is known that they could not have arrived from the
Internet or some other LAN, are handled according to the rules of my
LAN: they are treated according to the namespace of my LAN for RFC
1918 addresses.   In someone else's LAN, the same destination
address would be interpreted according to the namespace of that LAN,
which is completely different from that of my LAN.

Dino, you further wrote:

>> They're separate if they don't overlap. Even Lewis Carroll knew
>> that.  So if the allocation mechanism guarantees that they don't
>> overlap, we're good.
>
> That is true Brian, but to be specific, they will probably overlap
> for IPv4 if and only if we allow PAs to be EID-prefixes.

I guess I would understand this if I understood the previously noted
things hope you will explain better.

> If we require EID-prefixes to be PIs that could take longer for a
> site to upgrade to LISP.

OK - we are no longer discussing namespaces.  I will refer to the
rest of your comments in another thread sometime.

 - Robin