Subject: Re: [lisp] LISP Mobility Architecture

From: Sam Hartman <[email-masked]>
Date: Tue, 01 Sep 2009 10:49:31 -0400

Jari, thanks for making the high level decision on LISP mobility.

My interpretation of your wording as chair follows; please let me know
if I got it wrong.

First, as always, we're designing an extensible protocol.  So,
extensibility features that might be needed if we expand our scope in
the future are in scope--that includes things like making sure we
could allocate a flag in the future,making sure we have ways to evolve
ITR/ETR behavior in the future, etc.  I.E. the sorts of holes Noel is
talking about.

However, at this point, the IETF has not considered the following
questions, and this working group is not chartered to consider them:

1) is LISP going to be part of a mobility solution
2) If so, how course-grain/fine-grain
3) How does LISP fit together with protocols like MIP6, MIP4, NETLMM, NEMO
4) Will any LISP mobility solution be based on the current LISP mobility architecture

As a personal note, I'd recommend anyone interested in LISP and
mobility take a look at draft-ietf-mext-aero-reqs-04; I read it as a
secdir reviewer.  It seems that some of those requirements may not be
such a good fit for our existing mobility toolbox. I have not thought
much about whether LISP would be a good fit for them, but it seems worth thinking about.

In terms of mobility impact on our base specs, we're not currently
considering mobility or mobility related changes in the base specs,
beyond the sort of leaving room for future expansion we discussed
above.  Even if it were in scope, we'd need to come to a conclusion on
whether LISP was a mobility approach that the IETF wanted to pursue
before we'd want to consider mobility issues in the LISP design.

The boundary between mobility, which is out of scope for now, and
things like renumbering of a multi-homed site can be a bit fuzzy.  My
personal belief is that when you start considering issues like
preserving connections when all existing RLOCs change, rapid change of
RLOCs, or optimizing for /32 or /128 EID allocations, you're
definitely into the mobility realm.

Sam Hartman
LISP co-chair

---

From: Robin Whittle <[email-masked]>
Date: Wed, 02 Sep 2009 04:12:47 +1000

Short version:  Since WG participants presumably believe that
                LISP-ALT is either the only possible solution to
                the scalable routing problem, or that it is
                clearly superior to the alternatives (LISP-NERD,
                APT and Ivip), then AFAIK the WG must be planning
                to make LISP-ALT work in a future scenario in
                which the great majority of its hundreds of
                millions of EIDs are for individual mobile devices.

                If the scalable routing solution doesn't need to
                handle mobile devices, then there will never be
                more than a few million, perhaps 10 million, EIDs.

                LISP-NERD, APT or Ivip could scale to 10M EIDs
                without any fuss.  Any of these would all be
                superior to LISP-ALT since none of them involve
                delaying initial packets or depending on a
                global-scale query server system - as ALT does.
                NERD is nice and simple - nice and fast.  If we
                are not trying to do mass-market mobility, NERD
                would be a better solution than ALT.

                To complete this initial phase of work the WG
                needs to establish a coherent plan for how LISP
                would be deployed - how it would work in the next
                few years and in the decades to come.  That means
                you need to plan how LISP will handle hundreds of
                millions or billions of mobile devices, each with
                its own EID.

While I understand that development of LISP-mobile is out of scope
for the WG as currently chartered, I want to make two points.

Firstly, anyone who is interested in LISP-mobile will probably find
it interesting to read my critique a month ago:

  Critique of Mobile LISP: draft-meyer-lisp-mn-00 - why not use the
  TTR approach instead?
  http://www.ietf.org/mail-archive/web/lisp/current/msg00772.html

No-one has responded to this on list or privately.  If Mobility is
out of scope for the WG, the RRG would be a good place to discuss it.

Secondly, as part of developing a well documented and hopefully
widely shared set of principles about what LISP is, how it is to be
deployed etc.:

  Discussing LISP deployment
  Sam Hartman  2009-08-22
  http://www.ietf.org/mail-archive/web/lisp/current/msg01092.html

I believe the WG must plan how LISP will do mobility.  (I believe it
can, but only with the TTR mobility approach and not at all with the
approach of the recent LISP-mobile I-D.)

