Re: [netext] [request for feedback] FW: New Version Notification for draft-kaippallimalil-netext-pmip-qos-wifi-04.txt

Hi,

Thaks for the answers, please see inline.

Pierrick

De : Rajesh Pazhyannur (rpazhyan) [mailto:rpazhyan@cisco.com]
Envoyé : mardi 25 février 2014 17:58
À : SEITE Pierrick IMT/OLN; John Kaippallimalil; netext@ietf.org
Objet : RE: [request for feedback] FW: New Version Notification for draft-kaippallimalil-netext-pmip-qos-wifi-04.txt

Thanks for the review. Appreciate it.

Regards

Rajesh

-----Original Message-----
From: netext [mailto:netext-bounces@ietf.org] On Behalf Of pierrick.seite@orange.com
Sent: Tuesday, February 25, 2014 6:08 AM
To: John Kaippallimalil; netext@ietf.org
Subject: Re: [netext] [request for feedback] FW: New Version Notification for draft-kaippallimalil-netext-pmip-qos-wifi-04.txt

Hi John,

I have read draft-kaippallimalil-netext-pmip-qos-wifi and I found it very good.

IMHO, this document is a good companion document of draft-ietf-netext-pmip6-qos; it clarifies very well how to use PMIP QoS option on a WLAN access.

Hence, I have very few comments/questions:

- The draft assumes that MAC and WLC are collocated; can we imagine architecture where the controller is not in the datapath? If yes, what is the impact?

>  Yes, definitely we should consider the possibility of WLC not being in the datapath. In such a case we assume that MAG is on the AP. The link between AP and WLC is only used for control and management and not for carrying the datapath.
> There is a third possibility where the MAG is on the WLC but datapath is between the AP and LMA. (For example this could be
Done using the Alt-CoA option.  I don't think we have highlighted this case as this would depend on  how the MAG (on WLC) communicates with AP (e.g., using CAPWAP or some other means).

- There is an unsaid assumption: the LMA is the decision maker regarding the QoS policy. I think it should be clearly stated somewhere. I mean, although it is not the current trend, I imagine that some deployment may let the MAG making the final decision regarding the QoS policy to apply.

>  I don't fully understand the intent here. For example, is the LMA sends a policy in an Update Request and the MAG does not have resources to meet it, the MAG can change it.  But I suspect that  this is not what you are asking.

The document clearly illustrates how the MAG and LMA can negociate QoS ressources. My point is only on "who is making the final decision during this negotiation?"; the document assumes that the LMA makes the final decision and I'm fine with this. I'm just saying that this assumption should be clearly stated; just in case some people may want to let the MAG make the final decision (BTW, your document allows this kind of implementation).

- You wrote that Mean Data Rate has no equivalent parameter in PMIP QoS. However, last update of pmip-qos draft includes a vendor specific option which, IMO, could be used for that purpose.

> Noted.

BR,
Pierrick

>-----Message d'origine-----
>De : netext [mailto:netext-bounces@ietf.org] De la part de John
>Kaippallimalil Envoyé : lundi 24 février 2014 18:43 À : netext@ietf.org<mailto:netext@ietf.org>
>Objet : [netext] [request for feedback] FW: New Version Notification
>for draft-kaippallimalil-netext-pmip-qos-wifi-04.txt
>
>Hello,
>We have a new draft on Mapping 802.11 QoS in PMIPv6 Mobility domain
>(http://www.ietf.org/internet-drafts/draft-kaippallimalil-netext-pmip-q
>os-
>wifi-04.txt) with comments from the group addressed.
>
>The main comments from last meeting:
>- Why do we need per-user QoS and what is missing    ( -- new text in
>Introduction)
>- default connection/admission control, etc.         ( -- revised/added use cases)
>- Don't understand justification for DSCP map set    ( -- removed from draft)
>- mapping of connection parameters between WiFi/PMIP ( -- added tables
>for the mapping)
>
>We would like to get feedback on this draft/revision and would like to
>have it adopted as a working group item.
>
>Regards,
>John
>
>
>
>-----Original Message-----
>From: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> [mailto:internet-drafts@ietf.org]
>Sent: Tuesday, February 11, 2014 11:09 AM
>To: John Kaippallimalil; John Kaippallimalil; Rajesh Pazhyannur; Parviz
>Yegani; Rajesh Pazhyannur; Parviz Yegani
>Subject: New Version Notification for
>draft-kaippallimalil-netext-pmip-qos-
>wifi-04.txt
>
>
>A new version of I-D, draft-kaippallimalil-netext-pmip-qos-wifi-04.txt
>has been successfully submitted by John Kaippallimalil and posted to
>the IETF repository.
>
>Name:          draft-kaippallimalil-netext-pmip-qos-wifi
>Revision:      04
>Title:         Mapping 802.11 QoS in a PMIPv6 Mobility Domain
>Document date: 2014-02-10
>Group:         Individual Submission
>Pages:         24
>URL:            http://www.ietf.org/internet-drafts/draft-kaippallimalil-netext-
>pmip-qos-wifi-04.txt
>Status:         https://datatracker.ietf.org/doc/draft-kaippallimalil-netext-pmip-
>qos-wifi/
>Htmlized:       http://tools.ietf.org/html/draft-kaippallimalil-netext-pmip-qos-
>wifi-04
>Diff:           http://www.ietf.org/rfcdiff?url2=draft-kaippallimalil-netext-pmip-
>qos-wifi-04
>
>Abstract:
>   This document provides recommendations on procedures and mapping of
>   QoS parameters between 802.11 and PMIPv6. QoS parameters in 802.11
>   that reserve resources for 802.11 streams should be mapped to PMIP
>   QoS resources for IP sessions and flows. QoS reservation sequences in
>   802.11 should allow cases where MN initiate resource reservation, as
>   well as cases where the network initiates resource reservation.
>   Additionally, it should be possible for QoS parameters for PMIPv6
>   flows and mobility sessions to be mapped to 802.11 traffic stream
>   reservations. The sequences and parameters to be mapped to provide a
>   consistent behavior across 802.11 and PMIPv6 QoS are described here.
>
>
>
>
>
>
>Please note that it may take a couple of minutes from the time of
>submission until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>
>_______________________________________________
>netext mailing list
>netext@ietf.org<mailto:netext@ietf.org>
>https://www.ietf.org/mailman/listinfo/netext

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
netext mailing list
netext@ietf.org<mailto:netext@ietf.org>
https://www.ietf.org/mailman/listinfo/netext

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.