Subject: RE: nsis mobility interactions (was: RE: [NSIS] Some comments on draft-ietf-nsis-req-04.txt)

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 25 Oct 2002 09:57:59 +0100

hi Bob,

> -----Original Message-----
> From: Bob Braden [mailto:[email-masked]]
> Sent: 24 October 2002 23:17
> To: [email-masked]; [email-masked]; Hancock, Robert
> Subject: Re: nsis mobility interactions (was: RE: [NSIS] Some comments
> on draf t-ietf-nsis-req-04.txt)
> 
> 
>   *> 
>   *> [reh] You have it precisely. Whether it is critical 
> seems to be a matter for debate. Certainly, there seem to be 
> strong proponents; particular aspects to consider are that 
> teardown may be difficult in a hard handover situation,
> 
> Robert,
> 
> I don't grok the difficult teardown.  If you are moving from node A
> to node B, you need to send a teardown message to node A and a new
> allocation message to node B, right?  The only question is how you
> identify the resources in A -- do you use an identifier, or
> do you use the (old) source and destination IP addresses?  I don't
> see that the identifier buys anything.  What am I missing?
> 
> Bob
> 

Whenever i think about this, i have to admit i get confused. (One of the reasons i like the thomas seamoby draft is the abstract, which starts "IP Mobility along with RSVP makes my head hurt".)

But in the hard handover (break-before-make situation), the sort of reasoning is:
*) if you send the tear before the handover, you will lose the whole e2e path (can't find the crossover point without signaling via the new router);
*) if you wait until after the handover, you no longer have the ability to signal via the old router and you can't tear the dead branch down.
So, what would be nice is if you could send some message after the handover which had a reference to the old reservation in a way which allowed the dead branch to be removed.
(NB this path tear problem is only one of the problems, of course. the analysis documents contain several others.)

This 'reference' is generically referred to as a reservation identifier, but I guess all sorts of other techniques could also be used (something dependent on a context transfer protocol - although that sort of dependency is objected to - or simply talking directly about the old reservation, but needing some token to establish that talking about it was authorised and the token is then the identifier or maybe the crossover point is behind a NAT, or ...)

Maybe the requirement needs to be more abstractly phrased - the view that a "path-independent reservation identifier" is the right solution is pretty deep seated that it's kind of turned into a requirement in its own right, but our requirements document could be more problem oriented. 

Cheers,

Robert H.
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 25 Oct 2002 15:15:56 +0300 (EEST)

(mobility discussions, my favorite! :)

	Hi,

	Removing the old reservation is definitely an interesting 
question, but couldn't you rely on the refresh timers and set them "short 
enough" for the MN<->AR link? What I am getting at is the following 
two scenarios:

a) IF you have a context transfer (CT) mechanism, once the QoS
requirements at set up on the new AR (& path), the CT mechanisms can
trigger the NSIS daemon running on the old AR to remove the reservation on
the old path

b) If you DON'T have CT at hand, you can rely on the soft state mechanism
to remove the old reservation. How quickly this happens is a question of
refresh timers and QoS allocation strategies.

	I could image having a Tear-message that has a timer associated
with it: "Remove this reservation when the time comes". Well, to be
honest, this does sound like a needless hack, so let's stay with the
"simple" soft state mechanisms... for now...

	Regards,

	Jukka