Subject: Re: [NSIS] New diff of QoS NSLP

From: Roland Bless <[email-masked]>
Date: Tue, 03 Jan 2006 16:36:42 +0100

Hi Jukka and all,

(BTW: I wish you a happy and successful new year!)

> I've made a new diff of the QoS NSLP. It is available from:
>  
> http://www.cs.helsinki.fi/u/jmanner/diff-qosnslp-08-09.html
> I'll check my emails next week. If you have questions, hopefully someone 
> else answers, yet, if you have suggestions for clarfications, please 
> provide the new text, too. Thanks.
> 
> If there are no complex and difficult comments, we'll try to go for WGLC 
> right after new year.

Ok, I still have some additional comments and maybe you can consider
them before publishing draft-09:

* Terminology:
  Flow ID: This term is not really well defined in the document.
  There should be at least the definition that flow ID means MRI.

* RESERVE processing (sec. 5.4.1) / REPLACE flag

  "If the REPLACE flag is set, the QNE SHOULD update the reservation
  state according to the QSPEC contained in the message."

  Actually, the QSPEC may be omitted in the RESERVE. This is partly
  covered by the "Full QSPEC required" Error. However, the corresponding
  paragraph (on p. 57 bottom) relates to the case when the SII is
  unknown which may not be the case. So I propose to add text as follows:
  If the REPLACE flag is set, the QNE SHOULD update the reservation
  state according to the QSPEC contained in the message (if the QSPEC
  is missing the QNE should indicate this error by replying with
  a RESPONSE containing the corresponding INFO_SPEC "Full QSPEC
  required").

* INFO_SPEC (sec. 5.1.3.6.)

         *  0x01 - State installation succeeded

         *  0x02 - Reservation created: reservation installed on
                   complete path (sent by last node).

         *  0x03 - Reservation accepted: reservation installed at this
                   QNE, but not yet installed on the rest of the path.

         *  0x04 - Reservation created but modified: reservation
                   installed, but bandwidth reserved was not the maximum
                   requested.

  If I'm correct some guidance on using the different codes is missing,
  e.g. what is the difference between 0x01 and 0x03, or implies 0x04
  also 0x02?

  From sec. 5.3.1:
  If the ACKNOWLEDGE flag is set, the QNE MUST acknowledge its state
  installation action.  It does so by sending a RESPONSE with an
  INFO_SPEC indicating that the reservation is installed at the QNE.

  (it seems that it should be 0x03, but is 0x01 also allowed?)

* RESPONSE processing (sec. 5.3.4) / SCOPING

  "A RESPONSE message MUST be sent where the QNE is the last node to
   process a RESERVE or QUERY message containing an RII object (based on
   scoping of the RESERVE or QUERY, or because this is the last node on
   the path).  In this case, the RESPONSE MUST copy the RII object from
   the RESERVE or QUERY."

  In case of scoping: is it guaranteed that the RESPONSE will not be
  forwarded further upstream (I guess that there is currently no such
  statement)? Does it make sense to allow explicit scoping together with
  an RII in a RESERVE? I would recommend to set the success code
  at least accordingly: it must not be 0x02 if the node is not the
  QNR in order to distinguish it from a "far-end response".
  So maybe we can add the following text after the quoted text above:
  "In case of a successful RESPONSE carrying an INFO_SPEC class 0x02
  the error code must not be set to 0x02 unless the RESPONSE is really
  generated by the QNR."

* RESPONSE processing (sec. 5.3.4) / ACKNOWLEDGE

  "In addition, a RESPONSE message MUST be sent when the ACKNOWLEDGE
   flag is set or when an error occurs while processing a received
   message. If the received message contains an RII object, an error
   happened, and a response should be, this object MUST be put in the
             ^^^^^^^^^^^^^^^^^^^^^^^^^????
   RESPONSE, as described above. If the RESPONSE is sent as a result of"

   There seems to be some text missing.
   I propose the following:
  "In addition, a RESPONSE message MUST be sent when the ACKNOWLEDGE
   flag is set or when an error occurs while processing a received
   message. If the received message contains an RII object and the
   ACKNOWLEDGE flag is set, a QNE generates a RESPONSE without RII
   if the QNE is not the QNR. In this case a succesful RESPONSE
   carries the INFO_SPEC with success code 0x01 and the received
   message is
   forwarded further along the path towards the QNR. In case the QNR
   receives a message with an ACKNOWLEDGE flag and an RII object it
   generates two RESPONSEs: one for the ACK towards the previous
   upstream hop as above (without RII) and one as RESPONSE containing
   the RII (and if the request was successful an INFO_SPEC with code
   0x02 ??or 0x04??).

* RESPONSE processing (sec. 5.3.4) / Success

   "If the INFO_SPEC is not used to notify error situations, see above,
   then the RESPONSE message MUST NOT be forwarded further along the
   path."

  I guess that this is only true for the precondition that the RESPONSE
  carries an RSN. If I want a confirmation back from
  the far end (success 0x02 - reservation created: reservation installed
  on complete path (sent by last node) by inserting an RII object in my
  RESERVE then the RESPONSE should be forwarded up to the node who
  inserted the RII object.

  Sometimes it's not so easy to determine the scope or preconditions
  of the statements in the draft.

* Typo(s):
  5.3.2.
  If an intermediate QNE wants to request a response for an outgoing
  message, but the message already included an RII when it arrive, the
                                                           ^arrived
  5.4.:
     This section provides rules for message processing. Not all
   possible error situation are considered. A general rule for dealing
                  ^situations
  and
  s/sucessfull / sucessful/
  throughout the text.

Best regards,
 Roland

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Jukka MJ Manner <[email-masked]>
Date: Thu, 5 Jan 2006 10:27:55 +0200 (EET)

Hi Roland,

Your comments sounds good to me. I'm not sure about the INFO_SPEC values 
you are asking about. Maybe Georgios or Andrew can answer?

Cheers,
Jukka