Quality-of-Service Option for Proxy Mobile IPv6
draft-ietf-netext-pmip6-qos-12

[Ballot comment]
Thanks to the authors for working out what needed to be done to address my Discuss. It went in a slightly different way than I expected, but the outcome is good.

[Ballot comment]
I'm dropping my DISCUSS based on conversations with other IESG members, particularly Brian.  I don't think I will be able to finish the review this morning, but here are my comments up to the point where I stopped:

In Introduction, paragraph 1:

  However, handover
  and IP Flow Mobility using alternative radio access technologies,
  such as IEEE802.16 and Wireless LAN according to the IEEE802.11
  specification, are being considered by the standards [TS23.402],
  whereas inter-working with the cellular architecture to establish QoS
  policies in alternative access networks has not received much
  attention so far.

What does it mean to be "considered by the standards"?  I don't understand this sentence.

In 2.2, the definition for AARP:
      AARP is used in congestion situations when there are no sufficient
      resources for meeting all services requests.  It is used primarily
      by the Admission Control function to determine whether a
      particular service request must be rejected due to lack of
      resources, or if it must be rejected by preempting an existing
      low-priority service.

The second clause of the last sentence looks wrong.  Shouldn't it be "or if it must be satisfied by preempting an existing low-priority service?"

[Ballot discuss]
Ben Campbell's Gen-ART review and the subsequent discussion with Sri indicates that some revisions are needed. I think we need to wait for a new version of the draft before the final approval can happen.

[Ballot comment]
In Section 3.2, I think the emergency services example is over-promising a bit. Assuming that this is a hypothetical example, the idea that a service provider would have a condition imposed on it to "ensure the application traffic associated with emergency services is not impacted under any network condition" seems like a stretch. I would suggest editing this example along the following lines:

      An emergency service may require network
      resources in conditions when the network resources have been fully
      allocated to other users and the network may be experiencing
      severe congestion and in such cases the service provider may want
      to revoke resources that have been allocated and reassign them to
      emergency services.  The local mobility anchor and the mobile
      access gateway negotiate Allocation and Retention Priority (AARP)
      values for the IP sessions associated with the emergency
      applications.  The QoS option (Section 4.1) with the QoS
      Attribute, Allocation-Retention-Priority (Section 4.2.5) are used
      for this purpose.

In Section 4.2.5, the references to "QOS Traffic Selector attribute (Section 4.2.8)" should actually point to 4.2.10 where the QOS Traffic Selector attribute is defined.

In Section 4.2.10, "section 3.1 of [RFC6088]" resolves incorrectly to section 3.1 of the I-D itself, rather than section 3.1 of RFC 6088.

[Ballot comment]

- The document is very long and could have been shorter
I'd say. Too late now, but that's a pity.

- 4.2.1: If the n/w can set this, that provides a nice
kind of supercookie, assuming that any host (n/w) will
max out its allocated b/w sometimes. To track user X set
their max b/w to 24.01 Mbps and for their next-door user
Y set the max b/w to 24.09 Mbps. Not sure if you want to
note that but its just one example of many related things.

- I'm sympathetic with Ted's discuss to the effect that
this spec may not be within the WG's charter.

[Ballot discuss]
This document proposes that QoS guarantees can be made across the "diffserv-enabled IP network" in the context of handoffs between mobile networks and wifi networks (WLAN).  But if the WLAN and the MN are operated by different entities, I don't see how this can be made to work in any dependable fashion.  This leads me to suppose that the intended use case here is when the MN and WLAN are managed by the same operator.  If true, this would make it out of scope for the IETF, which generally works on protocols for the internet.  The document also doesn't appear to be covered in any explicit way by the working group charter.

So I would like to understand whether there has been any discussion about doing this within the IESG, and whether the IESG believes that it makes sense to proceed with this document given that it's arguably out of charter and also arguably out of scope for the IETF.  I realize the latter point is debatable, but at the very least if this is in-scope, it ought to see more widespread discussion.  Perhaps that decision already has IETF consensus and someone can point me to the relevant RFC, but normally I would expect to see that consensus reflected in the working group charter, and I don't see it there.

The authors and/or document shepherd may wish to weigh in on this, but should not feel pressured to do so—I think the bulk of this discussion will have to be an IESG discussion.

[Ballot comment]
In Introduction, paragraph 1:

  However, handover
  and IP Flow Mobility using alternative radio access technologies,
  such as IEEE802.16 and Wireless LAN according to the IEEE802.11
  specification, are being considered by the standards [TS23.402],
  whereas inter-working with the cellular architecture to establish QoS
  policies in alternative access networks has not received much
  attention so far.

