Subject: [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt

From: Hui Deng <[email-masked]>
Date: Fri, 27 Apr 2012 19:15:39 +0800

Hello authors,

I have read through document, want to clarify below:

In the section 6, many parameters related to 3GPP air-interface has been
spcified like ARP, GDBR, GUBR,
because wifi today doesn't have such capability, just wan to know whether
you would like to extend WLC capability
to support and make wifi a much better wireless technology:)

If PMIP6 historically doesn't QoS, is that PCC will not be able to use for
PMIP6 based S5/S8 interfaces?

thanks for writing this document.

Best,

-Hui

2012/4/26 Sri Gundavelli <[email-masked]>

> Folks:
>
> Please comment on this draft. Lot of efforts went in to this from all the
> Authors, please review and comment.
>
> http://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-01.txt
>
>
>
> Regards
> Sri
>
>
>
>
> On 3/13/12 8:40 AM, "Marco Liebsch" <[email-masked]> wrote:
>
>  Please find an update of our draft about a QoS option for PMIP6 on the
> IETF repository, which
> addresses comments from last meeting. The current version includes more
> details about the
> proposed operation and QoS attributes.
>
> Marco
>
> Filename:            draft-liebsch-netext-pmip6-qos
> Revision:              01
> Title:                      Quality of Service Option for Proxy Mobile IPv6
> Creation date:   2012-03-12
> WG ID:                  Individual Submission
> Number of pages: 32
> Link: http://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-01.txt
>
> 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&#39;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.
>
>
>
> ------------------------------
>  _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext
>
>
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext
>
>

---

From: <[email-masked]>
Date: Fri, 27 Apr 2012 14:17:40 +0200

Hi Hui,

Thanks for the feedback. 

Actually, parameters like , ARP, GDBR, GUBR are optional in the QoS option. You're right, this is 3GPP QoS policy parameters but they can be provisioned to the wifi network in a 3GPP/wi-fi interworking context. And using the PMIP QoS option if we assume that the wi-fi access has no PCC. In this situation, the mobile network (here LMA) provides the QoS policies, in a 3GPP format, to the wi-fi access network (here the MAG) which is supposed to do the mapping to DSCP policies that a wifi network used to manage.

Hope that clarifies.

BR,

Pierrick

