Subject: [netext] Consensus call on adopting I-D draft-liebsch-netext-pmip6-qos as WG document

From: <[email-masked]>
Date: Wed, 23 May 2012 19:01:52 +0000

Hello,

The authors of the I-D: Quality of Service Option for Proxy Mobile IPv6
<draft-liebsch-netext-pmip6-qos>
http://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-01.txt

have requested the adoption of this I-D as a WG document.
The I-D itself has been presented at IETF83 and has also been reviewed by
multiple WG members.

The crux of the proposal is to extend PMIP6 signaling to enable support
for QoS.

Abstract

   This specification defines a new mobility option that can be used by
   the mobility entities in the Proxy Mobile IPv6 domain to exchange
   Quality of Service parameters associated with a subscriber's IP
   flows.  Using the QoS option, the local mobility anchor and the
   mobile access gateway can exchange available QoS attributes and
   associated values.  This enables QoS policing and labeling 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 MAG enables mapping these parameters to
   QoS rules being specific to the access technology which operates
   below the mobile access gateway.  After such mapping, QoS rules can
   be enforced on the access technology components, such as an IEEE
   802.11e Wireless LAN controller.

Please review the I-D and respond by June 6th with your opinion.
Respond to the following question:

Should the Netext WG adopt this I-D as a WG document?

Yes   [  ]
No    [  ]

Thank you.
-Chairs

---

From: John Kaippallimalil <[email-masked]>
Date: Thu, 24 May 2012 02:01:43 +0000

Hello,
This I-D addresses a gap in PMIP6 capabilities to signal QoS. Thus, it provides a valuable solution in networks that need to provision QoS for such connections.

I support the adoption of this I-D as a WG document. 

Regards,
John 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, May 23, 2012 2:02 PM
To: [email-masked]
Subject: [netext] Consensus call on adopting I-D draft-liebsch-netext-pmip6-qos as WG document

Hello,

Abstract

Yes   [  ]
No    [  ]

Thank you.
-Chairs

_______________________________________________
netext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netext

---

From: Florin Baboescu <[email-masked]>
Date: Thu, 24 May 2012 19:51:34 -0700

Hi,

I believe that this draft makes one step further in providing QoS over
PMIP links. I support the adoption of this I-D as a WG document.
Best regards,

-Florin Baboescu

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 28 May 2012 09:29:14 +0200

Hi,

Yes   [ X ]
No    [  ]

As I mention in my review of the draft, I think it addresses an
interesting missing piece and the draft itself is a very good starting
point. Therefore, I support its adoption as WG document.

Carlos

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
   GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
                IEEE Network Special Issue on
                  Video over Mobile Networks
 http://dl.comsoc.org/livepubs/ni/info/cfp/cfpnetwork0313.htm 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 28 May 2012 14:54:02 +0000

I think this draft does address the QoS part of PMIP, I support to adopt
this draft as WG item.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 29 May 2012 15:11:24 -0700

Hello folks,

I read the document.  I think it would be worthwhile to accept as a working
group document.

Yes   [ X ]
No    [   ]

I have some comments below.

==============================================

In section 3.4, it's not easy to tell the difference that is
requested for handling QCI 1, 2, and 3.   I didn't go look,
but perhaps the differences were supposed to be variations in
allowable latency.  Since already the QoS option is allowed to
specify more than just DSCP code point (first paragraph of
section 3.4), shouldn't there be the possibility to specify
specific latency requirements?

Editorial comments:

"supports enforcement of solely"  -->
         "only supports enforcement of"
         also, citation needed here.

"is considered in"  -->  "is deployed in"

re discussion of "option (II)", pg. 7:
         The need for QoS interworking is
         about the same as for option I
         between MAG and AP, right?

"The following QoS parameters are good to negotiate" ...
         This is a very ambiguous formulation

"Specifically, the following parameters" ...
         the three items should be in an
         indented list (perhaps numbered)

Sentence starting "Upon accepting a Proxy Binding"...
         is hard to parse and ambiguous