The entire WG effort to develop LISP is based on using the ALT
mapping distribution system, which is a successor to CONS.

Both ALT and CONS go to a lot of trouble to avoid any one device
having to store the entire mapping database.  The primary or perhaps
only reason for doing this is so that LISP can scale to very large
numbers of EIDs.

AFAIK, the *only* reason you are pursuing ALT, instead of the
alternatives, is because of this goal of seemingly endless EID
scalability.

I think everyone currently working on LISP ALT, or any similarly
endlessly scalable successor to ALT, needs to justify all this
effort, and all the difficulties this goal entails for scalable
routing and therefore all future Internet users, in terms of there
actually being a need, albeit in the long-term, for such large
numbers of EIDs that no other simpler alternative would be able to cope.

The most obvious alternative is LISP-NERD: every ITR downloads the
entire mapping database via HTTP or whatever from a bunch of servers.
 Then it is pretty easy for end-user networks to update the mapping
in the central servers and let the changes propagate to all ITRs.

NERD is simple and fast.  There are no delayed or dropped packets as
there are with ALT.  There is no fancy mapping distribution network -
no complex ALT network of routers with their long-paths, bottlenecks,
etc.

NERD sits at the "simple" extreme of the spectrum.  ALT sits at the
other end.

In between are two systems - APT and Ivip - which involve ITRs
getting mapping in a few milliseconds, via a local query server.
This gives APT and Ivip the same major advantage as NERD compared to
ALT: no significant delays in ITRs tunneling initial packets.
Likewise, these three systems have the advantage over ALT that there
is no real-time, moment-to-moment, dependency on a global query
server system, with all its potential and likely delays and packet
loss problems.

Both APT and Ivip enable most or all ITRs to be caching ITRs - since
they use local (such as in the same ISP) full database query servers.
 So APT and Ivip ITRs are simpler and cheaper than NERD ITRs.
Therefore they can be more plentiful, closer to sending hosts - or in
the case of Ivip, *in* sending hosts (not behind NAT).

ALT incurs major costs of complexity, global dependencies for ITRs to
work at all moment-to-moment - and most seriously it will delay
initial packets of a significant number of new communication flows,
by times such as fractions of a second to one or two seconds.  That
will make it very hard for us to get it widely adopted.

In order to justify pursing ALT, I understand you all must be
proceeding on the basis that none of the alternatives (LISP-NERD, APT
or Ivip) could possibly do the job.

ALT has a bunch of disadvantages over these three, and AFAIK only one
potential advantage: the mapping database is entirely distributed, so
it can (in principle) handle vast numbers of EIDs without scaling
problems in any one device.

To establish that ALT is the only realistic approach to scalable
routing, AFAIK, you need to prove to yourselves that ALT's endless
scalability is absolutely essential to the successful long-term
resolution of the routing scalability problem.

In order to do this, I think you would need to establish three things
at least:

  1 - That there will be a demand for a very high number of EIDs -
      say YYY million EIDs.

  2 - That ALT can scale well, solving the routing scalability
      problem, handling this number YYY million EIDs, at some time
      in the future when this number will be needed.

  3 - That no other alternative (currently LISP-NERD, APT or Ivip)
      could be developed to the point where it could handle YYY
      million EIDs, whenever in the future (2020, 2030 etc.) these
      will be required.

Lets toss some numbers around.

At what number of EIDs would LISP-NERD encounter serious scaling
problems?  Lets think IPv6 mapping with (I guess) about 100 bytes per
EID.  PCs today (and therefore today's servers and dedicated routers
in a few years time) have 8, 12 or whatever GB of RAM.  They have
terabyte hard drives too.  Even for ECC RAM, the cost is
insignificant in the scheme of things.

A LISP-NERD ITR will be a caching ITR with packet switching in
hardware or software - co-located with a full database query server.
 The query server would be in the same box, including the same
server/router, or in the same rack just one or two patch cables away.
 I will assume the full mapping database sits in RAM.

Even if every EID consumed 256 bytes of RAM, a 12GB machine can
handle 48 million EIDs.

