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

From: Bob Braden <[email-masked]>
Date: Fri, 25 Oct 2002 22:13:45 GMT

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

This sounds like the sort of local (not E2E) mobility-specific mechanism
that I had in mind in an earlier message.  Maybe the details are not right,
but the principle sounds right.

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

If you don't have CT, or if CT fails.  It may simplify engineering of
the CT mechanism if it is allowed to occasionally fail... the soft
state will regardless clean up eventually.

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

Ugh! ;-)

Bob Braden

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

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 31 Oct 2002 09:26:27 +0100

Hi John,

I support Bob's suggestion and would like to ask you about your
and the AD's position.

Regards, Rüdiger

Bob Braden wrote:

There is a subtle difference between neighbor discovery and 
routing.  Discovery allows a node to find all the neighbor 
nodes to which signaling messages might be forwarded.
Routing determines which actual next hops are used for 
forwarding a particular signaling message.  Neighbor 
discovery involves only local information,\ while routing 
involves global information in general.
 
I can imagine that the new QoS signaling protocol [I refuse 
to call it "NSIS", because I think that's a dumb name for 
a protocol] might want to have a neighbor discovery 
mechanism (roughly an "up/down" protocol), but it might 
still want to route signaling packets using the same 
routing that is used for data packets.  Note that if you 
use "some different routing mechanism", you almost 
certainly have times when data routing differs from 
signal routing, which is busted.

Thanks,

Bob Braden

---

From: [email-masked]
Date: Fri, 1 Nov 2002 00:00:40 +0200

Hi Bob,

> I can imagine that the new QoS signaling protocol [I refuse to call it "NSIS",
> because I think that's a dumb name for a protocol] 

I haven't seriously meant that NSIS is the protocol name, I have only suggested
using it as a place holder until we start protocol work, in the WG.

> might want to have a neighbor discovery mechanism (roughly an "up/down" protocol), 
> but it might still want to route signaling packets using the same routing that
> is used for data packets.  

I think that is reasonable.

> Note that if you use "some different routing mechanism", you almost certainly have 
> times when data routing differs from signal routing, which is busted.

What do you mean by this - I think I know what you mean - do you mean
that at a conceptual level having data routing different from signaling routing
would be a 'broken' concept or something else?

John

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 31 Oct 2002 23:46:08 -0000

hi all,

[NB please note that this mail has nothing to do with either mobility interactions or the requirements draft, it's just framework terminology stuff. It also relates to other emails.]

1. I still like NTLP and NSLP (NSIS [Transport|Signalling] Layer Protocol) as terms. The fact that the N is dumb doesn't stop them being good placeholders, rather like IPng was used as a placeholder term (rfc1454, 1550, 1726 and so on). With any luck, the dumb-ness will discourage anyone from actually calling a proposed protocol 'NTLP', which is probably a good thing.

2. I think the unqualified term 'routing' should be reserved for 'what the IP layer does to work out where to forward an IP packet', and I sincerely hope there's no proposals to have different versions of this for data and signalling packets.

3. I could imagine a term like 'message routing' for 'what happens within the NTLP level to get a message to the right [NSIS] peer', which might be 'put it in an IP packet with the flow destination address and rely on the network' or 'send it explicitly to a known peer' or conceivably something else. Would that be a useful concept? (It's obviously closely related to the NSIS addressing question.)

4. I've proposed to add the term 'peer discovery' to denote 'finding implicitly or explicitly the NSIS peer to which a message for a given flow should be sent'. (Note that this is different from using the term 'discovery' to mean 'find all the NSIS entities I can talk to directly, mainly because I can't see that being easy or useful, especially in a world with a low density of NSIS-aware routers. Maybe there is a need for a different word for one of these.)

5. The proposal in the framework is then that the NTLP should do message routing by incorporating peer discovery capability based on what for shorthand I could call RSVP-like mechanisms ("Discovery should come automatically, due to the signaling." [JL]), BUT that the framework should include hooks to allow the same information to be obtained from other sources (and, I suppose, that we can discuss example mechanisms to make sure we put these hooks in the right place). Would people object to that (and would it match the charter?) Note: 'object' would mean either 'ignore the possibility, no external peer discovery mechanisms should be considered' or 'demand to incorporate the details of the external mechanisms in the framework'.

input before the -01 deadline appreciated (if we can get at least a stable and universally comprehensible terminology baseline, maybe that will count as progress),

cheers,

robert h.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 31 October 2002 22:01
> To: [email-masked]; [email-masked]; Hancock, Robert
> Cc: [email-masked]
> Subject: RE: nsis mobility interactions (was: RE: [NSIS] Some comments
> on draft-ietf-nsis-req-04.txt)
> 
> 
> Hi Bob,
> 
> to call it "NSIS",