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

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

Response to Brian's review Š




On 12/11/13 3:13 AM, "Marco Liebsch" <[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.
>
>
>>-----Original Message-----
>>From: Brian Haberman [mailto:[e-mail]]
>>Sent: Montag, 9. Dezember 2013 18:04
>>To: Sri Gundavelli (sgundave)
>>Cc: Hidetoshi Yokota; jouni korhonen; Marco Liebsch;
>>[e-mail]
>>Subject: Re: FW: [netext] I-D Action: draft-ietf-netext-pmip6-qos-08.txt
>>
>>All,
>>     Here are my comments on this draft...
>>
>>1. Somewhere in the front matter of the draft, there should be some
>>discussion
>>as to why existing QoS signaling mechanisms are not used (e.g., RSVP).
>>
>>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?
>
>>
>>3. Is there any expectation for infrastructure devices between the MAG
>>and LMA
>>to provide QoS services for these flows?  If so, how?  With the QoS
>>information
>>embedded in PMIP messages, how would these intermediate devices know
>>anything about these QoS parameters and any associated Per-Hop-Behaviors?
>>This needs some discussion in the draft to ensure a consistent
>>deployment view.
>
>The expectation is to prioritize traffic according to the DSCP, which is
>the
>only carried per-packet classifier being understood by transport network
>routers. Sect. 6 provides some clarification, but I agree that's a bit
>late.
>We could clarify in the introduction already what's the expectation from
>LMA, MAG and transport network infrastructure to enable QoS
>differentiation
>by using the specified option and attributes. Will add this.
>
>
>>
>>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.
>
>
>>
>>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?
>
>>
>>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,
>
>Thanks,
>
>marco