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

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