"is as specified"  -->  "are as specified"
         --> BUT: some parameters are NOT
                 "per session", so the sentence
                 contradicts earlier text.

"for using it in" --> "for use with"

"TS Format":  What are the values of the other
         254 values?  If undefined, what is the intention
         for defining future values?

"Allocation and Retention Priority":
         These look a lot different than normal QoS
         parameters.  Are these copied from the 3GPP
         specification?  Are they considered to be
         relevant to WiFi?  What if Priority were
         "only" 30 bits long and the pre-emption
         bytes were simply bits?  I'm having a bit
         of difficulty imagining these being used
         with WiFi or anything else actually.

==============================================

Regards,
Charlie P.

-- 
Regards,
Charlie P.

---

From: Hui Deng <[email-masked]>
Date: Wed, 30 May 2012 09:52:10 +0800

Hello

I have seen this draft updated by differentiating necessary QoS attributes
and Relevant QoS Attributes .
This is a good revision, thanks for update.
Should the Netext WG adopt this I-D as a WG document?

Yes   [X]
No    [  ]

Best,

-Hui

2012/5/24 <[email-masked]>

---

From: [email-masked]
Date: Wed, 30 May 2012 11:29:11 +0800

Hi all,

After reading through this version of draft, I believe it provides a 
flexible way to PMIPv6 in QoS related network architecture. I support this 
draft adopted as a WG draft.

Yes   [ X ]
No    [  ]

Best Regards,
Joy Zhou

<[email-masked]> 
发件人:  [email-masked]
2012-05-24 03:01

收件人
<[email-masked]>
抄送

主题
[netext] Consensus call on adopting I-D draft-liebsch-netext-pmip6-qos as 
WG document

Hello,

Abstract

Yes   [  ]
No    [  ]

Thank you.
-Chairs

---

From: <[email-masked]>
Date: Wed, 30 May 2012 10:31:34 +0200

Hi all, chairs and authors,

Yes   [x ]
No    [  ]

I also agree to accept the draft as WG document since the proposal extends PMIP6 signaling but does not require new MN interaction for QoS support during HO between cellular and non-cellular (and vice versa as proposed in Use Case B, right?).
If I understood correctly a HO between networks under different operators control (and between different LMAs) is not within scope, right?

Some nits I detected ...
On p.10:
, which is is a => , which is a
(i.e. pBA). => (i.e. PBA). (assuming it is Proxy Binding Acknowledgement)
On p.20:
Priority-Level: is of type unsigned 32 bit integer, and it used => Priority-Level: is of type unsigned 32 bit integer, and is used

Thanks and best regards!
Dirk

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von [email-masked]
Gesendet: Mittwoch, 23. Mai 2012 21:02
An: [email-masked]
Betreff: [netext] Consensus call on adopting I-D draft-liebsch-netext-pmip6-qos as WG document

Hello,

Abstract

Yes   [  ]
No    [  ]

Thank you.
-Chairs

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 30 May 2012 12:38:31 +0000

Hi Charlie,
thanks for your feedback and please see inline for my view on your comments.

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Charles E. Perkins
>Sent: Mittwoch, 30. Mai 2012 00:11
>To: [email-masked]
>Cc: [email-masked]
>Subject: Re: [netext] Consensus call on adopting I-D draft-liebsch-netext-
>pmip6-qos as WG document
>
>
>Hello folks,
>
>but perhaps the differences were supposed to be variations in allowable
>latency.  Since already the QoS option is allowed to specify more than just
>DSCP code point (first paragraph of section 3.4), shouldn't there be the
>possibility to specify specific latency requirements?

Good point. We wanted to propose and define a set of useful options in this
version of the draft.
Using a well defined key, such as the QCI, can help reducing the amount of options
that come with the QoS option, but on the other hand requires knowledge and
correct interpretation of these keys on components processing the QoS attributes.
So, I see advantage in also providing options that carry QoS attributes which are
intrinsically bound to the QCI, such as for latency requirements and possibly
packet error rate.

>"is considered in"  -->  "is deployed in"

Ok

