Subject: [Gen-art] Gen-ART LC Review of draft-ietf-netext-pmip6-qos-11

From: Ben Campbell <[email-masked]>
Date: Thu, 20 Mar 2014 17:42:00 -0500

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. 

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.

-- 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?)

-- 4.2.11:

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?

-- 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?

-- 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 ..."

By whom? 

-- 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]

-- 5:

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.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 25 Mar 2014 06:35:20 +0000

Hi Ben,

Thanks for the detailed review comments. Please see inline.

Regards
Sri

On 3/20/14 3:42 PM, "Ben Campbell" <[email-masked]> wrote:

>-- 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.

>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."
>

[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.

>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.

>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.

>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.

>Can you insert definitions or references for "charging profile" and

[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.

>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.

>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."
>
>"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

>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.

[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.

>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.

>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.

>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.

>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."

>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

[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.

>" Three functional operations have been identified ..."

[Sri] Ok 

OLD:
Three functional operations have been identified to accomplish this:

NEW:
For realizing this capability this specification identifies three

>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.

>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.

>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."
>

[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."
>

[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.

>(This repeats several times.)

[Sri] Ok.

Three occurrences. Fig 1, Fig 2 and Fig 3.

>-- 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.

>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. "

>"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"

[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

>Please reference RFC 5226 for the Expert Review policy.

[Sri] Ok