The task of sending all the world's mapping data to these LISP-NERD
ITRs will not be a problem.  By the time we have 48M EIDs, bandwidth
will be even cheaper than it is today.  The update traffic is not
going to be high, since LISP mappings don't change all that often.
The whole of LISP is built on the relative stability of mappings,
with ITRs handling the moment-to-moment changes in reachability,
making their own decisions about which of multiple ETRs to tunnel the
packets to.  (APT makes the same assumption.  Ivip is totally
different in this regard.)

So for LISP-ALT to be chosen in preference to the simple, chunky,
fast, LISP-NERD, you must be planning to handle more than 10s of
millions of EIDs.  You must be requiring the scalable routing
solution to cope with hundreds of millions of EIDs - billions or even
10 billion.

With equivalent hardware and communication costs, both APT and Ivip
can scale to a much larger number of EIDs than LISP-NERD, because
only the local query servers have to store the full mapping database
and get all the updates.  Dozens or hundreds of much simpler ITRs can
work from a single local query server - so for the same or more
likely much lower total cost you can make these local query servers
more expensive, with massive RAM, multiple CPUs etc.

Its hard to put a figure on it, but lets say that with 2025
technology and communication costs, APT or Ivip could scale nicely to
handle 200M EIDs, 500M EIDs or the like.

If you are still sure that ALT is the only way to solve the routing
scaling problem, then you must be planning on handling 500M, 1B, 5B
or more EIDs.

This means you must be planning on most of those EIDs being for
individual mobile devices, because there is never going to be demand
for non-mobile EIDs in anything like these numbers.

There's only a subset of non-mobile Internet customers who have any
significant motivation to use a scalable routing solution - for the
benefits of multihoming, and/or portability between ISPs and/or
inbound traffic engineering if they are multihomed.

If the population grows to 10B people, there are only going to be a
finite number of businesses or other organisations big enough to want
any of these benefits of scalable routing.  Let's assume there is one
such organisation for every 1000 people (10,000 people seems more
realistic to me).

As long as the scalable routing solution doesn't have to provide an
EID for mobile devices, then the maximum number of end-user networks
it needs to support will be 10M.  Some will have two or more EIDs,
but most will only have one.

So if the scalable routing solution is not directly involved in
mobility, then you simply don't need something as complex and
problematic (initial packet delays ...) as ALT, because the
alternatives LISP-NERD, APT and Ivip will scale just fine to 10M EIDs.

Therefore, if you are convinced that LISP-ALT is the only viable
approach to scalable routing, AFAIK, you must believe:

  1 - The scalable routing solution must provide an EID for each
      mobile device.

AND

  2 - There will be hundreds of millions or billions of these mobile
      devices - enough that NERD, APT or Ivip couldn't possibly scale
      to this number of EIDs, even with the technology of 2020, 2030
      etc.

AND

  3 - LISP-ALT will scale nicely when it does handle hundreds of
      millions or billions of EIDs - and the great majority of those
      EIDs are going to be for hand-held mobile devices.

As I wrote in my critique, I believe you can't make LISP work with
mobile devices as per the current I-D.  I believe you could make
LISP-ALT support mobility, including for billions of EIDs, using the
TTR approach to mobility:

   http://www.firstpr.com.au/ip/ivip/#mobile

I explained this over two years ago and Steve Russert and I wrote up
this nice documentation of it a year ago.

So as far as I can see, as long as you believe LISP-ALT is the only
viable solution to the scalable routing problem, in order to
establish how LISP will really work in the long-term, you need to
plan now for how LISP-ALT will handle hundred of millions of EIDs for
individual mobile devices.

  - Robin

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Tue, 1 Sep 2009 11:16:00 -0700

> for the WG as currently chartered, I want to make two points.

Robin,

The WG received no such direct guidance from the Area Director (Jari).
Only words to the effect that we should focus on the main spec's first,
to build a solid foundation for any follow on work.

-Darrel

---

From: Jari Arkko <[email-masked]>
Date: Tue, 01 Sep 2009 21:27:48 +0300

