Subject: [lisp] LISP Mobility Architecture

From: Margaret Wasserman <[email-masked]>
Date: Sun, 26 Jul 2009 17:04:57 -0400

I was surprised to see this document on the LISP agenda for Stockholm,  
because I don't think it is in-charter for the LISP WG.

That said, I have a few technical comments on the document...

I like the idea of viewing broadband subscribers whose addresses  
change frequently as a subset of mobile nodes.  This is a particularly  
interesting case, because when they "roam" there is no "home network"  
that can be reached using their former address, so some existing  
mobility mechanisms wouldn't work in this case.  I am not sure,  
though, how this definition is consistent with later portions of the  
document that define a LISP Mobile Node as a "LISP capable fast  
roaming mobile hand-set".

I am also uncertain that the architecture described is consistent with  
the goals stated in the document.  For instance, one goal is that the  
LISP-MN must not require additional state in the mapping system.   
However, mobility is achieved by making a single mobile node look like  
a LISP site.  Could you explain how this architecture avoids  
additional state in the mapping system when it would (as I understand  
it) support mobile handsets and broadband home networks by making all  
of them into separate LISP sites?

Margaret

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 26 Jul 2009 15:42:55 -0700

> I was surprised to see this document on the LISP agenda for  
> Stockholm, because I don't think it is in-charter for the LISP WG.

Well if we are going to have a mobile Internet, and a mobile device is  
an IP host, and if moving around means some sort of an address is  
going to change, we need to scale the routing system to accommodate  
that.

Wouldn't you agree?

> change frequently as a subset of mobile nodes.  This is a  
> particularly interesting case, because when they "roam" there is no  
> "home network" that can be reached using their former address, so  
> some existing mobility mechanisms wouldn't work in this case.  I am  
> not sure, though, how this definition is consistent with later  
> portions of the document that define a LISP Mobile Node as a "LISP  
> capable fast roaming mobile hand-set".

The hosts behind the broadband link have a home network. It is the  
physical location they reside. And the addresses, their EID addresses  
are how they are reached. If you map the EID to the locator that can  
reach them, and the locators changes, you want to register the new  
mapping into the mapping database system.

The edge home router is the device that runs LISP. What overlaps in  
this device with the LISP-MN architecture is that when a new DHCP'able  
locator address is learned by this device, it is this device that  
registers the new binding.

Today with a LISP capable site the bindings are configured, so if you  
do a ISP change, at subscription time, so to speak, the ETRs are  
reconfigured to register the new bindings.

In the broadband case, the change happens when DHCP address is learned  
and hence when the register happenings.

> I am also uncertain that the architecture described is consistent  
> with the goals stated in the document.  For instance, one goal is  
> that the LISP-MN must not require additional state in the mapping  
> system.

Well we don't say that explicitly. But when we do state "no additional  
state in the mapping system" we really mean "no additional state  
throughout the entire mapping system".

The map-servers keep the state the mobile nodes register to.

> However, mobility is achieved by making a single mobile node look  
> like a LISP site.  Could you explain how this architecture avoids  
> additional state in the mapping system when it would (as I  
> understand it) support mobile handsets and broadband home networks  
> by making all of them into separate LISP sites?

Dave will explain this tomorrow in his planned presentation, but the  
short answer is mobile nodes register their bindings to their  
respective map-servers. The Map-Servers, when ALT is used as the  
mechanism to learn mappings, only advertises an aggregate route into  
the ALT. So no ALT routers have to store /32 state (/128 state for  
IPv6). No other Map-Servers have to store /32 state. No Map-Resolvers  
have to store /32 state. And only the ITRs that are talking to the  
mobile node, will store the /32 state. They must because they need to  
informed of the new locator(s) when the mobile node moves.

Dino

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

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 27 Jul 2009 10:24:16 +0300

Dino wrote:

"Well if we are going to have a mobile Internet, and a mobile device is
an IP host, and if moving around means some sort of an address is going
to change, we need to scale the routing system to accommodate that.

Wouldn't you agree?"

None of the current mobility solutions for mobile nodes require routing
system redesign. Indirection is implemented as an overlay on top of the
routing system. There are several reasons for this but time scale of the
events of routing and mobility do not match too well.

