Subject: Re: [lisp] Mobile LISP

From: [email-masked] (Noel Chiappa)
Date: Fri, 3 Jul 2009 19:24:34 -0400 (EDT)

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

    >> The ITRs at site A will have to update the caches of all the remote
    >> sites currently talking to site A. 

    > From: "Joel M. Halpern" <[email-masked]>

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

I've been turning this problem over in the back of my mind while I was
working on my Shigenobu catalog raisonne, and in reading your message I think
I may have hit on a possible solution. (I say 'possible' because the
implementation overhead might be impractical... but I'm always optimistic
that clever implementation techniques will make things economic! :-)

(BTW, it's a solution to the _simple_ problem you describe, of 'how do you
find that someone has gone mobile'. The harder problem, of 'how do you keep
up with someone who is mobile, when they move from distant location P to
distant location Q' I seem to recall one of the LISPers [Darrell, maybe?] had
already worked on.)

So the distant ITR (at site B) sends traffic to site A, for a mobile node Ac
(you called it C, but I'd rather call it Ac to emphasize that it has an EID
from A's EID block), is sending packets for Ac to A because B's ITRs have a
mapping that says 'all of A is at A'.

What needs to happen is that if the ETRs at A can recognize that that
particular EID Ac has 'gone walkabout', if they see any incoming traffic to
that EID they can use that as a signal that the source ITR for that traffic
has incorrect, cached mapping data for Ac. They can then tell the source ITR
(at B) 'hey, your mapping for Ac is wrong, request a new one'. (I don't know
if it's possible to say 'hey, your mapping for this is wrong, here's the
right one', because without signed mappings, that's a DoS vector.)

They can also forward the traffic to the right place - yes, it causes
triangle routing for a bit, until B is updated, but that's probably better
than simply dropping it.

The inefficiency comes in in two ways.

First, all ETRs have to have a list of EIDs which are no longer at that ETR,
and incoming packets have to be checked against it. (Perhaps this can somehow
be folded into the 'route the packet to the internal destination once the
outer header has been stripped' operation, at little/no increase in overhead
for packets to other hosts within the site - but the original outer header
for such packets will have to be saved so the correct source ITR can be
notified if the lookup barfs on 'host moved'.)

Second, a mobile node has to let not just some entity which holds its current
mapping know that it has moved, but also all the ETRs through which it might
have been reached. That's since packets for it, from ITRs which hold only the
old mapping, might show up at any of them, and they all have to be able to do
the check outlined above. It's not clear how much of a problem this is,
though, and I don't remember enough of how mobile LISP works to comment.

	Noel

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 3 Jul 2009 16:33:46 -0700

> right one', because without signed mappings, that's a DoS vector.)

Noel, I think practically this can't work. A lot of times radios go  
down and the MN can't signal to anyone. And when the radios come back  
up, the MN could be somewhere else topologically.

Also, the ETRs can't tell the difference between the MN roaming or it  
is just down but stationary in the site. The MN, itself has to solve  
this problem.

> triangle routing for a bit, until B is updated, but that's probably  

I have seen cases where even if the packet to the MN is going to the  
home site, the packets can still get dropped because the MN hasn't  
come back up yet or there is latency in signaling that it is up. You  
can't do much about this.

> though, and I don't remember enough of how mobile LISP works to  

In my last email I indicated that the LISP mobile node sends an SMR to  
the sites it is currently talking to. This is the same action that an  
ITR would do when a mapping has changed at a stationary site.

In response to the SMR, the remote sites will send a new Map-Request.  
That Map-Request goes to the map-resolver that puts it on the ALT  
where the map-server gets the request with the newly registered RLOC- 
set from the LISP mobile node.

Dino

---

From: Scott Brim <[email-masked]>
Date: Tue, 14 Jul 2009 10:49:49 -0400

Noel Chiappa allegedly wrote on 07/03/2009 7:24 PM:
 So the distant ITR (at site B) sends traffic to site A, for a mobile
node Ac
> right one', because without signed mappings, that's a DoS vector.)

Noel: B sends a map-request for Ac and gets a reply from A's ETR.  It
then sends a packet to A and gets an SMR telling it to ask again.  When
it asks again, how does the request look different to A's ETR?  If A's
ETR is going to say something special the second time, why didn't it
just say it the first time?

> have been reached. 

This is a problem with all mobility solutions.  They all need
make-before-break to behave well.  In some cases those that have home
agents or other relay points might know that they are about to lose
their care-of address, even though they don't have a new one yet, and
they can tell their correspondent nodes to revert to using the home agent.