Then maybe I need to be clearer. Mobility and many other advanced 
features are out of scope. For now. When you complete the base 
specifications, we can talk about rechartering to add more features.

Jari

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Tue, 1 Sep 2009 11:28:50 -0700

> specifications, we can talk about rechartering to add more features.

Thanks for being clear Jari.

-Darrel

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 1 Sep 2009 11:34:28 -0700

Robin, I just want to make one technical response with a few points:

(1) LISP-ALT does not carry mappings.

(2) LISP-ALT carries EID-prefixes registered from sites to a specific  
aggregation boundary.

(3) LISP-ALT also carries aggregated EID-prefixes into the core (the  
LISP-ALT core), upstream from the aggregation boundaries.

(4) When a mobile-node changes locations and gets a new locator,  
nothing in LISP-ALT changes. The mobile-node keeps Map-Registering to  
its Map-Server which is the same ALT topological point regardless  
where the mobile-node moves to or how often it moves. Mobile-node  
roaming causes no route injection or withdrawal in the BGP that runs  
on the ALT.

I have enclosed a picture of how the mapping database architecture is  
modular. So if you want to remove the center piece (labeled ALT), you  
can insert your favorite solution and the outer elements don't have to  
change (i.e. xTRs and CPE devices).

Dino

P.S. Note the diagram shows a scenario with non-LISP sites as well.

On Sep 1, 2009, at 11:12 AM, Robin Whittle wrote:

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Sam Hartman <[email-masked]>
Date: Tue, 01 Sep 2009 15:02:51 -0400

>>>>> "Robin" == Robin Whittle <[email-masked]> writes:

    Robin> Short version: Since WG participants presumably believe
    Robin> that LISP-ALT is either the only possible solution to the
    Robin> scalable routing problem, or that it is clearly superior to
    Robin> the alternatives (LISP-NERD, APT and Ivip), then AFAIK the
    Robin> WG must be planning to make LISP-ALT work in a future
    Robin> scenario in which the great majority of its hundreds of
    Robin> millions of EIDs are for individual mobile devices.

    Robin>                 If the scalable routing solution doesn't
    Robin> need to handle mobile devices, then there will never be
    Robin> more than a few million, perhaps 10 million, EIDs.

I don't think there is a consensus that lisp-alt is superior.  It's
simply what we have to experiment with today and what this WG is
chartered to specify.  I think that the people I've talked to suspect
that the mapping system is going to require a lot of work and that is probably one of the bits that may well be revised between experimental and standards track.

So, while working on alt, we're also working on requirements for a
standards-track mapping system.

---

From: Robin Whittle <[email-masked]>
Date: Wed, 02 Sep 2009 14:43:54 +1000

I am replying to Noel, Dino and Sam.

Short version:   If the purpose of the WG is to explore LISP on an
                 experimental basis, then that's fine - Mobility
                 can be ignored.

                 However, since the purpose of this exploration is to
                 devise a lasting system for the Internet, then in
                 laying the experimental foundations of LISP-ALT, we
                 need to ensure this basis is correct for the long-
                 term task of solving the routing scaling problem.

                 Mobility is a vital part of the future of the
                 Internet.  Conventional mobility techniques don't
                 provide global mobility, in any access network,
                 with generally optimal path lengths and full
                 compatibility with existing non-mobile hosts.
                 The TTR Mobility approach solves these problems -
                 for IPv4 and IPv6.

                 So I think the current work of the WG needs to at
                 least involve some plan for how LISP-ALT will
                 handle mobility.  Without this, the work risks
                 being irrelevant to the final design of the
                 optimal routing scaling problem.

                 If there's no need for mobility, the total number
                 of EIDs is limited - so it is not so hard to
                 design a good system.  Then, something simpler
                 like NERD would be preferable to ALT.

                 Mobility in the form of the TTR approach will
                 definitely happen, because this is the only
                 mobility system (AFAIK) which provides global
                 mobility, in any access network (including behind
                 NAT), with generally optimal path lengths and with
                 session continuity - while remaining compatible with
                 existing apps and stacks.  (Also, it will work fine
                 for IPv4 and IPv6.)  Conventional mobile IP can't do
                 these things.

                 TTR mobility will happen irrespective of the
                 routing scaling problem, so any solution to the
                 routing scaling problem needs to integrate it,
                 rather than let it run as a separate system.  The
                 TTR approach should work fine for LISP.

                 The current LISP-mobile approach has many problems:

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

                 not least that each IPv4 MN using this approach
                 would require not just its EID address, but a full
                 public RLOC address to for its CoA.  It can't work
                 with the MN behind NAT, which is the typical
                 connectivity arrangement for IPv4.  The TTR approach
                 works fine with the MN behind NAT.

