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

[Robin Whittle <rw@firstpr.com.au>]

I am replying to Dino and Brian.

Dino, you wrote:

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

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

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.


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


>> However, "RLOC" and "EID" are not separate namespaces.
> 
> I view they are since they are allocated from different allocation
> entities.

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.


>> 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.
> 
> And I believe it does.

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 that is not the case.  12.34.56.78 may be an EID address or an
>> 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. 

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.


>> 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.
> 
> Without LISP they all, including the private addresses, are in one
> 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


--
to unsubscribe send a message to rrg-request@psg.com 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