Subject: Re: [lisp] LISP Mobility Architecture

From: [email-masked] (Noel Chiappa)
Date: Mon, 27 Jul 2009 09:01:40 -0400 (EDT)

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

    > It was my understanding that the scalability of LISP would come from
    > the ability to aggregate RLOCs for several sites behind a single LISP
    > router (in other words, my ISP would have a LISP router within their
    > network, aggregating RLOCs for a larger (logical or geographic) area.

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.

With that in hand (and sorry if this next is obvious/repetitive), the names
used by the routing layer can be assigned in a way that maximizes their
aggregability - and that goal doesn't have to be compromised by other goals
that people have when there's only a single namespace (e.g. persistence of
identifiers), and those names are also being used for other things. That,
fundamentally, is how the routing scalability works (or is supposed to :-).

I see the host mobility as an instance of something different from the
routing aggregability: the general principle of 'hey, we have this new
binding layer there, what _else_ can we do with it'.

It's common that when you provide a new, powerful tool (and a binding layer
is an example), it has many uses, and a great part of the charm of LISP, for
me when I first saw it, was the realization that it had that general-purpose
nature.

To answer your question in detail, the the scalability of LISP comes not from
"the ability to aggregate RLOCs for several sites behind a single LISP
router", but rather to 'aggregate' _EIDs_ for several sites behind a single
LISP router.

I say 'aggregate' because it's not aggregation in the usual sense (having a
group of addresses that one can collapse into one routing entry), but the
_effect_ is the same - where before, one would have needed multiple routes to
cover all those destinations (to the EIDs themselves, one now needs only one
- a route to the RLOC of the LISP router.

    > If I move my node to another site, its DHCP request will not go
    > to/through anything in my home network. So, how does that lead to
    > reconfiguration of the ETR in my home router?

I'm a bit hazy on the details, but basically the mobile node has to register
its new location (i.e. the RLOC where it currently is) with the mapping
system. That way, entities which want to talk to it ask 'what's the RLOC to
use to get to this EID', and are given the RLOC of its current location.

That process might include notifying a home ETR, but it doesn't fundamentally
_have_ to - it's easy to imagine systems where the home ETR has no idea the
mobile node has 'gone walkabout'. it all depends on how the mapping system is
set up (and the current ALT mapping system is intended to be replacable with
something better). I think at the moment the ETR has to be notified, because
of the way ALT works, but like I said it's not fundamental (in the sense that
'it can't possibly work without this information getting to that node').

    > Are you also expecting that I will have my own map server within, or at
    > the edge of, my home network?

In general, no. Although you do have to have a LISP router somewhere, and the
closer to the current location of the mobile node (topologically) the better,
otherwise you'll get 'stretch' in the path.

The map server could be anywhere in the Internet - the traffic doesn't go
through it, it's only used to find the EID->RLOC binding - just like your DNS
server could be anywhere in the Internet.

    > Or would my mobility state be maintained in my ISP's map server?

Some Map Server (or group of them) is going to be authoritative for the EID
range your mobile node has an EID out of - i.e. it is the one(s) anyone has
to go to to find the current EID->RLOC binding. That Map Server has to be
updated.

    > If the former, I agree that the extra state is all maintained in a
    > system that is controlled (and paid for) by the entity that wants the
    > mobility.

Well, the location of that binding (i.e. the place you have to go to to find
out the current value of "EID->RLOC") doesn't change over time. If it's in
Map Server X when you're at your 'base' location, it will still be in Map
Server X when you're mobile. The only thing that happens is that as you move
around, that binding has to be updated. Whether one considers that a
significant cost for the provider of the Map Server is the question. As long
as it's not manual updating, I guess I don't see that it can induce a
significant _extra_ cost, over the costs of providing the Map Server to begin
with. (And you have to have a Map Server to run LISP at all.)

    > If it is going to be in my ISP's map server, though, that added state
    > and complexity might be a reason to prefer mobility mechanisms I could
    > control myself.

I guess I don't understand this? Perhaps the foregoing will have answered
the question?

	Noel

---

From: [email-masked]
Date: Tue, 28 Jul 2009 04:47:02 EDT

In einer eMail vom 27.07.2009 13:36:48 Westeuropäische Normalzeit schreibt  
[email-masked]:

It was  my understanding that the scalability of LISP would  
come from the  ability to aggregate RLOCs for several sites behind a  
single LISP  router (in other words, my ISP would have a LISP router  
within their  network, aggregating RLOCs for a larger (logical or  
geographic)  area.

Well respected: LISP introduces, potentially, a new namespace. But then: It 
 reuses the old one by splitting it up. Whereas TARA would  indeed 
introduce  an new additional namespace, derived from the  geographical coordinates, 
which enables topology aggregation as to ABOLISH (not  just reduce or 
reshape) the scalability problem.
 
It was also mentioned that later on LISP may exchange its namespace by  
something better. But that can only work out in combination with some better  
concept, i.e. with some other concept.
Note, it neither takes a push- nor a pull model- to get geographical  
coordinates there where they are supposed to be. No ALT. No CONs. No  nothing.
 
And see above "ability to aggregegate": the use of  geo.cordinates enables 
not just one single aggregation  hierarchy (like with IP prefixes) but as 
many as you want: each single spot on  the surface of this planet can be 
viewed as the centerpoint of multiple  areas of contentric circles around it. I 
don't know of any better aggregation  scheme and also believe that exploiting 
the geographical coordinates is the  natural approach to deal with IP 
Mobility.

Heiner

---

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

> From: [email-masked] (Noel Chiappa)

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

I just realized that this part of my answer was confusing/wrong. Let me try

    > Although you do have to have a LISP router somewhere, and the closer to
    > the current location of the mobile node (topologically) the better,

A LISP Mobile Node is its own xTR (i.e. LISP encapsulating/decapsulating
router); the mobile host is prepared to receive and emit wrapped packets.

For communicating with a non-LISP host, the LISP MN does need a proxy LISP
encapsulating/decapsulating router somewhere, the 'Proxy ITR/ETR' (these
could be two different boxes, actually).

	Noel

---

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

> From: Dino Farinacci <[email-masked]>

    > If the home is still going to use private addresses .. NAT will still
    > be needed to translate from a private address .. to a global one.

The thing is that when NAT is used in a LISP context, there are _two_
potential ways to do so. Remember that NAT in a normal 'vanilla IPv4' context
allows a single global IP address to be shared by a bunch of hosts.

With LISP, in the first usage mode, a NAT box can allow a single _EID_ to be
shared by a bunch of hosts. This happens when the NAT box is between i) the
LISP two-namespace/one-namespace boundary (see previous message), and ii) the
hosts.