What does it mean to be "considered by the standards"?  I don't understand this sentence.

In 2.2, the definition for AARP:
      AARP is used in congestion situations when there are no sufficient
      resources for meeting all services requests.  It is used primarily
      by the Admission Control function to determine whether a
      particular service request must be rejected due to lack of
      resources, or if it must be rejected by preempting an existing
      low-priority service.

The second clause of the last sentence looks wrong.  Shouldn't it be "or if it must be satisfied by preempting an existing low-priority service?"

[I'm going to stop my review here because I think the IESG should agree that this document is in scope before I do any more work on it.  It was after looking at Figure 1 that it occurred to me to ask the question I raised in my DISCUSS.]

[Ballot comment]
In Sec 4.2.10, for the TS Format, are there any rules for allocating the values other than 0, 1, and 2?  Most other fields have really good information about this specified.  I realize that the formats are IPv4 and IPv6, so its hard to picture other values, but future-proofing is good.  Not being familiar with the formats, I don't have other examples to hand.

Does the IANA section need more details?  For instance Sec 4.1 has the Operational Code and allocates values and has some reserved for future allocation, but this is not mentioned in the IANA section.  Similarly, Sec 4.2.5 has Preemption capability and Preemption Vulnerability both have 0 and 1 defined and 2 and 3 reserved; how would those be allocated in the future?  Sec 4.2.10, the Traffic Selector Format is another example.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-netext-pmip6-qos-11.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there are five actions which IANA needs to complete.

First, in the Mobility Options subregistry of the Mobile IPv6 parameters registry located at:

http://www.iana.org/assignments/mobility-parameters/

a new mobility option will be registered as follows:

Value: [ TBD-at-registration ]
Description: Quality of Service (QoS)
Reference: [ RFC-to-be ]

Second, a new registry is to be created called the Quality of Service Attribute registry.  This new registry will be created in the existing Mobile IPv6 parameters registry located at:

http://www.iana.org/assignments/mobility-parameters/

The new registry is to be maintained through Expert Review as defined in RFC 5226.

There are initial registrations in the registry as follows:

+-----+---------------------------------+------------------+
|Value|      Description              |  Reference      |
+-----+---------------------------------+------------------+
| 0  | Reserved                        | [ RFC-to-be ]    |
+-----+----------------------------------------------------+
| 1  | Per-MN-Agg-Max-DL-Bit-Rate      | [ RFC-to-be ]    |
+-----+----------------------------------------------------+
| 2  | Per-MN-Agg-Max-UL-Bit-Rate      | [ RFC-to-be ]    |
+-----+----------------------------------------------------+
| 3  | Per-Session-Agg-Max-DL-Bit-Rate | [ RFC-to-be ]    |
+-----+----------------------------------------------------+
| 4  | Per-Session-Agg-Max-UL-Bit-Rate | [ RFC-to-be ]    |
+-----+----------------------------------------------------+
| 5  | Allocation-Retention-Priority  | [ RFC-to-be ]    |
+-----+----------------------------------------------------+
| 6  | Aggregate-Max-DL-Bit-Rate      | [ RFC-to-be ]    |
+-----+----------------------------------------------------+
| 7  | Aggregate-Max-UL-Bit-Rate      | [ RFC-to-be ]    |
+-----+----------------------------------------------------+
| 8  | Guaranteed-DL-Bit-Rate          | [ RFC-to-be ]    |
+-----+----------------------------------------------------+
| 9  | Guaranteed-UL-Bit-Rate          | [ RFC-to-be ]    |
+-----+----------------------------------------------------+
| 10  | QoS-Traffic-Selector            | [ RFC-to-be ]    |
+-----+----------------------------------------------------+
| 11  | QoS-Vendor-Specific-Attribtute  | [ RFC-to-be ]    |
+-----+----------------------------------------------------+
| 255 | Reserved                        | [ RFC-to-be ]    |
+-----+----------------------------------------------------+

Third, in the Status Codes subregistry of the Mobile IPv6 parameters registry located at:

http://www.iana.org/assignments/mobility-parameters/

a new status code will be registered as follows:

Value: [ TBD-at-registration ]
Description: CANNOT_MEET_QOS_SERVICE_REQUEST
Reference: [ RFC-to-be ]

IANA notes that the registered value must be a number greater than 127.

Fourth, in the Update Notification Reasons Registry also located in the Mobile IPv6 parameters registry located at:

http://www.iana.org/assignments/mobility-parameters/

a new notification reason is to be registered as follows:

Value: [ TBD-at-registration ]
Description: QOS_SERVICE_REQUEST
Reference: [ RFC-to-be ]

Fifth, in the Update Notification Acknowledgement Status Registry also located in the Mobile IPv6 parameters registry located at:

http://www.iana.org/assignments/mobility-parameters/

a new notification acknowledgement is to be registered as follows:

Value: [ TBD-at-registration ]
Description: CANNOT_MEET_QOS_SERVICE_REQUEST
Reference: [ RFC-to-be ]

IANA understands that these five actions are the only ones required to be completed up-on approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

[Ballot discuss]
This document creates a new registry with allocation policy "Expert
Review" yet does not give any guidance for the Designated Experts when
they make their reviews. (Well, I am assuming that "IANA Expert Review"
maps to RFC 5226 "Expert Review".)

See RFC 5226 which says:
            The required documentation and review
            criteria for use by the Designated Expert should be provided
            when defining the registry.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Quality of Service Option for Proxy Mobile IPv6) to Proposed Standard