- Hannu

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Dino Farinacci
>Sent: Monday, July 27, 2009 01:43
>To: Margaret Wasserman
>Cc: [email-masked]
>Subject: Re: [lisp] LISP Mobility Architecture
>
>Stockholm, 
>Well if we are going to have a mobile Internet, and a mobile 
>device is an IP host, and if moving around means some sort of 
>an address is going to change, we need to scale the routing 
>system to accommodate that.
>
>Wouldn't you agree?
>
>particularly 
>The hosts behind the broadband link have a home network. It is 
>the physical location they reside. And the addresses, their 
>EID addresses are how they are reached. If you map the EID to 
>the locator that can reach them, and the locators changes, you 
>want to register the new mapping into the mapping database system.
>
>The edge home router is the device that runs LISP. What 
>overlaps in this device with the LISP-MN architecture is that 
>when a new DHCP'able locator address is learned by this 
>device, it is this device that registers the new binding.
>
>Today with a LISP capable site the bindings are configured, so 
>if you do a ISP change, at subscription time, so to speak, the 
>ETRs are reconfigured to register the new bindings.
>
>In the broadband case, the change happens when DHCP address is 
>learned and hence when the register happenings.
>
>Well we don't say that explicitly. But when we do state "no 
>additional state in the mapping system" we really mean "no 
>additional state throughout the entire mapping system".
>
>understand 
>Dave will explain this tomorrow in his planned presentation, 
>but the short answer is mobile nodes register their bindings 
>to their respective map-servers. The Map-Servers, when ALT is 
>used as the mechanism to learn mappings, only advertises an 
>aggregate route into the ALT. So no ALT routers have to store 
>/32 state (/128 state for IPv6). No other Map-Servers have to 
>store /32 state. No Map-Resolvers have to store /32 state. And 
>only the ITRs that are talking to the mobile node, will store 
>the /32 state. They must because they need to informed of the 
>new locator(s) when the mobile node moves.
>
>Dino
>
>>
>> Margaret
>>
>>
>>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 27 Jul 2009 00:59:58 -0700

> going

It's because they use tunneling. If we have a LISP infrastructure in  
place and it is an overlay, you use it. But the LISP tunneling/ 
encapsulation is done without triangle paths from CN to MN.

Dino

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 27 Jul 2009 07:36:11 -0400

HI Dino,

On Jul 26, 2009, at 6:42 PM, Dino Farinacci wrote:

> Well if we are going to have a mobile Internet, and a mobile device  
> is an IP host, and if moving around means some sort of an address is  

Sorry for the late reply, I was in transit.

There are a lot of things we will need in a future LISP-based Internet  
that are not in charter for the LISP WG (security, management, etc.).   
The LISP charter very clearly restricts the work of the LISP WG to 5  
items, and mobility isn't one of them.

> physical location they reside. And the addresses, their EID  
> addresses are how they are reached. If you map the EID to the  
> locator that can reach them, and the locators changes, you want to  
> register the new mapping into the mapping database system.
>
> this device with the LISP-MN architecture is that when a new  
> DHCP'able locator address is learned by this device, it is this  
> device that registers the new binding.

In this scenario, you are expecting LISP  to run on the edge of my  
home or enterprise network, but I hadn't been thinking of it that  
way...  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.

> Today with a LISP capable site the bindings are configured, so if  
> you do a ISP change, at subscription time, so to speak, the ETRs are  

I am not sure what these statements mean...  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?
> The map-servers keep the state the mobile nodes register to.

Are you also expecting that I will have my own map server within, or  
at the edge of, my home network?  Or would my mobility state be  
maintained in my ISP's map server?  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.  This works nicely.  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.
> IPv6). No other Map-Servers have to store /32 state. No Map- 
> Resolvers have to store /32 state. And only the ITRs that are  
> talking to the mobile node, will store the /32 state. They must  
> because they need to informed of the new locator(s) when the mobile  
> node moves.

I agree that this part of things will scale nicely.

Margaret

---

From: Eliot Lear <[email-masked]>
Date: Mon, 27 Jul 2009 13:45:03 +0200

Hi Margaret,

