Hi Ben,
Thanks for the detailed review comments. Please see inline.
Regards
Sri
On 3/20/14 3:42 PM, "Ben Campbell" <ben(_at_)nostrum(_dot_)com> 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