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

Hi Roland,

Thanks for your comment on this! Whether the NODE_CAPABILITY object
should be contained in the tunnel RESERVE' message or in the e2e
RESERVE message is a design choice that I have thought about.

The primary reason the NODE_CAPABILITY object is included in the e2e
RESERVE message is to maintain the property that "any new mechanism
introduced in this document will be limited to the tunnel end-points
only".
In the current design, the tunnel end-point will be the only nodes
that receive the message with NODE_CAPABILITY, and as the "A,B" bit
setting (01) indicates, they will either process it or ignore it,
without propagating it further.

Your suggestion represents another valid choice. In this case, all
tunnel nodes will see this object. If they don't understand, they
should just forward it (so the A,B bit should be set to 10); if they
do understand it, they process it but make no action after they have
found they were not the tunnel end-point, and forward it. One benefit
of doing this in the tunnel signaling session is that you got the
results faster than doing this in the end-to-end signaling session.

I also saw the Poll Jukka sent out about the object indicating tunnel
handling capability. Given the current context, I think using Option
number two, and carry the NODE_CAPABILITY_TUNNEL object in tunnel
signaling messages may be an interesting choice.

Thanks

Charles




On Fri, Mar 26, 2010 at 2:51 AM, Roland Bless <[email protected]> wrote:
> 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
>
_______________________________________________
nsis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nsis