Skip to main content

Last Call Review of draft-ietf-netext-pmip6-qos-11
review-ietf-netext-pmip6-qos-11-genart-lc-campbell-2014-03-20-00

Request Review of draft-ietf-netext-pmip6-qos
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2014-03-24
Requested 2014-03-13
Authors Marco Liebsch , Pierrick Seite , Hidetoshi Yokota , Jouni Korhonen , Sri Gundavelli
I-D last updated 2014-03-20
Completed reviews Genart Last Call review of -11 by Ben Campbell (diff)
Secdir Last Call review of -11 by Donald E. Eastlake 3rd (diff)
Assignment Reviewer Ben Campbell
State Completed
Request Last Call review on draft-ietf-netext-pmip6-qos by General Area Review Team (Gen-ART) Assigned
Reviewed revision 11 (document currently at 12)
Result On the Right Track
Completed 2014-03-20
review-ietf-netext-pmip6-qos-11-genart-lc-campbell-2014-03-20-00
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.