Subject: Re: [NSIS] Working Group Last Call: NSIS Operation over IP Tunnels

From: Roland Bless <[email-masked]>
Date: Fri, 26 Mar 2010 07:51:09 +0100

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

---

From: Charles Shen <[email-masked]>
Date: Fri, 26 Mar 2010 10:21:04 -0400

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

---

From: Roland Bless <[email-masked]>
Date: Fri, 26 Mar 2010 17:26:34 +0100

Hi Charles,

> found they were not the tunnel end-point, and forward it. One benefit

Yes, exactly.

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

> signaling messages may be an interesting choice.

I'm also in favor of this solution.

Regards,
 Roland

---

From: Charles Shen <[email-masked]>
Date: Fri, 26 Mar 2010 12:50:13 -0400

Hi Roland,

I agree.

Thanks

Charles