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

Hi Charles,

Charles Shen wrote:
> 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

Yes, exactly.

> 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.

It is also safe in the sense that the tunnel endpoint is the final
destination node of this message. So the message will also not be
forwarded any further and the initiator can immediately see in the
RESPONSE whether the Texit is tunnel-aware. I think it is also more
natural, because one uses the tunnel flow for signaling this capability
and not the end-to-end flow. IMHO the capability logically belongs more
to the tunnel flow than to the end-to-end flows. Furthermore, you don't
want to signal this for every end-to-end flow and the tunnel flow is
usually only signalled once for initial tunnel setup. So I'd prefer
this option.

> 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.

I'm also in favor of this solution.

Regards,
 Roland