De : [email-masked] [mailto:[email-masked]] De la part de Hui Deng
Envoyé : vendredi 27 avril 2012 13:16
À : [email-masked]
Objet : [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt

Hello authors, 

In the section 6, many parameters related to 3GPP air-interface has been spcified like ARP, GDBR, GUBR,

because wifi today doesn't have such capability, just wan to know whether you would like to extend WLC capability

If PMIP6 historically doesn't QoS, is that PCC will not be able to use for PMIP6 based S5/S8 interfaces?

Best,

-Hui

Folks:

Please comment on this draft. Lot of efforts went in to this from all the Authors, please review and comment.

Regards
Sri 

	Please find an update of our draft about a QoS option for PMIP6 on the IETF repository, which
	addresses comments from last meeting. The current version includes more details about the
	proposed operation and QoS attributes. 
	 
	Marco

	Abstract:

________________________________

---

From: Hui Deng <[email-masked]>
Date: Fri, 27 Apr 2012 21:37:06 +0800

Pierrick,

thanks for your quick response,

but you also deliver dscp as well?

-Hui

2012/4/27 <[email-masked]>

>  Hi Hui,****
>
> ** **
>
> Thanks for the feedback. ****
>
> ** **
>
> Actually, parameters like , ARP, GDBR, GUBR are optional in the QoS
> option. You’re right, this is 3GPP QoS policy parameters but they can be
> provisioned to the wifi network in a 3GPP/wi-fi interworking context. And
> using the PMIP QoS option if we assume that the wi-fi access has no PCC. In
> this situation, the mobile network (here LMA) provides the QoS policies, in
> a 3GPP format, to the wi-fi access network (here the MAG) which is supposed
> to do the mapping to DSCP policies that a wifi network used to manage.****
>
> ** **
>
> Hope that clarifies.****
>
> ** **
>
> BR,****
>
> Pierrick****
>
> ** **
>
> *De :* [email-masked] [mailto:[email-masked]] *De la
> part de* Hui Deng
> *Envoyé :* vendredi 27 avril 2012 13:16
> *À :* [email-masked]
> *Objet :* [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt****
>
> ** **
>
> Hello authors, ****
>
>  ****
>
> I have read through document, want to clarify below:****
>
>  ****
>
> spcified like ARP, GDBR, GUBR,****
>
> you would like to extend WLC capability****
>
> to support and make wifi a much better wireless technology:)****
>
>  ****
>
> PMIP6 based S5/S8 interfaces?****
>
>  ****
>
> thanks for writing this document.****
>
>  ****
>
> Best,****
>
>  ****
>
> -Hui****
>
> 2012/4/26 Sri Gundavelli <[email-masked]>****
>
> Folks:
>
> Sri ****
> On 3/13/12 8:40 AM, "Marco Liebsch" <[email-masked]> wrote:****
>
>  ****
> https://www.ietf.org/mailman/listinfo/netext****
>
>
> https://www.ietf.org/mailman/listinfo/netext****
>
> ** **
>

---

From: <[email-masked]>
Date: Fri, 27 Apr 2012 17:17:29 +0200

Hi Hui,

Please see inline

Pierrick

De : Hui Deng [mailto:[email-masked]] 
Envoyé : vendredi 27 avril 2012 15:37
À : SEITE Pierrick RD-RESA-REN
Cc : [email-masked]
Objet : Re: [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt

Pierrick, 

Yes, the QoS option shall at least include a dscp. If QoS policy is a 3GPP policy, the LMA relies on default QCI/DSCP mapping as explained in section 3.4. Optional qos parameters may be used by the wi-fi access network to do its own mapping, but this is out of scope of the current document. The other reason to include a DSCP is that the QoS option may be used in another context that 3GPP/Wi-Fi, we have to document this use-case. 

-Hui

Hi Hui,

Thanks for the feedback. 

Hope that clarifies.

BR,

Pierrick

Hello authors, 

Best,

-Hui

Folks:

Regards
Sri 

	 
	Marco

	Abstract:

---

From: Hui Deng <[email-masked]>
Date: Sat, 28 Apr 2012 09:22:44 +0800

Hi Pierrick,

in previous email, you were saying that the purpose of delivering
parameters related to 3GPP air-interface like ARP, GDBR, GUBR is for
mapping to DSCP, then I asked you are also delivering DSCP. and then you
explained why DSCP is needed

then, my question has to go back, why you need to deliver parameters
related to 3GPP air-interface like ARP, GDBR, GUBR, is that for the purpose
of S5/S8 other than WLAN, or it is also for the WLAN

thanks for the discussion

-Hui

>  Hi Hui,****
>
> ** **
>
> Please see inline****
>
> ** **
>
> Pierrick****
>
> ** **
>
> *De :* Hui Deng [mailto:[email-masked]]
> *Envoyé :* vendredi 27 avril 2012 15:37
> *À :* SEITE Pierrick RD-RESA-REN
> *Cc :* [email-masked]
> *Objet :* Re: [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt**
> **
>
> ** **
>
> Pierrick, ****
>
>  ****
>
> thanks for your quick response,****
>
>  ****
>
> but you also deliver dscp as well?****
>
> ** **
>
> Yes, the QoS option shall at least include a dscp. If QoS policy is a 3GPP
> policy, the LMA relies on default QCI/DSCP mapping as explained in section
> 3.4. Optional qos parameters may be used by the wi-fi access network to do
> its own mapping, but this is out of scope of the current document. The
> other reason to include a DSCP is that the QoS option may be used in
> another context that 3GPP/Wi-Fi, we have to document this use-case. ****
>
> ** **
>
>  ****
>
> -Hui****
>
> 2012/4/27 <[email-masked]>****
>
> Hi Hui,****
>
>  ****
>