Subject: Re: [NSIS] clarifications on schulzrinne-nsis-ntlp

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 29 Jun 2003 22:55:10 -0400

Geib, Ruediger wrote:

> I don't understand how GIMPS works if a re-route occurs between
> querying node and an already discovered next-hop peer. If you've
> provided text I'd appreciate if you explain things more explicit.

This clearly needs more elaboration. There are three choices, similar to 
RSVP:

(1) explicit "trigger" if a node finds out that the next hop has 
changed; this is the RSVP mechanism where some form of notification 
mechanism from the routing table to the protocol handler is assumed. 
Clearly, in RSVP and GIMPS, this only works if the routing change is 
local to the NTLP node, not if the routing change happens somewhere a 
few hops away.

(2) An extended trigger, where the node checks the link-state routing 
table to discover that the path has changed. This makes certain 
assumptions on consistency of route computation (but you need to 
probably make those to avoid routing loops) and only works intra-domain 
and for OSPF and similar link-state protocols. This would be the best 
solution, I think, but requires more access to the routing boiler room 
than typical OS may provide.

(3) Probe: periodically, re-do the discovery operation. Again, similar 
to RSVP, except that there's an extra degree of freedom since not every 
message needs to redo the discovery, depending on the likely stability 
of routes. All indications are that leaving mobility aside that routes 
are stable for hours and days, so this may not be necessary on a 
30-second interval. (Mobility is not an issue since the message will 
visit "virgin" territory, rather than nodes with existing sessions.)

> 
> The state table seems to include information on the previous hop and
> on "the existing transport and security assosiaction to the next-hop
> peer". That's mentioned several times in the text. It may be added in
> the paragraph "each node maintains a forwarding state table that
> includes...". It's clear to me that several individual state table
> entries may refer to the same previous/next peer entries.

Indeed; added.

> 
> Two editorials:
> 
> Section 2 mentions a "GTSP". Section 6 doesn't contain a "message
> SDU" (or message content), which should at least be optional.

Old name; yes, clearly.

> 
> I don't intend to start a detailed discussion. I'm rather asking for
> a couple of clarifications by the author.

Thanks for the comments.

> Regards, Rüdiger

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