>         between MAG and AP, right?

Yes, but possibly using a different protocol.

>         This is a very ambiguous formulation

Agree. We'll find something better.

>         indented list (perhaps numbered)

Ok.

>         is hard to parse and ambiguous

Agreed, sentence may mix up things.
What about this:

If a Local Mobility Anchor is enabled to support the QoS option
and accepts a received Proxy Binding Update from a Mobile Access Gateway,
the Local Mobility Anchor SHOULD build a QoS option according to the
enforced QoS rules being associated with the MN's mobility session
and send the QoS option back to the Mobile Access Gateway in the
Proxy Binding Acknowledgement message. 

[and something more:]
If such Local Mobility Anchor receives QoS attributes in a QoS option along with
a Proxy Binding Update from a Mobile Access Gateway, the Local Mobility Anchor
SHOULD validate the received QoS parameters and, where appropriate, adjust the
QoS parameters and send the approved QoS parameters back to the Mobile Access
Gateway with the Proxy Binding Acknowledgement using the QoS option.

>                 contradicts earlier text.

Ok, we'll revise and make it consistent.

>"for using it in" --> "for use with"

Ok.

>         for defining future values?

I don't think that field is interpreted in the same way as the TS Format field being
part of the traffic selector according to RFC6088, which indicates already v4 or v6
format.
This field solely indicates which TS encoding rules are used. The one and only
may be RFC6088 formatting. If the option wants to be flexible to
other formats (e.g. to identify flow labels?), we could keep that key in the
Option header but need to describe that other values are for future use
(and FFS). 

>         with WiFi or anything else actually.

True, the ARP is more related to 3GPP utilizing the bearer concepts. 
It's role in shared medium or any other non-3GPP like technologies
needs further discussion. It might help to map its original meaning in
3GPP to downgrade or drop bearers, e.g. during handover to an
overloaded access, to the bearer-less communication in non-3GPP
accesses, e.g. by downgrading requested QoS parameters.

marco

>> The authors of the I-D: Quality of Service Option for Proxy Mobile
>> IPv6 <draft-liebsch-netext-pmip6-qos>
>> The I-D itself has been presented at IETF83 and has also been reviewed
>> by multiple WG members.
>>
>> The crux of the proposal is to extend PMIP6 signaling to enable
>> support for QoS.
>>
>> Abstract
>>

---

From: "Mark Grayson (mgrayson)" <[email-masked]>
Date: Wed, 30 May 2012 14:42:19 +0200

Being able to send QoS information on-path is useful for certain PMIPv6
deployments and therefore I support adoption as WG document

Mark

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 30 May 2012 12:43:17 +0000

Hi Dirk,

thanks for spotting the nits, we'll take them into account in the next revision.

marco

>Of [email-masked]
>Sent: Mittwoch, 30. Mai 2012 10:32
>To: [email-masked]; [email-masked]
>I also agree to accept the draft as WG document since the proposal extends
>PMIP6 signaling but does not require new MN interaction for QoS support
>during HO between cellular and non-cellular (and vice versa as proposed in
>Use Case B, right?).
>If I understood correctly a HO between networks under different operators
>control (and between different LMAs) is not within scope, right?
>
>Some nits I detected ...
>On p.10:
>(i.e. pBA). => (i.e. PBA). (assuming it is Proxy Binding Acknowledgement) On
>p.20:
>Priority-Level: is of type unsigned 32 bit integer, and it used => Priority-Level:
>is of type unsigned 32 bit integer, and is used
>
>Thanks and best regards!
>Dirk
>
>The authors of the I-D: Quality of Service Option for Proxy Mobile IPv6 <draft-
>liebsch-netext-pmip6-qos> http://www.ietf.org/id/draft-liebsch-netext-
>pmip6-qos-01.txt
>
>The crux of the proposal is to extend PMIP6 signaling to enable support for
>QoS.
>
>Abstract
>

---

From: Carl Williams <[email-masked]>
Date: Wed, 30 May 2012 09:50:32 -0400

Yes   [X]
No    [  ]