RE: AD comments on draft-ietf-nsis-ntlp-14

magnus,

finally following up your comment (1): 

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email protected]] 
> Sent: 26 November 2007 16:10
> To: [email protected]; NSIS
> Subject: AD comments on draft-ietf-nsis-ntlp-14
> 
> Hi,
> 
> I am sorry for the long time this AD review has taken. I 
> really liked to read the document from first to last word 
> before progressing it. I have now done this and thinks the 
> document is in pretty good shape. I would appreciate an 
> updated version as soon as we have resolved the questions.
> 
> 
> 1. Page 29:
> "   2.  The signalling application does not wish to set up 
> state with the
>        Querying node and become its peer.  This includes the 
> case where
>        a node wishes to avoid taking part in the signalling 
> for overload
>        protection reasons.  GIST MUST propagate the Query, similar to
>        the case described in Section 4.3.4.  No message is 
> sent back to
>        the Querying node.  The application MAY provide an updated NSLP
>        payload for the same NSLPID, which will be used in the Query
>        forwarded by GIST.  Note that if the node which 
> finally processes
>        the Query returns an Error message, this will be sent directly
>        back to the originating node, bypassing any forwarders.  For
>        these diagnostics to be meaningful, any GIST node forwarding a
>        Query MUST NOT modify it except in the NSLP payload 
> and GIST hop
>        count; in particular, it MUST NOT modify any other 
> GIST payloads
>        or their order.  An implementation MAY choose to 
> achieve this by
>        retaining the original message, rather than reconstructing it
>        from some parsed internal representation."
> 
> I can't quite understand "For
>        these diagnostics to be meaningful, any GIST node forwarding a
>        Query MUST NOT modify it except in the NSLP payload 
> and GIST hop
>        count; in particular, it MUST NOT modify any other 
> GIST payloads
>        or their order."
> 
> Why does a forwarding node may modify the NSLP payload? Can 
> you please explain this? GIST hop is clearly

The question ends in "mid-air", but I can comment on the NSLP payload
aspects. Basically, when a Query message is forwarded along a path,
NSLPs are allowed to inspect and modify the payload. The end result
is that there is a single GIST peering relationship, but where the 
NSLP nodes at each end have gathered some additional data about the
signalling application state at nodes between the peers.

Note that GIST doesn't make any reliability or integrity promises 
about the transmission of this payload - it's just NSLP data being 
piggybacked on the handshake, so there are no constraints (imposed 
by GIST) on what can be done to it. However, GIST itself doesn't 
allow changes in the GIST payloads at these intermediate points, 
because then error reporting wouldn't work.

The canonical example is RMD operating edge-to-edge across a
domain. The ingress sends a GIST query to the egress and these
then peer with each other (statefully, creating a messaging
association, including storing reverse path state and so on). 
As the peering is set up (and when routing state is refreshed)
the Query also gathers RMD state information from the interior
nodes, which however don't store any RMD or GIST per-flow state.

robert h.