The IESG has received a request from the Network-Based Mobility
Extensions WG (netext) to consider the following document:
- 'Quality of Service Option for Proxy Mobile IPv6'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-03-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This specification defines a new mobility option, the Quality of
  Service (QoS) option, for Proxy Mobile IPv6.  This option can be used
  by the local mobility anchor and the mobile access gateway for
  negotiating Quality of Service parameters for a mobile node's IP
  flows.  The negotiated QoS parameters can be used for QoS policing
  and marking of packets to enforce QoS differentiation on the path
  between the local mobility anchor and the mobile access gateway.
  Furthermore, making QoS parameters available on the mobile access
  gateway enables mapping of these parameters to QoS rules that are
  specific to the access technology and allows those rules to be
  enforced on the access network using access technology specific
  approaches.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-netext-pmip6-qos/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-netext-pmip6-qos/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

Proposed Standard
This I-D specifies a new mobility extension and enables application of
QoS to different flows. And hence it is appropriate to progress this
document on standards track.

(2) The IESG approval announcement includes a Document Announcement
Write-Up.
Technical Summary:

This specification defines a new mobility option, the Quality of
Service (QoS) option, for Proxy Mobile IPv6. This option can be used
by the local mobility anchor and the mobile access gateway for
negotiating Quality of Service parameters for a mobile node's IP
flows. The negotiated QoS parameters can be used for QoS policing
and marking of packets to enforce QoS differentiation on the path
between the local mobility anchor and the mobile access gateway.
Furthermore, making QoS parameters available on the mobile access
gateway enables mapping of these parameters to QoS rules that are
specific to the access technology and allows those rules to be
enforced on the access network using access technology specific
approaches.

Working Group Summary:

The WG supports this I-D as it is relevant in the context of the
protocols applicability within 3GPP standards. There is strong support
to standardize this work. It has been reviewed multiple times by
several experts.

Document Quality:

There is at least one known implementation of the protocol. There is
good support for the specification and an interest in utilizing the
protocol as a feature by various vendors.
All reviewers of the I-D have been acknowledged in the document.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Document Shepherd: Basavaraj Patil
Responsible AD: Brian Haberman


(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I have reviewed the I-D and this version of the document is ready for
consideration by the IESG. The justification for the needed mobility
extension to support QoS especially in the scenario of a handover from
a 3GPP access to non-3GPP access is weak. But it does have
applicability in various scenario in the context of 3GPP networks and
architectures.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No. There is no need for a special review by experts from security,
operations, DNS, DHCP etc.

(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

I do not have any concerns about the document and believe it is ready
to be progressed by the IESG.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?

Yes. All authors have confirmed compliance.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No known IPR disclosure which references this document.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

There is strong WG consensus behind this document to publish it as a
proposed standard.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

None.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Formal review by a MIB Doctor, media type or URI type not needed.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

All normative references are published RFCs.

(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

There are no downward normative references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

No. Publishing this document does not change the status of other
existing RFCs.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226).

The IANA considerations section is clear and easy to understand.

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registrie

This specification defines a new mobility attribute
format, Quality of Service attribute. The format of this
attribute is described in Section 4.2. This attribute can be
carried in Quality of Service mobility option. The type values
for this attribute needs to be managed by IANA, under the
Registry, Quality of Service Attribute Registry. This registry
should be created under "Mobile IPv6 Parameters" registry at
.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

None.