> within their network, aggregating RLOCs for a larger (logical or 

When do RLOCs sit behind a LISP router?  Most often one would expect EIDs.

Eliot

---

From: Jari Arkko <[email-masked]>
Date: Mon, 27 Jul 2009 15:07:19 +0300

> because I don't think it is in-charter for the LISP WG.

The charter focuses on basics, because we really need to figure out 
encapsulation format, failure detection, and the mapping system.

There is a ton of other interesting things that one could look at, 
including mobility. I don't mind the WG discussing some of these 
additional topics as well, but only if there's time left from the 
basics. The overall goal is not to add all possible features to Lisp, 
but to get a stable base specification that we can evaluate -- how well 
it works, does it cause problems, etc. Lets not get distracted from this 
central goal.

Jari

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 27 Jul 2009 15:41:48 +0300

Isn't this one of the mobility cases? Lisp mobile node with a routable
address?

- Hannu 

>Behalf Of ext Eliot Lear
>Sent: Monday, July 27, 2009 14:45
>To: Margaret Wasserman
>Cc: [email-masked]

---

From: David Meyer <[email-masked]>
Date: Mon, 27 Jul 2009 06:45:55 -0700

> Isn't this one of the mobility cases? Lisp mobile node with a routable

	I'm not sure what you mean by "routable address". A
	LISP MN will have a relatively static EID and 1 or more
	RLOCs.  

	Dave

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Mon, 27 Jul 2009 06:54:26 -0700

Hi Margaret,

One quick comment about a subject that has come up many times.  I want
to highlight it because this subject has come up before and I think its
important to be explicit.

> within their network, aggregating RLOCs for a larger (logical or  

We've attempted (it seems less than successfully) to state that the
anticipated typical deployment of LISP Ingress/Egress Tunnel Routers
(xTRs) are on a Customer Edge (CE) type device.  In this case LISP does
not require the participation of your ISP.  So your ISP _would not_ have
a LISP router within their network.

These RLOCs can be aggregated in the DFZ because a given (CE-->PE) link
is numbered out of the PE provider's (provider assigned) prefix (just as
they are today - lisp doesn't change this).

Hope this helps clear up some of the (apparent) confusion.

Thanks,

-Darrel

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 27 Jul 2009 07:29:17 -0700

>> is an IP host, and if moving around means some sort of an address  
>> is going to change, we need to scale the routing system to  
>> accommodate that.
>>
>> Wouldn't you agree?
>
> There are a lot of things we will need in a future LISP-based  
> Internet that are not in charter for the LISP WG (security,  
> management, etc.).  The LISP charter very clearly restricts the work  
> of the LISP WG to 5 items, and mobility isn't one of them.

Sure, I can go along with that.

I do agree with Jari's point. We have to be careful about feature- 
creep in LISP. But from customers we have talked to, deploying LISP  
*just to solve the route scalability problem* may not be compelling  
enough.

So we have to balance this view. But we can't have the cart come  
before the horse.

>>> particularly interesting case, because when they "roam" there is  
>>> no "home network" that can be reached using their former address,  
>>> so some existing mobility mechanisms wouldn't work in this case.   
>>> I am not sure, though, how this definition is consistent with  
>>> later portions of the document that define a LISP Mobile Node as a  
>>> "LISP capable fast roaming mobile hand-set".
>>

Nope, the sweet spot is in a CPE router for a branch office or SOHO  
site, or a home router in a residential site.

>> you do a ISP change, at subscription time, so to speak, the ETRs  
>> are reconfigured to register the new bindings.
>>
> home network.  So, how does that lead to reconfiguration of the ETR  
> in my home router?

You have to be clear what you are talking about. If you are moving a  
LISP mobile node, the EID goes with the node and DHCP is used to get a  
new RLOC for the EID.

If you move a stationary host, you can reassign an EID to that node is  
it's part of the allocation of the moved-to site. But this would be a  
more permanent move and not really a "roaming event".

> at the edge of, my home network?

Map-Servers are in the infrastructure, just like the DNS servers you  
use.

>  Or would my mobility state be maintained in my ISP's map server?   
> If the former, I agree that the

The Map-Server could be deployed by an interconnect provider, a  
service provider, a government, a registry, a neutral party, or a  
third party that monetized this service.

The Map-Server you use may have no relationship to the physical link  
you buy from a service provider.

> extra state is all maintained in a system that is controlled (and  
> paid for) by the entity that wants the mobility.  This works  
> nicely.  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.

If it would be complex for the service provider, don't you think it  
would be intractable for a mobile user? And do you really want users  
to control where state is put in the network?

>> Dave will explain this tomorrow in his planned presentation, but  
>> the short answer is mobile nodes register their bindings to their  
>> mechanism to learn mappings, only advertises an aggregate route  
>> into the ALT. So no ALT routers have to store /32 state (/128 state  
>> for IPv6). No other Map-Servers have to store /32 state. No Map- 

Good. Pity Dave couldn't present. He could conveyed the design to be  
more obvious to more people.

Dino

---

From: Sam Hartman <[email-masked]>
Date: Tue, 28 Jul 2009 06:35:39 -0400

>>>>> "Margaret" == Margaret Wasserman <[email-masked]> writes:

    Margaret> Sorry for the late reply, I was in transit.

    Margaret> There are a lot of things we will need in a future
    Margaret> LISP-based Internet that are not in charter for the LISP
    Margaret> WG (security, management, etc.).  The LISP charter very
    Margaret> clearly restricts the work of the LISP WG to 5 items,
    Margaret> and mobility isn't one of them.

It is my understanding of the LISP charter that security and
management are in scope, although in some cases we may choose to
document rather than solve security and management problems.  I
believe you were one of the people at the LISP BOF working to make
sure that we worked on some aspects of management.

Some aspects of management--defining a data model, management protocol
are out of scope, but understanding management concerns, etc,are in scope.

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 29 Jul 2009 11:55:37 -0400

> When do RLOCs sit behind a LISP router?  Most often one would expect  

I guess I'm not using the right terminology, sorry.  I could also be  
misunderstanding something, but...

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.

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 -- in an ISP network or perhaps at the edge  
of a large enterprise, which would result in significant scaling  
benefits for the Internet core.  However, it seems that some of the  
design decisions being made in LISP (such as UDP/IP tunneling for NAT  
traversal, statements in the mobility spec) 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.

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.

So, what am I missing or misunderstanding?

Margaret

---

From: Eliot Lear <[email-masked]>
Date: Wed, 29 Jul 2009 18:48:16 +0200

Hi Margaret,

> So, what am I missing or misunderstanding?

Not much.  I think you've got quite a lot of it (or we're both missing a
lot ;-).  I would simply ask the question, when given a choice between
chocolate and vanilla, have both.  Life's too short.  Why not go for
both home gateways AND enterprise edges?  I think it's perfectly
feasible.  What the mobile node draft then does, by the way, is take
that one further.  This tops the scaling chart.

Eliot

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 29 Jul 2009 14:14:14 -0700

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

Right.

> high level in the topology -- in an ISP network or perhaps at the  
> edge of a large

The word "transition" usually means moving from one technology to  
another. So I think it is being misused here. EIDs are used over the  
top of the core infrastructure and are not globally routable. They are  
used as TCP/UDP socket-ids and don't change when RLOCs might.

> enterprise, which would result in significant scaling benefits for  
> the Internet core.  However, it seems that some of the design  
> decisions being made in LISP (such as UDP/IP tunneling for NAT  
> traversal, statements in the

If the home is still going to use private addresses and the LISP  
architecture indicates EIDs are global addresses, NAT will still be  
needed to translate from a private address used as a TCP/UDP socket-id  
to a global one. And then you can encapsulate after the translation  
step to get multi-homing.

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

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

> So, what am I missing or misunderstanding?

LISP solves many problems due to it's level of indirection. The home  
gateway case allows you to have a single IP address as a locator much  
like a home NAT box does. But you get other benefits like:

(1) Both egress and ingress low-opex multi-homing.
(2) IPv6 usage at home to IPv6 servers wihtout needing IPv6 deployed  
between the 2 sites.
(3) Allows TCP connections to stay up while your DSL provider changes  
your IP address (i.e. your RLOC).

Dino