Re: [netext] AD Evaluation: draft-ietf-netext-pmip-qos-wifi

[John Kaippallimalil <[e-mail]>]

Hi Brian,
I have posted version 6 of the draft with all the changes made.

BR,
John

> -----Original Message-----
> From: Brian Haberman [mailto:[e-mail]]
> Sent: Wednesday, February 11, 2015 10:25 AM
> To: John Kaippallimalil; draft-ietf-netext-pmip-qos-
> [e-mail]; [e-mail]; [e-mail]
> Subject: Re: AD Evaluation: draft-ietf-netext-pmip-qos-wifi
> 
> Hi John,
>      Your proposed changes below look fine.  Go ahead and make them and
> post the updated version.
> 
> Regards,
> Brian
> 
> 
> On 2/11/15 11:06 AM, John Kaippallimalil wrote:
> > Hi Brian,
> > Copying snippets for 3 comments that need to be resolved:
> >
> >>>> * Definitions
> >>>>
> >>>> .............
> >>>> - Do the definitions need to use the 2119 keywords?
> >> I guess I didn't ask my question as clearly as I wanted.  The
> >> definitions currently have 2119 keywords (albeit in lower-case) and
> I
> >> was curious if they needed to be there in order for them to be
> correct.
> >>  I do not see a need to make them upper-case 2119 keywords, just
> >> trying to avoid the inevitable comment during IESG review as to
> >> whether the lower-case usage was meant to comply with 2119
> definitions.
> >
> > I think I understand better now. Don't see the need for capitalized
> 2119 keywords in this draft either.
> >
> > Proposed resolution:
> > - no capitalized 2119 keywords
> > - Revise text for Mean data rate from "should" to "must"- since it is
> required to populate the PMIP QoS options:
> >   "TSPECs for both uplink and downlink must contain the Mean Data
> Rate."
> > - all others are good as in version 05 of the draft.
> >
> >
> >>>> * Section 3.1.1
> >>>>
> >> ....
> >> The above is fine with me.  Is ALG the correct term to describe what
> >> is being done here?  I could envision DPI also being a correct way
> of
> >> doing this, just want to make sure a future reader clearly
> >> understands what needs to be implemented.
> >
> > Agree that it could be either a DPI or ALG. What we need here is some
> functionality to extract IP flow information from application or
> session layer signaling and then associate it to the subsequent QoS
> request.
> >
> > Proposed revision for step 1 (last para):
> > "It should be noted that WMM-AC specifications do not contain TCLAS.
> When TCLAS is not present, there is no direct way to derive flow
> specific attributes like Traffic Selector in PMIPv6. In this case
> functionality to derive IP flow details from information in upper layer
> protocols (e.g., SIP) and associate to subsequent QoS request may be
> used. This is not described further here, but it maybe functionality in
> an Application Layer Gateway (ALG) or Deep Packet Inspection (DPI). It
> should be noted that an ALG or DPI can increase the complexity of the
> AP/MAG implementation and affect its scalability. If no TCLAS is
> derived, the reservation applies to all flows of the MN (not desired).
> Parameter mapping in this case is shown in Table 2."
> >
> >
> >
> >>>> - In Step 2, what is the AP/MAG to do if the TCLAS is not present
> >>>> (when WMM-AC is used)?  Does it construct one via the ALG
> discussed
> >>>> above?
> >> ....................
> >>
> >> Same point as the previous comment.  Is ALG the correct term or is
> it
> >> really DPI?  I don't know the correct answer and the text is fuzzy
> >> enough to need some work.
> >
> > Proposed revision - add new para in step (2):
> > "If TCLAS is not present (when WMM-AC is used), TCLAS maybe derived
> from information in upper layer protocols (as described in step 1) and
> populated in Traffic Selector. If TCLAS cannot be derived, the Traffic
> Selector field is not included in the QoS options."
> >
> >
> > Best regards,
> > John
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: Brian Haberman [mailto:[e-mail]]
> >> Sent: Tuesday, February 10, 2015 11:23 AM
> >> To: John Kaippallimalil; draft-ietf-netext-pmip-qos-
> >> [e-mail]; [e-mail]; [e-mail]
> >> Subject: Re: AD Evaluation: draft-ietf-netext-pmip-qos-wifi
> >>
> >> Hi John,
> >>
> >> On 2/9/15 4:10 PM, John Kaippallimalil wrote:
> >>> Hi Brian, Inline below are the proposed resolutions.
> >>>
> >>> Thanks, John
> >>>
> >>>> -----Original Message----- From: Brian Haberman
> >>>> [mailto:[e-mail]] Sent: Monday, February 09, 2015
> >>>> 9:11 AM To: [e-mail];
> >>>> netext- [e-mail]; [e-mail] Subject: AD
> >>>> Evaluation: draft-ietf-netext-pmip-qos-wifi
> >>>>
> >>>> All, I have completed my AD Evaluation of
> >>>> draft-ietf-netext-pmip-qos- wifi as a part of the publication
> >>>> process.  I have a few points that I would like to discuss before
> >>>> moving this document into IETF Last Call...
> >>>>
> >>>> * The reference to RFC 2119 needs cleaning up.  The Normative
> >>>> References section tags the document as [RFC 2119], but section
> >>>> 1.1 refers to it as [RFC2119].
> >>>
> >>> Section 1.1: will change [RFC2119] to [RFC 2119]
> >>
> >> Ok.
> >>
> >>>
> >>>>
> >>>> * The Introduction uses several acronyms without expansion.
> >>>> Notionally, this seems to be because the acronyms are expanded in
> >>>> section 1.3.  I would suggest avoiding the use of the acronyms
> >>>> until after section 1.3. The Introduction should just use the
> >>>> expanded terms.
> >>>
> >>> Section 1 (Introduction): will expand each term such as MAG, LMA,
> >> etc.
> >>> to Mobility Access Gateway, Local Mobility Anchor, etc.
> >>>
> >>
> >> Ok.
> >>
> >>>>
> >>>> * Definitions
> >>>>
> >>>> - Do the definitions need to use the 2119 keywords?
> >>>
> >>> Proposed revision: - TSPECs for both uplink and downlink MAY
> contain
> >>> Peak Data Rate - TSPECs for both uplink and downlink SHOULD contain
> >>> the Mean Data Rate. - Minimum Data Rate is OPTIONAL and is not used
> >> in
> >>> QoS provisioning described here.
> >>>
> >>
> >> I guess I didn't ask my question as clearly as I wanted.  The
> >> definitions currently have 2119 keywords (albeit in lower-case) and
> I
> >> was curious if they needed to be there in order for them to be
> correct.
> >>  I do not see a need to make them upper-case 2119 keywords, just
> >> trying to avoid the inevitable comment during IESG review as to
> >> whether the lower-case usage was meant to comply with 2119
> definitions.
> >>
> >>>>
> >>>> - For simplicity, I would move section 1.3 ahead of section 1.2.
> >>>
> >>> Proposed revision: move section 1.3 ahead of section 1.2.
> >>>
> >>
> >> Ok.
> >>
> >>>>
> >>>> * Section 2 uses "(in decreasing order)". The context derived from
> >>>> the next sentence indicates that is in decreasing order of
> priority.
> >>>> I would state that explicitly.
> >>>
> >>> Proposed revision: "The levels of priority in EDCA are called
> access
> >>> categories (ACs) and there are four levels (in decreasing order of
> >>> priority): Voice, Video, Best-Effort, Background."
> >>>
> >>
> >> Ok.
> >>
> >>>>
> >>>> * Section 3.1.1
> >>>>
> >>>> - Step 1 seems to require the AP/MAG to do DPI if TCLAS is not
> >>>> present. Does that imply that the AP/MAG must have application
> >>>> layer gateway support for each app used by the MN?  If so, that
> >>>> could have scalability and usability implications.  May be worth
> mentioning.
> >>>
> >>> Proposed revision for step 1 (last para): "It should be noted that
> >>> WMM-AC specifications do not contain TCLAS.  When TCLAS is not
> >>> present, there is no direct way to derive flow specific attributes
> >>> like Traffic Selector in PMIPv6. In this case an Application Layer
> >>> Gateway (ALG) can derive IP flow details from information in upper
> >>> layer protocols (e.g. SIP). It should be noted that an ALG can
> >>> increase the complexity of the AP/MAG implementation and affect its
> >>> scalability. If no TCLAS is derived, the reservation applies to all
> >>> flows of the MN (not desired). Parameter mapping in this case is
> >> shown
> >>> in Table 2."
> >>>
> >>
> >> The above is fine with me.  Is ALG the correct term to describe what
> >> is being done here?  I could envision DPI also being a correct way
> of
> >> doing this, just want to make sure a future reader clearly
> >> understands what needs to be implemented.
> >>
> >>>>
> >>>> - In Step 2, what is the AP/MAG to do if the TCLAS is not present
> >>>> (when WMM-AC is used)?  Does it construct one via the ALG
> discussed
> >>>> above?
> >>>
> >>> Proposed revision - add new para in step (2): "If TCLAS is not
> >> present
> >>> (when WMM-AC is used), TCLAS maybe derived using an ALG and
> >>> populated in Traffic Selector. If TCLAS cannot be derived, the
> >>> Traffic Selector field is not included in the QoS options."
> >>>
> >>
> >> Same point as the previous comment.  Is ALG the correct term or is
> it
> >> really DPI?  I don't know the correct answer and the text is fuzzy
> >> enough to need some work.
> >>
> >>>>
> >>>> * Section 3.1.2
> >>>>
> >>>> - This is the first mention of a policy server and there is no
> >>>> description or reference of what the policy server does or how it
> >>>> is expected to interact with these QoS mechanisms.  At a minimum,
> >>>> there should be something in the Definitions that describes this
> function.
> >>>
> >>> LMA acts as the QoS policy server as far as semantics of this draft
> >> is
> >>> concerned.
> >>>
> >>> Proposed revisions  a-e: (a) Add clarifying statement in
> >>> introduction
> >>> - section 1: "The LMA (Local Mobility Anchor) configures QoS
> >>> policies on MN and AP/MAG. Further details on policy configuration
> >>> and PCF (Policy Control Function) can be found in [RFC 7222],
> section 6.1."
> >>>
> >>> (b) change policy server to LMA in first para: "When the
> application
> >>> session completes, the LMA, or the MN may signal for the release of
> >>> resources."
> >>>
> >>> (c) revise step (4) to remove reference to policy server. " LMA
> >>> receives the PBU and releases local resources."
> >>>
> >>> (d) in section 3.2.3, first para: " When the application session
> >>> completes, the LMA, or the MN may signal for the release of
> >>> resources."
> >>>
> >>> (e) in section 3.2.3, remove step 1. Renumber steps 2 - 5 as 1 - 4.
> >>>
> >>
> >> These all look good.
> >>
> >>>
> >>>>
> >>>> - What is the rationale for the order of steps?  I could very
> >>>> easily see the order being 1, 3, 4, 2.  Are there corner cases
> that
> >>>> should be discussed if the original order is not followed?
> >>>
> >>> Proposed revision: add following text after step 4. "It should be
> >>> noted that steps 3 and 4 can proceed independently of the DELTS
> >>> Response (step 2)."
> >>>
> >>
> >> Ok.
> >>
> >>>>
> >>>> * Section 3.2 seems like an attempt to cover all possible
> scenarios
> >>>> when it may not be needed.  Can a scenario be described where the
> >>>> network would originate the QoS signaling?
> >>>
> >>> Proposed revision - add as example - 3GPP TS23.203, section 7.4.2
> >>> (IP-CAN Session Modification, PCRF Initiated): Replace first
> >>> sentence
> >>> with: " This section describes the case when the QoS service
> request
> >>> is initiated by the LMA. For example an application  such as voice
> >> may
> >>> request the network to initiate configuration of additional QoS
> >> policy
> >>> as in [TS23.203], section 7.4.2."
> >>>
> >>
> >> Ok.
> >>
> >>>>
> >>>> * Figure 5 is never referenced in the text.
> >>>
> >>> Proposed revision (in para above Figure 5): " In this use case
> shown
> >>> in Figure 5, the network initiates the release of QoS resources."
> >>
> >> Ok.
> >>
> >> Regards,
> >> Brian
> >>
> >

--- Begin Message ---

A new version (-06) has been submitted for draft-ietf-netext-pmip-qos-wifi:
http://www.ietf.org/internet-drafts/draft-ietf-netext-pmip-qos-wifi-06.txt

Sub state has been changed to AD Followup from Revised ID Needed


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netext-pmip-qos-wifi/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-pmip-qos-wifi-06

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.

IETF Secretariat.

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

--- End Message ---