Subject: [lisp] Mobile LISP

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 03 Jul 2009 14:00:04 -0400

This is an interesting draft.  There is one case that I am not sure I 
follow.  It may well be that I missed something obvious.

Suppose that we have a site (A) with the EID block
10.1.0.0/16
A remote site (B), talking to servers at A, will have a cache entry for 
this block in its ITR, pointing to the ETRs for the site.

Now suppose that someone in B starts talking to a mobile node (C) from A 
that is using the EID 10.1.1.1/32.  And C has moved out of its home site.

As far as the site B ITR at can tell, 10.1.1.1 is a valid EID within 
site A.  How will B know that it needs to issue a query for the /32, 
since it already has the /16 entry?

Thank you,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 3 Jul 2009 11:43:07 -0700

> This is an interesting draft.  There is one case that I am not sure  
> I follow.  It may well be that I missed something obvious.

Thanks for reading it Joel.

> A remote site (B), talking to servers at A, will have a cache entry  
> for this block in its ITR, pointing to the ETRs for the site.

Right.

> Now suppose that someone in B starts talking to a mobile node (C)  
> from A that is using the EID 10.1.1.1/32.  And C has moved out of  
> its home site.

Okay.

> since it already has the /16 entry?

The ITRs at site A will have to update the caches of all the remote  
sites currently talking to site A. This can be done two ways:

o The ITRs can send an SMR-bit in data packets going to the site. That  
causes the remote ITRs
   to send Map-Requests to site A. Site A will need to reply with two  
EID-prefix records in the
   Map-Reply, one which is the /16 prefix and the other which is the / 
32 prefix. The information
   for LISP mobile node C is in the map-server that covers the /16  
prefix so anyone can find
   this out even the ITRs in the home site.

o Keep TTLs low, so a Map-Request will be sent for LISP mobile node C  
with EID 10.1.1.1/32.

o Have the ITRs send a Map-Request to the remote sites for their EID- 
prefix but include mapping
   data for the 10.1.1.1/32 mapping entry. If the remote sites use  
"accept-map-request-data" with
   or without verification, They can put the more specific entry in  
their map-cache.

We have not documented any of this because we have not decided which  
is the best approach. What do you think?

Dino

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 03 Jul 2009 15:48:23 -0400

If I am reading you right, as described, a site with fixed 
infrastructure and a lot of mobile nodes needs to send its short prefix 
and ALL the long prefixes (that are not home)  to anyone who asks about 
the short prefix?  That does not seem like a good trade.

Unfortunately, the alternative seems to require a way to say
prefix/16 :-> ETR list
prefix/20 :-> Ask for details
so that a site can allocate a block to mobile nodes, and tell anyone who 
inquires that they will need more details for anything in that block. 
Having to tell anyone who asks about a fixed server about all the mobile 
nodes that are away from home seems a bad trade.  Even if the site 
administrator things that is a small number, it is basically irrelevant 
information that they need "just in case."
(I would comment on the use of short TTLs, but that seems to be secondary.)

Yours,
Joel

Dino Farinacci wrote:
>> Now suppose that someone in B starts talking to a mobile node (C) from 
>> A that is using the EID 10.1.1.1/32.  And C has moved out of its home 
>> site.
> 
> Okay.
> 
>   Map-Reply, one which is the /16 prefix and the other which is the /32 
> prefix. The information
>   for LISP mobile node C is in the map-server that covers the /16 prefix 
> so anyone can find
> o Have the ITRs send a Map-Request to the remote sites for their 
> EID-prefix but include mapping
>   or without verification, They can put the more specific entry in their 
> map-cache.
> 
> We have not documented any of this because we have not decided which is 
> the best approach. What do you think?
> 
> Dino
> 
>>
>> Thank you,
>> Joel

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 3 Jul 2009 15:24:47 -0700

> infrastructure and a lot of mobile nodes needs to send its short  
> prefix and ALL the long prefixes (that are not home)  to anyone who  
> asks about the short prefix?  That does not seem like a good trade.

Well the LISP mobile node can do the Map-Request thing I mentioned as  
well. That would be better because the stationary site only needs the / 
32 state in it's ITRs only for the roaming LISP mobile nodes it is  
talking to.

I think this is a better fix. What I am saying is that the LISP mobile  
node can set the SMR-bit in data packets returning to the stationary  
site that has cached the /16.

We just have to spec in the main LISP spec that a decapsulated packet  
with the SMR-bit set should cause a Map-Request to be sent using the  
source EID of the packet as the target.