Noel wrote:

> Actually, ALT is generally considered a short-medium term thing -
> for the long term, the concept is to replace it.

Is this the consensus view?  If so, then why bother with ALT at all?
 The whole challenge is to devise an architecture which will work for
decades.  Why not develop the proper solution, if ALT is not it?

> (1) LISP-ALT does not carry mappings.

The entire scalable routing system needs to scale to some number of
EIDs.  LISP-ALT's major - perhaps only - claim to superiority is that
it can, supposedly, scale to arbitrary numbers of EIDs since there is
no need to have any one device or communication path handle the total
mapping data for all EIDs, or updates to that.

The LISP ALT network needs to convey a packet sent by an ITR, with a
destination address being the EID of the destination host, to either:

  1 - The ETR (or one of multiple ETRs) which is currently
      authoritative for the mapping for the EID prefix which the
      destination host's EID address is part of,

or:

  2 - To some device which, while not being authoritative or an ETR,
      does know the current mapping and can send the mapping back to
      ITR via the Internet.

Therefore, the ALT network needs to be able to handle these packets
from ITRs (whether they are map requests, or initial traffic packets
which also function as map requests) and have all its ALT routers
already set up, via the ALT BGP system, to forward those packets
correctly.

> (2) LISP-ALT carries EID-prefixes registered from sites to a
>     specific aggregation boundary.
>
> (3) LISP-ALT also carries aggregated EID-prefixes into the core
>     (the LISP-ALT core), upstream from the aggregation boundaries.

I don't think the LISP-ALT network physically carries either mappings
or EID prefixes.  It carries map-request packets from any ITR,
ideally via a short path, to a device such as an ETR which can
reliably answer the request and send mapping information directly to
the ITR.

>     nothing in LISP-ALT changes.  The mobile-node keeps
>     Map-Registering to its Map-Server which is the same ALT
>     topological point regardless where the mobile-node moves to
>     or how often it moves. Mobile-node roaming causes no route
>     injection or withdrawal in the BGP that runs on the ALT.

Yes - I understand this.

> I have enclosed a picture of how the mapping database architecture
> is modular. So if you want to remove the center piece (labeled
> ALT), you can insert your favorite solution and the outer elements
> don't have to change (i.e. xTRs and CPE devices).

I don't find the diagram very helpful.

The problems with the current LISP-mobile approach do not result
directly from LISP-ALT - they are inherent in the core principle of
LISP-mobile which is to make the MN become its own ETR.

The TTR approach works differently.  The particular TTR which any one
MN is using as its ETR remains stable as the MN moves around, gaining
new and often multiple CoAs.  If the MN moves far away (such as
1000km or more) from that TTR, then it still has connectivity.
However, to reduce overall path lengths, the MN will find another TTR
which is closer to its new CoA.  There is only a change to the the
mapping of the MN's EID when it starts to use a new TTR like this.
While the mapping change is propagating, the MN can receive packets
via the old and the new TTRs simultaneously, and via its 2-way tunnel
to each of them, use either one for its outgoing packets.

With the TTR approach there are few mapping changes and there is
continual continuity via one or more CoAs to the current TTR, no
matter how rapidly CoAs are gained and lost.

