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

From: Roland Bless <[email-masked]>
Date: Wed, 03 Feb 2010 01:48:06 +0100

Hi,

Jukka Manner wrote:
> This starts a two-week Working Group Last Call on the tunnel draft.
> Please submit your comments by February 3rd.

Here are my comments:

* Overall the Tunnel draft is useful, especially when considering
  running things like MobileIP in combination with NSIS. We found
  it (the previous draft) quite useful during our NSIS mobility-aware
  implementation.

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

* sec. 6.2: Fig. 8
  it's not clear when the Tentry should send the (end-to-end) RESERVE
  and it can also overtake the RESERVE' messages. So the RESERVE may
  arrive well before the RESERVE' at Texit. The RESERVE' may also
  fail in some cases due to lack of resources.
  That's actually why I proposed the MSG_ID and BOUND_MSG_ID in sections
  3.2.9. and 4.6 of the qos-nslp draft. So the RESERVE should include
  a BOUND_MSG_ID and the RESERVE' should include a MSG_ID. Then it won't
  matter which message arrives first at Texit and Tentry can emit them
  "simultaneously".

* sec. 6.3: Same as in 6.2: use MSG_ID and BOUND_MSG_ID.

   When Texit
   receives the tunnel QUERY' message, it creates a reservation state
   for the tunnel session without sending a tunnel RESERVE' message
   immediately.

  I think this is in contrast to the current text in the qos-nslp draft.
  If the QUERY contains an R-flag Texit must generate a RESERVE
  immediately?

* sec. 6.4:
  the whole section should consider the use of MSG_ID and BOUND_MSG_ID
  in order to allow for using the hybrid mode. The parallel mode is
  not really useful IMHO, because you're probably requesting resources
  for an end-to-end flow that cannot be admitted within the tunnel.
  Even in sequential mode, it is not clear when the RESERVE should
  be sent and when it will finally arrive at Texit. So MSG_ID
  is also useful in this case.

* sec. 7.1:
  Is it really a GIST object that you mean here or do you mean
  a QoS NSLP object? From the description in 7.2 it really reads
  more like being an object at the NSLP level, i.e. sending
  a RESERVE with RII and NODE_CHAR. The question is also whether
  the NSLP or the GIST extracts and uses this knowledge. If GIST
  evaluates the NODE_CHAR object, it probably has to tell the NSLP
  about the results...
  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...?!

  Furthermore, NODE_CHAR doesn't seem to be a good name for
  the object, NODE_CAPABILITY would probably be more suitable?

NITS:
* p.4:
end-points that support this mechanism is called NSIS-tunnel-aware
change to:
end-points that support this mechanism are called NSIS-tunnel-aware

* p. 7: figure caption  should be on the previous page

* p. 8: figure 4 is wrapped in the middle onto p. 9

* p. 9:
   information includes the data flow ID for packets classification and
   change to:
   information includes the Flow ID for packet classification and

   [Flow ID was defined in the terminology section, so change flow ID
    to Flow ID for consistency throughout the text]

* p.10: what do the // mean in fig. 5?

* p.13: caption of Fig. 6 wrapped to next page

Figures 7,8,9 are also wrapped at page boundaries...

Regards,
 Roland

---

From: Charles Shen <[email-masked]>
Date: Thu, 4 Feb 2010 07:17:29 -0500

Hi Roland, many thanks for the comments, please see inline:

>  it (the previous draft) quite useful during our NSIS mobility-aware

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.

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

> * sec. 6.3: Same as in 6.2: use MSG_ID and BOUND_MSG_ID.

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.

>  in order to allow for using the hybrid mode.

Will be taken into consideration in the update.

> The parallel mode is

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)

>  evaluates the NODE_CHAR object, it probably has to tell the NSLP

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.

>  it may also be known in advance that it has the required

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?

>  the object, NODE_CAPABILITY would probably be more suitable?

I don't have particularly strong opinion on the object name.

> Figures 7,8,9 are also wrapped at page boundaries...

All these will be fixed in the update.

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

Thanks!

Charles

>
> Regards,
>  Roland
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nsis
>

---

From: Charles Shen <[email-masked]>
Date: Tue, 9 Feb 2010 13:48:34 -0500

Hi Roland, and all:

please find an updated NSIS-tunnel draft incorporating the message
binding mechanisms. Also according to my understanding of the current
NSLP draft, the message binding is for RESERVE messages but not for
QUERY messages. This fact is taken into consideration in the revision.
A number of other comments are addressed as well. More suggestions
welcome.

Thanks

Charles

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Tue, Feb 9, 2010 at 1:15 PM
Subject: [NSIS] I-D Action:draft-ietf-nsis-tunnel-08.txt
To: [email-masked]
Cc: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Next Steps in Signaling Working Group
of the IETF.

       Title           : NSIS Operation Over IP Tunnels
       Author(s)       : C. Shen, et al.
       Filename        : draft-ietf-nsis-tunnel-08.txt
       Pages           : 27
       Date            : 2010-02-09

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nsis-tunnel-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Thanks

Charles

---

From: Roland Bless <[email-masked]>
Date: Tue, 09 Feb 2010 22:48:39 +0100

Hi Charles,

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

> this discovery is not necessary.

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

> the texts in these few days.

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

> specify parallel / sequential / hybrid, or list everything and leave

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

> also be helpful for other NSLPs, in addition to QoS NSLP. But I am

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

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

> if you have better idea about representing this.

I have to check the new version...

Regards,
 Roland

---

From: Charles Shen <[email-masked]>
Date: Mon, 15 Feb 2010 18:13:25 -0500

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.

Thanks!

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

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

Agreed.

> the GIST peer is sufficient.

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

> the capability check fails?

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

Thanks!

Charles