> so that a site can allocate a block to mobile nodes, and tell anyone  
> who inquires that they will need more details for anything in that  
> block. Having to tell anyone who asks about a fixed server about all  
> the mobile nodes that are away from home seems a bad trade.  Even if  
> the site administrator things that is a small number, it is  
> basically irrelevant information that they need "just in case."

By the way if a stationary sites or a LISP mobile node that is  
*starting* to talk to a roaming LISP mobile node, won't have this  
problem. Reason being is because a Map-Request will be sent for the / 
32 of the mobile node, the reply returned.

It might be obvious but caching a /32 first, and then a /16 later has  
no problem. It's the other way around (/16 exists and a /32 needs to  
be stored later) that you have identified as an issue.

Dino

>
> Yours,
> Joel
>
>
> Dino Farinacci wrote:
>>> This is an interesting draft.  There is one case that I am not  
>>> sure I follow.  It may well be that I missed something obvious.
>>> A remote site (B), talking to servers at A, will have a cache  
>>> entry for this block in its ITR, pointing to the ETRs for the site.
>> Right.
>>> As far as the site B ITR at can tell, 10.1.1.1 is a valid EID  
>>> within site A.  How will B know that it needs to issue a query for  
>>> the /32, since it already has the /16 entry?
>> o The ITRs can send an SMR-bit in data packets going to the site.  
>> That causes the remote ITRs
>> o Keep TTLs low, so a Map-Request will be sent for LISP mobile node  
>> C with EID 10.1.1.1/32.
>> We have not documented any of this because we have not decided  
>> which is the best approach. What do you think?
>> Dino
>>>
>>> Thank you,
>>> Joel

---

From: Scott Brim <[email-masked]>
Date: Tue, 14 Jul 2009 09:56:27 -0400

Dino Farinacci allegedly wrote on 07/03/2009 6:24 PM:
> well. That would be better because the stationary site only needs the
> /32 state in it's ITRs only for the roaming LISP mobile nodes it is
> talking to.
> 

That delays the final result by one step, but the result is still that
the correspondent site (maybe stationary) has entries for the /16 and
/32s for all of the mobile nodes it is talking to.

> source EID of the packet as the target.

How do you avoid hijacking?

> problem. Reason being is because a Map-Request will be sent for the /32
> of the mobile node, the reply returned.

... which will get SMRed as the node moves, and will have a low TTL
whether the node moves or not.

There will be many more mobile nodes than there are sites.  I'm just
trying to total up the various modes of interaction and think about how
it all scales.  It might work but I'm concerned.

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 14 Jul 2009 08:55:18 -0700

> How do you avoid hijacking?

You send a verifying Map-Request as described in the spec.

> it all scales.  It might work but I'm concerned.

Well, as you know we want to design the mapping database to support  
10^10 entries. At the time we stated this, that was the number of  
sites. So the number of LISP mobile nodes can be included in that  
number.

Dino

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 24 Jul 2009 13:50:33 +0300

This all looks quite complicated with

- short and long prefixes
- updating ITR caches, using TTLs of 1-2 to keep them in sync
- having separate cases when talking to mobile and non mobile
- mobile LISP nodes with access to map servers and resolvers

I was wondering if you considered just having a mobile ip homeagent
within a LISP site. If you added map server and resolver interface to
the home agent then you would have accomplished much what you want: LISP
ITR/ETRs can use mapping system based indirection and the rest stays as
it is.

Having standard home agent in the LISP site proxying the EIDs would
circumvent the problem of ETR knowing if a node is mobile or not. Home
agent would know that is the mobile registered to it with std mobile IP
messaging. Home agent would provide the first point of contact for those
ITR that do not know more specific match to RLOC. MN would advice the
corresponding node to use care of EID and all comes as part of mobile
IP(v6). 

Best regards
Hannu

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Dino Farinacci
>Sent: Tuesday, July 14, 2009 18:55
>To: Scott Brim
>Cc: [email-masked]
>Subject: Re: [lisp] Mobile LISP
>
>>> I think this is a better fix. What I am saying is that the LISP 
>>> mobile node can set the SMR-bit in data packets returning to the 
>>> stationary site that has cached the /16.
>>
>>> problem. Reason being is because a Map-Request will be sent for the 
>>> /32 of the mobile node, the reply returned.
>>
>> trying to total up the various modes of interaction and think about 
>> how it all scales.  It might work but I'm concerned.
>
>Well, as you know we want to design the mapping database to 
>support 10^10 entries. At the time we stated this, that was 
>the number of sites. So the number of LISP mobile nodes can be 
>included in that number.
>
>Dino
>
>

---

From: John Zwiebel <[email-masked]>
Date: Fri, 24 Jul 2009 02:38:32 -1000

