Subject: Re: [lisp] LISP Mobility Architecture

From: [email-masked] (Noel Chiappa)
Date: Wed, 29 Jul 2009 21:10:22 -0400 (EDT)

> From: Margaret Wasserman <[email-masked]>

    > It is my understanding that LISP provides a possible solution to the
    > global route scaling problem because it creates two tiered routing
    > domains: a global routing domain that uses RLOCS that are allocated in
    > contiguous blocks that mirror the global network topology, and an edge
    > routing domain that uses EIDs.

No, not really. Well, what you say is accurate, but it's only a _partial_
picture of what's really going on.

Like I said, the best way to think of LISP is that it's an incrementally
deployable system which splits the single IP address namespace into two
separate namespaces: one for location, and one for identity. In keeping with
the 'incremental' part, there is a boundary between the (logical) part of the
network in which those two separate name(space)s exist, and the (logical)
part of the network in which there's only one; and the location of that
boundary can move over time.

In the 'basic' LISP configuration, that boundary is at the very edge of a
site - to absolutely minimize the number of things that have to be changed
(e.g. hosts and routers inside the site don't have to be touched). There's an
xTR at the boundary (wherever that is) which encapsulates/decapsulates
packets; the encapsulated packet has both an EID and an RLOC (i.e. names from
the two separate namespaces).

In the mobile node case, that boundary has moved right into the host: i.e.
_part_ of the host software understand that there are two separate
namespaces, and that the host has both an EID and an RLOC, and part (e.g. the
TCP) known only of the single 'IP address' namespace.

    > I thought that the transition between the global routing domain (RLOCs)
    > and the edge routing domain (EIDs) would happen at a fairly high level
    > in the topology ... However, it seems that some of the design decisions
    > being made in LISP ... are being made to enable the RLOC-to-EID
    > transition to happen at the edge of much smaller networks (homes, small
    > offices, etc.), perhaps even behind a local NAT box.

Right. That's the 'location of the boundary moves over time' thing.

    > If LISP is deployed at the home gateway level, I am not sure how we
    > gain much in the way of route scaling improvements, since we would have
    > to support global domain (RLOC) routing all the way down to the
    > per-home level, which is what we are doing today.

The thing is that we expect RLOCs to be assigned in such a way that they are
much more eggregatable (i.e. smaller routing tables).

E.g. one problem has always been that people don't want to change their
hosts' IP addresses, because it's a pain in the XXX. So they keep their IP
addresses when they move, and that causes routing table bloat.

To put it another way, the requirements of low routing overhead (aggregatable
addresses) and the requirement of ordinary users (have unchanging IP
addresses for their hosts) were diametrically opposed - and as long as we
only had a single namespace, there was no way to do both of those things at
the same time.

Now, with separate EID and RLOC spaces, we can. RLOCs are assigned to be
maximally aggregatable, and EIDs stay constant no matter where the host(s)
move. E.g. when a small office moves to a different ISP, it can both keep its
old IP addresses, but without adding an entry to the core routing tables.

So, to go back to your question: even if we have a neighbourhood full of LISP
MN's, the entire neighbourhood will still only generate a single routing
table entry - all the LISP MN's will have RLOCs allocated from a single
block, even if their EIDs are from all sorts of different blocks.

    > So, what am I missing or misunderstanding?

Did that clarify it? If not, please keep asking questions.

	Noel

---

From: Robin Whittle <[email-masked]>
Date: Thu, 30 Jul 2009 12:49:56 +1000

This follows from Noel's message, responding to Margaret, in the "Re:
[lisp] LISP Mobility Architecture" thread:

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

I haven't been following recent discussions and I don't have time to
read about or critique the new LISP mobility ID.  However folks
interested in mobility might wish to compare it with a scheme which
is applicable to LISP:

  TTR Mobility Extensions for Core-Edge Separation Solutions to the
  Internet's Routing Scaling Problem
  Robin Whittle, Steven Russert  2008-08-25
  http://www.firstpr.com.au/ip/ivip/#mobile

I will comment on these continued assertions about LISP involving two
separate namespaces.  Please see this page for links to all the
previous discussion about the meaning of "namespace" and my posts to
the list about this:

  http://www.firstpr.com.au/ip/ivip/namespace/

>> routing domain that uses EIDs.

I think this is an accurate description of LISP and the other
core-edge separation schemes such as APT, Ivip and TRRP.  There needs
to be not too many prefixes which contain RLOCs, since each such
prefix needs to be in the global BGP routing table - and a primary
goal of any core-edge separation scheme is to reduce the number of
such routes.

> separate namespaces: one for location, and one for identity. 

These are not separate namespaces according to any definition I have
been able to find.  Noel, what is your definition of "namespace"?

LISP involves two subsets of the global unicast address space.  Some
prefixes are in the global routing table and their addresses can be
used for RLOC addresses.  EID addresses are in other prefixes which
are not within the first set, and so do not contribute to the burden
on the BGP control plane by adding to the size of the global BGP
routing table.

A namespace is a context within which a number or name is
interpreted.  If there were two separate namespaces, then 12.34.56.78
would have one meaning on namespace 1 and another in namespace 2.
Any situation which handles packets with addresses in two separate
namespaces needs a way to figure out which namespace to use for each
packet when interpreting the meaning of its address.

However, what happens with LISP or any other core-edge separation
scheme is that multiple prefixes of the global unicast space
constituting the "RLOC-capable" subset of the address space are used
for one purpose and the remainder of the global unicast space cannot
be used for routing packets in the BGP core.  That second subset can
be used for EID addresses.

LISP (in any form suitable for the foreseeable future, and as
currently formally defined) does not allow the use of a single
address for both purposes at once.  This would be possible only if
there were separate namespaces.

In principle, LISP could work with separate namespaces for RLOCs and
EIDs, but there is no way this can work in any time in the
foreseeable future because it would require all BGP routers to also
recognise these two namespaces.  Then, the BGP routers would be able
to see the packet destination address 12.34.56.78 as being either
within the RLOC namespace, or the EID namespace.  This would require
modifications to all BGP routers and some new packet structure to
carry information specifying the use of the RLOC or EID namespace.

The whole idea of LISP, APT, Ivip and TRRP is to remain compatible
with existing packet structures and BGP routers (though there are
options in Ivip which do involve modified routers and packet
structures as a way of avoiding encapsulation).

I am sure that as long as LISP is to remain compatible with existing
packet structures and BGP routers, that it does not involve separate
namespaces for RLOC and EID addresses.

> In keeping with

Noel, I would appreciate it if you described with a concrete examples
how these two separate "namespaces" would work.  I think this would
illuminate some misunderstandings or at least point out the different
meanings you and I ascribe to the term "namespace".

>     > per-home level, which is what we are doing today.

I share Margaret's concern.  This is not a problem with the TTR
approach to mobility.

> much more eggregatable (i.e. smaller routing tables).

This is the goal of LISP etc.  To achieve it, the addresses used by
end-user networks need to be EID addresses.  This includes any
end-user network where a mobile device might have its care-of address.

If Mobile LISP involves end-user networks having RLOC addresses, then
I can't see how LISP could achieve its goals of making such networks
portable between ISPs without renumbering and/or giving them robust
multihoming via two or more upstream ISPs.

You can't have some address 12.34.56.78 be both an EID and an RLOC.

If an ITR treated this address as an EID, it would encapsulate any
packet with 12.34.56.78 as its destination address and tunnel it to
some RLOC address, based on looking up the mapping for 12.34.56.78.

If any packet is encapsulated and tunneled to an address which an ITR
recognises as being within the EID subset of addresses (which I think
Noel calls the EID "namespace") then either that ITR or some other
ITR will simply encapsulate the resulting packet as just described.
This would continue for as often as the RLOC address returned by the
mapping system was also within the subset of addresses known as the
EID subset: that subset for which the mapping system will return an RLOC.

It is absolutely clear that this has never been the intention with
LISP.  Every draft from 00 to the current 12:

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

includes this as part of the definition of EID:

  "EIDs MUST NOT be used as LISP RLOCs."

If there were two separate namespaces for RLOC and EID space, then
this statement would not be true.  The same numeric address could be
used as both an EID and an RLOC.

> Did that clarify it? If not, please keep asking questions.

Noel, how can a LISP MN act as its own ETR without an RLOC address of
its own?  From all I know about LISP, any such ETR function needs to
have a unique IP address which is part of a prefix in the RLOC subset
of the global unicast subset of the address space.

If the MN is in an end-user network, and that end-user network is
using EID addresses (as it must be be portable and scalably
multihomable, as LISP provides), then its address can't be within an
RLOC prefix.  So how could the MN be its own ETR?

By contrast, in the TTR approach to mobility, the MN is not its own
ETR.  It establishes a two-way tunnel to a Translating Tunnel Router,
which with a single RLOC address is the ETR for many MNs in
potentially many networks.  The MN's care-of address can be behind
NAT and it will still be able to make a two-way encrypted tunnel to
the TTR.  The TTR acts as its ETR and also handles outgoing packets,
so the TTR is probably also an ITR.

Multihoming and mobility is achieved by the MN tunneling to multiple
TTRs, ideally a TTR which is "close" to the network it is tunneling from.

 - Robin

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 30 Jul 2009 12:11:59 -0400

Hi Noel,

Thank you for your response.  It was very helpful, but I still have  
some questions/concerns...

> boundary can move over time.

This is what I referring to in my earlier message when I said RLOC-to- 
EID transition.  I think that the term "boundary" is much clearer.   
Thank you.

> Right. That's the 'location of the boundary moves over time' thing.

In which direction do you think the boundary will move?

Am I right in my understanding that I can only have one LISP boundary  
between an end-node and the Internet core?  If so, will an end-site be  
unable to deploy LISP at their site boundary if their ISP has already  
deployed it at a higher level?  If that is the case, and the LISP  
boundary starts at the edges of sites, it would require a lot of  
coordination to move that boundary towards the Internet core later (as  
it would have to move upward for all sites at the same time, and the  
sites might lose some advantages that they have been enjoying).
> block, even if their EIDs are from all sorts of different blocks.

This all makes sense to me, I think...

Your explanation basically says (as I interpret it) that LISP will  
allow us to give provider-independent identifiers (EIDs) to end sites,  
without adding routes to the core Internet routing tables.  There is  
an assertion/belief that end-sites will not care about what locators  
(RLOCs) are used to route their packets, as long as the identifier(s)  
(EIDs) that others (other end-nodes, users, customers) use to find  
them remain persistent, even if they move (topologically) within the  
Internet for whatever reason.  So, we believe that we will be able to  
freely change a LISP-enabled site's RLOCs to retain a high level of  
aggregation, even when a site changes ISPs or the structure of the ISP  
network changes.

If that assertion/belief is actually true, then I do understand (now  
that you have explained it to me -- thank you!) how LISP hopes to  
address the scaling issues with the global routing table, even if the  
LISP boundaries are at site boundaries.

I have some concerns about how well this will work, though...

We already (pre-LISP) have a situation where the DNS is often used as  
a mapping system to locate other sites and services.  The DNS name(s)  
of a site do not change when the site's address(es) change, so the DNS  
name could be considered a persistent identifier.  The problem is that  
certain properties of the DNS make it unreasonable to use DNS names in  
all of the places that we'd prefer to have a persistent identifier for  
a remote host.  Are we sure that EIDs (and the associated EID->RLOC  
mapping mechanism) will be acceptable for this purpose?  How are we  
planning to avoid the problems that have made the in the DNS  
unacceptable?

Margaret