[netext] FW: I-D Action: draft-ietf-netext-pmip6-qos-08.txt

["Sri Gundavelli (sgundave)" <[e-mail]>]

Additional response to Brian's feedback.



From: Sri Gundavelli <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, December 11, 2013 4:22 PM
To: Marco Liebsch <[e-mail]<mailto:[e-mail]>>, Brian Haberman <[e-mail]<mailto:[e-mail]>>
Cc: Hidetoshi Yokota <[e-mail]<mailto:[e-mail]>>, jouni korhonen <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [netext] I-D Action: draft-ietf-netext-pmip6-qos-08.txt

Marco/Brian

Inline …


On 12/11/13 3:13 AM, "Marco Liebsch" <[e-mail]<mailto:[e-mail]>> wrote:

Brian, thanks a lot for your review and valuable comments.

All, please see inline for some considerations to address the comments,
adding to Sri's feedback.



2. Section 2.2 refers to the Allocation and Retention Priority option as ARP and
AARP.  I assume AARP is a typo (but ARP is also an unfortunate overload...).

Good point. I don't see an issue with deviating from the 3GPP term and gain
advantage of the typo :-) to avoid confusion. What about naming the attribute
AARP instead of ARP to abbreviate Allocation And Retention Priority?


We had the typo in the Terminology section as well, keeping it consistent across, but Yokota-san fixed it :)




4. Section 4.1 says that if M=1, D=0, but there is no discussion of what to do if
M=D=1 occurs.  Is the option ignored?

The spec mandates D to be cleared when M=1. We can treat M=D=1 as violation
of the spec and reject QoS enforcement using the CANNOT_MEET_QOS_SERVICE_REQUEST
status. Description of how to set the status to this value is solely about failure in
supporting the requested QoS. If we adopt the above mechanism, the protocol
operations section 6 must add description to set this status code in case of
unambiguous flag settings.



Its a pain to define error codes for this flag combination and document them.
May be as Carlos suggested, we combine the D and M flags into a 2 bit number.

1 - Create
2 - Delete
3 - Modify
0 - Reserved - Receiver will ignore; Or allow the sender to set to 0 when re-negotiating a QoS proposal with a counter proposal





5. I am curious as to why a 5-bit Service Request ID is sufficient.  You have bits
available in the Resvd field... Wouldn't an 8-bit field make
operations/comparisons easier?

That would leave no space for additional flags in case such extension is needed.
So far the format has a good packing style. If we want to align fields to 8 bit, e.g. to
enable easier decoding, we can consider 8 bit for flags (two are used), 8 bit
for a Traffic Class field (6 used for the DS code point) and add the service request
ID to another line of 32 bit, which gives us more space for the ID, but implies
much reserved fields.
Sri, all, what do you think? According to your description 5 bit are sufficient.
Preferences to keep the packing style?


I think this is a good suggestion. Works for me This should address Brian's concern.

Yokota-san/Jouni/Pierrick/ ?


OLD:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |   Length      |D|M|Resvd|    ID   |   DSCP    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                   QoS Attribute(s)                            ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


NEW:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |   Length      |       ID      |       TC      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|M|                         Resvd                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                   QoS Attribute(s)                            ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+








6. Section 4.2 only describes bit-rate-based attributes.  Is this due to use cases
described in other SDOs?

7. What is the handling if there is a conflict between a per-node QoS attribute
and a set of per-flow QoS attributes associated with that node?

We'll add clarifying text according to Sri's feedback,


We can define a new QoS error code and handle this.

Brian - We are going to this last update and hopefully we got a head-start here with respect to your reviews. We hope to see this doc in IESG by Jan.


Regards
Sri