On Jul 24, 2009, at 12:50 AM, Flinck, Hannu (NSN - FI/Espoo) wrote:

> within a LISP site.

Then it would be the same a the current mobile IP.  No gain.

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 24 Jul 2009 15:44:38 +0300

Not exactly, the added value would be that the "mobile ip binding" = EID
RLOC mapping is in the global mapping resolution system, so when once a
new correspondent node whose ITR didn't have the cached mapping would
get the right mapping from the mapping system. The mobile IP functions
are needed only for the case when there is a cached mapping pointing /16
or what ever shorter prefix.
 
- Hannu

________________________________

	From: ext John Zwiebel [mailto:[email-masked]] 
	Sent: Friday, July 24, 2009 15:39
	To: Flinck, Hannu (NSN - FI/Espoo)
	Cc: John Zwiebel; [email-masked]
	Subject: Re: [lisp] Mobile LISP

	On Jul 24, 2009, at 12:50 AM, Flinck, Hannu (NSN - FI/Espoo)
wrote:

		I was wondering if you considered just having a mobile
ip homeagent

		within a LISP site.

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 24 Jul 2009 09:48:01 -0700

> - short and long prefixes

There are the prefixes of the home area where the EIDs reside for  
stationary hosts. And there are more specifics that roam. The more  
specifics are only in the map-server that serves the short EID-prefix  
and the ITRs which talk to the LISP mobile node.

> - updating ITR caches, using TTLs of 1-2 to keep them in sync

You can use "verifying Map-Requests". Which means when a LISP mobile  
node moves, it can send a Map-Request to one of the locators for each  
of its map-cache entries. The receiver of such a Map-Request can see  
that the mapping data for the LISP mobile node has changed. It can (1)  
cache the new information without verifying (not recommended) or (2)  
send a verifying Map-Request back to the mobile node so it can return  
a Map-Reply with the nonce used in the verifying Map-Request.

So, you can use short TTLs or the approach above.

> - having separate cases when talking to mobile and non mobile

The separate cases are based on if the non-mobile node is at a LISP  
capable site or not. The reason for more mechanism is to interwork a  
non-LISP site with a mobile node. A mobile node which looks like a  
single LISP site (where the LISP host, ITR, and ETR are all in the  
same device).

That mechanism has to be there when a stationary non-LISP site wants  
to talk to another stationary LISP site. So we just use that for the  
mobile node case.

> - mobile LISP nodes with access to map servers and resolvers

Today you need a DNS resolver in your mobile node. This is just one  
more piece of information that can be easily put into DHCP. But we  
think its a home-base installation parameter as is the EID for the  
mobile-node. Because the map-server and the EID do not change while  
the mobile node roams.

> ITR/ETRs can use mapping system based indirection and the rest stays  

The map-server is like a home-agent, but ONLY for the control-plane.  
We don't want to make this like MIP. We want to do better and add more  
features given we have a LISP infrastructure deployed.

We can get shortest paths between any two LISP nodes while both roam.  
And allow those nodes to roam at the same time, either being a client  
or server of each other, while keeping TCP connections alive.

These LISP mobile nodes can use more than one radio at a time because  
they can be multi-homed and decide ingress policy like any other LISP  
site.

> messaging. Home agent would provide the first point of contact for  

That is exactly what the map-server does when the mobile node  
registers to it.

> corresponding node to use care of EID and all comes as part of mobile

There is some confusion. There is no more specific matching of RLOCs  
in the ITR. The underlying routing does not change due to this  
movement. The RLOCs are resident in the topology the mobile node moves  
to.

THERE IS NO WITHDRAWAL OR INJECTION OF BGP ROUTES into the underlying  
core. The BGP routing system is in steady state.

All that changes is the binding of EID to RLOC. And since the mobile  
node is the only one (i.e. the first one) to know if this change, it  
registers to the map-server so new Map-Requests can find the new  
location of the MN and existing cachers will be informed by verifying  
Map-Requests or short TTLs.

The reason we spec short TTLs is because it might make sense when  
doing mobile-node to mobile-node communication to have the MN itself  
clear it's own (smaller) cache. Where we might not want this for an  
ITR that is forwarding  packets for stationary hosts at a LISP site.

 From a scalability perspective, we are protecting the core from more  
specific routes while allowing shortest paths between any two LISP  
hosts, be it stationary or mobile. The more specific routes are in the  
mapping database AND ARE NOT PROPAGATED THROUGHOUT THE MAPPING  
DATABASE infrastructure.

The LISP mapping database is fully distributed so the more specific  
EIDs are only stored where they need to based on usage.

Dino