In the second usage mode, a NAT box can allow a single _RLOC_ to be shared by
a bunch of xTRs. This happens when the NAT box is between i) the LISP
two-namespace/one-namespace boundary (i.e. the xTRS), and ii) the rest of the
network.

I'm not sure there's much use for the second mode, mind... I imagine the
usual usage mode would be to allow a single EID to be shared between a bunch
of hosts.

Note that NAT is sort of orthogonal to LISP - LISP splits a single namespace
into two, where each namespace has _different_ properties; NAT shares a
single name between several entities, where for each user of the name their
use has _identical_ properties with the other users (except for referring to
a different box).

    >> are being made to enable the RLOC-to-EID transition to happen at the
    >> edge of much smaller networks

    > I don't know where you are referring to "RLOC-to-EID transition" and
    > frankly don't know what you mean.

I think she means 'transition from a mapped/wrapped packet, with separate
RLOC and EID, to an unwrapped/unmapped packet, with only an EID'.

    > But you get other benefits like:
    > 
    > (1) Both egress and ingress low-opex multi-homing.
    > ...
    > (3) Allows TCP connections to stay up while your DSL provider changes
    > your IP address (i.e. your RLOC).

Do note that for the third (and probably the first as well), you need to have
'permanent' EIDs (IP addresses) assigned to your host(s); you can't use the
IP address the provider handed out to your cable/DSL/whatever hookup, because
when it renumbers, that IP address - and in particular, its 'EID nature' -
will 'belong' to someone else.

	Noel

---

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

> In the second usage mode, a NAT box can allow a single _RLOC_ to be
    > shared by a bunch of xTRs. This happens when the NAT box is between i)
    > the LISP two-namespace/one-namespace boundary (i.e. the xTRS), and ii)
    > the rest of the network.

    > I'm not sure there's much use for the second mode, mind...

