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

Hancock, Robert skrev:
> 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.
> 

Hi,

I think I realize what the issue is with the text. It is the usage of
the word "forwarding". To me it imply that you wouldn't change the
payload. Either you are NSLP aware and then you would process a request,
or you are not aware and you simple forward it. But it might be the
issue what is considered to be the NSLP payload. Because I do understand
that a forwarding node will need to explicit mark that it has done this.
But that doesn't seem to be a NSLP function, rather a GIST level object.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email protected]
----------------------------------------------------------------------