With the current conception of LISP-mobile, when the MN goes to
another address (which I call a Care of Address - CoA - meaning just
that the MN gets a new point of attachment to the Net) in order to
maintain connectivity it needs to change the mapping of its own
individual EID prefix: to this new CoA.  Only when all ITRs which are
tunneling packets to the MN have this new RLOC can communication
continue.  The MN would need to send (or cause something else to
send) a secure map update message to every ITR which is caching its
old mapping.  Caching times need to be long in order to avoid
burdening the ALT network with too much map-query traffic.  So the MN
(or whatever other devices help it) has a lot of work to do as soon
as it gets a new CoA.

The longer the ITRs caching time and the more ITRs have been sending
packets to the MN during the caching time, the more updates need to
be sent and so the more management traffic and overall burden on ITRs
there will be.   There are time delays, computational and
communication costs, reliability problems etc. involved in the MN
telling a potentially large number of ITRs about its new CoA.  This
has to happen every time there is a new CoA.

With the TTR approach, when the MN gets a new CoA the MN only needs
to establish a 2 way tunnel with its current TTR (or one of its
current TTRs) in order to maintain connectivity.  The ITRs and the
mapping system are not affected by the new CoA.  A mobile device
might gain and loose CoAs automatically and so, change them every few
seconds according to radio propagation changes while travelling in
urban environments. So the TTR gets a workout - but nothing else
needs to know about each new CoA.

LISP was devised with the assumption that mappings would change
infrequently.  LISP-mobile can only work if they change frequently
and instantly.  LISP-ALT can't do either of these things.

The TTR approach will work fine within these constraints - the
mappings do not change frequently and it doesn't matter so much if
the ITRs take a while to get the updated mapping.

My understanding of the purpose of this WG is that it is to do early
development work on a particular approach to the core-edge separation
scheme - LISP-ALT.  You have chosen this over the alternatives
because you believe it is superior to them all, and to anything else
you can currently think of.

Therefore, the WG's goal is to lay the foundation for the future of
the Internet - which will include Mobility.

All I am saying is that in the current scenario where there is great
confusion about what LISP-ALT is supposed to do - how it is to be
deployed etc.

you need to plan for mobility, because it will be part of the final
total system.

I am also saying that the current LISP-mobile approach won't work and
the TTR approach will.

Hi Sam, you wrote:

> chartered to specify.

But few if any of the people in this WG would be putting any effort
into LISP-ALT if they did not think it was the best solution.

There are other solutions - NERD, APT and Ivip at least.

The fact that many people spend a huge amount of effort here working
on LISP-ALT, in preference to helping with or even publicly
critiquing APT or Ivip signifies to me that those people believe that
LISP-ALT is and will remain the best solution to the routing scaling
problem.

> I think that the people I've talked to suspect that the mapping
> system is going to require a lot of work and that is probably one
> of the bits that may well be revised between experimental and
> standards track.

> standards-track mapping system.

APT, Ivip and LISP have all been around for more than two years.  The
TTR mobility approach was first described with the initial Ivip
description in June 2007 - but it has always been a modular concept
which can work fine with LISP or APT.

I observe a bunch of people devoting all their attention to LISP, not
even bothering to critique APT or Ivip.

To me, this means that these people must believe that LISP-ALT is the
way forward.

You are different, in that you were asked to participate in this WG -
and you have graciously devoted great efforts to the task.  I
recognise you don't necessarily think that LISP-ALT is the best approach.

I am different in that I think Ivip is the best approach, but I want
to keep an eye on LISP development and learn from it.   I will
contribute to discussions when I see a problem with LISP-ALT which
seems not to be properly recognised.

 - Robin

---

From: Jari Arkko <[email-masked]>
Date: Wed, 02 Sep 2009 11:15:25 +0300

Sam, Robin,

> simply what we have to experiment with today and what this WG is

That's right. The mapping system is the area where I at least am most 
uncertain about what really works and what doesn't.

But the approach we are taking with this working group is not that we 
decided a prior that ALT (or even LISP itself) is the right answer. Our 
approach is that to fully understand the proposals we have we should 
develop them into completion and implement and test them -- only then we 
can decide if ALT actually is the right way to build mapping systems. 
There's definitely room for exploring other designs as well -- but this 
working group has to first focus on the small slice it has decided to 
take on.

Jari

---