Doohhh. My brain really isn't firing on all cylinders tonight..

Having the NAT box between the xTR and the rest of the network is, of course,
exactly what the situation will be anytime a LISP MN migrates to some place
that's behind a NAT box. 

There's some extra hair the xTR has to deal with in this case (basically,
since NAT boxes don't have LISP ALGs, the xTR has to find its 'real' global
RLOC to put in LISP control messages), but I don't recall how that works.

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Thu, 30 Jul 2009 14:21:01 -0400 (EDT)

> Thank you for your response.

Sure.

    > but I still have some questions/concerns...

Sure.

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

    > In which direction do you think the boundary will move?

My assumption has always been that it would move closer to the host, because
I'd like to see the 'advanced' area (the one where the two separate
namespaces are in use) spread over time, so that the architecture of the
Internet as a whole can evolve.

(I should explain that my long-term vision is that once we have a collection
of xTRs as a boundary around a 'LISP' backbone, we can evolve what's inside
that area separately from the edges.)

    > Am I right in my understanding that I can only have one LISP boundary
    > between an end-node and the Internet core?

I too had originally assumed there would/could only be one, but as pointed
out when the question about 'what happens when a LISP MN moves to a site
which has already deployed LISP, and gets as an 'RLOC' an IPvN address which
is actually an 'EID' in that site' came up, that situation is handled by
having nested LISP encapsulations. I.e. you can have more than one boundary,
they nest.

As RW correctly points out, this has the usual downsides of multiple
encapsulations: header overhead, etc. I'm also not thrilled about the way in
which it entangles the EID and RLOC namespaces. The upside is that it's
simpler to implement than the alternative (which is to have an encapsulation
which can hold multiple, nested, RLOCs, and a mapping system which can return
a nested-multi-RLOC output).

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

Although this is in fact technically feasible, it's still an interesting
scenario to discuss and evaluate. I guess my first question is 'why would an
ISP deploy LISP anywhere but the ISP/customer boundary anyway'? There's no
point to deploying it at the ISP/ISP boundary. It would naturally be deployed
at the customer boundary, to protect the customer from address changes in the
ISP, no?

    > 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

The question of 'how to move the boundary' is an interesting one, but there'
is not a synchronization issue - and in any event, I think it would be more
likely to move in the other direction (i.e. away from the core).

    > .. LISP will allow us to give provider-independent identifiers (EIDs)
    > to end sites, without adding routes to the core Internet routing
    > tables. .. end-sites will not care about what locators (RLOCs) are used
    > to route their packets, as long as the identifier(s) (EIDs) that others
    > .. 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.

Exactly. (In addition, a variety of things like multi-homing and traffic
engineering are also simpler if location and identity and separated, but
let's leave that for the moment.)

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

Well, nothing in life is certain... :-)

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

Well, exactly. I'd felt for a long time that we ought to be able to change
addreses easily, because we had DNS, but apparently that isn't so. Too many
places in the software use IP addresses, not DNS names.

To some degree this seems to be partially historical - since DNS name are
more recent, a lot of historical expectations were that we'd use IP
addresses, and so they got built in to a lot of places they didn't need to be.

Although there is _some_ success to DNS names, especially in places in which
they are 'deeply embedded'. E.g. moving a web site to a different provider
seems to be _relatively_ doable, because the web is _so_ centric on DNS
names.

    > Are we sure that EIDs (and the associated EID->RLOC mapping mechanism)
    > will be acceptable for this purpose?

I guess I'm hoping that a combination of i) already having two 'static'
namespaces (DNS names and EIDS), ii) the fact that most hosts can't even see
RLOCs, plus iii) hard-learned lessons about how painful it gets when names
which ought to be dynamic get 'hard-coded' into places where we ought to be
using non-dynamic names, will prevent the same problem happening all over
again. We'll see, I guess!

    > How are we planning to avoid the problems that have made the in the DNS
    > unacceptable?

It's not so much that DNS was unacceptable (I think), as that IP addresses
were used, e.g. in access control lists at places other than the site itself.

Were there problems with DNS names that led to people preferring addresses?
To the extent there were problems with DNS names, would EIDs be so different
that they would not share them? If so, then I think we can avoid people using
RLOCs, and degrading their dynamicity? Does that sound plausible?

	Noel