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