Dino Farinacci allegedly wrote on 07/03/2009 7:33 PM:
> Also, the ETRs can't tell the difference between the MN roaming or it is
> just down but stationary in the site. The MN, itself has to solve this
> problem.

How is this supposed to work?  I don't get it.  If the MN is responsible
for solving its own problem ... The ETR answers a map-request with a
full /16 including the possibly mobile node.  When a packet comes in,
does the ETR assume the node is on-site and use internal forwarding?  If
the MN is elsewhere, is there a home agent to tunnel packets to it?  If
there is not, do packets get dropped?  If they do, the MN never sees
them and never gets to send an SMR.

I think there has to be mapping information for the MN in the system
somewhere -- either injected as a /32 by some map-server (hm, security)
or resident on the home network's ETRs so that they can respond with a
/32 map-reply even if they only advertise a /16.

Dino Farinacci allegedly wrote on 07/03/2009 8:56 PM:
> It is a bit challenging because, 1) the ETR has to know which IP
> addresses for the site are mobile nodes, 2) the ETR has to ping or poll
> each one to find out when they are not around anymore.

That's where the MN has to be responsible.  It has to notify the ETR, or
someone, of its location.  MIP has all sorts of tweaks on this.

swb

---

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

> them and never gets to send an SMR.

The LISP mobile-node knows who it is talking to. It SMR's those ETRs,  
then then return Map-Requests to get the latest EID-to-RLOC binding.  
The Map-Request goes on the ALT and the Map-Server can proxy-reply for  
the LISP mobile-node.

> /32 map-reply even if they only advertise a /16.

Please read the draft, it is all explained in there. WHen the LISP  
mobile-node moves, it registers its new RLOC with the map-server that  
has an EID-prefix that covers the LISP mobile-node's EID.

Dino

---

From: Scott Brim <[email-masked]>
Date: Tue, 14 Jul 2009 14:49:48 -0400

Dino Farinacci allegedly wrote on 07/14/2009 11:59 AM:
> then then return Map-Requests to get the latest EID-to-RLOC binding. The
> Map-Request goes on the ALT and the Map-Server can proxy-reply for the
> LISP mobile-node.
> 

Dino, the first half of your answer missed my point; the second
disagrees with what you said previously and may agree with my conclusion
-- the one where you said "please read the draft".  Consider that I
might actually have read the draft, and there might be a problem with
what you said in the mail I originally replied to.

To start with you said:

  ... the ETRs can't tell the difference between the MN roaming or it
  is just down but stationary in the site. The MN, itself has to solve
  this problem.

If that's true, that means the ETR, responsible for mapping info for the
whole /16, does not have mapping info for the MN.  My question is: What
happens in a situation where the MN is out of the home site before a
correspondent node tries to talk to it?  How do initial packets from the
CN get to the MN, if the ETR doesn't know where it is?  If it doesn't
know the MN is roaming, what does put in the map-reply to the CN?  Does
it give it the /16 mapping, i.e. route packets to the MN to the home
site?  If so, what happens when a packet arrives at the ETR for the MN?

You say the MN can send an SMR because it "knows who it is talking to".
 No it can't, because no packets have reached it so it doesn't actually
know someone is trying to talk to it and thus doesn't know an SMR is
necessary.

Obviously it has to register its RLOC(s) with a map-server, but since
you said the ETR can't tell if it is roaming or down, the ETR isn't told
the MN's mapping.  Who is told?  Some special map-server associated with
the home site (since it is responsible for the EID prefix the MN is part
of)?  If it's some special map-server and not the ETR -- responsible for
the /16 -- then the ETR at least needs to know which EIDs it does _not_
have valid information for.  That's the same level of scale as having
the detailed information itself, and it hardly seems useful not to tell
it in the first place.

Can you put these two statements together and explain what you had in
mind?  Does an ETR responsible for the whole /16 find out mappings for
mobile nodes or not?  Speculating ... do you want to sequester all
mobile nodes into a particular EID sub-prefix and take that away from
the ETRs?  And if you think there is something specific I have missed in
the draft, please tell me.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 14 Jul 2009 15:53:53 -0400

It seems to me that the whole LISP mapping (and most mapping) approaches 
works better if we do not allow overlapping prefixes.   Since prefixes 
do not correspond to toplogy, this is not unreasoanble.
In that case, the mobile nodes should simp0ly come out of a block 
reserved for mobile nodes.  This can either be a sizeable portion of the 
site block (since the site block will need to be broken down to avoid 
overlap), or simply another suitably sized block.
If this is done, then one avoids any problem with misleading caches, or 
wtrying to determine who knows the status of what.  the price is that 
the mobile node behaves like a mobile node even if it is home.  This 
seems like a small price.

Yours,
Joel

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