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

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 protected]>
Date: Tue, Feb 9, 2010 at 1:15 PM
Subject: [NSIS] I-D Action:draft-ietf-nsis-tunnel-08.txt
To: [email protected]
Cc: [email protected]


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




On Thu, Feb 4, 2010 at 7:17 AM, Charles Shen <[email protected]> wrote:
> Hi Roland, many thanks for the comments, please see inline:
>
> On Tue, Feb 2, 2010 at 7:48 PM, Roland Bless <[email protected]> wrote:
>> 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.
>
> 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.
>
>>
>> * 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.
>
>>
>> * 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.
>>
>
> 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.
>
>>   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.
>
> Will be taken into consideration in the update.
>
>
>> 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.
>
> 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)
>
>>
>> * 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...
>
> 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.
>
>>  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?
>
>
>>
>>  Furthermore, NODE_CHAR doesn't seem to be a good name for
>>  the object, NODE_CAPABILITY would probably be more suitable?
>>
>
> I don't have particularly strong opinion on the object name.
>
>
>> 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...
>
> 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 protected]
>> https://www.ietf.org/mailman/listinfo/nsis
>>
>
_______________________________________________
nsis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nsis