From: Sam Hartman <[email-masked]>
Date: Wed, 02 Sep 2009 09:14:53 -0400

>>>>> "Robin" == Robin Whittle <[email-masked]> writes:

    Robin>                  However, since the purpose of this
    Robin> exploration is to devise a lasting system for the Internet,
    Robin> then in laying the experimental foundations of LISP-ALT, we
    Robin> need to ensure this basis is correct for the long- term
    Robin> task of solving the routing scaling problem.

    Robin>                  Mobility is a vital part of the future of
    Robin> the Internet.  Conventional mobility techniques don't
    Robin> provide global mobility, in any access network, with
    Robin> generally optimal path lengths and full compatibility with
    Robin> existing non-mobile hosts.  The TTR Mobility approach
    Robin> solves these problems - for IPv4 and IPv6.

I don't know what the TTR mobility approach is.
However, determining whether we agree with the statement above is out of scope.

    Robin>                  So I think the current work of the WG
    Robin> needs to at least involve some plan for how LISP-ALT will
    Robin> handle mobility.  Without this, the work risks being
    Robin> irrelevant to the final design of the optimal routing
    Robin> scaling problem.

This is definitely out of scope as well.

What is probably in scope is to contribute a section to the mapping
analysis/requirements document on what the requirements might be for
various mobility approaches if we decide LISP should support mobility.
Any effort you want to expend towards that would be greatly
appreciated.

---

From: David Meyer <[email-masked]>
Date: Wed, 2 Sep 2009 07:44:25 -0700

WG charis: Pursuant to this email:

From: Jari Arkko <[email-masked]>
To: "Darrel Lewis (darlewis)" <[email-masked]>
Cc: Robin Whittle <[email-masked]>, [email-masked]
Subject: Re: [lisp] LISP Mobility Architecture
Date: Tue, 01 Sep 2009 21:27:48 +0300

Then maybe I need to be clearer. Mobility and many other advanced
features are out of scope. For now. When you complete the base
specifications, we can talk about rechartering to add more
features.

	Can we kill this tread?

	Thanks,

	Dave

---

---

From: Robin Whittle <[email-masked]>
Date: Thu, 03 Sep 2009 02:47:17 +1000

Hi Sam,

> I don't know what the TTR mobility approach is.

I proposed the Translating Tunnel Router approach on 2007-06-15:

  http://www.ietf.org/mail-archive/web/ram/current/msg01518.html

It is fully described here:

  TTR Mobility Extensions for Core-Edge Separation Solutions to the
  Internet's Routing Scaling Problem

  Robin Whittle (First Principles) and Steven Russert (Boeing)
  http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf  2008-08-25

Briefly, a TTR behaves to LISP etc. just like any ETR.  MNs make a
2-way tunnel from their CoA (including from behind NAT) to a nearby
TTR.  The TTR also sends the MN's outgoing packets to the rest of the
world, so it may include an ITR function too.

TTRs are typically located outside access networks, so a MN using
multiple access networks in the one city or region can keep using the
same TTR.  No mapping changes for the MN's EID are required as long
as it keeps using the same TTR.  The MN can still use that TTR from a
CoA on the other side of the world, but for efficiency it would be
best to use a TTR near where it is currently located.  Then, with a
new TTR, there needs to be a mapping change.

The MN doesn't need any conventional Mobile IP capabilities, or to be
in a mobile-ready access network.  The MN gets its CoA like any other
host - WiFi, cabled Ethernet, 3G or whatever - including behind one
or more layers of NAT and including with DHCP assigned and
potentially unstable addresses.

If the MN's address lease expires and it gets another CoA, it needs
to establish a fresh tunnel from the new CoA to its one or more
current TTRs.  No mapping changes are needed for this.

The TTR system should work fine for IPv4 and IPv6.  It provides
global mobility, with the MN retaining the one EID address for all
application traffic.  The main IP stack in the MN is unchanged, as
are the applications.  The MN communicates normally with all
correspondent nodes - fixed and those using TTR mobility.

