Hi Ben, Thanks for the detailed review comments. Please see inline.
Regards Sri On 3/20/14 3:42 PM, "Ben Campbell" <[email protected]> wrote: >I am the assigned Gen-ART reviewer for this draft. For background on >Gen-ART, please see the FAQ at > ><http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > >Please resolve these comments along with any other Last Call comments >you may receive. > >Document: draft-ietf-netext-pmip6-qos-11 > >Reviewer: Ben Campbell >Review Date: 2014-03-20 >IETF LC End Date: 2014-03-26 > >Summary: This draft is on the right track, but there are issues that need >to be resolved prior to publication. > > >*** Major issues: > >-- section 3, 1st paragraph: "The access and the home network in the >Proxy Mobile IPv6 domain are assumed to be DiffServ enabled, with every >network node in the forwarding path for the mobile node¹s IP traffic >being Diffserv compliant. The per-hop behavior for providing >differential treatment based on the DiffServ marking in the packet is >assumed to be consistent throughout the Proxy Mobile IPv6 domain." > >That¹s a really big assumption. Is the scope of this draft limited to >situations where an operator controls the entire forwarding path? If so, >that might be worth an applicability statement. [Sri] A rewording is needed. We will close this one issue separately. > >Are there any implications for DSCP marking across the PMIP tunnel that >should be discussed?(e.g. RFC2983)? > [Sri] PMIPv6 uses standard GRE/IP-in-IP tunnels and no special interactions are needed between Diff-serv services and the PMIP tunnels. Considerations from RFC2983 do apply here. We can certainly add a reference to this spec. > >*** Minor issues: > >-- Section 1, first paragraph: " Current standardization effort considers >strong QoS classification and enforcement for cellular radio access >technologies." > > What efforts? Can you reference something? Or do you mean this document? [Sri] We can revise this. OLD: Current standardization effort considers strong QoS classification and enforcement for cellular radio access technologies. NEW: The current standardization efforts in 3GPP considers strong QoS classification and enforcement for cellular radio access technologies. > >-- 1, 2nd to last paragraph, last sentence: > >Much of this draft seems fairly 3GPP specific. Do you expect it to be >used by non-3GPP operators? [Sri] Yes. That is one of the key motivations. A cable operator offering SP Wi-Fi services should be able to deploy PMIP QoS based on this specification. The spec is not 3GPP specific; None of the QoS attributes, or the protocol extensions are 3GPP specific. The draft does try to be access agnostic (WLAN/LTE), but attempts to align the QoS attributes with those QoS definitions in access specific QoS architectures. > >-- 2.2, GBR: "It is assumed that the network reserves the resources for >supporting the GBR parameter." > >Can this be more precise than "the network"? Is this assumed to be useful >across the network between the LMA and MAG? How might one express a >per-flow GBR in DSCP? [Sri] We are generally introducing the terms here without bringing the PMIP architecture in to the picture. > >-- 2.2, Service Identifier: > >RFC5149 seems like it should be a normative reference, but it¹s listed as >informational. [Sri] Ack. Will move RFC5149 to Normative References: > >-- 3, 1st paragraph "The Quality of Service support in Proxy Mobile IPv6 >specified in this document is based on the Differentiated-Services >architecture..." > >That seems a little misleading. The list of QoS attributes seems very >much based on 3GPP mobile data network architectures. [Sri] Per my earlier response, nothing in the spec makes it 3GPP specific. PMIP is access agnostic mobility protocol and the QoS extensions are not specific to any access either. We did try to align the QoS attributes with 3GPP and WLAN QoS objects, but still keeping the general goal of realizing QoS services on an IP network. The QoS attributes are generic enough to provide the basic set of QoS services. > >-- 3: 3rd paragraph: > >Can you insert definitions or references for "charging profile" and >"subscriber profile"? [Sri] Ack. Will do that. > >-- 3, paragraph before figure 1: "The signaling related to QoS services >is strictly between the mobility entities and does not result in per-flow >state, or signaling to any other node in the network." > >I am confused by the assertion that QoS signaling does not result in >per-flow state, as it seem to specify several per-flow attributes that >certainly create per-flow state. [Sri] The intent of that statement is to suggest that we are not provisioning every router in the path like in RSVP. This signaling is strictly between two mobility entities where there is already subscriber state. > >-- 4.2.1, general: > >I'm concerned that the QoS requests are per-session, but there are >attributes that can effect more than one mobile session. This seems error >prone. It seems like you could easily get a conflicting per-mobile-node >requests on different sessions that effect the same mobile node. > >Does " Per-MN-Agg-Max-DL-Bit-Rate" really need a resolution of bits per >second? With a 32 bit field, this limits you to expressing values up to >the 4 gig range. (Maybe I am more optimistic than the authors about the >future of mobile network bandwidth?) [This applies to all of the various >bit-rate expressions.] > [Sri] We had this discussion in the WG on the units. We have the choice to engineer this for future but at the cost of loosing smaller rate representations, or increase the field sizes. We did realize that this limits to 4 Gbps, but we though we are covered for the currently known access technologies. In future when operators and access technologies offer such high data rates, we can certainly define a newer set of QoS Attributes. > >-- 4.2.1, last paragraph before packet format diagram: > >There could be multiple operators involved here, couldn't there? Is there >an assumption that they have a shared idea of this policy? Seems like >there could be unexpected side effects if not. [Sri] We have the text stating this needs to be resolved using of out-band mechanisms. > >-- 4.2.3, last paragraph before packet diagram: > >Should the per mobile node version also say this? [Sri] Agree. Thanks. Will include this text 4.2.1 and 4.2.2. > >- 4.2.3, "Service Flag" > >Rather than have a modifier that turns a per-session attribute into >something bigger, wouldn't it be better to a separate attribute type for >controlling all sessions in a service at once? What if you get >disagreeing attributes on different sessions? [Sri] Agree with that. But, thought if we can deal with a simple bit flag, why not avoid additional attributes. > >-- 4.2.3, "(E) flag" : "When the (E) flag is set to a value of (0), then >there is no special effect on the receiver" > >"No special effect" is vague. Pleased describe the expected behavior when >E is not set. [Issue appears in multiple times.] [Sri] Ok. Will reword. It implies the receiver should not exclude any IP flows in the computation of Guaranteed-DL-Bit-Rate/Guaranteed-UL-Bit-Rate > >-- 4.2.5, priority levels: "Values 1 to 8 should only be assigned for >services that are authorized to receive prioritized treatment within an >operator domain." > >Can you elaborate on the meaning of that? Are we assuming a single >operator domain? > >"Values 9 to 15 may be assigned to resources that are authorized by the >home network and thus applicable when a mobile node is roaming." > >Does this imply two separate independent ranges? Is 8 always higher >priority than 9? That is, are all mobile operator priorities higher than >home network priorities? [Sri] This relative prioritization is at a single node, so not sure if I understood the concern > >-- 4.2.5, "Premption-Capability" and "Preemption-Vulnerablity" > >Can PC and PV deadlock? Seems odd to have both. [Sri] There are two things. - Allocation of resources for this flow, can be it at the cost of preempting some other allocated resource - One the resources are allocated, can some other high-priority request can allocated resources at the cost of withdrawing already allocated resources for this flow ? If we tie the Priority-Level to the flow, then PC/PV can be used by the resource manger. > >-- 4.2.6: > >How is Aggregate-Max-DL-Bit-Rate used with no traffic selector different >than the per-session version? (that is, why have both?) [Sri] We have Per-Session and Per-MN attributes have more specific meaning, where the ggregate-Max-DL-Bit-Rate are always at a flow / flow group level and are intended to be used with a flow filter. > >-- 4.2.11: > >Are there rules for handling unknown vendor-specific attributes? [Sri] Its strictly up to the vendor defining the object and the handling logic. > >-- Section 5 general: > >I think the draft overuses 2119 language. There are a lot of MUST level >requirements that are simply description of protocol. You don't need a >MUST for every assertion about how the protocol works, just where >implementors need to make choices that can impact interoperability. You >can describe the basic gears of the protocol with descriptive language. [Sri] Ok. Will take a careful look. > >-- 5.1 : "The local mobility anchor MUST enforce ... " > >Is that really a MUST for all QoS rules? For example, is the requirement >to police max bit rates at the same normative level as supporting >guaranteed minimums? > >-- If the LMA wants to negotiate different QoS rules, and puts its >proposed rules in the PBA, is it limited to a subset of the rules sent by >the MAG? Can it make up a completely different set? [Sri] Ok. I agree on the aspects of enforcement we should relax the language. > >-- 6.2: > >Can you reference something for the 3GPP QCI? > >" DSCP={BE,AF11/21/31/32}" > >I assume that means pick one? Any guidance on how? [Sri] Based on the service requirement, the DSCP marking can be set to one of these values. We can add a clarifying comment. > >-- 6.2, last paragraph: > >"For the latter, the rule associated with the identified flow(s) >overrules the aggregated rules" > >Is that always true? Seems like there are at least some cases for max bit >rates where it would not apply. [Sri] A negotiated GBR for a flow, still should meet the Per-Session AMBR rates. A rewording is needed. > >-- Security Considerations: > >I'm always skeptical when a draft updates a protocol, then says that >update does not create new security considerations. In this case, you are >adding a whole new class of operations and data objects. Even if the >answer turns out to be that there are no new security concerns, I'd like >to see documentation of the thought process that led to that conclusion. > >It would help to discuss the new kinds of information objects that are >being carried as a result of the update, and why you believe the security >mechanisms in 5213 and 7077 are still adequate. For example, 5213 >recommends integrity protection, but not confidentiality protection. Is >that still good enough? Could an eavesdropper infer information about >user activity from QoS requests that could have privacy impacts? Could a >DoS attacker use application triggers to deceive the mobility anchors >into reserving all their bandwidth? > [Sri] 1.) The spec defines a new mobility option. This is like any other mobility option and does not require any new considerations. 2.) Confidentially of the content in the option. PMIPv6 relies on IPsec for all security services. If the content of the PBU needs confidentiality protection, the mobility peers can enable IPsec with Confidentiality Protection. We did not think QoS attributes require confidentiality protection. But, happy to add some text here. NEW: "The Quality of Service option used in the Proxy Mobile IPv6 signaling messages exposes the service related information of a mobile subscriber. When this information is considered to be very sensitive, care must be taken to secure the Proxy Mobile IPv6 signaling messages when carrying this sub-option. The base Proxy Mobile IPv6 specification [RFC5213] specifies the use of IPsec for securing the signaling messages, and those mechanisms can be enabled for protecting this information. Operators can potentially apply IPsec Encapsulating Security Payload (ESP) with confidentiality and integrity protection for protecting the QoS option." > > >*** Nits/editorial comments: > >-- section 1, first paragraph: "... alternative non-cellular access >technologies is not yet considered ... " > >Not yet considered by whom/what? (consider changing to active voice) [Sri] OLD: Policy control and QoS differentiation for access to the mobile operator network through alternative non-cellular access technologies is not yet considered, even though some of these access technologies are able to support QoS by appropriate traffic prioritization techniques. NEW: Policy control and QoS differentiation for access to the mobile operator network through alternative non-cellular access technologies is not yet considered by the current standardization efforts, even though some of these access technologies are able to support QoS by appropriate traffic prioritization techniques. > >-- section 1, paragraph 2: " In particular Wireless LAN (WLAN) has been >identified ... " [Sri] OLD: In particular Wireless LAN (WLAN) has been identified as an alternative technology to complement cellular radio access. NEW: Based on the deployment trends, Wireless LAN (WLAN) can be viewed as dominant alternative access technology to complement cellular radio access. > >By whom? (consider active voice) > >" Three functional operations have been identified ..." > >By whom? [Sri] Ok OLD: Three functional operations have been identified to accomplish this: NEW: For realizing this capability this specification identifies three functional operations: > >-- 1, list item (b) > >This doesn't seem like a functional operation. [Sri] Lets assume the MAG function is hosted on an access point. The MAG may obtain the QoS service request from the LMA, which it needs to enforce on the 802.11 access using WLAN specific QoS rules. It is one sense there is a function on the MAG which maps the QoS classes between the two systems and enforces them. If this does not sound right, you can suggest some text. > >-- 1, second to last paragraph: "... expected QoS class for this IP >session ..." > >Which session is _this_ session? [Sri] Typo. OLD: IP session classification characteristics, such as a Differentiated Services Code Point (DSCP) [RFC2474], and the expected QoS class for this IP session. NEW: IP session classification characteristics, such as a Differentiated Services Code Point (DSCP) [RFC2474], and the expected QoS class for the IP session. > >-- 2.2, AARP: " there are no sufficient resources" > >I suggest "not sufficient" or "insufficient". [Sri] OLD: AARP is used in congestion situations when there are no sufficient resources for meeting all services requests. NEW: AARP is used in congestion situations when there are insufficient resources for meeting all services requests. > >-- 3, 2nd paragraph: "These entities being the entry and exit points for >the mobile node¹s IP traffic are the logical choice for being the QoS >enforcement points." > >Confusing sentence. Missing commas? [Sri] Ok. OLD: These entities being the entry and exit points for the mobile node¹s IP traffic are the logical choice for being the QoS enforcement points. NEW: These entities being the entry and exit points for the mobile node¹s IP traffic, are the logical choice for being chosen as the QoS enforcement points. Or, if you can propose some text please... > >" The basic QoS primitives such as marking, metering, policing and >rate-shaping on the mobile node¹s IP flows can be enforced at these >nodes." > >I'm not sure "primitive" is the right word choice here. Perhaps >"functions" or "use cases"? [Sri] Ok. OLD: The basic QoS primitives such as marking, metering, policing and rate-shaping on the mobile node's IP flows can be enforced at these nodes. NEW: The basic QoS functions such as marking, metering, policing and rate-shaping on the mobile node's IP flows can be enforced at these nodes. > >-- 3, paragraph after figure 1: "Figure 1 explains..." > >s/explains/illustrates (or shows). > >(This repeats several times.) [Sri] Ok. Three occurrences. Fig 1, Fig 2 and Fig 3. > >-- 3.1, 2nd bullet after figure 2: > >-- last sentence is confusing. Consider restructuring. [Sri] Ok OLD: The mobile access gateway on determining that it cannot support the requested QoS service request for that mobile sends an revised QoS option in the Update Notification Acknowledgement message, which the LMA agrees to the proposed QoS parameters by sending a new Update Notification message with a modified QoS option. NEW: The mobile access gateway on determining that it cannot support the requested QoS service request for that mobile sends an Update Notification Acknowledgement message. The message contains a revised QoS option with updated set of QoS attributes. The LMA accepts the revised QoS service request by sending a new Update Notification message including the updated QoS option. > >-- 4.2.5, "preemption capability": "... flow with a lower priority level >..." > >Does that mean a lower priority flow, or a lower numerical value (which >means higher priority) [Issue appears several times] [Sri] The following text in "Priority Level" block is covering that. Lower the numerical value, higher the priority with 1 being the highest priority. "Values 1 to 15 are defined, with value 1 as the highest level of priority. " > >-- 5: > >Section uses the word "Considerations" repeatedly when I think it means >"procedures" or something similar. [Sri] May be true, but not sure if the usage is incorrect. > >-- 5.1, first bullet: "multiple such entries and entry" > >and _each_ entry? [Sri] Ok. OLD: There can be multiple such entries and entry must include the Service Request NEW: There can be multiple such entries and each entry must include the Service Request > >-- IANA Considerations, Action 2: > >Please reference RFC 5226 for the Expert Review policy. [Sri] Ok _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
