Re: Working Group Last Call: NSIS Operation over IP Tunnels

Roland Bless <[email protected]> Fri, 26 Mar 2010 07:51:09 +0100
Newsgroups gmane.ietf.nsis
Organization Institute of Telematics, Karlsruhe Institute of Technology (KIT)
Message-ID <[email protected]>
Hi Charles,

Charles Shen wrote:
> I've submitted another update, the main difference is Section 7 where
> the NODE_CAPABILITY object has been named as a QoS NSLP object instead
> of a GIST object. pls see further responses inline.

> In the latest version, the object has been renamed to be a QoS NSLP object.

I don't think that the description in section 7.2 is correct.
In my opinion, the NODE_CAPABILITY object should be contained
in the RESERVE' message:
Since it is generated by the Tentry, it can set the RII object
and will also get a reply from the other end, which is Texit
then. Otherwise Tentry should insert the RII object only if
none was present and Texit has to remove the NODE_CAPABILITY
object from the RESERVE and insert it into the RESPONSE when it comes
back from the far end. So I think the part:
   After receiving the first end-to-end
   RESERVE message and without initiating a tunnel RESERVE' message,
   Tentry inserts an RII object and a NODE_CAPABILITY object with T bit
   set into the end-to-end RESERVE message and sends it to Texit.

Should rather read:
   After receiving the first end-to-end RESERVE message, Tentry
   inserts an RII object and a NODE_CAPABILITY object with T bit
   set into the tunnel RESERVE' message (2) and sends it to Texit.
   If Texit is NSIS-tunnel-aware, it learns from the
   NODE_CAPABILITY object that Tentry is also NSIS-tunnel-aware and
   includes the same object with T bit into the tunnel RESPONSE'
   message (4) sent back to Tentry.

Regards,
 Roland