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

Hi Charles,

Charles Shen wrote:
> The current version has been significantly simplified from the
> original version with the intention of preserving the core ideas but
> excluding too many alternatives to be chosen from, which hopefully
> will benefit the readers and implementers. However, if you feel any
> removed part from previous versions should actually be included,
> please feel free to point that out.

I forgot to point out that it has been improved a lot compared
to the previous version, so well done, since its a lot easier
to read.

>> * sec 4.2:
>>   tunnel exit-point to be NSIS-tunnel-aware.  If an NSIS-tunnel-aware
>>   end-point needs to know whether the other tunnel end-point is also
>>   NSIS-tunnel-aware, it uses the NSIS-tunnel capability discovery
>>   mechanism defined in Section 7.
>>
>>  it's not clear to me why this knowledge couldn't be also preconfigured
>>  as stated in the previous draft version.
> 
> The underlying assumption is that there might be situations where the
> tunnel exit-point is not known in advance, and it is difficult to be
> sure that the other end has been pre-configured. In those cases, we
> use this discovery mechanism. If pre-configuration is always possible,
> this discovery is not necessary.

Ok, it just sounds as the capability discovery must be used in all cases.

> Thanks for the pointer. I looked at the MSG_ID and BOUND_MSG_ID
> mechanism and feel they could indeed be helpful. Will work on updating
> the texts in these few days.

I saw that you submitted a new version. I'll check that in a few days.

> Whether to use parallel mode or sequential mode or hybrid mode is
> really up to the usage scenario. parallel mode offers a potentially
> lower delay comparing to sequential mode. For the sake of clarity, we
> specify the set of decisions as in the current description, and I
> would welcome a working group consensus on this (whether we should
> specify parallel / sequential / hybrid, or list everything and leave
> the decision open)

Yep. However, the outcome must be deterministic in any case.

> The original intention of making it an GIST object is that it might
> also be helpful for other NSLPs, in addition to QoS NSLP. But I am
> open on this.

The question is how an NSLP can access this information and whether
the GIST peer is sufficient.

>>  Note that Texit must be known beforehand, so it is likely that
>>  it may also be known in advance that it has the required
>>  tunnel capability...?!
> 
> In many cases, the Tentry knows the Texit when it receives a message
> that needs to be tunneled, that might be before it is sending the
> first RESERVE message, that's why it may not know the Texit's
> NSIS-tunnel capability? Did I miss something here?

??? Sorry, I'm confused now. My point was that one probably can assume
that Texit has such a capability...but the additional option check is
probably good to assure that. And: how should the Tentry react if
the capability check fails?

> The // in Figure 5 means there are other nodes in between, let me know
> if you have better idea about representing this.

I have to check the new version...

Regards,
 Roland