Path lengths between CNs and MNs is generally optimal, assuming there
is an ITR (or PTR) near the CN and the MN is using a TTR reasonably
nearby (< 1000 km or so).   There is no fixed "home agent", but the
system does require a sophisticated global network of TTRs.  Most
likely multiple companies will run such networks, charge for access
and compete for business.

Since one TTR, with one RLOC address, can serve thousands of MNs,
there is no wastage of RLOC space as would occur with the current
LISP-mobile approach.  Also, since MNs can be behind NAT, each MN
only consumes from the global unicast address pool its own, unique,
single IP address EID address.  With the current LISP-mobile, each MN
needs a global unicast EID address and its own global unicast (RLOC) CoA.

> Any effort you want to expend towards that would be greatly

OK, here goes:

For the TTR approach, there are no additional mapping requirements
for LISP.

Each MN has its own EID, which may be a single IP address for IPv4 or
probably a /64 for IPv6.  The mapping only needs to change as noted
above - when the MN uses another TTR.

Exactly how MNs find TTRs, how they securely establish their 2-way
encrypted tunnels to the TTR, the commercial arrangements for using
TTRs from any one TTR network etc. are all quite separate from the
core-edge separation scheme (LISP, APT, Ivip or whatever) itself.
The TTR behaves like any ETR.

Each TTR network can have its own arrangements for tunneling,
managing MNs etc. and so would provide each MN with its own software
to implement this.  Ideally there would be IETF standards for all
this, but this is a separate matter entirely from the core-edge
separation scheme.  To the core-edge separation schemes data plane,
the TTR is simply an ETR and also a source of packets, probably with
an ITR integrated in it as well.

As long as the MN has a single TTR, the mapping of the MN's EID is no
different from that of any single-homed EID - it consists simply of
the TTR's address.

If the MN has two or more active TTRs, which is possible, then the
mapping would be like a multihomed end-user network with two or more
ETR addresses in two or more ISPs.  Alternatively, the mapping can be
just for the newest, closest, TTR and it is fine for some ITRs to be
running from their cached version of the old mapping, and so
tunneling packets to the old, and now more distant, TTR.

In principle, the MN itself could control the mapping of its EID.
However, this would be very tricky and I expect the TTR system to
work best when the MN uses a commercial TTR network, whose servers
would control the mapping of the MN's EID and coordinate the way the
MN tunnels to TTRs.

That distributed network of servers would be the best place to decide
on the mapping of the the MN's EID, since that network is robust and
always connected to the Net, which the MN is not.  That network can
probe reachability of its TTRs and it will know which of potentially
several TTRs has the best connectivity to the MN.

Also, the MN has restricted, unreliable and possibly expensive
connectivity, so it would be best if the TTR company's network of
servers managed the MN and the mapping of its EID.

The TTR company's network of servers can interface to the LISP-ALT
network just like any other LISP-using end-user network - in
whichever way makes most sense for LISP.

Typically a MN would choose a single TTR company to manage its EID.
The most likely arrangement would be for that company to have a slab
of address space which it splits into individually mappable EIDs, one
for each of its MN customers.  So a single TTR network company might
control the mapping for millions or hundreds of millions of small
EIDs.  From the point of view of LISP's mapping system, this would be
exactly like a non-mobile end-user network with a large EID address
space which has chosen to split that address space into many
independently mapped EIDs.

Because mapping changes will only typically occur when the MN
connects to the Net somewhere very distant (such as > 1000km) from
its current TTR, mapping changes will not be particularly frequent.
If the mapping change takes some time to propagate to all ITRs, such
as by simple cache expiry, this is fine, since the MN can still have
tunnels to its old, and now distant, TTR, while it has tunnels to a
new, closer TTR.

Unlike the LISP-mobile approach, there is no need for mapping changes
every time the MN gets a new CoA.  Nor is there any need for the MN
to directly update the mapping cache of ITRs which are tunneling
packets to an initial, and now distant, TTR.

The current LISP-mobile I-D involves some mapping system
requirements, such as the ability of the MN to rapidly update the
mapping of ITRs which are tunneling packets addressed to its EID.  I
can't advise on this and I believe this approach to mobility - making
the MN be its own ETR - will not work.

  - Robin