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

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

FYI


>
>On 12/9/13 9:04 AM, "Brian Haberman" <[e-mail]> wrote:
>
>>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).
>
>
>Ok. We can add some considerations.
>
>1. In mobility deployments, access and core network can be in two
>different operator domains. Assumption  of  Int-serv based architecture
>will not work
>2. The QoS signaling and the models that we support have a tight relation
>to the subscriber policy and charging, in the context of QoS policy
>negotiation and so explicit signaling tied to mobility signaling is needed
>3. In general RSVP/Int-serv based models in SP network will not scale
>
>Agree. We need a motivation statement, summary of features supported and
>the architectural model. Will add few lines of text at the beginning.
>
>
>
>>
>>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...).
>
>
>Agree. 
>
>Better not to confuse this with the ARP term. Will add some explanation
>around this,
>
>
>>
>>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.
>
>
>There are some considerations here:
>
>1.) MAG and LMA apply rate-limiting and other features based on the
>negotiated QoS policies
>2.) MAG and LMA apply proper DSCP marking/re-marking on the user flows
>based on the negotiated QoS policy
>3.) Transit network honoring the QoS markings on the tunneled flows
>(tunnel peers copy the DSCP marking from inner payload to outer GRE
>header)
>
>
>>
>>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?
>
>
>It should be considered an error. May be as Carlos suggested, we will use
>a two-bit field instead of flags.
>
>
>
>
>>
>>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?
>
>
>Typically in QoS architectures, differentiated flow treatment is
>provisioned for "N" DSCP flows. In 3GPP this is the QCI groups.  These
>have to be in single digit count, else the network cannot scale.
>
>When a MAG makes a QoS service request for a subscriber flow(s), it will
>create unique service requests, each request identifying a set of flows,
>unique DSCP marking and some QoS properties (MBR, GBR ..etc). The number
>of requests cannot be more than 64 groups (given that DSCP is a 6-bit
>field). We are tying the QoS service request to a unique DSCP value. So,
>32 QoS flow groups should be sufficient.
>
>
>
>
>>
>>6. Section 4.2 only describes bit-rate-based attributes.  Is this due to
>>use cases described in other SDOs?
>
>
>Yes. To be consistent with the 3GPP and Wi-FI QoS attributes.
>
>
>>
>>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?
>
>
>Its an error condition. Will add some text in the LMA processing rules.
>
>
>
>Regards
>Sri
>
>