Last Call Review of draft-ietf-netext-pmip6-qos-11
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
Please resolve these comments along with any other Last Call comments
you may receive.
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.
Are there any implications for DSCP marking across the PMIP tunnel that should be discussed?(e.g. RFC2983)?
*** 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?
-- 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?
-- 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?
-- 2.2, Service Identifier:
RFC5149 seems like it should be a normative reference, but it’s listed as informational.
-- 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.
-- 3: 3rd paragraph:
Can you insert definitions or references for "charging profile" and "subscriber profile"?
-- 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.
-- 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.]
-- 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.
-- 4.2.3, last paragraph before packet diagram:
Should the per mobile node version also say this?
- 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?
-- 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.]
-- 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?
-- 4.2.5, "Premption-Capability" and "Preemption-Vulnerablity"
Can PC and PV deadlock? Seems odd to have both.
How is Aggregate-Max-DL-Bit-Rate used with no traffic selector different than the per-session version? (that is, why have both?)
Are there rules for handling unknown vendor-specific attributes?
-- 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.
-- 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?
Can you reference something for the 3GPP QCI?
I assume that means pick one? Any guidance on how?
-- 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.
-- 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?
*** 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)
-- section 1, paragraph 2: " In particular Wireless LAN (WLAN) has been identified ... "
By whom? (consider active voice)
" Three functional operations have been identified ..."
-- 1, list item (b)
This doesn't seem like a functional operation.
-- 1, second to last paragraph: "... expected QoS class for this IP session ..."
Which session is _this_ session?
-- 2.2, AARP: " there are no sufficient resources"
I suggest "not sufficient" or "insufficient".
-- 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?
" 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"?
-- 3, paragraph after figure 1: "Figure 1 explains..."
s/explains/illustrates (or shows).
(This repeats several times.)
-- 3.1, 2nd bullet after figure 2:
-- last sentence is confusing. Consider restructuring.
-- 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]
Section uses the word "Considerations" repeatedly when I think it means "procedures" or something similar.
-- 5.1, first bullet: "multiple such entries and entry"
and _each_ entry?
-- IANA Considerations, Action 2:
Please reference RFC 5226 for the Expert Review policy.