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

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 25 Oct 2002 09:13:13 +0200

Bob,

if node B gets a new allocation message with a different
source address than the old one, the complete path will 
be reserved again and the old reservation will time out,
doesn't it?
The identifier may be used to prevent that, I think. 

Regards, Rüdiger

> *> [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,
> 

> [Bob] 
> 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?
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Bob Braden <[email-masked]>
Date: Fri, 25 Oct 2002 16:30:17 GMT

*> 
  *> Bob,
  *> 
  *> if node B gets a new allocation message with a different
  *> source address than the old one, the complete path will 
  *> be reserved again and the old reservation will time out,
  *> doesn't it?
  *> The identifier may be used to prevent that, I think. 
  *> 
  *> Regards, Rüdiger
  *> 

Well, yes, that's the obvious approach, and it does not seem to use a
reservation identifier.  I was trying (and failing) to constuct an
argument for why the identifier would help.

Thanks,

Bob Braden

---

From: Bob Braden <[email-masked]>
Date: Fri, 25 Oct 2002 18:13:28 -0700 (PDT)

*> > 
  *> > I can imagine that its function is to prevent "trading" reservations
  *> > when end points move, i.e., it allows you to reuse the resources you
  *> > already have for an ongoing call, rather than allocating new resources
  *> > and freeing the old ones.  Is that right? (If so, it seems like a
  *> > second-order optimization that might be nice but is not critical.)
  *> 
  *> [reh] You have it precisely.

Well, actually, subsequent messages have enlightened me somewhat
so now I think I was dead wrong ;-)  There certainly is a lot of
confusion around this point.

Bob