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

Hi Roland:

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.

On Tue, Feb 9, 2010 at 4:48 PM, Roland Bless <[email protected]> wrote:

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

Thanks!


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

This has been further clarified in the latest version just submitted, hope
it helps.



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

Agreed.


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

In the latest version, the object has been renamed to be a QoS NSLP object.


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

It will fall back into the default case where the tunnel behaves like an
NSIS-unaware virtual link.

Thanks!

Charles


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

_______________________________________________
nsis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nsis