From Basavaraj.Patil@nokia.com Tue May 1 07:30:10 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3771E21F8836 for ; Tue, 1 May 2012 07:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.561 X-Spam-Level: X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4rPjfe89Kem for ; Tue, 1 May 2012 07:30:09 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 4A37521F883D for ; Tue, 1 May 2012 07:30:09 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q41EU3ho028227; Tue, 1 May 2012 17:30:03 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 May 2012 17:30:03 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.103]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.02.0283.004; Tue, 1 May 2012 16:30:02 +0200 From: To: Thread-Topic: [netext] Questions on: draft-ietf-netext-logical-interface-support-05.txt Thread-Index: AQHNJxYMMu/A+bLcNEmdVxwqAA1fFpaz8gqA///ZIQCAAF7ygIAAYCaA Date: Tue, 1 May 2012 14:30:02 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 x-originating-ip: [172.19.59.24] Content-Type: text/plain; charset="us-ascii" Content-ID: <806CFD076F60054DBF47E489A654E60A@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 May 2012 14:30:03.0255 (UTC) FILETIME=[E587D070:01CD27A6] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] Questions on: draft-ietf-netext-logical-interface-support-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 14:30:10 -0000 On 4/30/12 10:45 PM, "ext Sri Gundavelli" wrote: > >>>=20 >>>=20 >>>> 2. Regarding path MTU, the I-D says that in the case where the MN is >>>> attached simultaneously to multiple interfaces, the LIF will choose >>>>the >>>> smaller of the MTU values of the physical interfaces. However the I-D >>>> also says that the LIF has awareness of forwarding packets on the >>>> interface from which a packet was received. If that is the case, why >>>> would >>>> the LIF be configured with the lower value MTU? The LIF should be able >>>> to >>>> choose the appropriate MTU for sending a packet depending on the >>>> interface >>>> over which the packet is sent/received. >>>>=20 >>>=20 >>> [Sri] Keeping the lower of the MTU values across different interfaces >>> will ensure there is no MTU change notification to the ND stack after >>> each handover. It will keep a stable MTU value. >>=20 >> But it comes at the cost of sending packets on the interface in a >> suboptimal manner. As a result the bandwidth of the air-interface is >>(may >> be) wasted. Since the LI knows which of the interfaces to send the >>packets >> on, why does it need to adapt to the lower value MTU? I do not believe >>it >> is necessary. > >The other aspect is constant MTU change at each handoff. So, we can leave >both the considerations and let implementations decide. Change of the underlying interface has an impact on MTU as well as latency, congestion etc. Hence just maintaining a constant MTU is not sufficient. It would be preferable to allow for the LIF to use the Max MTU value of the underlying physical interface. I am okay with your suggestion to document both approaches. > > > > >>>=20 >>>=20 >>>> 3. The statement: "The logical interface adapts to the point-to-point >>>> link >>>> model." is not completely clear. What exactly is the LIF adapting to? >>>>=20 >>>=20 >>> [Sri] We have had this discussion in the past on this topic. LIF is >>> adapting to P2P link model. May be we can add more details. >>=20 >> I am still at a loss to understand what you mean when you say "LIF is >> adapting to P2P link model". What exactly is happening at the LIF in >>terms >> of behavior? >>=20 > >Every interface that is exposed to the ND stack is reflecting the >interface type, shared/p2p. There is even a socket API to get this >property and its used by the application/ND stack for different purposes, >Now, the question is about LIF, what is the tag that exposed to the upper >layer. The LIF operation has no bearing on the type and given that we >have pre-established assumption on the link model, we rather expect the >LIF be of another P2P link type. That's all to it. Would be good to explain this in the I-D. If the underlying physical interface is not of type P2P does the LIF then create such a link type between the MN and the AR/MAG? The LIF is yet another interface that is available on the MN. Any application may potentially use it. Is the intent that the LIF is used only in a PMIP6 domain? How does the MN know when the LIF interface is to be used Vs any of the other interfaces? -Raj > > >Sri > > > From Basavaraj.Patil@nokia.com Tue May 1 07:54:27 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60BA21E80BD for ; Tue, 1 May 2012 07:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.563 X-Spam-Level: X-Spam-Status: No, score=-106.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyEncUr2PKQj for ; Tue, 1 May 2012 07:54:26 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id BEF4F21F863F for ; Tue, 1 May 2012 07:54:26 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q41EsLjm017584; Tue, 1 May 2012 17:54:22 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 May 2012 17:54:21 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.103]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.02.0283.004; Tue, 1 May 2012 16:54:20 +0200 From: To: , Thread-Topic: [netext] Review request: draft-ietf-netext-logical-interface-support-05.txt Thread-Index: AQHNJ6pK+Q6R2LdyF0miNKSNnY32rg== Date: Tue, 1 May 2012 14:54:20 +0000 Message-ID: In-Reply-To: <818438E2-DB5D-475F-9E5A-D1509FEB13FB@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 x-originating-ip: [172.19.59.24] Content-Type: text/plain; charset="Windows-1252" Content-ID: <3D1182804D46844087A1E9E79E5A0FE0@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 May 2012 14:54:21.0216 (UTC) FILETIME=[4A8B0200:01CD27AA] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] Review request: draft-ietf-netext-logical-interface-support-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 14:54:27 -0000 Sri, Your comment below: "Clearly this is a requirement spec with some minimal guidance on how to deal with specific issues." is not exactly reflected in terms of the content in the I-D. It does not read that way. I think Julien has a good point about how to structure and document the concept of a logical interface while leaving the details to implementations.=20 -Raj On 4/30/12 7:25 PM, "ext Sri Gundavelli" wrote: >Hi Julien. > >Thanks for the comments. Inline ... > > >On Apr 30, 2012, at 4:29 PM, Julien Laganier wrote: > >> On Mon, Apr 30, 2012 at 12:32 PM, wrote: >>>=20 >>> Please make an effort and do a review of this I-D. >>=20 >> I have reviewed this document and IMHO the document is focused too >> much on one implementation strategy, i.e., that of a stub logical >> interface not connected to any link, layered on top of physical >> interfaces, at the expense of describing a generic abstract model of a >> logical interface that can be implemented in many manners. In doing >> so, the document unnecessarily restrict the applicability of the >> logical interface concept and describes workarounds that seem overly >> complex and unnecessary. For example, the concept of virtual >> identifier seems to prevent doing inter technology handovers. >>=20 > >Not sure, if that was our goal, but if any part of the text is focussed >on a specific approach, we have to fix that. Logical interface is a >software construct with certain expected behavior with respect to its >interfacing with the physical link, ND traffic handling, and with respect >to how the messages/events are forwarded up the stack. Clearly this is a >requirement spec with some minimal guidance on how to deal with specific >issues. The focus was mainly on: > >- The concept of a Logical Interface and the purpose >- properties of the Logical interface, its related to the physical >interfaces >- How does logical interface deal with link specific ND messages, how >RA's are seen, how RS is sent. L2 identifiers ... >- Presents only the details/issues that the implementations have to be >aware off. > >As I see it, if I'm implementing a logical interface, I need to know >these details. Now, there can be multiple ways to implement and meet >these requirements. No part of the spec is using 2119 language, or >suggesting how to implement it. Its some general guidance. > > > > >> o In access architectures, where the link-layer identifier is >> associated with a specific access technology, it will not be >> possible for the logical interface to adopt a virtual identifier >> and it use it across different access networks. In such networks, >> the logical interface must use the identifier of the respective >> sub-interface through which a packet is being transmitted. >> However, if more than one access technology domains that are part >> of the logical interface have such requirement, then the logical >> interface will not be able to support such configuration. >>=20 >> It seems to me that much of the issues revolving around link layer >> identifiers, MTU, Neighbor Discovery, and Multicast, could be avoided >> if the document eliminated the current dependency on the >> implementation strategy being described in favor of a comprehensive >> logical interface support, where the logical interface is attached to >> a logical link which is terminated by a logical router. This logical >> router would in turn be attached to the physical interfaces themselves >> and perform adequate routing. >>=20 > >The above text is about a specific issue related to choice of interface >identifier selection. If WiMAX access is making certain assumption about >the interface identifier, a given implementation needs to be sensitive to >that aspect. So, we are only reflecting the issues with the interface >identifier selection and the considerations. So, I'm not sure, if the >above is about a specific implementation. The spec can be silent about >this, but implementations will have no clue. At the end of the day, this >is an informational spec, you and me/WG having worked on such things we >have some understanding about the issues. But, some developer may not be >aware of these considerations. > > >> This logical >> router would in turn be attached to the physical interfaces themselves >> and perform adequate routing. >> Doing so, the IP layer on the host runs unmodified and uses the >> logical interface as any other interface. ND/ARP/DHCP etc. are >> executed together with the logical router at the end of the logical >> link, so is multicast. Dissimilar MTU of physical interfaces are >> hidden behind the logical router as well=8A >>=20 > >One can surely make this a logical router ( I don't know how this works >..), still taking into account the considerations listed in the document. >Not sure, what part of the spec is preventing any specific >implementation, still conforming to the logical interface requirements. > > > >> Unlike the approach currently described in the document, I see only >> advantages and no drawbacks to what I am proposing here. >>=20 >> Also note that this model is currently implemented and shipping on >> many mobile devices, where two flavors of the model coexist; one where >> the logical link is PPP, and another where it is Ethernet-like. >>=20 > > >I agree with that. But, you also know, in the absence of some guidance >how different implementations have violated some basics and the current >situation with the 3G drivers. But, I again, we are not interested in >reflecting any specific implementation, the goal is to provide >requirements. > > > >Sri > > > >> --julien >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext From sgundave@cisco.com Tue May 1 08:02:27 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5032621E82CC for ; Tue, 1 May 2012 08:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.533 X-Spam-Level: X-Spam-Status: No, score=-10.533 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_UNSUB18=0.131] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXULc6qENxJt for ; Tue, 1 May 2012 08:02:26 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1312F21E808A for ; Tue, 1 May 2012 08:02:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=4952; q=dns/txt; s=iport; t=1335884546; x=1337094146; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=2ntHGvI5QbR4HB2/6op12n7Ur3g/QCGfsSugESvWELQ=; b=MIpEjm78/oTZgTbFVE0LHpQ9pPaH0fpCQ5GXZRoH5byqA6UmKs7sWkCu uxHmz2QXVMVr0ZRiQsbYdGZxrPLXZNWMPiPWgAGpajnrDQYJ/X3hRD4GX uy6oFUO7JNNP7tXs95ii7SZI+IAzy+RCLOWsP91RtO8Q/u94OGU7T2pui Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsEFAJf6n0+rRDoJ/2dsb2JhbABEr2uDAYEHggkBAQEDARIBZgULCwRCVxkih2YEmi+fWZAmYwSIZI0ajlmBaYMI X-IronPort-AV: E=Sophos;i="4.75,510,1330905600"; d="scan'208,217";a="40394638" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 01 May 2012 15:02:25 +0000 Received: from stealth-10-32-246-214.cisco.com (stealth-10-32-246-214.cisco.com [10.32.246.214]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q41F2P3b021094; Tue, 1 May 2012 15:02:25 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_E78F0A0D-83A3-4E2B-B5B6-2EFB845802F4" From: Sri Gundavelli In-Reply-To: Date: Tue, 1 May 2012 08:02:25 -0700 Message-Id: <5B4694F8-F7ED-4968-B843-456A9E41BDF8@cisco.com> References: To: Basavaraj.Patil@nokia.com X-Mailer: Apple Mail (2.1257) Cc: netext@ietf.org Subject: Re: [netext] Questions on: draft-ietf-netext-logical-interface-support-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 15:02:27 -0000 --Apple-Mail=_E78F0A0D-83A3-4E2B-B5B6-2EFB845802F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 1, 2012, at 7:30 AM, = wrote: >>=20 >> The other aspect is constant MTU change at each handoff. So, we can = leave >> both the considerations and let implementations decide. >=20 > Change of the underlying interface has an impact on MTU as well as > latency, congestion etc. Hence just maintaining a constant MTU is not > sufficient. It would be preferable to allow for the LIF to use the Max = MTU > value of the underlying physical interface. I am okay with your = suggestion > to document both approaches. >=20 Ack >>>=20 >>=20 >> Every interface that is exposed to the ND stack is reflecting the >> interface type, shared/p2p. There is even a socket API to get this >> property and its used by the application/ND stack for different = purposes, >> Now, the question is about LIF, what is the tag that exposed to the = upper >> layer. The LIF operation has no bearing on the type and given that we >> have pre-established assumption on the link model, we rather expect = the >> LIF be of another P2P link type. That's all to it. >=20 > Would be good to explain this in the I-D. > If the underlying physical interface is not of type P2P does the LIF = then > create such a link type between the MN and the AR/MAG? Sure > The LIF is yet another interface that is available on the MN. Any > application may potentially use it. Is the intent that the LIF is used > only in a PMIP6 domain? How does the MN know when the LIF interface is = to > be used Vs any of the other interfaces? >=20 This is touching Pete's comment. We will respond to this. Regards Sri --Apple-Mail=_E78F0A0D-83A3-4E2B-B5B6-2EFB845802F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Basavaraj.Patil@nokia.com>= ; <Basavaraj.Patil@nokia.com>= ; wrote:

The other aspect is constant MTU change at each handoff. = So, we can leave
both the = considerations and let implementations = decide.

Change of the underlying interface has an = impact on MTU as well as
latency, congestion etc. Hence just = maintaining a constant MTU is not
sufficient. It would be preferable = to allow for the LIF to use the Max MTU
value of the underlying = physical interface. I am okay with your suggestion
to document both = approaches.


Ack



Every interface = that is exposed to the ND stack is reflecting = the
interface type, = shared/p2p. There is even a socket API to get = this
property and its used by = the application/ND stack for different = purposes,
Now, the question is = about LIF, what is the tag that exposed to the = upper
layer. The LIF operation = has no bearing on the type and given that we
have pre-established assumption on the link model, we = rather expect the
LIF be of = another P2P link type. That's all to it.

Would be = good to explain this in the I-D.
If the underlying physical interface = is not of type P2P does the LIF then
create such a link type between = the MN and the = AR/MAG?

Sure

The LIF is yet another interface that is available = on the MN. Any
application may potentially use it. Is the intent that = the LIF is used
only in a PMIP6 domain? How does the MN know when the = LIF interface is to
be used Vs any of the other = interfaces?


This is = touching Pete's comment. We will respond to = this.

Regards
Sri

<= /div>
= --Apple-Mail=_E78F0A0D-83A3-4E2B-B5B6-2EFB845802F4-- From sgundave@cisco.com Tue May 1 08:04:20 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A32221E828D for ; Tue, 1 May 2012 08:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.592 X-Spam-Level: X-Spam-Status: No, score=-10.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7srV8lfZEwtM for ; Tue, 1 May 2012 08:04:19 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id BF0A621E8241 for ; Tue, 1 May 2012 08:04:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=1036; q=dns/txt; s=iport; t=1335884660; x=1337094260; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=6WDewvY66J1grTAbB8J+azV6A21SnbsIDeFz0HA+Pj8=; b=Jf5Oj/dKnWo6WmPGTTlpw+YgI5FiEXq+vTMTY/VLg0ZQhbjjq/Ts84gl 8v0DJcdMLd+8Hv7HApBRiHNIF2hfmZpncAGeuLWNM90RgsRaCTlLLu7xG 2JuC2fLerg6nwFSbfuBUC0rnInBoKXgR6x4qkGtdr7hLFVWOZWM0SyfcK o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsEFAJf6n0+rRDoH/2dsb2JhbABEr2uDAYEHggkBAQEDARIBZhALRlcGEyKHZgSaL59ZjWSCQmMEiGSNGo5ZgWmDCA X-IronPort-AV: E=Sophos;i="4.75,510,1330905600"; d="scan'208";a="40394939" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 01 May 2012 15:04:19 +0000 Received: from stealth-10-32-246-214.cisco.com (stealth-10-32-246-214.cisco.com [10.32.246.214]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q41F4Jnf031295; Tue, 1 May 2012 15:04:19 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Sri Gundavelli In-Reply-To: Date: Tue, 1 May 2012 08:04:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5F959BEF-A841-4AE2-8FC9-80538BA0F7BB@cisco.com> References: To: X-Mailer: Apple Mail (2.1257) Cc: netext@ietf.org Subject: Re: [netext] Review request: draft-ietf-netext-logical-interface-support-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 15:04:20 -0000 Raj: On May 1, 2012, at 7:54 AM, wrote: >=20 > Sri, >=20 > Your comment below: > "Clearly this is a requirement spec with some minimal guidance on how = to > deal with specific issues." > is not exactly reflected in terms of the content in the I-D. It does = not > read that way. >=20 > I think Julien has a good point about how to structure and document = the > concept of a logical interface while leaving the details to > implementations.=20 >=20 No disagreement. As I said, our goal is get some implementations = supporting the LIF approach on mobile terminals. Help the implementors = understand all the issues with ND and related issues, provide some hints = on how to achieve this. if there are parts of the text suggesting only a = specific way of implementation, we should fix that and state that its = only out of the many ways to achieve that. So, no disagreement there. = These comments from you and Julien help; we know at least the open = issues. Sri From yokota@kddilabs.jp Tue May 1 23:00:38 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40E321F8A30 for ; Tue, 1 May 2012 23:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_71=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFWd1MJvsqcc for ; Tue, 1 May 2012 23:00:38 -0700 (PDT) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id E513B21F8998 for ; Tue, 1 May 2012 23:00:37 -0700 (PDT) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id AD6D317481B9 for ; Wed, 2 May 2012 15:00:30 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jo7Fb5TbOPKN for ; Wed, 2 May 2012 15:00:30 +0900 (JST) Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [172.19.90.145]) by mandala.kddilabs.jp (Postfix) with ESMTP id 46AAD174818A for ; Wed, 2 May 2012 15:00:30 +0900 (JST) Received: from [127.0.0.1] (yokoletsR9.mn.mip.kddilabs.jp [172.19.90.26]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id 14A8A1B863 for ; Wed, 2 May 2012 14:58:20 +0900 (JST) Message-ID: <4FA0CD79.80201@kddilabs.jp> Date: Wed, 02 May 2012 15:00:25 +0900 From: Hidetoshi Yokota User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: netext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [netext] New Version Notification for draft-liebsch-netext-pmip6-qos-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 06:00:38 -0000 Hi Yiu, Thanks for your good comment. The current document does not clearly mention the case where the QoS option was not agreed. If the MAG cannot satisfy the QoS options provided by the LMA, it will either terminate the session or renegotiate with a new set of QoS options by another PBU/PBA exchange based on the predefined policy. The same will be applied to Section 3.5.2. If the LMA cannot accept the QoS options requested by the MAG, it will return the PBA with acceptable QoS options and an appropriate status code. The MAG will then behave the same way above at the next round of PBU/PBA exchange. We will elaborate on it in the next version. Regards, -- Hidetoshi (2012/04/30 4:59), Lee, Yiu wrote: > Hi, > > I read this draft and I think is an important aspect missing in PMIPv6. > I think the WG should seriously consider to work on it. > > In the current version, I have a concern. For example: Fig 3.5.1 shows > the LMA will include the QoS option in PBA. If the MAG can't satisfy the > QoS, what will the MAG do? Dereg the session? PBA is an acknowledgement > to the PBU. It looks odd to me to use it for carrying QoS request.r > Perhaps a better way to handle it is to create a new set of QoS > request/response rather than embedding the QoS request in the PBA. > > Thanks, > Yiu > > > From: Sri Gundavelli > > Date: Wednesday, April 25, 2012 7:31 PM > To: Marco Liebsch >, "netext@ietf.org > " > > Subject: Re: [netext] New Version Notification for > draft-liebsch-netext-pmip6-qos-01.txt > > 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" 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'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 > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Marco.Liebsch@neclab.eu Wed May 2 03:19:44 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59E911E8087 for ; Wed, 2 May 2012 03:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_71=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3mDbBbX3sia for ; Wed, 2 May 2012 03:19:41 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 27F8E11E807F for ; Wed, 2 May 2012 03:19:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 2C46F100EEC; Wed, 2 May 2012 12:16:15 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNvPssa4l2cx; Wed, 2 May 2012 12:16:15 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 08635100EE2; Wed, 2 May 2012 12:16:00 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.31]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 2 May 2012 12:19:10 +0200 From: Marco Liebsch To: "Lee, Yiu" , Sri Gundavelli , "netext@ietf.org" Thread-Topic: [netext] New Version Notification for draft-liebsch-netext-pmip6-qos-01.txt Thread-Index: Ac0BLrfJDA4oGJmRTXyJExWUxpScgQiDMzo1AL2RggAAhkAc8A== Date: Wed, 2 May 2012 10:19:10 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D24DB7766@Polydeuces.office.hd> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26D24DB7766Polydeucesoffic_" MIME-Version: 1.0 Subject: Re: [netext] New Version Notification for draft-liebsch-netext-pmip6-qos-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 10:19:45 -0000 --_000_69756203DDDDE64E987BC4F70B71A26D24DB7766Polydeucesoffic_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yiu, good comment! Please let me add to Hidetoshi's feedback. I don't think the mobility session should be broken just because the MAG cannot enforce the QoS rules as provided by the LMA. There are different cases: the MAG may propose QoS rules in the PBU and the= LMA may accept or adjust (e.g. downgrade) them, then notify the MAG in the PBA. We should assume that the MAG can enforce the QoS policy it proposes to the= LMA in the PBU. The other case is that the MAG does not include QoS, but receives QoS polic= ies from the LMA in the PBA. In case it cannot enforce the provided rules but a= ll other requirements are met to enable the mobility session state as result of the = received PBA, the mobility binding should be accepted while QoS can be re-negotiated= in the background. In such case, the traffic is forwarded, possibly using a defaul= t or BE QoS, and the MAG proposes alternative QoS to the LMA in an updating PBU. Could that be a satisfying solution? We may even consider an administrative setting for loose or strong QoS support. Loose support would follow the above operation, whereas strong support may allow accepting a mobility binding at LMA and MAG only when the negotiated QoS can be enforced. What do you think? marco From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] Sent: Sonntag, 29. April 2012 21:59 To: Sri Gundavelli; Marco Liebsch; netext@ietf.org Subject: Re: [netext] New Version Notification for draft-liebsch-netext-pmi= p6-qos-01.txt Hi, I read this draft and I think is an important aspect missing in PMIPv6. I t= hink the WG should seriously consider to work on it. In the current version, I have a concern. For example: Fig 3.5.1 shows the = LMA will include the QoS option in PBA. If the MAG can't satisfy the QoS, w= hat will the MAG do? Dereg the session? PBA is an acknowledgement to the PB= U. It looks odd to me to use it for carrying QoS request.r Perhaps a bette= r way to handle it is to create a new set of QoS request/response rather th= an embedding the QoS request in the PBA. Thanks, Yiu From: Sri Gundavelli > Date: Wednesday, April 25, 2012 7:31 PM To: Marco Liebsch >= , "netext@ietf.org" > Subject: Re: [netext] New Version Notification for draft-liebsch-netext-pmi= p6-qos-01.txt Folks: Please comment on this draft. Lot of efforts went in to this from all the A= uthors, 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" 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 det= ails 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'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 netext@ietf.org https://www.ietf.org/mailman/listinfo/netext --_000_69756203DDDDE64E987BC4F70B71A26D24DB7766Polydeucesoffic_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [netext] New Version Notification for draft-liebsch-netext-pmip6= -qos-01.txt

Hi Yiu,

good comment! Please let me add to Hidetoshi’s feedback. <= /span>

I don’t think the m= obility session should be broken just because the MAG
cannot enforce the QoS rules as provided by the LMA.

 <= /p>

There are different cases= : the MAG may propose QoS rules in the PBU and the LMA
may accept or adjust (e.g. downgrade) them, then notify the MAG in the PBA.=
We should assume that the MAG can enforce the QoS policy it proposes to the= LMA
in the PBU.

 <= /p>

The other case is that th= e MAG does not include QoS, but receives QoS policies
from the LMA in the PBA. In case it cannot enforce the provided rules but a= ll other
requirements are met to enable the mobility session state as result of the = received
PBA, the mobility binding should be accepted while QoS can be re-negotiated= in the
background. In such case, the traffic is forwarded, possibly using a defaul= t or BE QoS,
and the MAG proposes alternative QoS to the LMA in an updating PBU.

 <= /p>

Could that be a satisfyin= g solution? We may even consider an administrative
setting for loose or strong QoS support. Loose support would follow the
above operation, whereas strong support may allow accepting a
mobility binding at LMA and MAG only when the negotiated QoS
can be enforced.

 <= /p>

What do you think?

 <= /p>

marco

 <= /p>

 <= /p>

 <= /p>

From: Lee, Yiu= [mailto:Yiu_Lee@Cable.Comcast.com]
Sent: Sonntag, 29. April 2012 21:59
To: Sri Gundavelli; Marco Liebsch; netext@ietf.org
Subject: Re: [netext] New Version Notification for draft-liebsch-net= ext-pmip6-qos-01.txt

 

Hi,

 

I read this draft and I thi= nk is an important aspect missing in PMIPv6. I think the WG should seriousl= y consider to work on it. 

 

In the current version, I have a concern. For example: Fig = 3.5.1 shows the LMA will include the QoS option in PBA. If the MAG can't satisfy the QoS, what will the MAG do? Dereg the session? PBA is an acknowledgement to the PBU. It looks = odd to me to use it for carrying QoS request.r  Perhaps a better way to handle it is to create a new set of QoS requ= est/response rather than embedding the QoS request in the PBA. =

 

Thanks,

Yiu

 

 

From: Sri Gundavelli <sgundave@cisco.com>
Date: Wednesday, April 25, 2012 7:31 PM
To: Marco Liebsch <Mar= co.Liebsch@neclab.eu>, "nete= xt@ietf.org" <netext@ietf.or= g>
Subject: Re: [netext] New Version Notification for draft-liebsch-net= ext-pmip6-qos-01.txt

 

Folks:

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

ht= tp://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-01.txt



Regards
Sri



On 3/13/12 8:40 AM, "Marco Liebsch" <Marco.Liebsch@neclab.eu> 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 det= ails about the
proposed operation and QoS attributes.
 
Marco
 
Filename:            = ;draft-liebsch-netext-pmip6-qos
Revision:            = ;  01
Title:            &n= bsp;         Quality of Servic= e Option for Proxy Mobile IPv6
Creation date:   2012-03-12
WG ID:            &n= bsp;     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 subscribe= r&#39;s IP
   flows.  Using the QoS option, the local mobility anc= hor and the
   mobile access gateway can exchange available QoS attribut= es and
   associated values.  This enables QoS policing and la= beling of packets
   to enforce QoS differentiation on the path between the lo= cal mobility
   anchor and the mobile access gateway.  Furthermore, = making QoS
   parameters available on the MAG enables mapping these par= ameters to
   QoS rules being specific to the access technology which o= perates
   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
netext@ietf.org
https://www.ietf.o= rg/mailman/listinfo/netext

--_000_69756203DDDDE64E987BC4F70B71A26D24DB7766Polydeucesoffic_-- From cjbc@it.uc3m.es Wed May 2 05:57:58 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF7A21F863D for ; Wed, 2 May 2012 05:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ta2UiWY32jI for ; Wed, 2 May 2012 05:57:55 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id BD30721F8639 for ; Wed, 2 May 2012 05:57:54 -0700 (PDT) X-uc3m-safe: yes Received: from [192.168.1.3] (62.83.52.112.dyn.user.ono.com [62.83.52.112]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 05C7675AAF0; Wed, 2 May 2012 14:57:52 +0200 (CEST) Message-ID: <1335963471.4285.21.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Sri Gundavelli Date: Wed, 02 May 2012 14:57:51 +0200 In-Reply-To: References: Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-jOeLVLrpET5F9cPVByyo" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18878.006 Cc: "netext@ietf.org" Subject: Re: [netext] Review of draft-ietf-netext-pmipv6-sipto-option-03 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 12:57:58 -0000 --=-jOeLVLrpET5F9cPVByyo Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Sorry for the late reply. Thanks for the update. I don't have any further comments. Carlos On Wed, 2012-04-25 at 16:13 -0700, Sri Gundavelli wrote: > Hi Carlos, Yokota-san, Marco, Pierrick, Ahmad & folks ... >=20 > Thanks for all the review comments. Please let us know if there any comme= nts > missing. >=20 > http://tools.ietf.org/html/draft-ietf-netext-pmipv6-sipto-option-04 >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 > On 2/5/12 11:58 PM, "Carlos Jes=FAs Bernardos Cano" wro= te: >=20 > > Hi, > >=20 > > Some additional comments after a quick review of the draft: > >=20 > > - Section 3.1: I think there is a problem with the references, because > > it appears in thge text: "If the received Proxy Binding Update includes > > the IP Traffic Offload Selector option Section 4". I guess it should > > say: "If the received Proxy Binding Update includes the IP Traffic > > Offload Selector option (Section 4)". There are more instances referrin= g > > to other sections. > >=20 > > - Section 4. The IPTS options has the field "TS Format", which resemble= s > > the option defined in RFC 6089 for the traffic selector sub-option, and > > in this way re-uses the binary TS defined for IPv4 in RFC 6088. However= , > > the draft defines a new IANA space for this "TS Format" field, which > > might be a bit confusing. Can we just re-use RFC 6089 space (now it onl= y > > has three values reserved: "0" that should not be used, and "1" for > > binary TS IPv4, and "2" for binary TS IPv6)? I think we would avoid som= e > > redundancy that might lead to confusion. If we do that, the draft would > > probably need to define a flag or something to catch what it is now don= e > > by putting a "TS Format" equal to "0". > >=20 > > - By doing offloading, there are issues associated to handovers (if the > > mobile node moves, any traffic that was being offloaded would need to b= e > > restarted). I guess some text on that would be helfpul. > >=20 > > Hope this helps, > >=20 > > Carlos >=20 --=20 Carlos Jes=FAs 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=20 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-jOeLVLrpET5F9cPVByyo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk+hL08ACgkQNdy6TdFwT2fUOACfcq8tbEx36QsXXzgXW2waO6Se tH4Aniw+59oTqPd1Hru7Y5re9iF+yaRI =lFSX -----END PGP SIGNATURE----- --=-jOeLVLrpET5F9cPVByyo-- From sarikaya2012@gmail.com Thu May 3 08:52:19 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C6421F85AD for ; Thu, 3 May 2012 08:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3ThyX2pCBaN for ; Thu, 3 May 2012 08:52:15 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C97BA21F8643 for ; Thu, 3 May 2012 08:52:13 -0700 (PDT) Received: by yhq56 with SMTP id 56so2274981yhq.31 for ; Thu, 03 May 2012 08:52:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=ZnyJD+0eJtOrLbQQGB0vaxHgw7oauKqDsGfYKcKIKC8=; b=F0p9Cpvvk+pm5nje86GNtbww0/o9AfvkSfZZYFtEHpDyAYavVMEA4qbC7kIAxJ4iNZ K6MYYh0mr8HUeY170QbKrKnfg5yat7znZb2Ewo9dXLby5WpJh8CXrTeIFl44p5NUaNYL F7x603798yJBaXXS+RcOFOBBHaiM6f5z05OSBTf5VzppjaXRbTVT/dRAuZnOpqQKIc1l WI2Vt0PtJkr6/v4t0EzEbthooqeiY+wun4o/qsHGUlVbVwAH80RDvS/vUAQI80lTHTGd f3qUt3HpbrmdI+uqoX7r6YuyulKNYHE6O3IIwuD2wRUifEbFJk/OxwhqhyRQ0ebMwnXC mcHw== MIME-Version: 1.0 Received: by 10.50.212.37 with SMTP id nh5mr1022510igc.63.1336060332621; Thu, 03 May 2012 08:52:12 -0700 (PDT) Received: by 10.231.194.73 with HTTP; Thu, 3 May 2012 08:52:12 -0700 (PDT) In-Reply-To: <20120503155020.11934.73495.idtracker@ietfa.amsl.com> References: <20120503155020.11934.73495.idtracker@ietfa.amsl.com> Date: Thu, 3 May 2012 10:52:12 -0500 Message-ID: From: Behcet Sarikaya To: netext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [netext] Fwd: New Version Notification for draft-sarikaya-netext-pmipv6-shared-link-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 15:52:21 -0000 Hi folks, To get things straight, I wrote this draft and submitted to Netext as follo= ws. Regards, Behcet ---------- Forwarded message ---------- From: Date: Thu, May 3, 2012 at 10:50 AM Subject: New Version Notification for draft-sarikaya-netext-pmipv6-shared-link-00.txt To: sarikaya@ieee.org A new version of I-D, draft-sarikaya-netext-pmipv6-shared-link-00.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-sarikaya-netext-pmipv6-shared-link Revision: =A0 =A0 =A0 =A000 Title: =A0 =A0 =A0 =A0 =A0 PMIPv6 Operation on Shared Links Creation date: =A0 2012-05-03 WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission Number of pages: 10 Abstract: =A0 This document describes Proxy Mobile IPv6 (PMIPv6) operation on =A0 shared links such as IEEE 802.11. =A0Two solutions of providing point- =A0 to-point link operation on the shared links are compared. =A0Advantages =A0 and disadvantages of each solution are identified. The IETF Secretariat From pierrick.seite@orange.com Sat May 5 01:17:26 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9DA21F84B9 for ; Sat, 5 May 2012 01:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.148 X-Spam-Level: X-Spam-Status: No, score=-6.148 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XeTnZvTn0ZVt for ; Sat, 5 May 2012 01:17:23 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6FE21F84B8 for ; Sat, 5 May 2012 01:17:21 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9137A5D8A8D; Sat, 5 May 2012 10:17:19 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 721FA5D8A8B; Sat, 5 May 2012 10:17:19 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Sat, 5 May 2012 10:17:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD2A97.7CC96925" Date: Sat, 5 May 2012 10:17:17 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C4620256A504@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt Thread-Index: Ac0k3WsAImKZeMVNToKyRE7h+MPM1QFueePw References: <843DA8228A1BA74CA31FB4E111A5C46202520F26@ftrdmel0.rd.francetelecom.fr><843DA8228A1BA74CA31FB4E111A5C46202520FB4@ftrdmel0.rd.francetelecom.fr> From: To: X-OriginalArrivalTime: 05 May 2012 08:17:20.0185 (UTC) FILETIME=[7DC12290:01CD2A97] Cc: netext@ietf.org Subject: Re: [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 08:17:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD2A97.7CC96925 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Hui, =20 Sorry for the late response. The QoS option has not been specified to = used on S5/S8; we have described only 3GPP/Wi-Fi use-cases (i.e. based = on S2a). However, we do not restrict the QoS option to these use-cases; = e.g. if you have a use-case involving S2/S8 exists , that's fine. =20 Pierrick =20 =20 De : Hui Deng [mailto:denghui02@gmail.com]=20 Envoy=E9 : samedi 28 avril 2012 03:23 =C0 : SEITE Pierrick RD-RESA-REN Cc : netext@ietf.org Objet : Re: [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt =20 Hi Pierrick, =20 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 =20 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 =20 thanks for the discussion =20 -Hui 2012/4/27 Hi Hui, =20 Please see inline =20 Pierrick =20 De : Hui Deng [mailto:denghui02@gmail.com]=20 Envoy=E9 : vendredi 27 avril 2012 15:37 =C0 : SEITE Pierrick RD-RESA-REN Cc : netext@ietf.org Objet : Re: [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt =20 Pierrick,=20 =20 thanks for your quick response, =20 but you also deliver dscp as well? =20 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.=20 =20 =20 -Hui 2012/4/27 Hi Hui, =20 Thanks for the feedback.=20 =20 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. =20 Hope that clarifies. =20 BR, Pierrick =20 De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part = de Hui Deng Envoy=E9 : vendredi 27 avril 2012 13:16 =C0 : netext@ietf.org Objet : [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt =20 Hello authors,=20 =20 I have read through document, want to clarify below: =20 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:) =20 If PMIP6 historically doesn't QoS, is that PCC will not be able to use = for PMIP6 based S5/S8 interfaces? =20 thanks for writing this document. =20 Best, =20 -Hui 2012/4/26 Sri Gundavelli 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=20 On 3/13/12 8:40 AM, "Marco Liebsch" 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.=20 =20 Marco =20 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 =20 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. =20 =20 =09 ________________________________ _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext =20 =20 =20 ------_=_NextPart_001_01CD2A97.7CC96925 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Hui,

 

Sorry for the late response. The QoS option has not been specified to used on S5/S8; we have = described only 3GPP/Wi-Fi use-cases (i.e. based on S2a). However, we do = not restrict the QoS option to these use-cases; e.g. if you have a = use-case involving S2/S8 exists , that’s = fine.

 

Pierrick

 

 

De : Hui Deng = [mailto:denghui02@gmail.com]
Envoy=E9 : samedi 28 avril = 2012 03:23
=C0 : SEITE Pierrick = RD-RESA-REN
Cc : netext@ietf.org
Objet : = Re: [netext] Comments on = draft-liebsch-netext-pmip6-qos-01.txt

 

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

2012/4/27 <pierrick.seite@orange.com>

Hi Hui,

 

Please see inline

 

Pierrick

 

De : Hui Deng = [mailto:denghui02@gmail.com]
Envoy=E9 : = vendredi 27 avril 2012 15:37
=C0 : SEITE Pierrick = RD-RESA-REN
Cc : netext@ietf.org
Objet : Re: = [netext] Comments on = draft-liebsch-netext-pmip6-qos-01.txt

 <= /o:p>

Pierrick, =

 <= /o:p>

thanks for = your quick response,

 <= /o:p>

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 = <pierrick.seite@orange.com>

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 : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part de Hui = Deng
Envoy=E9 : vendredi 27 avril 2012 = 13:16
=C0 : netext@ietf.org
Objet : [netext] = Comments on = draft-liebsch-netext-pmip6-qos-01.txt

 <= /o:p>

Hello = authors,

 <= /o:p>

I have read = through document, want to clarify below:

 <= /o:p>

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:)

 <= /o:p>

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

 <= /o:p>

thanks for = writing this document.

 <= /o:p>

Best,

 <= /o:p>

-Hui

2012/4/26 = Sri Gundavelli <sgundave@cisco.com>

Folks:
<= br>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-0= 1.txt



Regards
Sri =




On 3/13/12 8:40 AM, "Marco Liebsch" <Marco.Liebsch@neclab.eu> = 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-l= iebsch-netext-pmip6-qos
Revision: =             &= nbsp;01
Title: =             &= nbsp;        Quality of Service = Option for Proxy Mobile IPv6
Creation date: =   2012-03-12
WG ID: =             &= nbsp;    Individual Submission
Number of pages: = 32
Link: http://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-0= 1.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
netext@ietf.org
https://www.ietf.org/mailman/listinfo/netext=


______________= _________________________________
netext mailing list
netext@ietf.org
https://www.ietf.org/mailman/listinfo/netext

 <= /o:p>

 <= /o:p>

 

------_=_NextPart_001_01CD2A97.7CC96925-- From denghui02@gmail.com Sun May 6 16:42:20 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992B121F84D5 for ; Sun, 6 May 2012 16:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.437 X-Spam-Level: X-Spam-Status: No, score=-103.437 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyixbY9Dxz6Z for ; Sun, 6 May 2012 16:42:19 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3847E21F84D1 for ; Sun, 6 May 2012 16:42:19 -0700 (PDT) Received: by yhq56 with SMTP id 56so4559924yhq.31 for ; Sun, 06 May 2012 16:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CyeqME8pdC4BYVNPDEmXmoZheOBM5/HKSb//ZuxeS3Y=; b=gTaUrwW03SKzNZw/HcB844XFYYFJCJ747quXZpTHNmggGFK/X1uXCb8z1Hht5O3QbL lUaGlHPVGo3Dc+aPgTLOZ9ux0tCHyMFhlj5by08VVxEXR9+lggEmR+zvgj1SkZgUqFlH ZrVfzdcua5cjMHr2hup4qRD50ChBpaTofQWDPt81zs0RTo78701GKQkGH0UgTTZ2BhBL 3t/1diB4PvLfJwEuSKFzghKE5yvBeK3lrkoInNUK61qB9ZlDNPWS7H6HaETzSrtkoMTO QiG/YXX9ra7kucNg2oUzJ4KvlR+v9z+er7Ml+pdnni7la5xFRoMQnCVZHEzKbR1jWBUQ tWSQ== MIME-Version: 1.0 Received: by 10.236.125.168 with SMTP id z28mr16932686yhh.120.1336347272349; Sun, 06 May 2012 16:34:32 -0700 (PDT) Received: by 10.147.115.6 with HTTP; Sun, 6 May 2012 16:34:32 -0700 (PDT) In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C4620256A504@ftrdmel0.rd.francetelecom.fr> References: <843DA8228A1BA74CA31FB4E111A5C46202520F26@ftrdmel0.rd.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C46202520FB4@ftrdmel0.rd.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C4620256A504@ftrdmel0.rd.francetelecom.fr> Date: Mon, 7 May 2012 07:34:32 +0800 Message-ID: From: Hui Deng To: pierrick.seite@orange.com Content-Type: multipart/alternative; boundary=20cf3036388b7706db04bf66981d Cc: netext@ietf.org Subject: Re: [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 23:42:20 -0000 --20cf3036388b7706db04bf66981d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, Pierrick, thanks for your explaination. -Hui 2012/5/5 > Hi Hui,**** > > ** ** > > Sorry for the late response. The QoS option has not been specified to > used on S5/S8; we have described only 3GPP/Wi-Fi use-cases (i.e. based on > S2a). However, we do not restrict the QoS option to these use-cases; e.g. > if you have a use-case involving S2/S8 exists , that=92s fine.**** > > ** ** > > Pierrick**** > > ** ** > > ** ** > > *De :* Hui Deng [mailto:denghui02@gmail.com] > *Envoy=E9 :* samedi 28 avril 2012 03:23 > > *=C0 :* SEITE Pierrick RD-RESA-REN > *Cc :* netext@ietf.org > *Objet :* Re: [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt*= * > ** > > ** ** > > 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 purpo= se > of S5/S8 other than WLAN, or it is also for the WLAN**** > > **** > > thanks for the discussion**** > > **** > > -Hui**** > > 2012/4/27 **** > > Hi Hui,**** > > **** > > Please see inline**** > > **** > > Pierrick**** > > **** > > *De :* Hui Deng [mailto:denghui02@gmail.com] > *Envoy=E9 :* vendredi 27 avril 2012 15:37 > *=C0 :* SEITE Pierrick RD-RESA-REN > *Cc :* netext@ietf.org > *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 3GP= P > policy, the LMA relies on default QCI/DSCP mapping as explained in sectio= n > 3.4. Optional qos parameters may be used by the wi-fi access network to d= o > 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 **** > > Hi Hui,**** > > **** > > Thanks for the feedback. **** > > **** > > Actually, parameters like , ARP, GDBR, GUBR are optional in the QoS > option. You=92re right, this is 3GPP QoS policy parameters but they can b= e > 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 suppos= ed > to do the mapping to DSCP policies that a wifi network used to manage.***= * > > **** > > Hope that clarifies.**** > > **** > > BR,**** > > Pierrick**** > > **** > > *De :* netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] *De la > part de* Hui Deng > *Envoy=E9 :* vendredi 27 avril 2012 13:16 > *=C0 :* netext@ietf.org > *Objet :* [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt**** > > **** > > 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 fo= r > PMIP6 based S5/S8 interfaces?**** > > **** > > thanks for writing this document.**** > > **** > > Best,**** > > **** > > -Hui**** > > 2012/4/26 Sri Gundavelli **** > > 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" 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 IP= v6 > 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'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 > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext**** > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext**** > > **** > > **** > > ** ** > --20cf3036388b7706db04bf66981d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi, Pierrick,
=A0
thanks for your explaination.
=A0
-Hui

2012/5/5 <pierrick.seite@orange.com= >

Hi Hui,

=A0

Sorry for the la= te response. The QoS option has = not been specified to used on S5/S8; we have described only 3GPP/Wi-Fi use-= cases (i.e. based on S2a). However, we do not restrict the QoS option to th= ese use-cases; e.g. if you have a use-case involving S2/S8 exists , that=92= s fine.

=A0

Pierrick<= u>

=A0

=A0

De=A0: Hui Deng [mailto:denghui02@gmail.com<= /a>]
Envoy=E9=A0: samedi 28 avril 2012 03:23=20

=A0

Hi Pierrick,
=A0
in previous email, you=A0were= saying that the purpose of delivering parameters related to 3GPP air-inter= face 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

=A0

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

=A0

thanks for the discussion

=A0

-Hui

<= /div>

2012/4/27 <pierrick.seite@orange.com>

Hi Hui,

=A0

Please see inline=

=A0

Pierrick<= u>

=A0

De=A0: Hui Deng [mailto:denghui02@gmail.com<= /a>]
Envoy=E9=A0: vendredi 27 avril 2012 15:37
=C0=A0: SEITE Pi= errick RD-RESA-REN
Cc=A0: netext@ietf.org
Objet=A0: Re: [netext] Comments= on draft-liebsch-netext-pmip6-qos-01.txt

=A0

Pierrick,

=A0

thanks for your quick response,

=A0

but you also deliver dscp as well?

=A0

Yes, the QoS opt= ion 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 qo= s 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 incl= ude a DSCP is that the QoS option may be used in another context that 3GPP/= Wi-Fi, we have to document this use-case.

=A0

=A0

-Hui

<= /div>

2012/4/27 <pierrick.seite@orange.com>

Hi Hui,

=A0

Thanks for the f= eedback.

=A0

Actually, parame= ters like , ARP, GDBR, GUBR are optional in the QoS option. You=92re 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 optio= n if we assume that the wi-fi access has no PCC. In this situation, the mob= ile 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.

=A0

Hope that clarif= ies.

=A0

BR,

Pierrick<= u>

=A0

De=A0: netext-bounces@ietf.org [mail= to:netext-boun= ces@ietf.org] De la part de Hui Deng
Envoy=E9=A0: vendredi 27 avril 2012 13:16
=C0=A0: netext@ietf.org
Obj= et=A0: [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt

=A0

Hello authors,

=A0

I have read through document, want to clarify below:=

=A0

In the section 6, many parameters related to 3GPP ai= r-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 tech= nology:)

=A0

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

<= /div>

=A0

thanks for writing this=A0document.

=A0

Best,

=A0

-Hui

<= /div>

2012/4/26 Sri Gundavelli <sgundave@cisco.com>

Folks:

Please comment on this draft. L= ot of efforts went in to this from all the Authors, please review and comme= nt.

http://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-0= 1.txt



Regards
Sri





= On 3/13/12 8:40 AM, "Marco Liebsch" <Marco.Liebsch@neclab.eu> wrote:<= /span>

Please find an u= pdate of our draft about a QoS option for PMIP6 on the IETF repository, whi= ch
addresses comments from last meeting. The current version includes more det= ails about the
proposed operation and QoS attributes.
=A0
Marco=A0
Filename: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0draft-liebsch-netext-pm= ip6-qos
Revision: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A001
Title: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Quali= ty of Service Option for Proxy Mobile IPv6
Creation date: =A0=A02012-03-= 12
WG ID: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Individual = Submission
Number of pages: 32
Link: http://www.ietf.= org/id/draft-liebsch-netext-pmip6-qos-01.txt
=A0
Abstract:
=A0=A0=A0This specification defines a new mobility opti= on that can be used by
=A0=A0=A0the mobility entities in the Proxy Mobil= e IPv6 domain to exchange
=A0=A0=A0Quality of Service parameters associa= ted with a subscriber&#39;s IP
=A0=A0=A0flows. =A0Using the QoS option, the local mobility anchor and the<= br>=A0=A0=A0mobile access gateway can exchange available QoS attributes and=
=A0=A0=A0associated values. =A0This enables QoS policing and labeling o= f packets
=A0=A0=A0to enforce QoS differentiation on the path between th= e local mobility
=A0=A0=A0anchor and the mobile access gateway. =A0Furthermore, making QoS=A0=A0=A0parameters available on the MAG enables mapping these parameters= to
=A0=A0=A0QoS rules being specific to the access technology which ope= rates
=A0=A0=A0below the mobile access gateway. =A0After such mapping, Q= oS rules can
=A0=A0=A0be enforced on the access technology components, such as an IEEE=A0=A0=A0802.11e Wireless LAN controller.
=A0
=A0<= /u>

= _______________________________________________
netext mailing list
<= a href=3D"http://netext@ietf.org" target=3D"_blank">netext@ietf.org
= = https://www.ietf.org/mailman/listinfo/netext


___________________= ____________________________
netext mailing list
netext@ietf.org
https://www.ietf.or= g/mailman/listinfo/netext

=A0

<= /div>

=A0

<= /div>

=A0

<= /div>

--20cf3036388b7706db04bf66981d-- From internet-drafts@ietf.org Mon May 7 10:26:51 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7B521F867A; Mon, 7 May 2012 10:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tcBDs8b8IZh; Mon, 7 May 2012 10:26:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D987F21F864E; Mon, 7 May 2012 10:26:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120507172650.10654.45720.idtracker@ietfa.amsl.com> Date: Mon, 07 May 2012 10:26:50 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmip-lr-09.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 17:26:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Wor= king Group of the IETF. Title : Localized Routing for Proxy Mobile IPv6 Author(s) : Suresh Krishnan Rajeev Koodli Paulo Loureiro Qin Wu Ashutosh Dutta Filename : draft-ietf-netext-pmip-lr-09.txt Pages : 29 Date : 2012-05-07 Proxy Mobile IPv6 (PMIPv6) is a network based mobility management protocol that enables IP mobility for a host without requiring its participation in any mobility-related signaling. PMIPv6 requires all communications to go through the local mobility anchor. As this can be suboptimal, localized routing (LR) allows mobile nodes attached to the same or different mobile access gateways to route traffic by using localized forwarding or a direct tunnel between the gateways. This document proposes initiation, utilization and termination mechanisms for localized routing between mobile access gateways within a proxy mobile IPv6 domain. It defines two new signaling messages, Localized Routing Initiation (LRI) and Local Routing Acknowledgment (LRA), that are used to realize this mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-pmip-lr-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-pmip-lr-09.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmip-lr/ From internet-drafts@ietf.org Mon May 7 10:32:42 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9878921F8691; Mon, 7 May 2012 10:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqJy9RaebTdI; Mon, 7 May 2012 10:32:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0C921F8650; Mon, 7 May 2012 10:32:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120507173242.12040.51553.idtracker@ietfa.amsl.com> Date: Mon, 07 May 2012 10:32:42 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmip-lr-10.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 17:32:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Wor= king Group of the IETF. Title : Localized Routing for Proxy Mobile IPv6 Author(s) : Suresh Krishnan Rajeev Koodli Paulo Loureiro Qin Wu Ashutosh Dutta Filename : draft-ietf-netext-pmip-lr-10.txt Pages : 29 Date : 2012-05-07 Proxy Mobile IPv6 (PMIPv6) is a network based mobility management protocol that enables IP mobility for a host without requiring its participation in any mobility-related signaling. PMIPv6 requires all communications to go through the local mobility anchor. As this can be suboptimal, localized routing (LR) allows mobile nodes attached to the same or different mobile access gateways to route traffic by using localized forwarding or a direct tunnel between the gateways. This document proposes initiation, utilization and termination mechanisms for localized routing between mobile access gateways within a proxy mobile IPv6 domain. It defines two new signaling messages, Localized Routing Initiation (LRI) and Local Routing Acknowledgment (LRA), that are used to realize this mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-pmip-lr-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-pmip-lr-10.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmip-lr/ From charliep@computer.org Fri May 11 14:40:33 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 418DF21F866E for ; Fri, 11 May 2012 14:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYJ+RzVkLmi9 for ; Fri, 11 May 2012 14:40:32 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id C0C4421F8666 for ; Fri, 11 May 2012 14:40:32 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.255.200]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1SSxZg-0002Ya-7V for netext@ietf.org; Fri, 11 May 2012 17:40:32 -0400 Message-ID: <4FAD873D.4040204@computer.org> Date: Fri, 11 May 2012 14:40:13 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: netext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86065e473a2f474708b133402e39a6a1de350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Subject: [netext] Alternate Tunnel Source Address for LMA and Home Agent X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 21:40:33 -0000 Hello folks, I have submitted draft-perkins-netext-hatunaddr-00.txt. I hope that there will be interest in the [netext] working group for this proposal. -- Regards, Charlie P. From sgundave@cisco.com Fri May 11 16:00:58 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B411421F8539 for ; Fri, 11 May 2012 16:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.594 X-Spam-Level: X-Spam-Status: No, score=-10.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1+ru4jindql for ; Fri, 11 May 2012 16:00:58 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 01BA421F8534 for ; Fri, 11 May 2012 16:00:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=2214; q=dns/txt; s=iport; t=1336777258; x=1337986858; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=4h6rurEe/ZYXuceHbVDQAuupeJM79HoTKZ5tscQDDTY=; b=OR3mtBjY9tGuBn8wMOAf/HjakxTNH4xNavvXrTe115kUfxEwS+J0Tmpu aQBIvsjGs9W+C+LUwAlaF+0OGOfW/ql14rhFd/EGnDeOpr/G8ZgeTwAtZ wBkvYRoCsD/3heHIEctM5N58GA2axHfm/PtMvohP2ou/Uw2rffCwvnVIF s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAOCZrU+rRDoH/2dsb2JhbABEs2+BB4IVAQEBAwEBAQEPASc0CxALRicwBhMih2cEDJssn2UEixeFOmMEiGSNGY5XgWmDCQ X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="41908623" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 11 May 2012 23:00:58 +0000 Received: from stealth-10-32-246-214.cisco.com (stealth-10-32-246-214.cisco.com [10.32.246.214]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q4BN0vVj030627; Fri, 11 May 2012 23:00:57 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Sri Gundavelli In-Reply-To: <4FAD873D.4040204@computer.org> Date: Fri, 11 May 2012 16:00:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FAD873D.4040204@computer.org> To: "Charles E. Perkins" X-Mailer: Apple Mail (2.1257) Cc: netext@ietf.org Subject: Re: [netext] Alternate Tunnel Source Address for LMA and Home Agent X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 23:00:58 -0000 Hi Charlie, Thanks for sharing the document. Currently, we do have the support for = the following: - Alternate Care-of Address mobility option for a mobile node to = register IPv6 reachability address for the data path termination - We have the Alternate IPv4 Care-of Address mobility option for a = mobile node to register a IPv4 reachability address for the data path = termination This essentially, allows the MAG to achieve register different IP = addresses for control and data plane termination. However, the gaps = exists on the LMA, there are no semantics to deliver a different data = path address. So, your proposal fixes this gap and that's great. But, = I've some comments. 1. Its unclear if the option can be used for both IPv4 and IPv6 tunnel = end point registration. To be consistent with Alternate (IPv6) Care-of = address and Alternate IPv4 Care-of Address options, its better to = define one more option. You may want to define a new option 2. The spec is not clear on how this option is used with Binding = Revocation and other messages. You may want to add some clarifications = on the usage 3. Please add a reference to RFC-6463 on the Alt IPv4 Care-of address = option 4. The draft is bit ambitious :), it seems to be extending Mobile IPv4 = as well. I'm not sure, if we ever mixed Mobile IPv4 and Mobile = IPv6/PMIPv6 extensions in a single spec 5. Finally, it will be very useful, if we can have some thing in = Appendix, that shows how MAG and LMA can use different IP address end = points for control and data plane traffic. Thanks for writing this up and finally posting it in MEXT. Long back = there used to be a guy, Vijay D., he wanted to write this up for long = time :) Regards Sri On May 11, 2012, at 2:40 PM, Charles E. Perkins wrote: >=20 > Hello folks, >=20 > I have submitted draft-perkins-netext-hatunaddr-00.txt. I hope that = there will be interest in the [netext] working group for this proposal. >=20 > --=20 > Regards, > Charlie P. >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From wwwrun@rfc-editor.org Mon May 14 17:02:34 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029EE21F889C; Mon, 14 May 2012 17:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.116 X-Spam-Level: X-Spam-Status: No, score=-102.116 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8yFz7QvlAXy; Mon, 14 May 2012 17:02:33 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 880CD21F886F; Mon, 14 May 2012 17:02:33 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C27BBB1E003; Mon, 14 May 2012 16:59:56 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120514235956.C27BBB1E003@rfc-editor.org> Date: Mon, 14 May 2012 16:59:56 -0700 (PDT) Cc: netext@ietf.org, rfc-editor@rfc-editor.org Subject: [netext] RFC 6602 on Bulk Binding Update Support for Proxy Mobile IPv6 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 00:02:34 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6602 Title: Bulk Binding Update Support for Proxy Mobile IPv6 Author: F. Abinader, Ed., S. Gundavelli, Ed., K. Leung, S. Krishnan, D. Premec Status: Standards Track Stream: IETF Date: May 2012 Mailbox: fabinader@gmail.com, sgundave@cisco.com, kleung@cisco.com, suresh.krishnan@ericsson.com, domagoj.premec@gmail.com Pages: 23 Characters: 56348 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netext-bulk-re-registration-12.txt URL: http://www.rfc-editor.org/rfc/rfc6602.txt For extending the lifetime of a mobility session, the Proxy Mobile IPv6 specification requires the mobile access gateway to send a Proxy Binding Update message to the local mobility anchor on a per-session basis. In the absence of signaling semantics for performing operations with group-specific scope, this results in a significant amount of signaling traffic on a periodic basis between a given mobile access gateway and a local mobility anchor. This document defines optimizations to the binding update and revocation operations in Proxy Mobile IPv6 for performing operations with group-specific scope with the use of a group identifier. [STANDARDS-TRACK] This document is a product of the Network-Based Mobility Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From sarikaya2012@gmail.com Tue May 15 11:17:09 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E5021F87F2 for ; Tue, 15 May 2012 11:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.557 X-Spam-Level: X-Spam-Status: No, score=-3.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1dDdB+U-kIA for ; Tue, 15 May 2012 11:17:08 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B0A9221F871A for ; Tue, 15 May 2012 11:17:08 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so11210985obb.31 for ; Tue, 15 May 2012 11:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=74Df2QdLo1xN0qJZfMpNZGVIZhqVaGX6i+jRDWQn8xo=; b=QzYzDKhGopgaVBpO+KDpWgVbLUistdTmfMff3z9odrVpw3eDM4prEFrM2BuF3AG9qc Iib4JkAkDB8yxgKxFi431WhaZ2qf26MJy6vpjQW6PDwaZrtmbBdLmeWgdw11wvPcvBPa uFbfMwIkWLbUw13RMNJG8OZzPDOzekQ8w1M8V3lRB51bmiPAvQ/DYNEoYyFbK9B4N1vL J839lfbuSxCFEMnQKZC+aVVHoNJZ/QKdfPWwX4jv+vpp/s0b/VaQ9EF6fe4GxVFy+p7W bdwonYMcbW8dN0LacZHwOBg4X7rKNvH3iej9hmjVXZlmAK+aR5IDiCQIdek2yJ19GVC9 zQIw== MIME-Version: 1.0 Received: by 10.182.115.74 with SMTP id jm10mr18473147obb.71.1337105828194; Tue, 15 May 2012 11:17:08 -0700 (PDT) Received: by 10.60.164.103 with HTTP; Tue, 15 May 2012 11:17:08 -0700 (PDT) In-Reply-To: <4FAD873D.4040204@computer.org> References: <4FAD873D.4040204@computer.org> Date: Tue, 15 May 2012 13:17:08 -0500 Message-ID: From: Behcet Sarikaya To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Alternate Tunnel Source Address for LMA and Home Agent X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 18:17:09 -0000 Hi Charlie, I think that this draft belongs to dmm WG. I don't understand what is the relevance of your content with Netext which deals with PMIPv6. Regards, Behcet On Fri, May 11, 2012 at 4:40 PM, Charles E. Perkins wrote: > > Hello folks, > > I have submitted draft-perkins-netext-hatunaddr-00.txt. =A0I hope that th= ere > will be interest in the [netext] working group for this proposal. > > -- > Regards, > Charlie P. > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From cjbc@it.uc3m.es Wed May 16 13:38:11 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C843D21F86B0 for ; Wed, 16 May 2012 13:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kW-xan6tswkC for ; Wed, 16 May 2012 13:38:10 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8ED21F8682 for ; Wed, 16 May 2012 13:38:10 -0700 (PDT) X-uc3m-safe: yes Received: from [192.168.1.3] (89.141.94.44.dyn.user.ono.com [89.141.94.44]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: verified sender ) by smtp03.uc3m.es (Postfix) with ESMTP id 54BD79D1EBF Message-ID: <1337200687.3263.17.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "netext@ietf.org" Date: Wed, 16 May 2012 22:38:07 +0200 Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-hYMgJVL6TxFs/ZO+V8Ow" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18908.007 Cc: draft-liebsch-netext-pmip6-qos@tools.ietf.org Subject: [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 20:38:11 -0000 --=-hYMgJVL6TxFs/ZO+V8Ow Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Dear authors, all, I've read the draft and I find it a very useful missing piece for NETEXT, thanks for writing it. While I must admint that I want to read it again more carefully to provide more comments, I have a couple of questions (apologies if you have already discussed them): - The QoS option, is it per flow, per MN or per mobility session? Looking at the draft I'd say it should support per-flow granularity, but then I look at the options and I don't fully see if that is the case. - Regarding the relevant QoS attributes, are you planning to add more or this will this be left out of the scope of the draft? For example, with IEEE 802.11e, I'm not sure the mapping could be done without adding more. Thanks again for the draft. I think this should be considered to be included as part of NETEXT work. Carlos --=20 Carlos Jes=FAs 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=20 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-hYMgJVL6TxFs/ZO+V8Ow Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk+0EC8ACgkQNdy6TdFwT2c4UwCgiAgckk8Dm6OY1WwhfWw5yNkB NYUAn3PJvj6tneBMody3I4CWnsnjd1AX =XZAK -----END PGP SIGNATURE----- --=-hYMgJVL6TxFs/ZO+V8Ow-- From jouni.nospam@gmail.com Wed May 16 14:06:00 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B5321F86E3 for ; Wed, 16 May 2012 14:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PleTv1pDCBYD for ; Wed, 16 May 2012 14:06:00 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B5AF421F86BE for ; Wed, 16 May 2012 14:05:59 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so793723wgb.13 for ; Wed, 16 May 2012 14:05:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=wclAS91fgAYZiZI9s0akoHc5VE7mybQ6iPHUufXaPkQ=; b=XyRlRvAI5Bu0AId2e3V2ZRLpJhkm72nUa0wDjfMIIX5UGRiRkYrbN7O5e2B9Af6dyi HmEMqWgMiS1Yuj4E0XY3h6GBzbsIEjW0VG+eYlvTB7K2sucAsNI6tA62vMsJH++ZLqn+ Rjj0trzfJz/F7i1MLREQjmDqVSKqeBPp08Z+nbH05Qnqvm5+r6Bw07NBaB7OYiWwu4KT 9z8x+gdI8b7icCfwvXgr7QUhC0J0oq70eoXx9ujB4FJPMfKbDiQZKc3nd7JX+gX3jZ0Y t0qI6zaxzX3QnuquaXYsK5ViYCC0D//j+jiRNi80ZJkRdGcGPS72h2byyA1JrQqfVtT1 pPrg== Received: by 10.180.104.137 with SMTP id ge9mr11549153wib.20.1337202356432; Wed, 16 May 2012 14:05:56 -0700 (PDT) Received: from [188.117.15.110] ([188.117.15.110]) by mx.google.com with ESMTPS id h8sm12950745wix.4.2012.05.16.14.05.55 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 May 2012 14:05:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Jouni In-Reply-To: <1337200687.3263.17.camel@acorde.it.uc3m.es> Date: Thu, 17 May 2012 00:05:53 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <854C126F-877A-4212-9A9F-7CB2C210B408@gmail.com> References: <1337200687.3263.17.camel@acorde.it.uc3m.es> To: cjbc@it.uc3m.es X-Mailer: Apple Mail (2.1257) Cc: draft-liebsch-netext-pmip6-qos@tools.ietf.org, "netext@ietf.org" Subject: Re: [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 21:06:01 -0000 Carlos, On May 16, 2012, at 11:38 PM, Carlos Jes=FAs Bernardos Cano wrote: > Dear authors, all, >=20 > I've read the draft and I find it a very useful missing piece for > NETEXT, thanks for writing it. >=20 > While I must admint that I want to read it again more carefully to > provide more comments, I have a couple of questions (apologies if you > have already discussed them): >=20 > - The QoS option, is it per flow, per MN or per mobility session? > Looking at the draft I'd say it should support per-flow granularity, = but > then I look at the options and I don't fully see if that is the case. The QoS option allows you to go into the detail RFC6088 traffic = selectors allow. That is into too detailed flow granularity IMHO but possible..=20 However, if you go into QoS information attributes that the draft = currently have, they are defined either per MN or per mobility session but still = you can do everything at flow level. The attributes we have now mostly = define the aggregates. > - Regarding the relevant QoS attributes, are you planning to add more = or > this will this be left out of the scope of the draft? For example, = with > IEEE 802.11e, I'm not sure the mapping could be done without adding > more. Current draft is intentionally rather conservative on attributes. Those can be added at will.. Our intention was to cover deployment cases we = had immediate (known) need for. - Jouni >=20 > Thanks again for the draft. I think this should be considered to be > included as part of NETEXT work. >=20 > Carlos >=20 > --=20 > Carlos Jes=FAs 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=20 > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From cjbc@it.uc3m.es Thu May 17 00:43:05 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6628621F8631 for ; Thu, 17 May 2012 00:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bharzT4BMSAV for ; Thu, 17 May 2012 00:43:04 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id A3B0621F862B for ; Thu, 17 May 2012 00:43:03 -0700 (PDT) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 549628209; Thu, 17 May 2012 09:43:01 +0200 (CEST) Message-ID: <1337240581.3623.11.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Jouni Date: Thu, 17 May 2012 09:43:01 +0200 In-Reply-To: <854C126F-877A-4212-9A9F-7CB2C210B408@gmail.com> References: <1337200687.3263.17.camel@acorde.it.uc3m.es> <854C126F-877A-4212-9A9F-7CB2C210B408@gmail.com> Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-LCO6GbpeF+Ai938q9mRA" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-18850.006 X-TM-AS-Result: No--26.493-7.0-31-1 X-imss-scan-details: No--26.493-7.0-31-1 Cc: draft-liebsch-netext-pmip6-qos@tools.ietf.org, "netext@ietf.org" Subject: Re: [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 07:43:05 -0000 --=-LCO6GbpeF+Ai938q9mRA Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Jouni, On Thu, 2012-05-17 at 00:05 +0300, Jouni wrote: > Carlos, >=20 >=20 > On May 16, 2012, at 11:38 PM, Carlos Jes=FAs Bernardos Cano wrote: >=20 > > Dear authors, all, > >=20 > > I've read the draft and I find it a very useful missing piece for > > NETEXT, thanks for writing it. > >=20 > > While I must admint that I want to read it again more carefully to > > provide more comments, I have a couple of questions (apologies if you > > have already discussed them): > >=20 > > - The QoS option, is it per flow, per MN or per mobility session? > > Looking at the draft I'd say it should support per-flow granularity, bu= t > > then I look at the options and I don't fully see if that is the case. >=20 > The QoS option allows you to go into the detail RFC6088 traffic selectors > allow. That is into too detailed flow granularity IMHO but possible..=20 >=20 > However, if you go into QoS information attributes that the draft current= ly > have, they are defined either per MN or per mobility session but still yo= u > can do everything at flow level. The attributes we have now mostly define > the aggregates. Yes, this exactly the impression I got. In some parts of the draft it seems that flow granularity is possible, but then I missed the attributes at that level. >=20 > > - Regarding the relevant QoS attributes, are you planning to add more o= r > > this will this be left out of the scope of the draft? For example, with > > IEEE 802.11e, I'm not sure the mapping could be done without adding > > more. >=20 > Current draft is intentionally rather conservative on attributes. Those > can be added at will.. Our intention was to cover deployment cases we had > immediate (known) need for. OK, I just mentioned .11e because it is one of the examples listed in the draft. In some cases, the mapping between the attributes and the parameters that would need to be used for a some L2 technologies would not be very straightforward, but this is an independent issue not related to what the draft aims at covering. Thanks, Carlos >=20 > - Jouni >=20 > >=20 > > Thanks again for the draft. I think this should be considered to be > > included as part of NETEXT work. > >=20 > > Carlos > >=20 > > --=20 > > Carlos Jes=FAs 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=20 > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >=20 --=20 Carlos Jes=FAs 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=20 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-LCO6GbpeF+Ai938q9mRA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk+0rAUACgkQNdy6TdFwT2f8CACgwKqWoh4YpgNJH5OvtMjWvofN t5kAnjnT3gaiwnqV5oIdsBXMuBfmusQY =yG82 -----END PGP SIGNATURE----- --=-LCO6GbpeF+Ai938q9mRA-- From sarikaya2012@gmail.com Thu May 17 12:19:28 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0123321F86D4 for ; Thu, 17 May 2012 12:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMRL1cUJ+70R for ; Thu, 17 May 2012 12:19:27 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id EA0D121F86CE for ; Thu, 17 May 2012 12:19:26 -0700 (PDT) Received: by yhq56 with SMTP id 56so2613886yhq.31 for ; Thu, 17 May 2012 12:19:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=QFQJLduMxGOJlmy4jSLfrqPpoisCPVz9NZGr2ZtLoN0=; b=mBeQB9WrJU+CROQmzc6TcVLLr8/dPHaAosSY7IufkRgFatDgymsC1tGNppSS1NHwkV ytkD0rigtwELUAQTL4JqQTydE2KN90ix2lU+7yevNOTwapZ6gwXX+wiJtzQcJ/DIGMq3 NG/1JFUy/pYq+lRA9upgwemGeVoh9+eLZblRRx/L4RlfI+i/yO/SJ6QFu9hoR2L18qGw XfnOrC58PPkYqENN3g+oDO9GnxD1BZOGsELeHWlyCZ/01X0KM+WbmdGPwXQsFIfeNNdk Am6FydpbslNe+kuiMgu7yjnHE7CmvGT0J6Aq+m5xzAEXgE4H0KPrlbKMazb7+aDgW/EJ OqgQ== MIME-Version: 1.0 Received: by 10.50.178.106 with SMTP id cx10mr6846747igc.9.1337282366483; Thu, 17 May 2012 12:19:26 -0700 (PDT) Received: by 10.231.78.10 with HTTP; Thu, 17 May 2012 12:19:26 -0700 (PDT) In-Reply-To: References: Date: Thu, 17 May 2012 14:19:26 -0500 Message-ID: From: Behcet Sarikaya To: Sri Gundavelli Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 19:19:28 -0000 On Fri, Apr 27, 2012 at 11:53 AM, Sri Gundavelli wrote= : > Mac address is bound to the EAP identity. The Wireless LAN Controller/Acc= ess > Point has the Mac to identity binding, which has association in the BUL > entry. What if EAP is not used? Anyways, read the draft. Behcet > > > > Sri > > > On 4/27/12 9:51 AM, "Behcet Sarikaya" wrote: > >> On Fri, Apr 27, 2012 at 11:45 AM, Sri Gundavelli wr= ote: >>>> I wonder how do you map to a single receiver if there are more than >>>> one receivers, i.e. the correct receiver? >>> >>> L3-Multicast, L2 unicast to a given node. RFC 6085. This is standard st= uff; >>> There is no issue here. >>> >> >> I read RFC 6085. >> >> I had that question and I could not find an answer for that? How does >> the AP know "the given node"? >> >> Anyways, I repeat my plea for documenting this issue in Netext and >> clearing the air once and for all. >> >> Behcet >>> >>> >>> Sri >>> >>> >>> >>> >>> >>> >>> On Apr 27, 2012, at 9:43 AM, Behcet Sarikaya wrote: >>> >>>> Hi Sri, >>>> >>>> Thanks for chipping in your valuable views on this. >>>> Basavaraj seems to disagree that there is a problem there but I don't = know >>>> why? >>>> >>>> On Fri, Apr 27, 2012 at 11:15 AM, Sri Gundavelli = wrote: >>>>> Hi Behcet: >>>>> >>>>> Sorry to jump in to this thread. I'm going to respond/clarify only on= one >>>>> specific comment (may be tangential to your discussion), as I'm not >>>>> following this thread/rest of the discussion. I want to clarify only = that >>>>> one part though about WLAN, PMIPv6 and SaMOG. >>>>> >>>>> >>>>> >>>>>>> Why? Are you saying that the current link model for PMIP6 allows on= ly a >>>>>>> single MN to attach to a WiFi AP (as an example)? >>>>>>> What is the basis for saying that having many MNs attach to a MAG i= n a >>>>>>> hotspot (assuming wifi) will result in problems? >>>>>>> Is there any work that you have done to make such a statement? >>>>>> >>>>>> >>>>>> As you know similar concerns have been voiced over and over again in >>>>>> Netext. >>>>>> >>>>>> Isn't it time to do something on this? >>>>>> >>>>>> Clarify that everything will work fine >>>>> >>>>> >>>>> >>>>> It is true, WLAN access is a shared media and what we need in Proxy >>>>> Mobile IPv6 is essentially the ability for the MAG to advertise unica= st >>>>> RA's/or in general keep multicast traffic map to a single receiver (a= s >>>>> clarified in RFC-6085). This is today the case on WLAN access >>>>> networks. A client when it sends a multicast/broadcast packet, that >>>>> packet is not sensed by the other receivers directly on the air inter= face, >>>>> as in the case of ethernet, but rather it hits the access point and i= ts the >>>>> function if the access point to stream it down with using the correct >>>>> multicast keys; this in essence is giving the model that we needed, a= s l >>>>> ong as the access point/WLC blocks multicast traffic from wireless >>>>> clients from other wireless clients. =A0All most every WLAN deploymen= t is >>>>> typically configured to operate it this way. The SaMOG architecture (= or >>>>> the WLAN IWK document that I've published), makes that assumption >>>>> with impact to link model, else SaMOG architecture (with either of S2= a >>>>> protocol interfaces) is broken and un deployable. >>>>> >>>> >>>> I wonder how do you map to a single receiver if there are more than >>>> one receivers, i.e. the correct receiver? >>>> >>>> You mentioned WLAN IWK document, can you provide the link? >>>> >>>> As you know there are also Layer 2 solutions. >>>> >>>> I think we need to document it in Netext, maybe the chairs can add a >>>> milestone on this to the charter? >>>> >>>> Regards, >>>> >>>> Behcet >>>> >>>> >>>>> >>>>> >>>>> Regards >>>>> Sri >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Apr 27, 2012, at 8:34 AM, Behcet Sarikaya wrote: >>>>> >>>>>> Hi Basavaraj, >>>>>> >>>>>> Pls see inline. >>>>>> >>>>>> On Thu, Apr 26, 2012 at 10:44 AM, =A0 wro= te: >>>>>>> >>>>>>> Inline: >>>>>>> >>>>>>> On 4/26/12 9:59 AM, "ext Behcet Sarikaya" = wrote: >>>>>>> >>>>>>>> Hi Basavaraj, >>>>>>>> >>>>>>>>>> 2. As I said above, the draft's main concern is MN authenticatio= n on >>>>>>>>>> Wi-Fi links. As we all know, PMIPv6 is based on point-to-point l= inks >>>>>>>>>> and Wi-Fi link is a shared link. >>>>>>>>>> Does this raise any concerns to you? >>>>>>>>> >>>>>>>>> No. >>>>>>>> >>>>>>>> Really? >>>>>>>> >>>>>>>> Imagine MAG as defined in RFC 5213 (which assumes that each MN is = on a >>>>>>>> point-to-point link) is connected to a shared link. >>>>>>> >>>>>>> We all understand the link model requirements for PMIP6. Nothing is= being >>>>>>> changed there. >>>>>>> >>>>>>>> I think the result will be disastrous. >>>>>>> >>>>>>> Why? Can you elaborate? >>>>>>> >>>>>>>> If there is only one MN, it may >>>>>>>> be OK but as more MNs join, especially in hot spots then the probl= ems >>>>>>>> start. >>>>>>> >>>>>>> Why? Are you saying that the current link model for PMIP6 allows on= ly a >>>>>>> single MN to attach to a WiFi AP (as an example)? >>>>>>> What is the basis for saying that having many MNs attach to a MAG i= n a >>>>>>> hotspot (assuming wifi) will result in problems? >>>>>>> Is there any work that you have done to make such a statement? >>>>>> >>>>>> >>>>>> As you know similar concerns have been voiced over and over again in >>>>>> Netext. >>>>>> >>>>>> Isn't it time to do something on this? >>>>>> >>>>>> Clarify that everything will work fine >>>>>> >>>>>> or >>>>>> >>>>>> if not, then propose solutions. >>>>>> >>>>>> If you look at SaMOG work in 3GPP, they repeatedly said WiFi should >>>>>> provide point to point link to UEs. >>>>>> >>>>>> Why do you think they said so if they anticipated no problems? >>>>>> >>>>>> Behcet >>>>>> _______________________________________________ >>>>>> netext mailing list >>>>>> netext@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netext >>>>> >>> > From sgundave@cisco.com Thu May 17 16:50:01 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A5521F8734 for ; Thu, 17 May 2012 16:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.594 X-Spam-Level: X-Spam-Status: No, score=-10.594 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gy8q+lrCTKMc for ; Thu, 17 May 2012 16:50:00 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 933A521F8701 for ; Thu, 17 May 2012 16:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=7260; q=dns/txt; s=iport; t=1337298600; x=1338508200; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=DxGNbX/VLr/WYqvv36Qt3bnGQmisSzL9jR5ru+YZqOU=; b=e6u2Ll4877wUZhVzAtdml2vEbfgo1Hx8Mlfk4dBPBroJdQdTQ+zwvmXN 3K6e2qETBN/IrYCWCnUIvSxsCIkUFiHah53JtBlUrnAF05E5Ykz8comrH E+ZOgdUa0p1LKY8D7y+IDxtynfWYyRfdsFL0jme3BV8QcFeoFNM9cH9H/ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEqOtU+rRDoG/2dsb2JhbAA8CbNQgQeCFQEBAQMBEgFmBQsLGC4hNhkih14DBgScJ5YZDYlTihZuEIIYgkFiA4hbjH+LHoMYgWSDCQ X-IronPort-AV: E=Sophos;i="4.75,612,1330905600"; d="scan'208,217";a="42680752" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 17 May 2012 23:50:00 +0000 Received: from stealth-10-32-246-212.cisco.com (stealth-10-32-246-212.cisco.com [10.32.246.212]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q4HNnxle029314; Thu, 17 May 2012 23:50:00 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_8E033819-1191-4400-9BC8-06BE782D6835" From: Sri Gundavelli In-Reply-To: Date: Thu, 17 May 2012 16:49:59 -0700 Message-Id: <09843C17-A495-4A00-A176-E5DD77B36303@cisco.com> References: To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1278) Cc: netext@ietf.org Subject: Re: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 23:50:01 -0000 --Apple-Mail=_8E033819-1191-4400-9BC8-06BE782D6835 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I thought the discussion was about the case when EAP is in use. Any = case, my point is JUST about how L2 unicast semantics can be used by the = MAG on the WLAN access. How the MAG learns about that L2 identity is a = different consideration; if there is always EAP or some thing I = commented on =85 Sri On May 17, 2012, at 12:19 PM, Behcet Sarikaya wrote: > On Fri, Apr 27, 2012 at 11:53 AM, Sri Gundavelli = wrote: >> Mac address is bound to the EAP identity. The Wireless LAN = Controller/Access >> Point has the Mac to identity binding, which has association in the = BUL >> entry. >=20 >=20 > What if EAP is not used? >=20 > Anyways, read the draft. >=20 > Behcet >=20 >>=20 >>=20 >>=20 >> Sri >>=20 >>=20 >> On 4/27/12 9:51 AM, "Behcet Sarikaya" wrote: >>=20 >>> On Fri, Apr 27, 2012 at 11:45 AM, Sri Gundavelli = wrote: >>>>> I wonder how do you map to a single receiver if there are more = than >>>>> one receivers, i.e. the correct receiver? >>>>=20 >>>> L3-Multicast, L2 unicast to a given node. RFC 6085. This is = standard stuff; >>>> There is no issue here. >>>>=20 >>>=20 >>> I read RFC 6085. >>>=20 >>> I had that question and I could not find an answer for that? How = does >>> the AP know "the given node"? >>>=20 >>> Anyways, I repeat my plea for documenting this issue in Netext and >>> clearing the air once and for all. >>>=20 >>> Behcet >>>>=20 >>>>=20 >>>> Sri >>>>=20 >>>=20 --Apple-Mail=_8E033819-1191-4400-9BC8-06BE782D6835 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Fri, Apr = 27, 2012 at 11:53 AM, Sri Gundavelli <sgundave@cisco.com> = wrote:
Mac address is bound to the EAP = identity. The Wireless LAN Controller/Access
Point has the Mac to identity binding, which has = association in the BUL
entry.


What if EAP is not = used?

Anyways, read the draft.

Behcet




Sri


On 4/27/12 9:51 = AM, "Behcet Sarikaya" <sarikaya2012@gmail.com> = wrote:

On Fri, Apr 27, 2012 at 11:45 AM, Sri Gundavelli <sgundave@cisco.com> = wrote:
I = wonder how do you map to a single receiver if there are more = than
one receivers, i.e. the correct = receiver?

L3-Multicast, L2 unicast to a given node. RFC 6085. This = is standard stuff;
There = is no issue here.


I read RFC = 6085.

I had that question and I could = not find an answer for that? How = does
the AP know "the given = node"?

Anyways, I repeat my plea for = documenting this issue in Netext = and
clearing the air once and for = all.

Behcet


Sri



= --Apple-Mail=_8E033819-1191-4400-9BC8-06BE782D6835-- From sgundave@cisco.com Thu May 17 17:00:44 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7C121F87FE for ; Thu, 17 May 2012 17:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.595 X-Spam-Level: X-Spam-Status: No, score=-10.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEF1+JhMsFxR for ; Thu, 17 May 2012 17:00:44 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 378AC21F87FD for ; Thu, 17 May 2012 17:00:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=1520; q=dns/txt; s=iport; t=1337299244; x=1338508844; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=J4zzihqOw3By3FPXq6WSXLZZ5teEl7fDYwGFoXnRHV4=; b=TOa/Htw6xquxFzZVHlpdkmL2NST2c0B3W4K2AF0GB3Xg6Wo4cDELdjCb gUxJZYwtLbgIJpiIPLRSM2WlfW9eP6eGUx0bSPMx8BO9BLFxSF3kNqHDt TWcgZjXjkvNAQQPLBDghS1bcy6yEfxHzV+37C3NrCmuPN3EbLIpmcsDi6 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EACKQtU+rRDoI/2dsb2JhbABFs1GBB4IVAQEBAwEBAQEPAVsLBQsLGC4nMBkih2cEDJwfn3cEiwSCKIJBYgOIW4x/jjaBZIMJ X-IronPort-AV: E=Sophos;i="4.75,612,1330905600"; d="scan'208";a="42143012" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 18 May 2012 00:00:44 +0000 Received: from stealth-10-32-246-212.cisco.com (stealth-10-32-246-212.cisco.com [10.32.246.212]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q4I00h4j019204; Fri, 18 May 2012 00:00:43 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Sri Gundavelli In-Reply-To: Date: Thu, 17 May 2012 17:00:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <28BB2D37-D4D0-4A83-8157-E7F413693F2E@cisco.com> References: <4FAD873D.4040204@computer.org> To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1278) Cc: netext@ietf.org Subject: Re: [netext] Alternate Tunnel Source Address for LMA and Home Agent X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 00:00:45 -0000 Behcet:=20 This is related to the Alternate CoA option that we have for the MAG; = the same option for LMA. What Charlie is proposing is a PMIPv6 protocol = option for allowing the LMA to register a different IP address for the = tunnel end-point, different from the destination IP address in the PBU. = It is a mobility option over PMIPv6 control plane with LMA/MAG = operational specification. The WG is already pathetically slow (we all = can take the blame) in defining new extensions, we bake the specs for = years, now if we argue about these minor extensions, it does not help = the guys who are bringing contributions. Sri On May 15, 2012, at 11:17 AM, Behcet Sarikaya wrote: > Hi Charlie, >=20 > I think that this draft belongs to dmm WG. I don't understand what is > the relevance of your content with Netext which deals with PMIPv6. >=20 > Regards, >=20 > Behcet >=20 > On Fri, May 11, 2012 at 4:40 PM, Charles E. Perkins > wrote: >>=20 >> Hello folks, >>=20 >> I have submitted draft-perkins-netext-hatunaddr-00.txt. I hope that = there >> will be interest in the [netext] working group for this proposal. >>=20 >> -- >> Regards, >> Charlie P. >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From charliep@computer.org Thu May 17 21:00:05 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6F721F8686 for ; Thu, 17 May 2012 21:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wR-AjVrqxpOn for ; Thu, 17 May 2012 21:00:04 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 87FDB21F8683 for ; Thu, 17 May 2012 21:00:04 -0700 (PDT) Received: from [65.127.208.182] (helo=[10.1.0.188]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1SVEMF-0003pn-PS; Fri, 18 May 2012 00:00:03 -0400 Message-ID: <4FB5C93D.6030202@computer.org> Date: Thu, 17 May 2012 20:59:57 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Sri Gundavelli References: <4FAD873D.4040204@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8688b6f6993814949cfd858c1363e2b2eb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 65.127.208.182 Cc: netext@ietf.org Subject: Re: [netext] Alternate Tunnel Source Address for LMA and Home Agent X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 04:00:05 -0000 On 5/11/2012 4:00 PM, Sri Gundavelli wrote: > 1. Its unclear if the option can be used for both IPv4 and IPv6 tunnel end point registration. To be consistent with Alternate (IPv6) Care-of address and Alternate IPv4 Care-of Address options, its better to define one more option. You may want to define a new option Do you mean that the LMA might instruct the IPv6 mobile node to tunnel data to an IPv4 address? Yes, I think this would require another option. I'll include this feature. > 2. The spec is not clear on how this option is used with Binding Revocation and other messages. You may want to add some clarifications on the usage Well, I would expect that if the binding is revoked, then the data plane tunnel is no longer useful either. In this case, the option would not be useful with the Binding Revocation message. If, on the other hand, the Binding Revocation message were issued to the MN including the Alternate Tunnel Source Address option, it could be interpreted as instruction for the mobile node to refer to using the LMA address as the IP address of home agent data plane tunnel endpoint. I'm not sure anyone would want that, and it's not a completely natural interpretation. But it's within the realm of imagination. What do you suggest? If the document is accepted as a working group document, I'll provide more detailed descriptions about other possible messages from the LMA (or Home Agent). > > 3. Please add a reference to RFC-6463 on the Alt IPv4 Care-of address option Check. I can also include text about it from your email. > > 4. The draft is bit ambitious :), it seems to be extending Mobile IPv4 as well. I'm not sure, if we ever mixed Mobile IPv4 and Mobile IPv6/PMIPv6 extensions in a single spec I think there is a precedent for this -- at least I know I've written up such documents before. But I'm open to suggestion about it. > > 5. Finally, it will be very useful, if we can have some thing in Appendix, that shows how MAG and LMA can use different IP address end points for control and data plane traffic. Do you mean a flow diagram? Is it really unclear enough to need ASCII art? O.K., I'll do it if the working group adopts the document. Regards, Charlie P. From sgundave@cisco.com Thu May 17 21:50:39 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD71321F8713 for ; Thu, 17 May 2012 21:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.595 X-Spam-Level: X-Spam-Status: No, score=-10.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYMhfj8Qqe0I for ; Thu, 17 May 2012 21:50:39 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id F25C721F8711 for ; Thu, 17 May 2012 21:50:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=3124; q=dns/txt; s=iport; t=1337316639; x=1338526239; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=vJbjZiktbkKVdnOxFS3RyrvFyqvXH4yw522cYbbYWzo=; b=JUSGnqTC8HDEWZkKolC9zpS8tATRPGLeP7iiRQKrKc3ZHzI5WpVup/P5 0ckBtoSeD+ppe5uNb9JHQQByPhbxKrht3Ad30JpsEVp4fzoFzGUw59WEG ht0Hp5Y9mxA7ZZQvfLd7TmdZRMjQjvlcVJK3ClrVld6c1ULGc0imYiPIk o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEKAKPTtU+rRDoJ/2dsb2JhbAAMObAPg0WBB4IVAQEBAwESAWYFCwsYLlcGNYdnBJw/n3GKf4RkYgOIQIxfjhGBZIMJgTYJDw X-IronPort-AV: E=Sophos;i="4.75,614,1330905600"; d="scan'208";a="42705643" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 18 May 2012 04:50:37 +0000 Received: from stealth-10-32-246-212.cisco.com (stealth-10-32-246-212.cisco.com [10.32.246.212]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q4I4oak2028289; Fri, 18 May 2012 04:50:37 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Sri Gundavelli In-Reply-To: <4FB5C93D.6030202@computer.org> Date: Thu, 17 May 2012 21:50:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <106A1168-1EDB-43E9-9F04-AB0E95080E41@cisco.com> References: <4FAD873D.4040204@computer.org> <4FB5C93D.6030202@computer.org> To: "Charles E. Perkins" X-Mailer: Apple Mail (2.1278) Cc: netext@ietf.org Subject: Re: [netext] Alternate Tunnel Source Address for LMA and Home Agent X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 04:50:40 -0000 Charlie: On May 17, 2012, at 8:59 PM, Charles E. Perkins wrote: > On 5/11/2012 4:00 PM, Sri Gundavelli wrote: >> 1. Its unclear if the option can be used for both IPv4 and IPv6 = tunnel end point registration. To be consistent with Alternate (IPv6) = Care-of address and Alternate IPv4 Care-of Address options, its better = to define one more option. You may want to define a new option >=20 > Do you mean that the LMA might instruct the IPv6 mobile node to tunnel = data to an IPv4 address? > Yes, I think this would require another option. I'll include this = feature. Since, we do support both IPv4 [RFC5844] and IPv6 transport [RFC5213] = for PMIPv6, we need both the variants of Alt-Tunnel-Source option >=20 >> 2. The spec is not clear on how this option is used with Binding = Revocation and other messages. You may want to add some clarifications = on the usage >=20 > Well, I would expect that if the binding is revoked, then the data = plane tunnel is no longer useful either. > In this case, the option would not be useful with the Binding = Revocation message. >=20 I intended to say, we need more text on where the option is relevant and = where its not relevant. I agree, its not relevant for BRI/BRA. > If, on the other hand, the Binding Revocation message were issued to = the MN including the > Alternate Tunnel Source Address option, it could be interpreted as = instruction for the mobile > node to refer to using the LMA address as the IP address of home agent = data plane tunnel > endpoint. I'm not sure anyone would want that, and it's not a = completely natural interpretation. > But it's within the realm of imagination. What do you suggest? >=20 > If the document is accepted as a working group document, I'll provide = more detailed > descriptions about other possible messages from the LMA (or Home = Agent). Ok >=20 >>=20 >> 3. Please add a reference to RFC-6463 on the Alt IPv4 Care-of address = option >=20 > Check. I can also include text about it from your email. >=20 >>=20 >> 4. The draft is bit ambitious :), it seems to be extending Mobile = IPv4 as well. I'm not sure, if we ever mixed Mobile IPv4 and Mobile = IPv6/PMIPv6 extensions in a single spec >=20 > I think there is a precedent for this -- at least I know I've written = up such documents before. > But I'm open to suggestion about it. >=20 IMO, we should just keep this to MIPv6/PMIPv6. If its needed for MIPv4, = its worth publishing a new document >>=20 >> 5. Finally, it will be very useful, if we can have some thing in = Appendix, that shows how MAG and LMA can use different IP address end = points for control and data plane traffic. >=20 > Do you mean a flow diagram? Is it really unclear enough to need = ASCII art? > O.K., I'll do it if the working group adopts the document. >=20 Once this gap is fixed, per this spec, we can enable MAG and LMA both = negotiate a different end points. Earlier, with Alt-CoA we just allowed = the MAG to do that.=20 Sri > Regards, > Charlie P. >=20 >=20 From jouni.nospam@gmail.com Thu May 17 22:35:25 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A162021F86CA for ; Thu, 17 May 2012 22:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p12SGAa5xn+1 for ; Thu, 17 May 2012 22:35:25 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B1A5521F86C8 for ; Thu, 17 May 2012 22:35:24 -0700 (PDT) Received: by lagv3 with SMTP id v3so2066962lag.31 for ; Thu, 17 May 2012 22:35:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=7Fdbto4hK0pYOVKGLBqR1aFYDK6MUUGD7A0WuW8NPGU=; b=tr2N9XsHl3+iaZUN0RnqDTv5V1FdMjdCZAAIjGTBbn6UxL9sqfg60p6yFfJQqNlVk8 DfVsYOz2Q2nZ+AVVPdyWJcnVv0jHeCArkENPs2Y1MLxW5gwPv4NtDjjV8i9VV8LfWWLE 7y2jVw2S7K66N5zZWL9LmDfzEYTnBzWqfQo+79EmfO6SYOg1pxxUzmkCA9LBEhaWXAGG G9vCKLX8mitzZqSP7oOIiIyPQ3W8JuHaHVSP4P0qVEDyVdZbi5E2D6TBJWAx8QMX5akx 3iLtvFjImHnb1pNrWpmL5SvtPO7gQ12dU9IFJGbmEYMcKZpdYF1dKGmCRPF1P1/JlAW4 RroQ== Received: by 10.152.129.74 with SMTP id nu10mr9493695lab.50.1337319323016; Thu, 17 May 2012 22:35:23 -0700 (PDT) Received: from a88-114-71-183.elisa-laajakaista.fi (a88-114-71-183.elisa-laajakaista.fi. [88.114.71.183]) by mx.google.com with ESMTPS id mo3sm10882730lab.2.2012.05.17.22.35.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 May 2012 22:35:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4FAD873D.4040204@computer.org> Date: Fri, 18 May 2012 08:34:58 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FAD873D.4040204@computer.org> To: Charles E. Perkins X-Mailer: Apple Mail (2.1084) Cc: netext@ietf.org Subject: Re: [netext] Alternate Tunnel Source Address for LMA and Home Agent X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 05:35:25 -0000 Charlie, It was not entirely clear to me how this option would be different from RFC6463 and its Redirect Mobility Option, which also allows you to move bind LMA to a different address than the PBU was originally sent to? How would these two co-exists? - Jouni On May 12, 2012, at 12:40 AM, Charles E. Perkins wrote: >=20 > Hello folks, >=20 > I have submitted draft-perkins-netext-hatunaddr-00.txt. I hope that = there will be interest in the [netext] working group for this proposal. >=20 > --=20 > Regards, > Charlie P. >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From sarikaya2012@gmail.com Fri May 18 07:51:52 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07DBC21F8652 for ; Fri, 18 May 2012 07:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjpZn+fdV5IK for ; Fri, 18 May 2012 07:51:51 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7035021F864A for ; Fri, 18 May 2012 07:51:51 -0700 (PDT) Received: by yhq56 with SMTP id 56so3494569yhq.31 for ; Fri, 18 May 2012 07:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=mkZkQoBFDft/GFraSS7IAWzi+/rIIlXJD222IjYlsY4=; b=pcEXBqAOVuzBF4MA/DWsJsQggY2OK4+UDT7Le0xlEcZHcryTpZwy+9/sttnOJWqpOM qKFiGegnAGH2c2+MsK2XkwEUiyIegXnNYQlxFUrh8HsnW1egg0rW4MN+u6iKANYYsSwr +rmcbj4rDr/dJwk7m4FBvaMUhg8dwYc60P5TCHjaYSAjJINIh2pgqrJjfEs4Vjuu/BVb 3MkGvkvQNzwBfXDIWIAMooogrC2Uu9tkkE3S6OGQEtZUttJHl+PVV0K0Y7mWmcatXm0a j1mon545QaMWe4YCIY/odYi0WEfTLzmZF6Az+CMvRCgLOFrWselr9plkdOgVZyBvI4ls 53Eg== MIME-Version: 1.0 Received: by 10.50.179.38 with SMTP id dd6mr846695igc.9.1337352710623; Fri, 18 May 2012 07:51:50 -0700 (PDT) Received: by 10.231.78.10 with HTTP; Fri, 18 May 2012 07:51:50 -0700 (PDT) Date: Fri, 18 May 2012 09:51:50 -0500 Message-ID: From: Behcet Sarikaya To: Sri Gundavelli Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] draft-sarikaya-netext-pmipv6-shared-link X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 14:51:52 -0000 Hi Sri, My point is what if EAP is not used, e.g. at home? Even if EAP is used, how would AP which is L2 device know the contents of an application layer protocol? On Thu, May 17, 2012 at 6:49 PM, Sri Gundavelli wrote: > I thought the discussion was about the case when EAP is in use. Any case,= my > point is JUST about how L2 unicast semantics can be used by the MAG on th= e > WLAN access. How the MAG learns about that L2 identity is a different > consideration; if there is always EAP or some thing I commented on =85 > As you know this point has been missed in 6085. IIf you wish you can send me some elaborate text and I may be able to incorporate it in the draft. Behcet > > > Sri > > > > > > > On May 17, 2012, at 12:19 PM, Behcet Sarikaya wrote: > > On Fri, Apr 27, 2012 at 11:53 AM, Sri Gundavelli wro= te: > > Mac address is bound to the EAP identity. The Wireless LAN Controller/Acc= ess > > Point has the Mac to identity binding, which has association in the BUL > > entry. > > > > What if EAP is not used? > > Anyways, read the draft. > > Behcet > > > > > Sri > > > > On 4/27/12 9:51 AM, "Behcet Sarikaya" wrote: > > > On Fri, Apr 27, 2012 at 11:45 AM, Sri Gundavelli wro= te: > > I wonder how do you map to a single receiver if there are more than > > one receivers, i.e. the correct receiver? > > > L3-Multicast, L2 unicast to a given node. RFC 6085. This is standard stuf= f; > > There is no issue here. > > > > I read RFC 6085. > > > I had that question and I could not find an answer for that? How does > > the AP know "the given node"? > > > Anyways, I repeat my plea for documenting this issue in Netext and > > clearing the air once and for all. > > > Behcet > > > > Sri > > > > From sarikaya2012@gmail.com Fri May 18 07:55:28 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D08421F869E for ; Fri, 18 May 2012 07:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMLqI3eY4CBS for ; Fri, 18 May 2012 07:55:27 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8D68021F869D for ; Fri, 18 May 2012 07:55:27 -0700 (PDT) Received: by yenq13 with SMTP id q13so3393886yen.31 for ; Fri, 18 May 2012 07:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=w8Bqy0i1k3OYtYmZNOehxZNOcnUHf8foAlh64OWrkPo=; b=WnYchcsArBU94x61EvyvM7qHM22+TfyWQ4wNkTnOM8sLfesCmh48ZK0CmQAGLYeP6s JI4STJVFpUkZr6+k32gA8j8AtrNkVF9MbD31b9yeo1HGNHh/9uWtpxmxATmPWTqzBdoM bYJ7XPdY4TtL1SzId5SdEXNGzJRwirUM2oU6g7wNbBowdWmy2YLjE/j3NxvSPYf1563V R8Pj8d43JBHJDYv0115Q2pEOuOImFTCZxdGoLTe8w/qOf9DUbxLOyak+t4LKOxtnyX7+ fo3lQZq6e6e9qydTlji76JClJCtkj1JOOOY5gkrowVK/X+b8HYQiBilzadCqiBd/RFSg jD5w== MIME-Version: 1.0 Received: by 10.50.194.132 with SMTP id hw4mr741618igc.63.1337352926778; Fri, 18 May 2012 07:55:26 -0700 (PDT) Received: by 10.231.78.10 with HTTP; Fri, 18 May 2012 07:55:26 -0700 (PDT) In-Reply-To: References: <4FAD873D.4040204@computer.org> Date: Fri, 18 May 2012 09:55:26 -0500 Message-ID: From: Behcet Sarikaya To: jouni korhonen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Alternate Tunnel Source Address for LMA and Home Agent X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 14:55:28 -0000 On Fri, May 18, 2012 at 12:34 AM, jouni korhonen w= rote: > Charlie, > > It was not entirely clear to me how this option would be different > from RFC6463 and its Redirect Mobility Option, which also allows > you to move bind LMA to a different address than the PBU was originally > sent to? How would these two co-exists? Absolutely. This was what I intended to write in reply to Sri and noticed that Jouni already wrote it. This option may look OK syntactically in PMIP but we can not find any useful semantics other that redirect. Folks, please wake up and realize that PMIPv6 NOT =3D MIPv6. Having another entity called MN makes huge difference. Behcet > > - Jouni > > > On May 12, 2012, at 12:40 AM, Charles E. Perkins wrote: > >> >> Hello folks, >> >> I have submitted draft-perkins-netext-hatunaddr-00.txt. =A0I hope that t= here will be interest in the [netext] working group for this proposal. >> >> -- >> Regards, >> Charlie P. >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From sgundave@cisco.com Fri May 18 08:55:58 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA1921F8700 for ; Fri, 18 May 2012 08:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.595 X-Spam-Level: X-Spam-Status: No, score=-10.595 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZ7GeISgiKcj for ; Fri, 18 May 2012 08:55:57 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id BBE8421F869D for ; Fri, 18 May 2012 08:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=6599; q=dns/txt; s=iport; t=1337356557; x=1338566157; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=G3MT/ho3Fd+3lPhEMNdqYyqL5VBJH6fgHm4nL3p1Cno=; b=L6l8x11tZmvDXCNp2NlYppPPebBBQu/9azQ8GjblJ3sAiFYCsvHgNrut gzAxHwULzL1QG4YVXMypA003+tZoAmoFjC0O2LFQDxzCDiM22S75xyz23 L8zWjMThh1lASxcbJCRGAUvK5KMUZTNsIS4a8GWXHMdXcb4Cfcq/y7THE 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMdvtk+rRDoI/2dsb2JhbABFs22BB4IVAQEBAwEBAQEPARRHCwULCxguJzAGEyKHZwQMnE6gAwSKf4RkYgOIQIxgjhGBZIMJ X-IronPort-AV: E=Sophos;i="4.75,617,1330905600"; d="scan'208,217";a="45251379" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 18 May 2012 15:55:57 +0000 Received: from stealth-10-32-246-212.cisco.com (stealth-10-32-246-212.cisco.com [10.32.246.212]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q4IFtuEw026065; Fri, 18 May 2012 15:55:57 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_14927318-6168-4166-AB8E-1AE581364276" From: Sri Gundavelli In-Reply-To: Date: Fri, 18 May 2012 08:55:56 -0700 Message-Id: <83AF6F65-24A9-40A6-869C-5AB86E9250EB@cisco.com> References: <4FAD873D.4040204@computer.org> To: jouni korhonen X-Mailer: Apple Mail (2.1278) Cc: netext@ietf.org Subject: Re: [netext] Alternate Tunnel Source Address for LMA and Home Agent X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 15:55:58 -0000 --Apple-Mail=_14927318-6168-4166-AB8E-1AE581364276 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is a good comment and this discussion is needed. The difference I = see is the following: In RFC 6463, both in the collocated and non-collocated model, the LMA is = able to provide the Redirect Mobility option, with a different IP = address so the MAG can establish tunnel to that target IP address. Sure, = the tunnel end point is now moved, but so did the control end point. The = subsequent PBU is also required to be sent to the same target IP = address. So, in affect we have relocated the session (both control and = use plane) to that target IP address. We are never truly allowed the = scenario where the PBU/PBA can always be sent to a different IP than the = tunnel end point.=20 I'm sure, we could have fixed that option to be bit more generic and = addressed this issue. Either way, we need to make sure both the options = coexist properly. [MAG] [rfLMA] [r2LMA] | | | 1) |--PBU-->| | LMA assignment takes place in rfLMA. | | | 2) | | ~ ~ ~ >|\ | | | + BCE gets created in r2LMA. 3) | |<~ ~ ~ ~|/ | | | 4) |<--PBA--| | PBA contains r2LMA information. | | | |<=3D=3D=3D=3D=3Ddata=3D=3D=3D=3D=3D=3D>| | | | 5) |-------PBU------>| Lifetime extension, 6) |<------PBA-------| de-registration, etc. | | | Regards Sri On May 17, 2012, at 10:34 PM, jouni korhonen wrote: > Charlie, >=20 > It was not entirely clear to me how this option would be different > from RFC6463 and its Redirect Mobility Option, which also allows > you to move bind LMA to a different address than the PBU was = originally > sent to? How would these two co-exists? >=20 > - Jouni >=20 >=20 > On May 12, 2012, at 12:40 AM, Charles E. Perkins wrote: >=20 >>=20 >> Hello folks, >>=20 >> I have submitted draft-perkins-netext-hatunaddr-00.txt. I hope that = there will be interest in the [netext] working group for this proposal. >>=20 >> --=20 >> Regards, >> Charlie P. >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --Apple-Mail=_14927318-6168-4166-AB8E-1AE581364276 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 
    [MAG]   =
[rfLMA]  [r2LMA]
      |        |        |
   1) |--PBU-->|        | LMA assignment takes place in rfLMA.
      |        |        |
   2) |        | ~ ~ ~ >|\
      |        |        | + BCE gets created in r2LMA.
   3) |        |<~ ~ ~ ~|/
      |        |        |
   4) |<--PBA--|        | PBA contains r2LMA information.
      |        |        |
      |<=3D=3D=3D=3D=3Ddata=3D=3D=3D=3D=3D=3D>|
      |        |        |
   5) |-------PBU------>| Lifetime extension,
   6) |<------PBA-------| de-registration, etc.
      |        |        |
=


Regards
Sri



On May 17, 2012, = at 10:34 PM, jouni korhonen wrote:

Charlie,

It was not entirely clear to me how = this option would be different
from RFC6463 and its Redirect Mobility = Option, which also allows
you to move bind LMA to a different address = than the PBU was originally
sent to? How would these two = co-exists?

- Jouni


On May 12, 2012, at 12:40 AM, = Charles E. Perkins wrote:


Hello = folks,

I have = submitted draft-perkins-netext-hatunaddr-00.txt.  I hope that there = will be interest in the [netext] working group for this = proposal.

-- =
Regards,
Charlie = P.

_______________________________________________
netext mailing = list
netext@ietf.org
https://www.ietf.org= /mailman/listinfo/netext

_________________________= ______________________
netext mailing list
netext@ietf.org
https://www.ietf.or= g/mailman/listinfo/netext

= --Apple-Mail=_14927318-6168-4166-AB8E-1AE581364276-- From jouni.nospam@gmail.com Sat May 19 01:59:29 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3681521F8643 for ; Sat, 19 May 2012 01:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TH5K4j3ZS+JG for ; Sat, 19 May 2012 01:59:27 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id C764621F864A for ; Sat, 19 May 2012 01:59:26 -0700 (PDT) Received: by wibhj8 with SMTP id hj8so701614wib.13 for ; Sat, 19 May 2012 01:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=HB4CyPaXcShIYxCnz8KZajbntd3uqlKdmpPg+oBpSAM=; b=GChz8qWHinFzuKvtqyFuaxapeoc6Tp+Fj8FdBJkf9QHII3RhjncztOwmmL8e7DRah4 dUB/VNsIe0BEw7w1DqvrUWzykHiHT3oTeOzUr64lzyPiVKOhT6XAdNQb874tpOLlgB6c MoM0E4U07NM2A/DD1sNbn9//lcwmdkPLp71PqncyWcZCyYap3SK324XWHUQNK9V4+cYO RdQCOsXjPWJc5ykHTCqLJoXhn8PSfGUkCO519d57BiWFo5SPTLf3R8VYOeOwXOhYfTJk PZ/b3NWIhKvpo8ZhGnV79HkeT6rtM7E8SuV6sfdYPAWZ9vEBe1TESqn6t7/VRLNGlbW8 0EyQ== Received: by 10.180.107.101 with SMTP id hb5mr8910394wib.7.1337417965904; Sat, 19 May 2012 01:59:25 -0700 (PDT) Received: from [188.117.15.110] ([188.117.15.110]) by mx.google.com with ESMTPS id z3sm14225451wix.0.2012.05.19.01.59.24 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 19 May 2012 01:59:25 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Jouni In-Reply-To: <83AF6F65-24A9-40A6-869C-5AB86E9250EB@cisco.com> Date: Sat, 19 May 2012 11:59:22 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FAD873D.4040204@computer.org> <83AF6F65-24A9-40A6-869C-5AB86E9250EB@cisco.com> To: Sri Gundavelli , "Charles E. Perkins" X-Mailer: Apple Mail (2.1257) Cc: netext@ietf.org Subject: Re: [netext] Alternate Tunnel Source Address for LMA and Home Agent X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 08:59:29 -0000 Sri, On May 18, 2012, at 6:55 PM, Sri Gundavelli wrote: > This is a good comment and this discussion is needed. The difference I = see is the following: >=20 > In RFC 6463, both in the collocated and non-collocated model, the LMA = is able to provide the Redirect Mobility option, with a different IP = address so the MAG can establish tunnel to that target IP address. Sure, = the tunnel end point is now moved, but so did the control end point. The = subsequent PBU is also required to be sent to the same=20 Sure, because this is the model PMIP was designed for.. AltTSA is a bigger architectural change to whole PMIP IMHO, not just another mobility option. > target IP address. So, in affect we have relocated the session (both = control and use plane) to that target IP address. We are never truly = allowed the scenario where the PBU/PBA can always be sent to a different = IP than the tunnel end point.=20 Honestly, if we want GTP, lets go for GTP ;) Another big question I have is whether AltTSA allows for changing the tunnel endpoint for an already established mobility session? Keeping in mind that this particular feature was a big no-no when RFC6463 was done and therefore not particularly endorsed by RFC6463. I would love to errata/bis RFC6463 for midsession changes of LMA address..=20 > I'm sure, we could have fixed that option to be bit more generic and = addressed this issue. Either way, we need to Yes, that could have been "easy" to add to RFC6463 if we would have decided at that time having combined CP+AP is not the way forward. > make sure both the options coexist properly. Or alternatively bis RFC6463 to relax some language it has now..? - Jouni >=20 >=20 >=20 > [MAG] [rfLMA] [r2LMA] > | | | > 1) |--PBU-->| | LMA assignment takes place in rfLMA. > | | | > 2) | | ~ ~ ~ >|\ > | | | + BCE gets created in r2LMA. > 3) | |<~ ~ ~ ~|/ > | | | > 4) |<--PBA--| | PBA contains r2LMA information. > | | | > |<=3D=3D=3D=3D=3Ddata=3D=3D=3D=3D=3D=3D>| > | | | > 5) |-------PBU------>| Lifetime extension, > 6) |<------PBA-------| de-registration, etc. > | | | >=20 >=20 >=20 > Regards > Sri >=20 >=20 >=20 > On May 17, 2012, at 10:34 PM, jouni korhonen wrote: >=20 >> Charlie, >>=20 >> It was not entirely clear to me how this option would be different >> from RFC6463 and its Redirect Mobility Option, which also allows >> you to move bind LMA to a different address than the PBU was = originally >> sent to? How would these two co-exists? >>=20 >> - Jouni >>=20 >>=20 >> On May 12, 2012, at 12:40 AM, Charles E. Perkins wrote: >>=20 >>>=20 >>> Hello folks, >>>=20 >>> I have submitted draft-perkins-netext-hatunaddr-00.txt. I hope that = there will be interest in the [netext] working group for this proposal. >>>=20 >>> --=20 >>> Regards, >>> Charlie P. >>>=20 >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >=20 From sgundave@cisco.com Mon May 21 19:05:15 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D6321F84B2 for ; Mon, 21 May 2012 19:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQ0S-2mZt+IM for ; Mon, 21 May 2012 19:05:14 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF1F21F8498 for ; Mon, 21 May 2012 19:05:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=4921; q=dns/txt; s=iport; t=1337652314; x=1338861914; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Dup0bJxhVPgV40bhYq5JaNp6bHmfTrkO9URJ9UYqgGo=; b=OGkPk7hCZ8elf6ghjquag8MM8+HKQeS6/xQjefNECyXukwHbwdsxB92q rl/ULI7mz+MXAELNi1CpjctMToQqL0Ng86f/sXnASuVchknHG/dyAHeTV oFxojmEpQxWsxaZHgtMZik0hxQp1/T2tHlPQx8V+aVu8VVQp7v80sMuQR 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJDzuk+rRDoG/2dsb2JhbABEtBuBB4IVAQEBAwEBAQEPARQTNAsFCwsSBi4nIg4GEyKHZwQMnlagDgSLBYRaYgOIQoxZjgyBZIMJ X-IronPort-AV: E=Sophos;i="4.75,635,1330905600"; d="scan'208";a="43232268" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 22 May 2012 02:05:14 +0000 Received: from sjc-vpn7-811.cisco.com (sjc-vpn7-811.cisco.com [10.21.147.43]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q4M25D4T015901; Tue, 22 May 2012 02:05:13 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Sri Gundavelli In-Reply-To: Date: Mon, 21 May 2012 19:05:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6B218332-59A0-4A05-A85F-A1F0D4568EAE@cisco.com> References: <4FAD873D.4040204@computer.org> <83AF6F65-24A9-40A6-869C-5AB86E9250EB@cisco.com> To: Jouni X-Mailer: Apple Mail (2.1278) Cc: netext@ietf.org Subject: Re: [netext] Alternate Tunnel Source Address for LMA and Home Agent X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 02:05:15 -0000 Hi Jouni: The approach of registering different transport end points is a semantic = that is already present in the (Proxy) Mobile IPv6 architectures. You = allow the MAG to register those different transport end points, or you = allow the LMA to do the same is not radically different. If this = semantic is present in Protocol - X, or Protocol - Y is orthogonal to = the core point. To me 3GPP is one access technology, while it is a = dominant access architecture, but what we are enabling in this working = group or the work applicability statement does not mandate 3GPP as the = target access. I cannot take some Protocol-X and deploy it in an access = architecture that has nothing to do with 3GPP. To the technical comment on the co-existence of the option with 6463 = Redirect option, its just a relay mode, if the rfLMA receives from the = r2LMA is the AltTSA is what can be passed down to the MAG. But, from = this discussion, it is clear we need to think bit more about the option = coexistence.=20 > Or alternatively bis RFC6463 to relax some language it has now..? We can certainly leverage the Redirect option and extend this for this = use-case, but that is more about the semantics related to option = definition. We still need this text on the use-case. Regards Sri On May 19, 2012, at 1:59 AM, Jouni wrote: >=20 > Sri, >=20 > On May 18, 2012, at 6:55 PM, Sri Gundavelli wrote: >=20 >> This is a good comment and this discussion is needed. The difference = I see is the following: >>=20 >> In RFC 6463, both in the collocated and non-collocated model, the LMA = is able to provide the Redirect Mobility option, with a different IP = address so the MAG can establish tunnel to that target IP address. Sure, = the tunnel end point is now moved, but so did the control end point. The = subsequent PBU is also required to be sent to the same=20 >=20 > Sure, because this is the model PMIP was designed for.. AltTSA is a > bigger architectural change to whole PMIP IMHO, not just another > mobility option. >=20 >> target IP address. So, in affect we have relocated the session (both = control and use plane) to that target IP address. We are never truly = allowed the scenario where the PBU/PBA can always be sent to a different = IP than the tunnel end point.=20 >=20 > Honestly, if we want GTP, lets go for GTP ;) >=20 > Another big question I have is whether AltTSA allows for changing the > tunnel endpoint for an already established mobility session? Keeping > in mind that this particular feature was a big no-no when RFC6463 was > done and therefore not particularly endorsed by RFC6463. I would love > to errata/bis RFC6463 for midsession changes of LMA address..=20 >=20 >> I'm sure, we could have fixed that option to be bit more generic and = addressed this issue. Either way, we need to >=20 > Yes, that could have been "easy" to add to RFC6463 if we would have > decided at that time having combined CP+AP is not the way forward. >=20 >> make sure both the options coexist properly. >=20 > Or alternatively bis RFC6463 to relax some language it has now..? >=20 > - Jouni >=20 >=20 >=20 >>=20 >>=20 >>=20 >> [MAG] [rfLMA] [r2LMA] >> | | | >> 1) |--PBU-->| | LMA assignment takes place in rfLMA. >> | | | >> 2) | | ~ ~ ~ >|\ >> | | | + BCE gets created in r2LMA. >> 3) | |<~ ~ ~ ~|/ >> | | | >> 4) |<--PBA--| | PBA contains r2LMA information. >> | | | >> |<=3D=3D=3D=3D=3Ddata=3D=3D=3D=3D=3D=3D>| >> | | | >> 5) |-------PBU------>| Lifetime extension, >> 6) |<------PBA-------| de-registration, etc. >> | | | >>=20 >>=20 >>=20 >> Regards >> Sri >>=20 >>=20 >>=20 >> On May 17, 2012, at 10:34 PM, jouni korhonen wrote: >>=20 >>> Charlie, >>>=20 >>> It was not entirely clear to me how this option would be different >>> from RFC6463 and its Redirect Mobility Option, which also allows >>> you to move bind LMA to a different address than the PBU was = originally >>> sent to? How would these two co-exists? >>>=20 >>> - Jouni >>>=20 >>>=20 >>> On May 12, 2012, at 12:40 AM, Charles E. Perkins wrote: >>>=20 >>>>=20 >>>> Hello folks, >>>>=20 >>>> I have submitted draft-perkins-netext-hatunaddr-00.txt. I hope = that there will be interest in the [netext] working group for this = proposal. >>>>=20 >>>> --=20 >>>> Regards, >>>> Charlie P. >>>>=20 >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>=20 >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>=20 >=20 From sarikaya2012@gmail.com Tue May 22 08:27:08 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0705821F847E for ; Tue, 22 May 2012 08:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sg6DpVRMzZxg for ; Tue, 22 May 2012 08:27:07 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4587621F8459 for ; Tue, 22 May 2012 08:27:07 -0700 (PDT) Received: by yenq13 with SMTP id q13so6452140yen.31 for ; Tue, 22 May 2012 08:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=ZFcjmRy/Jha+D5kSn3UsbF6qUfng6UP4m5r/XcbOu1o=; b=rG3/reWoG/rECwr2L6nc7P4Kzu3tPYQyK18f7nUlEk3tby99T9umK3B8M+66641teO RyImMy4em2zhQCk6nbEQb0hAeJrEPlbXCEGwZ8dHNamLNlwq3N4KbbniwcXqqPkebAUV LLSIAwDNlgDtZ8IN2vhSCNhgyLK/25qJ23YKWmY3Hb58Egqu1rt2Vk2jIMXMiCD5391U PKm4trlFG0u5o2FIuBDJOtwi7bgLsiiGCLW6Ut/76xwDwUcXGON901YQkjF9jdGtFpmx XH+idn6vTs9TZh8FIubDQYErQVXwg8uZ7j1udUpckJXrS0UBW8dma1JUFxbfERExgpgW Tfrg== MIME-Version: 1.0 Received: by 10.50.6.229 with SMTP id e5mr8448468iga.9.1337700426509; Tue, 22 May 2012 08:27:06 -0700 (PDT) Received: by 10.231.78.10 with HTTP; Tue, 22 May 2012 08:27:06 -0700 (PDT) In-Reply-To: References: <4FAD873D.4040204@computer.org> <83AF6F65-24A9-40A6-869C-5AB86E9250EB@cisco.com> Date: Tue, 22 May 2012 10:27:06 -0500 Message-ID: From: Behcet Sarikaya To: Jouni Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Alternate Tunnel Source Address for LMA and Home Agent X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 15:27:08 -0000 On Sat, May 19, 2012 at 3:59 AM, Jouni wrote: > > Sri, > > On May 18, 2012, at 6:55 PM, Sri Gundavelli wrote: > >> This is a good comment and this discussion is needed. The difference I s= ee is the following: >> >> In RFC 6463, both in the collocated and non-collocated model, the LMA is= able to provide the Redirect Mobility option, with a different IP address = so the MAG can establish tunnel to that target IP address. Sure, the tunnel= end point is now moved, but so did the control end point. The subsequent P= BU is also required to be sent to the same > > Sure, because this is the model PMIP was designed for.. AltTSA is a > bigger architectural change to whole PMIP IMHO, not just another > mobility option. > >> target IP address. So, in affect we have relocated the session (both con= trol and use plane) to that target IP address. We are never truly allowed t= he scenario where the PBU/PBA can always be sent to a different IP than the= tunnel end point. > > Honestly, if we want GTP, lets go for GTP ;) I guess Sri is talking about MME+ SGW + PGW for PMIP. I agree with Jouni and say to Sri that you are dreaming :-). Behcet > > Another big question I have is whether AltTSA allows for changing the > tunnel =A0endpoint for an already established mobility session? Keeping > in mind that this particular feature was a big no-no when RFC6463 was > done and therefore not particularly endorsed by RFC6463. I would love > to errata/bis RFC6463 for midsession changes of LMA address.. > >> I'm sure, we could have fixed that option to be bit more generic and add= ressed this issue. Either way, we need to > > Yes, that could have been "easy" to add to RFC6463 if we would have > decided at that time having combined CP+AP is not the way forward. > >> =A0make sure both the options coexist properly. > > Or alternatively bis RFC6463 to relax some language it has now..? > > - Jouni > > > >> >> >> >> =A0 =A0 [MAG] =A0 [rfLMA] =A0[r2LMA] >> =A0 =A0 =A0 | =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0| >> =A0 =A01) |--PBU-->| =A0 =A0 =A0 =A0| LMA assignment takes place in rfLM= A. >> =A0 =A0 =A0 | =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0| >> =A0 =A02) | =A0 =A0 =A0 =A0| ~ ~ ~ >|\ >> =A0 =A0 =A0 | =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0| + BCE gets created in r2= LMA. >> =A0 =A03) | =A0 =A0 =A0 =A0|<~ ~ ~ ~|/ >> =A0 =A0 =A0 | =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0| >> =A0 =A04) |<--PBA--| =A0 =A0 =A0 =A0| PBA contains r2LMA information. >> =A0 =A0 =A0 | =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0| >> =A0 =A0 =A0 |<=3D=3D=3D=3D=3Ddata=3D=3D=3D=3D=3D=3D>| >> =A0 =A0 =A0 | =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0| >> =A0 =A05) |-------PBU------>| Lifetime extension, >> =A0 =A06) |<------PBA-------| de-registration, etc. >> =A0 =A0 =A0 | =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0| >> >> >> >> Regards >> Sri >> >> >> >> On May 17, 2012, at 10:34 PM, jouni korhonen wrote: >> >>> Charlie, >>> >>> It was not entirely clear to me how this option would be different >>> from RFC6463 and its Redirect Mobility Option, which also allows >>> you to move bind LMA to a different address than the PBU was originally >>> sent to? How would these two co-exists? >>> >>> - Jouni >>> >>> >>> On May 12, 2012, at 12:40 AM, Charles E. Perkins wrote: >>> >>>> >>>> Hello folks, >>>> >>>> I have submitted draft-perkins-netext-hatunaddr-00.txt. =A0I hope that= there will be interest in the [netext] working group for this proposal. >>>> >>>> -- >>>> Regards, >>>> Charlie P. >>>> >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >> > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From charliep@computer.org Tue May 22 15:52:29 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE8421F86CB for ; Tue, 22 May 2012 15:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awRGHiq7+dju for ; Tue, 22 May 2012 15:52:29 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1B48B21F86C9 for ; Tue, 22 May 2012 15:52:28 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.255.187]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1SWxwK-0007CE-16; Tue, 22 May 2012 18:52:28 -0400 Message-ID: <4FBC18A9.9070904@computer.org> Date: Tue, 22 May 2012 15:52:25 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jouni References: <4FAD873D.4040204@computer.org> <83AF6F65-24A9-40A6-869C-5AB86E9250EB@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad866085fdbb1a6f9b9c940266fc1c76d314350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Cc: netext@ietf.org Subject: Re: [netext] Alternate Tunnel Source Address for LMA and Home Agent X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 22:52:29 -0000 Hello Jouni et al., On 5/19/2012 1:59 AM, Jouni wrote: > ............... AltTSA is a > bigger architectural change to whole PMIP IMHO, not just another > mobility option. The point of AltTSA is to enable split control and data plane. Judging from modern mobility management infrastructures, that is a good thing. I'm hoping that the working group would be willing to agree -- or if not, perhaps explain why keeping the control plane and data plane together is still the right approach going forward. >> target IP address. So, in affect we have relocated the session (both control and use plane) to that target IP address. We are never truly allowed the scenario where the PBU/PBA can always be sent to a different IP than the tunnel end point. > Honestly, if we want GTP, lets go for GTP ;) I am happy to resubmit my draft to do that. I think it is a very good idea. > > Another big question I have is whether AltTSA allows for changing the > tunnel endpoint for an already established mobility session? Keeping > in mind that this particular feature was a big no-no when RFC6463 was > done and therefore not particularly endorsed by RFC6463. I would love > to errata/bis RFC6463 for midsession changes of LMA address.. This is easy to do, but from the perspective of separation of control and data plane looks more like a failover scheme rather than the basic requirement. Even so, I'd be happy to see it supported as part of AltTSA. -- Regards, Charlie P. From sgundave@cisco.com Tue May 22 16:36:29 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE62E21F8681 for ; Tue, 22 May 2012 16:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3kWE09vtqzh for ; Tue, 22 May 2012 16:36:29 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3641A21F85E4 for ; Tue, 22 May 2012 16:36:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=622; q=dns/txt; s=iport; t=1337729789; x=1338939389; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Nmj3RAFnY0sNH5pqPiVtd/z3ok4eOMiWTLR+1CJ3WiQ=; b=lNcI1L7w/n+wE/QJimAEJoZPWvfp1GHKPHLSAEiwss+iKpdflFGk6CkA D+tdeUETsLgyOBzF3fyXqZK2HOsgJ0DNKG4d0wNj3pcYcL//sEJHLgtBf Ev83elQ2WBwb6Ht4XbQtk6Y2k1PhkaNVfCIZI2xvI16t5aD0tO68Uqh2U 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIAivE+rRDoG/2dsb2JhbABEtByBB4IWAQEEEgFmEAtGVzuHa5sJn2yLCIIfgjxiA4hDjFmODIFkgwo X-IronPort-AV: E=Sophos;i="4.75,641,1330905600"; d="scan'208";a="45884216" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 22 May 2012 23:36:29 +0000 Received: from sjc-vpn6-984.cisco.com (sjc-vpn6-984.cisco.com [10.21.123.216]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q4MNaR7c021185; Tue, 22 May 2012 23:36:28 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Sri Gundavelli In-Reply-To: Date: Tue, 22 May 2012 16:36:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6B6BFDF6-99EE-4C27-AB59-6653235187F5@cisco.com> References: <4FAD873D.4040204@computer.org> <83AF6F65-24A9-40A6-869C-5AB86E9250EB@cisco.com> To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1278) Cc: netext@ietf.org Subject: Re: [netext] Alternate Tunnel Source Address for LMA and Home Agent X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 23:36:29 -0000 On May 22, 2012, at 8:27 AM, Behcet Sarikaya wrote: >>=20 >>=20 >>> target IP address. So, in affect we have relocated the session (both = control and use plane) to that target IP address. We are never truly = allowed the scenario where the PBU/PBA can always be sent to a different = IP than the tunnel end point. >>=20 >> Honestly, if we want GTP, lets go for GTP ;) >=20 >=20 > I guess Sri is talking about MME+ SGW + PGW for PMIP. > I agree with Jouni and say to Sri that you are dreaming :-). >=20 :) Right. One of us is smoking some bad stuff, and I just realized I = don't smoke :) Sri From charliep@computer.org Tue May 22 17:42:44 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B5C21F868A for ; Tue, 22 May 2012 17:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgKlMnPMVRm7 for ; Tue, 22 May 2012 17:42:44 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id EA62921F8647 for ; Tue, 22 May 2012 17:42:43 -0700 (PDT) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1SWzf1-0007CI-62; Tue, 22 May 2012 20:42:43 -0400 Message-ID: <4FBC3280.2010103@computer.org> Date: Tue, 22 May 2012 17:42:40 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: sarikaya@ieee.org, Behcet Sarikaya References: <4FAD873D.4040204@computer.org> <83AF6F65-24A9-40A6-869C-5AB86E9250EB@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86dd32ff5a99315abe8fcce125ca1cc0da350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Cc: netext@ietf.org Subject: Re: [netext] Alternate Tunnel Source Address for LMA and Home Agent X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 00:42:44 -0000 Hello Behcet, On 5/22/2012 8:27 AM, Behcet Sarikaya wrote: > On Sat, May 19, 2012 at 3:59 AM, Jouni wrote: >> >> Honestly, if we want GTP, lets go for GTP ;) > > I guess Sri is talking about MME+ SGW + PGW for PMIP. > I didn't arrive at that conclusion from Sri's email. And, as I've mentioned, anyway I think it would be wise to enable GTP as a choice for encapsulation between HA and CoA [e.g., LMA and MAG]. But MME and SGW and PGW are LTE functional entities; nevertheless PMIP is already specified for SGW and PGW. It turns out that one can nearly do MME for PMIP also if you are willing to split control and data plane. I have shown architectural diagrams that exhibit the "special case" that you identify under certain restrictive assumptions and additional (orthogonal) LTE-required reference points. I don't think it's irrational to try to identify the gaps between IETF-based mobility management and 3GPP-based mobility management. -- Regards, Charlie P. From Basavaraj.Patil@nokia.com Wed May 23 12:02:03 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAD521F8699 for ; Wed, 23 May 2012 12:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0dBjaRLz8ha for ; Wed, 23 May 2012 12:02:02 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 2314321F864C for ; Wed, 23 May 2012 12:02:01 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4NJ1a6u013175 for ; Wed, 23 May 2012 22:01:56 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 May 2012 22:01:54 +0300 Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.4]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.02.0283.004; Wed, 23 May 2012 21:01:53 +0200 From: To: Thread-Topic: Consensus call on adopting I-D draft-liebsch-netext-pmip6-qos as WG document Thread-Index: AQHNORaDzXXBLSQQaEiNUGHX4GFi7w== Date: Wed, 23 May 2012 19:01:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [172.19.40.102] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 May 2012 19:01:54.0000 (UTC) FILETIME=[84947D00:01CD3916] X-Nokia-AV: Clean Subject: [netext] Consensus call on adopting I-D draft-liebsch-netext-pmip6-qos as WG document X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 19:02:03 -0000 Hello, The authors of the I-D: Quality of Service Option for Proxy Mobile IPv6 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 Basavaraj.Patil@nokia.com Wed May 23 12:40:20 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61AA611E809A for ; Wed, 23 May 2012 12:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6iAR+MefXfp for ; Wed, 23 May 2012 12:40:19 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 78A0911E8099 for ; Wed, 23 May 2012 12:40:19 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4NJeDAG002756 for ; Wed, 23 May 2012 22:40:13 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 May 2012 22:40:12 +0300 Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.4]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.02.0283.004; Wed, 23 May 2012 21:40:12 +0200 From: To: Thread-Topic: WGLC for I-D: draft-ietf-netext-pmipv6-sipto-option Thread-Index: AQHNORveLK1oAljmSUmXVg5/MDRKDw== Date: Wed, 23 May 2012 19:40:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [172.19.40.102] Content-Type: text/plain; charset="us-ascii" Content-ID: <861DC14BD7D2A14397B152F25F363298@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 May 2012 19:40:12.0752 (UTC) FILETIME=[DEBE3500:01CD391B] X-Nokia-AV: Clean Subject: [netext] WGLC for I-D: draft-ietf-netext-pmipv6-sipto-option X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 19:40:20 -0000 Hello, This is the working group last call for the I-D: IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6 Abstract This specification defines a mechanism and a related mobility option for carrying IPv4 Offload traffic selectors between a mobile access gateway and a local mobility anchor in a Proxy Mobile IPv6 domain. Based on the received offload flow selectors from the local mobility anchor, a mobile access gateway can enable offload traffic rule on the selected IPv4 flows. The I-D is intended for publication as a proposed standard. The deadline for receiving reviews, comments, feedback is June 8th, 2012. Please send your review comments to the mailing list, chairs or, authors. -Chairs From amuhanna@awardsolutions.com Wed May 23 16:13:21 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67E921F8611 for ; Wed, 23 May 2012 16:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnpH1r9gjiJr for ; Wed, 23 May 2012 16:13:21 -0700 (PDT) Received: from exprod8og120.obsmtp.com (exprod8og120.obsmtp.com [64.18.3.40]) by ietfa.amsl.com (Postfix) with ESMTP id A857021F8610 for ; Wed, 23 May 2012 16:13:17 -0700 (PDT) Received: from mail.awardsolutions.com ([66.142.250.98]) (using TLSv1) by exprod8ob120.postini.com ([64.18.7.12]) with SMTP ID DSNKT71vDOS957ko9cnt9nlpQho1CmQmZqT1@postini.com; Wed, 23 May 2012 16:13:20 PDT Received: from REDWOOD.usa.awardsolutions.com ([fe80::49e1:b469:c7ad:bab1]) by Redwood.usa.awardsolutions.com ([fe80::49e1:b469:c7ad:bab1%11]) with mapi id 14.01.0355.002; Wed, 23 May 2012 18:13:16 -0500 From: Ahmad Muhanna To: "netext@ietf.org" Thread-Topic: [netext] Consensus call on adopting I-D draft-liebsch-netext-pmip6-qos as WG document Thread-Index: AQHNOTfAh3ZKhDnj+0SkGPwfbh6S85bX/4iA Date: Wed, 23 May 2012 23:13:15 +0000 Message-ID: <3359F724933DFD458579D24EAC7690987A4CDA@Redwood.usa.awardsolutions.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.25.208.82] Content-Type: multipart/alternative; boundary="_000_3359F724933DFD458579D24EAC7690987A4CDARedwoodusaawardso_" MIME-Version: 1.0 Subject: [netext] FW: Consensus call on adopting I-D draft-liebsch-netext-pmip6-qos as WG document X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 23:14:33 -0000 --_000_3359F724933DFD458579D24EAC7690987A4CDARedwoodusaawardso_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQ2hhaXJzLA0KDQpJIGJlbGlldmUgdGhpcyBkcmFmdCBpcyBxdWl0ZSBuZWVkZWQgdG8g ZmlsbCB0aGUgZ2FwIGluIHRoZSBzdWl0ZSBvZiBleHRlbnNpb25zIHRoYXQgYXJlIG5lZWRlZCBm b3IgYSBzdWNjZXNzZnVsIFBNSVB2NiBkZXBsb3ltZW50Lg0KDQpUaHVzOg0KSSBzdXBwb3J0IHRo ZSBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0IGFzIGEgd29ya2luZyBncm91cCBkb2N1bWVudC4NCg0K UmVnYXJkcywNCkFobWFkIE11aGFubmENCg0KDQpGcm9tOiA8QmFzYXZhcmFqLlBhdGlsQG5va2lh LmNvbTxtYWlsdG86QmFzYXZhcmFqLlBhdGlsQG5va2lhLmNvbT4+DQpEYXRlOiBNYXkgMjMsIDIw MTIgMjowMTo1MiBQTSBDRFQNClRvOiA8bmV0ZXh0QGlldGYub3JnPG1haWx0bzpuZXRleHRAaWV0 Zi5vcmc+Pg0KU3ViamVjdDogW25ldGV4dF0gQ29uc2Vuc3VzIGNhbGwgb24gYWRvcHRpbmcgSS1E IGRyYWZ0LWxpZWJzY2gtbmV0ZXh0LXBtaXA2LXFvcyBhcyBXRyBkb2N1bWVudA0KSGVsbG8sDQoN ClRoZSBhdXRob3JzIG9mIHRoZSBJLUQ6IFF1YWxpdHkgb2YgU2VydmljZSBPcHRpb24gZm9yIFBy b3h5IE1vYmlsZSBJUHY2DQo8ZHJhZnQtbGllYnNjaC1uZXRleHQtcG1pcDYtcW9zPg0KaHR0cDov L3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1saWVic2NoLW5ldGV4dC1wbWlwNi1xb3MtMDEudHh0DQoN CmhhdmUgcmVxdWVzdGVkIHRoZSBhZG9wdGlvbiBvZiB0aGlzIEktRCBhcyBhIFdHIGRvY3VtZW50 Lg0KVGhlIEktRCBpdHNlbGYgaGFzIGJlZW4gcHJlc2VudGVkIGF0IElFVEY4MyBhbmQgaGFzIGFs c28gYmVlbiByZXZpZXdlZCBieQ0KbXVsdGlwbGUgV0cgbWVtYmVycy4NCg0KVGhlIGNydXggb2Yg dGhlIHByb3Bvc2FsIGlzIHRvIGV4dGVuZCBQTUlQNiBzaWduYWxpbmcgdG8gZW5hYmxlIHN1cHBv cnQNCmZvciBRb1MuDQoNCkFic3RyYWN0DQoNCiAgVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMg YSBuZXcgbW9iaWxpdHkgb3B0aW9uIHRoYXQgY2FuIGJlIHVzZWQgYnkNCiAgdGhlIG1vYmlsaXR5 IGVudGl0aWVzIGluIHRoZSBQcm94eSBNb2JpbGUgSVB2NiBkb21haW4gdG8gZXhjaGFuZ2UNCiAg UXVhbGl0eSBvZiBTZXJ2aWNlIHBhcmFtZXRlcnMgYXNzb2NpYXRlZCB3aXRoIGEgc3Vic2NyaWJl cidzIElQDQogIGZsb3dzLiAgVXNpbmcgdGhlIFFvUyBvcHRpb24sIHRoZSBsb2NhbCBtb2JpbGl0 eSBhbmNob3IgYW5kIHRoZQ0KICBtb2JpbGUgYWNjZXNzIGdhdGV3YXkgY2FuIGV4Y2hhbmdlIGF2 YWlsYWJsZSBRb1MgYXR0cmlidXRlcyBhbmQNCiAgYXNzb2NpYXRlZCB2YWx1ZXMuICBUaGlzIGVu YWJsZXMgUW9TIHBvbGljaW5nIGFuZCBsYWJlbGluZyBvZiBwYWNrZXRzDQogIHRvIGVuZm9yY2Ug UW9TIGRpZmZlcmVudGlhdGlvbiBvbiB0aGUgcGF0aCBiZXR3ZWVuIHRoZSBsb2NhbCBtb2JpbGl0 eQ0KICBhbmNob3IgYW5kIHRoZSBtb2JpbGUgYWNjZXNzIGdhdGV3YXkuICBGdXJ0aGVybW9yZSwg bWFraW5nIFFvUw0KICBwYXJhbWV0ZXJzIGF2YWlsYWJsZSBvbiB0aGUgTUFHIGVuYWJsZXMgbWFw cGluZyB0aGVzZSBwYXJhbWV0ZXJzIHRvDQogIFFvUyBydWxlcyBiZWluZyBzcGVjaWZpYyB0byB0 aGUgYWNjZXNzIHRlY2hub2xvZ3kgd2hpY2ggb3BlcmF0ZXMNCiAgYmVsb3cgdGhlIG1vYmlsZSBh Y2Nlc3MgZ2F0ZXdheS4gIEFmdGVyIHN1Y2ggbWFwcGluZywgUW9TIHJ1bGVzIGNhbg0KICBiZSBl bmZvcmNlZCBvbiB0aGUgYWNjZXNzIHRlY2hub2xvZ3kgY29tcG9uZW50cywgc3VjaCBhcyBhbiBJ RUVFDQogIDgwMi4xMWUgV2lyZWxlc3MgTEFOIGNvbnRyb2xsZXIuDQoNCg0KUGxlYXNlIHJldmll dyB0aGUgSS1EIGFuZCByZXNwb25kIGJ5IEp1bmUgNnRoIHdpdGggeW91ciBvcGluaW9uLg0KUmVz cG9uZCB0byB0aGUgZm9sbG93aW5nIHF1ZXN0aW9uOg0KDQpTaG91bGQgdGhlIE5ldGV4dCBXRyBh ZG9wdCB0aGlzIEktRCBhcyBhIFdHIGRvY3VtZW50Pw0KDQpZZXMgICBbWF0NCk5vICAgIFsgIF0N Cg0KVGhhbmsgeW91Lg0KLUNoYWlycw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KbmV0ZXh0IG1haWxpbmcgbGlzdA0KbmV0ZXh0QGlldGYub3JnPG1h aWx0bzpuZXRleHRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldGV4dA0K --_000_3359F724933DFD458579D24EAC7690987A4CDARedwoodusaawardso_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv QWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRl IiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21w b3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGVsbG8gQ2hh aXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYmVsaWV2ZSB0aGlzIGRyYWZ0IGlzIHF1aXRlIG5lZWRlZCB0 byBmaWxsIHRoZSBnYXAgaW4gdGhlIHN1aXRlIG9mIGV4dGVuc2lvbnMgdGhhdCBhcmUgbmVlZGVk IGZvciBhIHN1Y2Nlc3NmdWwgUE1JUHY2IGRlcGxveW1lbnQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaHVzOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRoaXMg ZHJhZnQgYXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2Fy ZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFobWFkIE11aGFubmE8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGk+PG86cD4mbmJzcDs8L286cD48L2k+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPkZyb206PC9i PiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkJhc2F2YXJhai5QYXRpbEBub2tpYS5jb20iPkJhc2F2YXJh ai5QYXRpbEBub2tpYS5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6PC9iPiBNYXkgMjMsIDIwMTIg MjowMTo1MiBQTSBDRFQ8YnI+DQo8Yj5Ubzo8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86bmV0ZXh0 QGlldGYub3JnIj5uZXRleHRAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiA8 Yj5bbmV0ZXh0XSBDb25zZW5zdXMgY2FsbCBvbiBhZG9wdGluZyBJLUQgZHJhZnQtbGllYnNjaC1u ZXRleHQtcG1pcDYtcW9zIGFzIFdHIGRvY3VtZW50PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPkhlbGxvLDxicj4NCjxicj4NClRoZSBhdXRob3JzIG9mIHRo ZSBJLUQ6IFF1YWxpdHkgb2YgU2VydmljZSBPcHRpb24gZm9yIFByb3h5IE1vYmlsZSBJUHY2PGJy Pg0KJmx0O2RyYWZ0LWxpZWJzY2gtbmV0ZXh0LXBtaXA2LXFvcyZndDs8YnI+DQo8YSBocmVmPSJo dHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWxpZWJzY2gtbmV0ZXh0LXBtaXA2LXFvcy0wMS50 eHQiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtbGllYnNjaC1uZXRleHQtcG1pcDYtcW9z LTAxLnR4dDwvYT48YnI+DQo8YnI+DQpoYXZlIHJlcXVlc3RlZCB0aGUgYWRvcHRpb24gb2YgdGhp cyBJLUQgYXMgYSBXRyBkb2N1bWVudC48YnI+DQpUaGUgSS1EIGl0c2VsZiBoYXMgYmVlbiBwcmVz ZW50ZWQgYXQgSUVURjgzIGFuZCBoYXMgYWxzbyBiZWVuIHJldmlld2VkIGJ5PGJyPg0KbXVsdGlw bGUgV0cgbWVtYmVycy48YnI+DQo8YnI+DQpUaGUgY3J1eCBvZiB0aGUgcHJvcG9zYWwgaXMgdG8g ZXh0ZW5kIFBNSVA2IHNpZ25hbGluZyB0byBlbmFibGUgc3VwcG9ydDxicj4NCmZvciBRb1MuPGJy Pg0KPGJyPg0KQWJzdHJhY3Q8YnI+DQo8YnI+DQombmJzcDsmbmJzcDtUaGlzIHNwZWNpZmljYXRp b24gZGVmaW5lcyBhIG5ldyBtb2JpbGl0eSBvcHRpb24gdGhhdCBjYW4gYmUgdXNlZCBieTxicj4N CiZuYnNwOyZuYnNwO3RoZSBtb2JpbGl0eSBlbnRpdGllcyBpbiB0aGUgUHJveHkgTW9iaWxlIElQ djYgZG9tYWluIHRvIGV4Y2hhbmdlPGJyPg0KJm5ic3A7Jm5ic3A7UXVhbGl0eSBvZiBTZXJ2aWNl IHBhcmFtZXRlcnMgYXNzb2NpYXRlZCB3aXRoIGEgc3Vic2NyaWJlcidzIElQPGJyPg0KJm5ic3A7 Jm5ic3A7Zmxvd3MuICZuYnNwO1VzaW5nIHRoZSBRb1Mgb3B0aW9uLCB0aGUgbG9jYWwgbW9iaWxp dHkgYW5jaG9yIGFuZCB0aGU8YnI+DQombmJzcDsmbmJzcDttb2JpbGUgYWNjZXNzIGdhdGV3YXkg Y2FuIGV4Y2hhbmdlIGF2YWlsYWJsZSBRb1MgYXR0cmlidXRlcyBhbmQ8YnI+DQombmJzcDsmbmJz cDthc3NvY2lhdGVkIHZhbHVlcy4gJm5ic3A7VGhpcyBlbmFibGVzIFFvUyBwb2xpY2luZyBhbmQg bGFiZWxpbmcgb2YgcGFja2V0czxicj4NCiZuYnNwOyZuYnNwO3RvIGVuZm9yY2UgUW9TIGRpZmZl cmVudGlhdGlvbiBvbiB0aGUgcGF0aCBiZXR3ZWVuIHRoZSBsb2NhbCBtb2JpbGl0eTxicj4NCiZu YnNwOyZuYnNwO2FuY2hvciBhbmQgdGhlIG1vYmlsZSBhY2Nlc3MgZ2F0ZXdheS4gJm5ic3A7RnVy dGhlcm1vcmUsIG1ha2luZyBRb1M8YnI+DQombmJzcDsmbmJzcDtwYXJhbWV0ZXJzIGF2YWlsYWJs ZSBvbiB0aGUgTUFHIGVuYWJsZXMgbWFwcGluZyB0aGVzZSBwYXJhbWV0ZXJzIHRvPGJyPg0KJm5i c3A7Jm5ic3A7UW9TIHJ1bGVzIGJlaW5nIHNwZWNpZmljIHRvIHRoZSBhY2Nlc3MgdGVjaG5vbG9n eSB3aGljaCBvcGVyYXRlczxicj4NCiZuYnNwOyZuYnNwO2JlbG93IHRoZSBtb2JpbGUgYWNjZXNz IGdhdGV3YXkuICZuYnNwO0FmdGVyIHN1Y2ggbWFwcGluZywgUW9TIHJ1bGVzIGNhbjxicj4NCiZu YnNwOyZuYnNwO2JlIGVuZm9yY2VkIG9uIHRoZSBhY2Nlc3MgdGVjaG5vbG9neSBjb21wb25lbnRz LCBzdWNoIGFzIGFuIElFRUU8YnI+DQombmJzcDsmbmJzcDs4MDIuMTFlIFdpcmVsZXNzIExBTiBj b250cm9sbGVyLjxicj4NCjxicj4NCjxicj4NClBsZWFzZSByZXZpZXcgdGhlIEktRCBhbmQgcmVz cG9uZCBieSBKdW5lIDZ0aCB3aXRoIHlvdXIgb3Bpbmlvbi48YnI+DQpSZXNwb25kIHRvIHRoZSBm b2xsb3dpbmcgcXVlc3Rpb246PGJyPg0KPGJyPg0KU2hvdWxkIHRoZSBOZXRleHQgV0cgYWRvcHQg dGhpcyBJLUQgYXMgYSBXRyBkb2N1bWVudD88YnI+DQo8YnI+DQpZZXMgJm5ic3A7Jm5ic3A7Wzxi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5YPC9zcGFuPjwvYj5dPGJyPg0KTm8gJm5ic3A7 Jm5ic3A7Jm5ic3A7WyAmbmJzcDtdPGJyPg0KPGJyPg0KVGhhbmsgeW91Ljxicj4NCi1DaGFpcnM8 YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCm5ldGV4dCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bmV0ZXh0QGll dGYub3JnIj5uZXRleHRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRleHQiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0ZXh0PC9hPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_3359F724933DFD458579D24EAC7690987A4CDARedwoodusaawardso_-- From John.Kaippallimalil@huawei.com Wed May 23 19:03:14 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9440111E8072 for ; Wed, 23 May 2012 19:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41LE2cAwUOCB for ; Wed, 23 May 2012 19:03:14 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 02BFC11E80AF for ; Wed, 23 May 2012 19:03:13 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGM06166; Wed, 23 May 2012 22:03:13 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 May 2012 19:01:40 -0700 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.75]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Wed, 23 May 2012 19:01:44 -0700 From: John Kaippallimalil To: "Basavaraj.Patil@nokia.com" , "netext@ietf.org" Thread-Topic: [netext] Consensus call on adopting I-D draft-liebsch-netext-pmip6-qos as WG document Thread-Index: AQHNORaDzXXBLSQQaEiNUGHX4GFi75bYLJug Date: Thu, 24 May 2012 02:01:43 +0000 Message-ID: <6561EABF52675C45BCDACA1B4D7AA11705A8D0@dfweml511-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.138.141] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [netext] Consensus call on adopting I-D draft-liebsch-netext-pmip6-qos as WG document X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 02:03:14 -0000 Hello, This I-D addresses a gap in PMIP6 capabilities to signal QoS. Thus, it prov= ides a valuable solution in networks that need to provision QoS for such co= nnections. I support the adoption of this I-D as a WG document.=20 Regards, John=20 -----Original Message----- From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of= Basavaraj.Patil@nokia.com Sent: Wednesday, May 23, 2012 2:02 PM To: netext@ietf.org Subject: [netext] Consensus call on adopting I-D draft-liebsch-netext-pmip6= -qos as WG document Hello, The authors of the I-D: Quality of Service Option for Proxy Mobile IPv6 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 _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From Basavaraj.Patil@nokia.com Thu May 24 15:19:16 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C04C11E80E4 for ; Thu, 24 May 2012 15:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id An5D5OYqyD+V for ; Thu, 24 May 2012 15:19:15 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id B096111E80A3 for ; Thu, 24 May 2012 15:19:12 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4OMJ878011890; Fri, 25 May 2012 01:19:08 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 May 2012 01:19:07 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.16]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.02.0283.004; Fri, 25 May 2012 00:19:06 +0200 From: To: Thread-Topic: Review of I-D draft-ietf-netext-pmipv6-sipto-option Thread-Index: AQHNOfs7Ha1qLUaGQEmEfH3LUy9D2A== Date: Thu, 24 May 2012 22:19:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [172.19.40.62] Content-Type: text/plain; charset="us-ascii" Content-ID: <42A945FC5BB298479704C7E557FB8C33@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 24 May 2012 22:19:07.0566 (UTC) FILETIME=[3C591CE0:01CD39FB] X-Nokia-AV: Clean Cc: draft-ietf-netext-pmipv6-sipto-option@tools.ietf.org Subject: [netext] Review of I-D draft-ietf-netext-pmipv6-sipto-option X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 22:19:16 -0000 My review comments for this I-D below: General comment: The document quality needs improvement before it would be considered ready for being forwarded to the IESG. There is a lack of readability in this I-D. Authors assume that readers are familiar with 3GPP architectures or offloading features. Recommend explaining the problem and proposed solution much more clearly. 1. The abstract is intended to at least give a high level perspective on what the I-D is about. Current abstract does not do that. Other than the authors or someone following this work very closely, I doubt if anyone can understand what this document is specifying. 2. What are "access technology domains"? 3. "For providing IP mobility support to a mobile node irrespective of the access network to which it is attached." ???? Rephrase. 4. "the 3GPP S2a Proxy Mobile IPv6 [TS23402] interface," Is this an interface or a reference point? 5. "...is providing the needed protocol glue." Protocol glue for what? 6. " The mobile node's IP traffic is always tunneled back from the mobile access gateway [RFC5213] in the access network to the local mobility anchor in the home network." The MN could use the local address provided by the access-network for some applications, right? Just having the S2a interface does not imply that all traffic is routed back to the LMA, right? 7. "Not all IP traffic need to be routed back to the home network, some of the non-essential traffic which does not require IP mobility support can be offloaded at the mobile access gateway in the access network." What is non-essential traffic? Can you give some examples. And what happens if such traffic does not have IP mobility support? 8. "This approach provides greater leverage and efficient usage of the mobile packet core which help lowering transport cost." Greater leverage of what? Sounds like too much of marketing buzz in what is intended to be a technical spec. 9. Definition of IP Traffic Offload in Sec 2.2 is lacking clarity in the context of this I-D. It would be good to define what is meant by IP Traffic offload in the 3GPP operator scenario. 10. Is this specification applicable to 3GPP network deployments only? 11. "The selectors that are delivered to the mobile access gateway can be used to classify the traffic, so it can be offloaded to the local access network. " What is the local access network? 12. "The details related to DHCP transactions, or Router Advertisements on the access link are not shown here." Are these part of the MN attachment to the MAG process? 13. Figure 2 can be improved 14. "This would not have no effect ..." 15. What happens to IPsec tunnel-mode encrypted traffic? The I-D does not say anything about such traffic whether it can be offloaded. 16. There is not enough information about how the MAG or the LMA decide which traffic to offload. There is some handwaving about interacting with a policy server and the I-D says it is out of scope. But it would be useful to understand more about how this is expected to work. For example, how does the MAG choose the traffic selectors? 17. Is the NAT co-located with the MAG? 18. What happens if the MAG and LMA are in different domains (visited and home networks)? Is there an issue in such a scenario? 19. The bandwidth and characteristics of the connectivity at the access network may be different from what is at the home network (LMA). The performance and user experience may be degarded when the traffic is offloaded via the access network. The end-user has no awareness of the traffic being offloaded. How do you handle this situation?=20 -Raj From sgundave@cisco.com Thu May 24 17:11:56 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4956F11E8097 for ; Thu, 24 May 2012 17:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.498 X-Spam-Level: X-Spam-Status: No, score=-10.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0ZMIUmUtEoP for ; Thu, 24 May 2012 17:11:55 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6A311E8081 for ; Thu, 24 May 2012 17:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=18438; q=dns/txt; s=iport; t=1337904715; x=1339114315; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=MaAXa1u4pgCFdJOmoFEyV1YMByT+H/y9Uk0e99vBd7s=; b=OUkL0ZOHKdRtsgWYL2MixsS7+WfGIGHUHuyU2VCk0mleB4yTRn2bulji 7iwmmZlNhXAO13M2GGqDRepKUxJj8iXhyAJcap4uwPNMe1v2ROwvzlXaa 2skiCNQ+cEQJV4Oa8Z0yCuZADPbFXvYP1Yv9q5VW+dECxVlPIUGNXaO1M A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAD7Nvk+rRDoJ/2dsb2JhbAA6CoJFsiiBB4IVAQEBAwEBAQEPAVsBCgULCxI0JyIOBhMbB4dmBAybXJ9iBIp/EIRWYAOIP4xZjgyBZIMA X-IronPort-AV: E=Sophos;i="4.75,653,1330905600"; d="scan'208,217";a="43739416" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 25 May 2012 00:11:54 +0000 Received: from sjc-vpn5-1218.cisco.com (sjc-vpn5-1218.cisco.com [10.21.92.194]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q4P0Brbg031743; Fri, 25 May 2012 00:11:53 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_92931B56-4EF2-4363-90D5-267C42A65659" From: Sri Gundavelli In-Reply-To: Date: Thu, 24 May 2012 17:11:52 -0700 Message-Id: <19D8F307-BF0A-40A9-AF8F-BF572C349D43@cisco.com> References: To: "" X-Mailer: Apple Mail (2.1278) Cc: netext@ietf.org, draft-ietf-netext-pmipv6-sipto-option@tools.ietf.org Subject: Re: [netext] Review of I-D draft-ietf-netext-pmipv6-sipto-option X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 00:11:56 -0000 --Apple-Mail=_92931B56-4EF2-4363-90D5-267C42A65659 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks for the review. Comments inline .. On May 24, 2012, at 3:19 PM, = wrote: >=20 > My review comments for this I-D below: >=20 > General comment: The document quality needs improvement before it > would be considered ready for being forwarded to the IESG. There is a > lack of readability in this I-D. Authors assume that readers are > familiar with 3GPP architectures or offloading features. Recommend > explaining the problem and proposed solution much more clearly. >=20 > 1. The abstract is intended to at least give a high level perspective > on what the I-D is about. Current abstract does not do that. Other > than the authors or someone following this work very closely, I doubt > if anyone can understand what this document is specifying. >=20 This specification defines a mechanism and a related mobility option for carrying IPv4 Offload traffic selectors between a mobile access gateway and a local mobility anchor in a Proxy Mobile IPv6 domain. Based on the received offload flow selectors from the local mobility anchor, a mobile access gateway can enable offload traffic rule on the selected IPv4 flows. This is a feature extension to an existing protocol. Its hard to provide = the complete context in the Abstract. Its just stating the two peers LMA = and MAG can negotiate an offload policy, so those offload support can be = enabled. > 2. What are "access technology domains"? >=20 Ex: WLAN Will clarify with examples > 3. "For providing IP mobility support to a mobile node irrespective of = the > access network to which it is attached." ???? Rephrase. >=20 Ok > 4. "the 3GPP S2a Proxy Mobile IPv6 [TS23402] interface," Is this an > interface or a reference point? >=20 reference pt. will reword it > 5. "...is providing the needed protocol glue." Protocol glue for what? >=20 will reword it > 6. " The mobile node's IP traffic is > always tunneled back from the mobile access gateway [RFC5213] in the > access network to the local mobility anchor in the home network." >=20 > The MN could use the local address provided by the access-network > for some applications, right? Just having the S2a interface does > not imply that all traffic is routed back to the LMA, right? >=20 Yes, the access network can assign an IP address. That is for IPv6 and = assuming there is prefix coloring, or other mechanisms for the mobile to = identify that local address. But, we already stated this document is for = IPv4-only traffic offload support. There we don't have mechanisms to = assign multiple IPv4 addresses over DHCPv4; we can only assign a single = IPv4 address. So, that IPv4 address is either a local address, or the = home address. > 7. "Not all IP traffic need to be > routed back to the home network, some of the non-essential traffic > which does not require IP mobility support can be offloaded at the > mobile access gateway in the access network." >=20 > What is non-essential traffic? Can you give some examples. And what > happens if such traffic does not have IP mobility support? >=20 Traffic which does not require any services such as mobility, QoS or = inline services =85 will add clarifying text > 8. "This approach provides > greater leverage and efficient usage of the mobile packet core which > help lowering transport cost." >=20 > Greater leverage of what? Sounds like too much of marketing buzz in > what is intended to be a technical spec. >=20 Will reword it > 9. Definition of IP Traffic Offload in Sec 2.2 is lacking clarity in > the context of this I-D. It would be good to define what is meant by > IP Traffic offload in the 3GPP operator scenario. >=20 Per your other comment, will have minimal text on 3GPP terminology or = usage. > 10. Is this specification applicable to 3GPP network deployments only? >=20 This is a feature in standard PMIPv6 architecture; we can leave it there > 11. "The selectors that are delivered to the mobile access gateway can = be > used to classify the traffic, so it can be offloaded to the local > access network. " >=20 > What is the local access network? >=20 reworded to "access network" > 12. "The details related to DHCP transactions, or Router > Advertisements on the access link are not shown here." >=20 > Are these part of the MN attachment to the MAG process? >=20 They are missing as they are not relevant to core part of the = discussion. There is change on the MN-MAG interface, or to the address = assignment procedures. Will add a statement covering that. > 13. Figure 2 can be improved >=20 Ok. Will try > 14. "This would not have no effect =85" fixed, thanks > 15. What happens to IPsec tunnel-mode encrypted traffic? The I-D does > not say anything about such traffic whether it can be offloaded. >=20 IPsec Tunnel mode ESP is applied on the flows that are routed through = the tunnel and is not applied on offloaded traffic.=20 > 16. There is not enough information about how the MAG or the LMA > decide which traffic to offload. There is some handwaving about > interacting with a policy server and the I-D says it is out of > scope. But it would be useful to understand more about how this is > expected to work. For example, how does the MAG choose the traffic > selectors? >=20 That is a operator policy decision. There is no hand waiving there, its = a configuration option. Should the spec recommend a specific flow that = needs to be offloaded ? Does DSMIP spec specific what flow needs to be = assigned to what access ? The mechanism is only allowing a mechanism and = the peers to negotiate offload policy. > 17. Is the NAT co-located with the MAG? >=20 The offloaded traffic flows have to NAT translated. If that NAT function = is collocated on the MAG, or outside is a deployment option =20 > 18. What happens if the MAG and LMA are in different domains (visited > and home networks)? Is there an issue in such a scenario? >=20 Per RFC 5213 definition, PMIPv6 is for local mobility, with the protocol = signaling between two peers in the same domain. > 19. The bandwidth and characteristics of the connectivity at the > access network may be different from what is at the home network > (LMA). The performance and user experience may be degarded when the > traffic is offloaded via the access network. The end-user has no > awareness of the traffic being offloaded. How do you handle this > situation?=20 >=20 That is the nature of offload. Traffic which does not require any = services such as mobility are chosen for offload. Those offloaded flows = are not assured for any SLA's from the home operator. The traffic = treatment is based on the resources in the access network and that is = the case for home routed traffic as well (on the MN to MAG path). With = respect to end-user awareness, there is no awareness same as with any = NAT deployment, NAT64, DSLite or any other approach, the end-user is not = aware of such translation. Thanks for the review comments. Sri > -Raj >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --Apple-Mail=_92931B56-4EF2-4363-90D5-267C42A65659 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Basavaraj.Patil@nokia.com>= ; <Basavaraj.Patil@nokia.com>= ; wrote:


My = review comments for this I-D below:

General comment: The document = quality needs improvement before it
would be considered ready for = being forwarded to the IESG. There is a
lack of readability in this = I-D. Authors assume that readers are
familiar with 3GPP architectures = or offloading features. Recommend
explaining the problem and proposed = solution much more clearly.

1. The abstract is intended to at = least give a high level perspective
on what the I-D is about. Current = abstract does not do that. Other
than the authors or someone = following this work very closely, I doubt
if anyone can understand = what this document is = specifying.



<= span class=3D"Apple-style-span" style=3D"font-family: Times; ">
   This specification defines a =
mechanism and a related mobility option
   for carrying IPv4 Offload traffic selectors between a mobile access
   gateway and a local mobility anchor in a Proxy Mobile IPv6 domain.
   Based on the received offload flow selectors from the local mobility
   anchor, a mobile access gateway can enable offload traffic rule on
   the selected IPv4 =
flows.


Th= is is a feature extension to an existing protocol. Its hard to provide = the complete context in the Abstract. Its just stating the two peers LMA = and MAG can negotiate an offload policy, so those offload support can be = enabled.



2. What are "access technology = domains"?


Ex: = WLAN
Will clarify with = examples


3. "For = providing IP mobility support to a mobile node irrespective of = the
  access network to which it is attached." ???? = Rephrase.


Ok

4. "the 3GPP S2a Proxy Mobile IPv6 [TS23402] = interface," Is this an
interface or a reference = point?


reference pt. = will reword it


5. "...is providing the needed protocol glue." = Protocol glue for = what?


will reword = it


6. " The = mobile node's IP traffic is
  always tunneled back from the = mobile access gateway [RFC5213] in the
  access network to = the local mobility anchor in the home network."

  The = MN could use the local address provided by the = access-network
  for some applications, right? Just having = the S2a interface does
  not imply that all traffic is = routed back to the LMA, = right?


Yes, the access = network can assign an IP address. That is for IPv6 and assuming there is = prefix coloring, or other mechanisms for the mobile to identify that = local address. But, we already stated this document is for IPv4-only = traffic offload support. There we don't have mechanisms to assign = multiple IPv4 addresses over DHCPv4; we can only assign a single IPv4 = address. So, that IPv4 address is either a local address, or the home = address.


7. "Not = all IP traffic need to be
  routed back to the home = network, some of the non-essential traffic
  which does not = require IP mobility support can be offloaded at = the
  mobile access gateway in the access = network."

  What is non-essential traffic? Can you give = some examples. And what
  happens if such traffic does not = have IP mobility = support?


Traffic which = does not require any services such as mobility, QoS or inline services =85= will add clarifying text


8. "This approach provides
  greater = leverage and efficient usage of the mobile packet core = which
  help lowering transport = cost."

  Greater leverage of what? Sounds like too much = of marketing buzz in
  what is intended to be a technical = spec.


Will reword = it


9. Definition = of IP Traffic Offload in Sec 2.2 is lacking clarity in
the context of = this I-D. It would be good to define what is meant by
IP Traffic = offload in the 3GPP operator = scenario.


Per your other = comment, will have minimal text on 3GPP terminology or = usage.


10. Is = this specification applicable to 3GPP network deployments = only?


This is a feature in = standard PMIPv6 architecture; we can leave it = there


11. "The = selectors that are delivered to the mobile access gateway can = be
  used to classify the traffic, so it can be offloaded = to the local
  access network. "

  What is = the local access = network?


reworded to = "access network"



12. "The details related to DHCP transactions, or = Router
  Advertisements on the access link are not shown = here."

  Are these part of the MN attachment to the MAG = process?


They are missing = as they are not relevant to core part of the discussion. There is change = on the MN-MAG interface, or to the address assignment = procedures.
 Will add a statement covering = that.




13. Figure 2 can be = improved


Ok. Will = try



14. "This would not have no effect = =85"

fixed, = thanks



15. What happens to IPsec tunnel-mode encrypted = traffic? The I-D does
not say anything about such traffic whether it = can be offloaded.


IPsec = Tunnel mode ESP is applied on the flows that are routed through the = tunnel and is not applied on offloaded = traffic. 



16. There is not enough information about how the MAG = or the LMA
decide which traffic to offload. There is some handwaving = about
interacting with a policy server and the I-D says it is out = of
scope. But it would be useful to understand more about how this = is
expected to work. For example, how does the MAG choose the = traffic
selectors?


That = is a operator policy decision. There is no hand waiving there, its a = configuration option. Should the spec recommend a specific flow that = needs to be offloaded ? Does DSMIP spec specific what flow needs to be = assigned to what access ? The mechanism is only allowing a = mechanism and the peers to negotiate offload = policy.



17. Is the NAT co-located with the = MAG?


The offloaded traffic = flows have to NAT translated. If that NAT function is collocated on the = MAG, or outside is a deployment = option


  =   

18. What happens if = the MAG and LMA are in different domains (visited
and home networks)? = Is there an issue in such a = scenario?


Per RFC 5213 = definition, PMIPv6 is for local mobility, with the protocol signaling = between two peers in the same = domain.



19. The bandwidth and characteristics of the = connectivity at the
access network may be different from what is at = the home network
(LMA). The performance and user experience may be = degarded when the
traffic is offloaded via the access network. The = end-user has no
awareness of the traffic being offloaded. How do you = handle = this
situation? 


That is the nature of offload. Traffic which does not = require any services such as mobility are chosen for offload. Those = offloaded flows are not assured for any SLA's from the home operator. = The traffic treatment is based on the resources in the access network = and that is the case for home routed traffic as well (on the MN to MAG = path). With respect to end-user awareness, there is no awareness = same as with any NAT deployment, NAT64, DSLite or any other approach, = the end-user is not aware of such = translation.

Thanks for the review = comments.


Sri

=


-Raj

___________________________________________= ____
netext mailing list
netext@ietf.org
https://www.ietf.or= g/mailman/listinfo/netext

=
= --Apple-Mail=_92931B56-4EF2-4363-90D5-267C42A65659-- From florin.baboescu.ietf@gmail.com Thu May 24 19:51:38 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA16411E80B0 for ; Thu, 24 May 2012 19:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBSvM0x0nCf2 for ; Thu, 24 May 2012 19:51:37 -0700 (PDT) Received: from mail-wi0-f194.google.com (mail-wi0-f194.google.com [209.85.212.194]) by ietfa.amsl.com (Postfix) with ESMTP id CB5AD21F8433 for ; Thu, 24 May 2012 19:51:35 -0700 (PDT) Received: by wibhn6 with SMTP id hn6so103771wib.1 for ; Thu, 24 May 2012 19:51:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=evCJctEZbY0r/Vc6DazO3Er/vkUfH6+QLWEnnedewCQ=; b=m3NyEmO6wt/CwvUyCeLNOYIjmogJB9FuCmmIzotCQFFyBkvS/TJL0vip77vAro5yRf oHtmYpGvDr7rF5YRXcioQ8Gar8PgjwajZXozJNYt5X6Nk/0AVt/dH3rJ8UuIbcdvwE6e dGBzFwywxNX+Mj9R2mFyfb+fn52juGz7/20t1ZH5ymxXrBOHk8yL1agIym/Mo2ShuZ6s d9N9oHxqyXGvXHJHp2By3g1xyAZYpxfTjhg71pzGo6J/YHBEBg1WuNFO1N5O6JwiqRkv k3qNH6xm5HRr/ckbzKaoB/wmW/k10Bpgn7BI/l1aUU00kRoZLG/EKPW9NgdQD7u9PtK6 zdSQ== MIME-Version: 1.0 Received: by 10.180.85.129 with SMTP id h1mr3486729wiz.2.1337914294740; Thu, 24 May 2012 19:51:34 -0700 (PDT) Received: by 10.194.41.230 with HTTP; Thu, 24 May 2012 19:51:34 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 May 2012 19:51:34 -0700 Message-ID: From: Florin Baboescu To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org Subject: Re: [netext] Consensus call on adopting I-D draft-liebsch-netext-pmip6-qos as WG document X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 02:51:38 -0000 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 On 5/23/12, Basavaraj.Patil@nokia.com wrote: > > Hello, > > The authors of the I-D: Quality of Service Option for Proxy Mobile IPv6 > > 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 > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From Basavaraj.Patil@nokia.com Fri May 25 13:05:32 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC0021F8603 for ; Fri, 25 May 2012 13:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4JXLpAlKi6j for ; Fri, 25 May 2012 13:05:30 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id E76A521F853C for ; Fri, 25 May 2012 13:05:29 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4PK5IOR027264; Fri, 25 May 2012 23:05:19 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 May 2012 23:05:18 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.16]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.02.0283.004; Fri, 25 May 2012 22:05:17 +0200 From: To: Thread-Topic: [netext] Review of I-D draft-ietf-netext-pmipv6-sipto-option Thread-Index: AQHNOfs7Ha1qLUaGQEmEfH3LUy9D2JbZgHsAgAD5mgA= Date: Fri, 25 May 2012 20:05:17 +0000 Message-ID: In-Reply-To: <19D8F307-BF0A-40A9-AF8F-BF572C349D43@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [172.19.40.58] Content-Type: multipart/alternative; boundary="_000_CBE54C271F4A7basavarajpatilnokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 25 May 2012 20:05:18.0528 (UTC) FILETIME=[B514E400:01CD3AB1] X-Nokia-AV: Clean Cc: netext@ietf.org, draft-ietf-netext-pmipv6-sipto-option@tools.ietf.org Subject: Re: [netext] Review of I-D draft-ietf-netext-pmipv6-sipto-option X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 20:05:32 -0000 --_000_CBE54C271F4A7basavarajpatilnokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Inline: From: Sri Gundavelli > Date: Thursday, May 24, 2012 7:11 PM To: Basavaraj Patil > Cc: Netext >, "draft-ietf-netext-pm= ipv6-sipto-option@tools.ietf.org" > Subject: Re: [netext] Review of I-D draft-ietf-netext-pmipv6-sipto-option Thanks for the review. Comments inline .. On May 24, 2012, at 3:19 PM, > > wrote: My review comments for this I-D below: General comment: The document quality needs improvement before it would be considered ready for being forwarded to the IESG. There is a lack of readability in this I-D. Authors assume that readers are familiar with 3GPP architectures or offloading features. Recommend explaining the problem and proposed solution much more clearly. 1. The abstract is intended to at least give a high level perspective on what the I-D is about. Current abstract does not do that. Other than the authors or someone following this work very closely, I doubt if anyone can understand what this document is specifying. This specification defines a mechanism and a related mobility option for carrying IPv4 Offload traffic selectors between a mobile access gateway and a local mobility anchor in a Proxy Mobile IPv6 domain. Based on the received offload flow selectors from the local mobility anchor, a mobile access gateway can enable offload traffic rule on the selected IPv4 flows. This is a feature extension to an existing protocol. Its hard to provide th= e complete context in the Abstract. Its just stating the two peers LMA and = MAG can negotiate an offload policy, so those offload support can be enable= d. Raj> So you expect the user to know what offload means? The term "IPv4 offl= oad traffic selectors" or "enable offload traffic" are used without setting= the context. 2. What are "access technology domains"? Ex: WLAN Will clarify with examples 3. "For providing IP mobility support to a mobile node irrespective of the access network to which it is attached." ???? Rephrase. Ok 4. "the 3GPP S2a Proxy Mobile IPv6 [TS23402] interface," Is this an interface or a reference point? reference pt. will reword it 5. "...is providing the needed protocol glue." Protocol glue for what? will reword it 6. " The mobile node's IP traffic is always tunneled back from the mobile access gateway [RFC5213] in the access network to the local mobility anchor in the home network." The MN could use the local address provided by the access-network for some applications, right? Just having the S2a interface does not imply that all traffic is routed back to the LMA, right? Yes, the access network can assign an IP address. That is for IPv6 and assu= ming there is prefix coloring, or other mechanisms for the mobile to identi= fy that local address. But, we already stated this document is for IPv4-onl= y traffic offload support. There we don't have mechanisms to assign multipl= e IPv4 addresses over DHCPv4; we can only assign a single IPv4 address. So,= that IPv4 address is either a local address, or the home address. Raj> Agree. 7. "Not all IP traffic need to be routed back to the home network, some of the non-essential traffic which does not require IP mobility support can be offloaded at the mobile access gateway in the access network." What is non-essential traffic? Can you give some examples. And what happens if such traffic does not have IP mobility support? Traffic which does not require any services such as mobility, QoS or inline= services =85 will add clarifying text Raj> How does the MAG/LMA or policy server determine if traffic is consider= ed essential? How do these elements know whether that application which is = generating the traffic needs mobility, QoS etc. or not? As an example, a us= er could be streaming some video over HTTP. If the policy says that HTTP tr= affic can be offloaded, that application will suffer a break in session con= tinuity. How do you deal with such a scenario? The session would be uninter= rupted if it was not offloaded. 8. "This approach provides greater leverage and efficient usage of the mobile packet core which help lowering transport cost." Greater leverage of what? Sounds like too much of marketing buzz in what is intended to be a technical spec. Will reword it 9. Definition of IP Traffic Offload in Sec 2.2 is lacking clarity in the context of this I-D. It would be good to define what is meant by IP Traffic offload in the 3GPP operator scenario. Per your other comment, will have minimal text on 3GPP terminology or usage= . Raj> I would even suggest that instead of using the term offload, you could= say something like traffic breakout at the MAG. 10. Is this specification applicable to 3GPP network deployments only? This is a feature in standard PMIPv6 architecture; we can leave it there Raj> The I-D implies applicability to 3GPP network deployments (as you can = see from the intro section) as well as the use of terms like PCRF, S2a etc.= If you want to make it a generic capability of PMIP6, then you need to cle= an up the text accordingly. 11. "The selectors that are delivered to the mobile access gateway can be used to classify the traffic, so it can be offloaded to the local access network. " What is the local access network? reworded to "access network" 12. "The details related to DHCP transactions, or Router Advertisements on the access link are not shown here." Are these part of the MN attachment to the MAG process? They are missing as they are not relevant to core part of the discussion. T= here is change on the MN-MAG interface, or to the address assignment proced= ures. Will add a statement covering that. Raj> What is the MN-MAG interface change that you are referring to? I thoug= ht there is no interaction with the MN in this spec. 13. Figure 2 can be improved Ok. Will try 14. "This would not have no effect =85" fixed, thanks 15. What happens to IPsec tunnel-mode encrypted traffic? The I-D does not say anything about such traffic whether it can be offloaded. IPsec Tunnel mode ESP is applied on the flows that are routed through the t= unnel and is not applied on offloaded traffic. Raj> Hmmm=85 Not sure I understand your comment above. Are you saying that = offloading is not applicable to such Ipsec traffic? If so, please state in = the I-D. 16. There is not enough information about how the MAG or the LMA decide which traffic to offload. There is some handwaving about interacting with a policy server and the I-D says it is out of scope. But it would be useful to understand more about how this is expected to work. For example, how does the MAG choose the traffic selectors? That is a operator policy decision. There is no hand waiving there, its a c= onfiguration option. Should the spec recommend a specific flow that needs t= o be offloaded ? Does DSMIP spec specific what flow needs to be assigned to= what access ? The mechanism is only allowing a mechanism and the peers to = negotiate offload policy. Raj> The comparison with DSMIP6 spec is invalid. The MN in the case of DSMI= P6 makes the decision of which traffic/flow to switch from one interface to= another. It is an MN decision. In this case, the network and some policy s= tore is making the decision. So the question is : What is the basis for suc= h a decision? Because the MN/user has no awareness of the traffic being shu= nted off via another access network. 17. Is the NAT co-located with the MAG? The offloaded traffic flows have to NAT translated. If that NAT function is= collocated on the MAG, or outside is a deployment option Raj> If the NAT is not collocated with the MAG, do you have another tunnel = to the NAT? 18. What happens if the MAG and LMA are in different domains (visited and home networks)? Is there an issue in such a scenario? Per RFC 5213 definition, PMIPv6 is for local mobility, with the protocol si= gnaling between two peers in the same domain. Raj> So are you saying that the MAG/LMA are always in the same domain? Ther= e is no roaming (between operators) possibility with PMIP6? 19. The bandwidth and characteristics of the connectivity at the access network may be different from what is at the home network (LMA). The performance and user experience may be degarded when the traffic is offloaded via the access network. The end-user has no awareness of the traffic being offloaded. How do you handle this situation? That is the nature of offload. Traffic which does not require any services = such as mobility are chosen for offload. Those offloaded flows are not assu= red for any SLA's from the home operator. The traffic treatment is based on= the resources in the access network and that is the case for home routed t= raffic as well (on the MN to MAG path). With respect to end-user awareness,= there is no awareness same as with any NAT deployment, NAT64, DSLite or an= y other approach, the end-user is not aware of such translation. Raj> I still have a problem with the comment about the network/operator dec= iding unilaterally about whether certain traffic needs a capability like mo= bility or not. -Raj Thanks for the review comments. Sri -Raj _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext --_000_CBE54C271F4A7basavarajpatilnokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4128D1FB5298A74DA88D3E0BACD47AB7@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable

Inline: 

From: Sri Gundavelli <sgundave@cisco.com>
Date: Thursday, May 24, 2012 7:11 P= M
To: Basavaraj Patil <basavaraj.patil@nokia.com>
Cc: Netext <netext@ietf.org>, "draft-ietf-netext-pmipv6-sipto-o= ption@tools.ietf.org" <draft-ietf-netext-pmipv6-sipto-option@tools= .ietf.org>
Subject: Re: [netext] Review of I-D= draft-ietf-netext-pmipv6-sipto-option

Thanks for the review.  Comments inline ..



On May 24, 2012, at 3:19 PM, <Basavaraj.Patil@nokia.com> <Basavaraj.Patil@nokia.com> wrote:


My review comments for this I-D below:

General comment: The document quality needs improvement before it
would be considered ready for being forwarded to the IESG. There is a
lack of readability in this I-D. Authors assume that readers are
familiar with 3GPP architectures or offloading features. Recommend
explaining the problem and proposed solution much more clearly.

1. The abstract is intended to at least give a high level perspective
on what the I-D is about. Current abstract does not do that. Other
than the authors or someone following this work very closely, I doubt
if anyone can understand what this document is specifying.



   This specification defines a mechanism and a relat=
ed mobility option
   for carrying IPv4 Offload traffic selectors between a mobile access
   gateway and a local mobility anchor in a Proxy Mobile IPv6 domain.
   Based on the received offload flow selectors from the local mobility
   anchor, a mobile access gateway can enable offload traffic rule on
   the selected IPv4 flows.


This is a feature extension to an existing protocol. Its hard to provi= de the complete context in the Abstract. Its just stating the two peers LMA= and MAG can negotiate an offload policy, so those offload support can be e= nabled.

Raj> So you expect the user to know what offload means? The term &q= uot;IPv4 offload traffic selectors" or "enable offload traffic&qu= ot; are used without setting the context.

2. What are "access technology domains"?


Ex: WLAN
Will clarify with examples


3. "For providing IP mobility support to a mobile node irrespecti= ve of the
  access network to which it is attached." ???? Rephrase.

Ok

4. "the 3GPP S2a Proxy Mobile IPv6 [TS23402] interface," Is = this an
interface or a reference point?


reference pt. will reword it


5. "...is providing the needed protocol glue." Protocol glue= for what?


will reword it


6. " The mobile node's IP traffic is
  always tunneled back from the mobile access gateway [RFC5213] i= n the
  access network to the local mobility anchor in the home network= ."

  The MN could use the local address provided by the access-netwo= rk
  for some applications, right? Just having the S2a interface doe= s
  not imply that all traffic is routed back to the LMA, right?

Yes, the access network can assign an IP address. That is for IPv6 and= assuming there is prefix coloring, or other mechanisms for the mobile to i= dentify that local address. But, we already stated this document is for IPv= 4-only traffic offload support. There we don't have mechanisms to assign multiple IPv4 addresses over DHCP= v4; we can only assign a single IPv4 address. So, that IPv4 address is eith= er a local address, or the home address.

Raj> Agree. 


7. "Not all IP traffic need to be
  routed back to the home network, some of the non-essential traf= fic
  which does not require IP mobility support can be offloaded at = the
  mobile access gateway in the access network."

  What is non-essential traffic? Can you give some examples. And = what
  happens if such traffic does not have IP mobility support?


Traffic which does not require any services such as mobility, QoS or i= nline services =85 will add clarifying text

Raj> How does the MAG/LMA or policy server determine if traffic is = considered essential? How do these elements know whether that application w= hich is generating the traffic needs mobility, QoS etc. or not? As an examp= le, a user could be streaming some video over HTTP. If the policy says that HTTP traffic can be offloaded, th= at application will suffer a break in session continuity. How do you deal w= ith such a scenario? The session would be uninterrupted if it was not offlo= aded. 


8. "This approach provides
  greater leverage and efficient usage of the mobile packet core = which
  help lowering transport cost."

  Greater leverage of what? Sounds like too much of marketing buz= z in
  what is intended to be a technical spec.


Will reword it


9. Definition of IP Traffic Offload in Sec 2.2 is lacking clarity in the context of this I-D. It would be good to define what is meant by
IP Traffic offload in the 3GPP operator scenario.


Per your other comment, will have minimal text on 3GPP terminology or = usage.

Raj> I would even suggest that instead of using the term offload, y= ou could say something like traffic breakout at the MAG. 


10. Is this specification applicable to 3GPP network deployments only?=


This is a feature in standard PMIPv6 architecture; we can leave it the= re

Raj> The I-D implies applicability to 3GPP network deployments (as you c= an see from the intro section) as well as the use of terms like PCRF, S2a e= tc. If you want to make it a generic capability of PMIP6, then you need to = clean up the text accordingly. 
11. "The selectors that are delivered to the mobile access gatewa= y can be
  used to classify the traffic, so it can be offloaded to the loc= al
  access network. "

  What is the local access network?


reworded to "access network"



12. "The details related to DHCP transactions, or Router
  Advertisements on the access link are not shown here."

  Are these part of the MN attachment to the MAG process?


They are missing as they are not relevant to core part of the discussi= on. There is change on the MN-MAG interface, or to the address assignment p= rocedures.
 Will add a statement covering that.

Raj> What is the MN-MAG interface change that you are referring to?= I thought there is no interaction with the MN in this spec.


13. Figure 2 can be improved


Ok. Will try



14. "This would not have no effect =85"

fixed, thanks



15. What happens to IPsec tunnel-mode encrypted traffic? The I-D does<= br> not say anything about such traffic whether it can be offloaded.


IPsec Tunnel mode ESP is applied on the flows that are routed through = the tunnel and is not applied on offloaded traffic. 

Raj> Hmmm=85 Not sure I understand your comment above. Are you sayi= ng that offloading is not applicable to such Ipsec traffic? If so, please s= tate in the I-D.

16. There is not enough information about how the MAG or the LMA
decide which traffic to offload. There is some handwaving about
interacting with a policy server and the I-D says it is out of
scope. But it would be useful to understand more about how this is
expected to work. For example, how does the MAG choose the traffic
selectors?


That is a operator policy decision. There is no hand waiving there, it= s a configuration option. Should the spec recommend a specific flow that ne= eds to be offloaded ? Does DSMIP spec specific what flow needs to be assign= ed to what access ? The mechanism is only allowing a mechanism and the peers to negotiate offload policy.

Raj> The comparison with DSMIP6 spec is invalid. The MN in the case= of DSMIP6 makes the decision of which traffic/flow to switch from one inte= rface to another. It is an MN decision. In this case, the network and some = policy store is making the decision. So the question is : What is the basis for such a decision? Because the MN= /user has no awareness of the traffic being shunted off via another access = network.

17. Is the NAT co-located with the MAG?


The offloaded traffic flows have to NAT translated. If that NAT functi= on is collocated on the MAG, or outside is a deployment option


Raj> If the NAT is not collocated with the MAG, do you have another= tunnel to the NAT?    

18. What happens if the MAG and LMA are in different domains (visited<= br> and home networks)? Is there an issue in such a scenario?


Per RFC 5213 definition, PMIPv6 is for local mobility, with the protoc= ol signaling between two peers in the same domain.

Raj> So are you saying that the MAG/LMA are always in the same doma= in? There is no roaming (between operators) possibility with PMIP6?

19. The bandwidth and characteristics of the connectivity at the
access network may be different from what is at the home network
(LMA). The performance and user experience may be degarded when the
traffic is offloaded via the access network. The end-user has no
awareness of the traffic being offloaded. How do you handle this
situation? 



That is the nature of offload. Traffic which does not require any serv= ices such as mobility are chosen for offload. Those offloaded flows are not= assured for any SLA's from the home operator. The traffic treatment is bas= ed on the resources in the access network and that is the case for home routed traffic as well (on the MN to= MAG path). With respect to end-user awareness, there is no awareness = same as with any NAT deployment, NAT64, DSLite or any other approach, the e= nd-user is not aware of such translation.

Raj> I still have a problem with the comment about the network/oper= ator deciding unilaterally about whether certain traffic needs a capability= like mobility or not.

-Raj

Thanks for the review comments.


Sri



-Raj

_______________________________________________
netext mailing list
netext@ietf.org
https://www.ietf.o= rg/mailman/listinfo/netext

 --_000_CBE54C271F4A7basavarajpatilnokiacom_-- From sgundave@cisco.com Fri May 25 13:35:27 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDA421F87D7 for ; Fri, 25 May 2012 13:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHjSL3zybEO7 for ; Fri, 25 May 2012 13:35:25 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6ECF621F87CF for ; Fri, 25 May 2012 13:35:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=34914; q=dns/txt; s=iport; t=1337978125; x=1339187725; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=aIIDzuahTm2pGSrbmH2kFNNRp5YR9+dNPxW/3UO6zs8=; b=UvEaEliIlShsBwDt7xSLmkhQbEjrfxwom0yLNY5TtkPio3RdiO/g1FgJ sds0wYvbFKrfEhmzVF0AGcrrrzq/5UexyGJBT94GR/dyRmz4HikGrvIpr Ms8bq91Dr5voHjZ2T41MXzFeoxzuYPoXnkWS/HROpjCCvV/f7sUGx4K9w Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAObrv0+rRDoH/2dsb2JhbAA6CoJFslGBB4IVAQEBAwESAQdVChALEQECAQIBIAENSQYIBhMUBweHZgSYeZ9WiwEQhFZgA4g/jFmODIFkgwA X-IronPort-AV: E=Sophos;i="4.75,658,1330905600"; d="scan'208,217";a="46354209" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 25 May 2012 20:35:24 +0000 Received: from stealth-10-32-246-210.cisco.com (stealth-10-32-246-210.cisco.com [10.32.246.210]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q4PKZOVJ015593; Fri, 25 May 2012 20:35:24 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_DFA312FD-9F19-4A8B-8EC1-D525AA2919A4" From: Sri Gundavelli In-Reply-To: Date: Fri, 25 May 2012 13:35:23 -0700 Message-Id: References: To: "" X-Mailer: Apple Mail (2.1278) Cc: netext@ietf.org, draft-ietf-netext-pmipv6-sipto-option@tools.ietf.org Subject: Re: [netext] Review of I-D draft-ietf-netext-pmipv6-sipto-option X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 20:35:27 -0000 --Apple-Mail=_DFA312FD-9F19-4A8B-8EC1-D525AA2919A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks ..inline .. On May 25, 2012, at 1:05 PM, = wrote: >=20 > Inline:=20 >=20 > From: Sri Gundavelli > Date: Thursday, May 24, 2012 7:11 PM > To: Basavaraj Patil > Cc: Netext , = "draft-ietf-netext-pmipv6-sipto-option@tools.ietf.org" = > Subject: Re: [netext] Review of I-D = draft-ietf-netext-pmipv6-sipto-option >=20 > Thanks for the review. Comments inline .. >=20 >=20 >=20 > On May 24, 2012, at 3:19 PM, = wrote: >=20 >>=20 >> My review comments for this I-D below: >>=20 >> General comment: The document quality needs improvement before it >> would be considered ready for being forwarded to the IESG. There is a >> lack of readability in this I-D. Authors assume that readers are >> familiar with 3GPP architectures or offloading features. Recommend >> explaining the problem and proposed solution much more clearly. >>=20 >> 1. The abstract is intended to at least give a high level perspective >> on what the I-D is about. Current abstract does not do that. Other >> than the authors or someone following this work very closely, I doubt >> if anyone can understand what this document is specifying. >>=20 >=20 >=20 > This specification defines a mechanism and a related mobility = option > for carrying IPv4 Offload traffic selectors between a mobile access > gateway and a local mobility anchor in a Proxy Mobile IPv6 domain. > Based on the received offload flow selectors from the local = mobility > anchor, a mobile access gateway can enable offload traffic rule on > the selected IPv4 flows. >=20 >=20 > This is a feature extension to an existing protocol. Its hard to = provide the complete context in the Abstract. Its just stating the two = peers LMA and MAG can negotiate an offload policy, so those offload = support can be enabled. >=20 > Raj> So you expect the user to know what offload means? The term "IPv4 = offload traffic selectors" or "enable offload traffic" are used without = setting the context. >=20 Please suggest some text. I don think I can write an Abstract without = using any technical terms. Offload is a generic term known to the mobile = community. The target audience for this spec is a developer working in = this field and I'd expect them to know this term. We can add explanation = in the terminology section. >> 2. What are "access technology domains"? >>=20 >=20 > Ex: WLAN > Will clarify with examples >=20 >=20 >> 3. "For providing IP mobility support to a mobile node irrespective = of the >> access network to which it is attached." ???? Rephrase. >>=20 >=20 > Ok >=20 >> 4. "the 3GPP S2a Proxy Mobile IPv6 [TS23402] interface," Is this an >> interface or a reference point? >>=20 >=20 > reference pt. will reword it >=20 >=20 >> 5. "...is providing the needed protocol glue." Protocol glue for = what? >>=20 >=20 > will reword it >=20 >=20 >> 6. " The mobile node's IP traffic is >> always tunneled back from the mobile access gateway [RFC5213] in = the >> access network to the local mobility anchor in the home network." >>=20 >> The MN could use the local address provided by the access-network >> for some applications, right? Just having the S2a interface does >> not imply that all traffic is routed back to the LMA, right? >>=20 >=20 > Yes, the access network can assign an IP address. That is for IPv6 and = assuming there is prefix coloring, or other mechanisms for the mobile to = identify that local address. But, we already stated this document is for = IPv4-only traffic offload support. There we don't have mechanisms to = assign multiple IPv4 addresses over DHCPv4; we can only assign a single = IPv4 address. So, that IPv4 address is either a local address, or the = home address. >=20 > Raj> Agree.=20 >=20 >=20 >> 7. "Not all IP traffic need to be >> routed back to the home network, some of the non-essential traffic >> which does not require IP mobility support can be offloaded at the >> mobile access gateway in the access network." >>=20 >> What is non-essential traffic? Can you give some examples. And what >> happens if such traffic does not have IP mobility support? >>=20 >=20 > Traffic which does not require any services such as mobility, QoS or = inline services =85 will add clarifying text >=20 > Raj> How does the MAG/LMA or policy server determine if traffic is = considered essential? How do these elements know whether that = application which is generating the traffic needs mobility, QoS etc. or = not? As an example, a user could be streaming some video over HTTP. If = the policy says that HTTP traffic can be offloaded, that application = will suffer a break in session continuity. How do you deal with such a = scenario? The session would be uninterrupted if it was not offloaded.=20 >=20 Operator enables some firewall policy and blocks the traffic, what will = the user do ? Operator enabling this firewall policy or the Offload = policy should have the same considerations.=20 >=20 >> 8. "This approach provides >> greater leverage and efficient usage of the mobile packet core = which >> help lowering transport cost." >>=20 >> Greater leverage of what? Sounds like too much of marketing buzz in >> what is intended to be a technical spec. >>=20 >=20 > Will reword it >=20 >=20 >> 9. Definition of IP Traffic Offload in Sec 2.2 is lacking clarity in >> the context of this I-D. It would be good to define what is meant by >> IP Traffic offload in the 3GPP operator scenario. >>=20 >=20 > Per your other comment, will have minimal text on 3GPP terminology or = usage. >=20 > Raj> I would even suggest that instead of using the term offload, you = could say something like traffic breakout at the MAG.=20 >=20 Will reword the text to explain this more clearly >> 10. Is this specification applicable to 3GPP network deployments = only? >>=20 >=20 > This is a feature in standard PMIPv6 architecture; we can leave it = there >=20 > Raj> The I-D implies applicability to 3GPP network deployments (as you = can see from the intro section) as well as the use of terms like PCRF, = S2a etc. If you want to make it a generic capability of PMIP6, then you = need to clean up the text accordingly.=20 Ok, 3GPP is just an example >> 11. "The selectors that are delivered to the mobile access gateway = can be >> used to classify the traffic, so it can be offloaded to the local >> access network. " >>=20 >> What is the local access network? >>=20 >=20 > reworded to "access network" >=20 >=20 >=20 >> 12. "The details related to DHCP transactions, or Router >> Advertisements on the access link are not shown here." >>=20 >> Are these part of the MN attachment to the MAG process? >>=20 >=20 > They are missing as they are not relevant to core part of the = discussion. There is change on the MN-MAG interface, or to the address = assignment procedures. > Will add a statement covering that. >=20 > Raj> What is the MN-MAG interface change that you are referring to? I = thought there is no interaction with the MN in this spec. >=20 typo .."there is no change" >=20 >> 13. Figure 2 can be improved >>=20 >=20 > Ok. Will try >=20 >=20 >=20 >> 14. "This would not have no effect =85" >=20 > fixed, thanks >=20 >=20 >=20 >> 15. What happens to IPsec tunnel-mode encrypted traffic? The I-D does >> not say anything about such traffic whether it can be offloaded. >>=20 >=20 > IPsec Tunnel mode ESP is applied on the flows that are routed through = the tunnel and is not applied on offloaded traffic.=20 >=20 > Raj> Hmmm=85 Not sure I understand your comment above. Are you saying = that offloading is not applicable to such Ipsec traffic? If so, please = state in the I-D. >=20 The tunnel mode ESP is on the MAG - LMA tunnel. The MAG splits the = traffic, some traffic go out the gateway and some go through the tunnel. = The tunneled traffic gets ESP policy. If you are referring to the IPsec traffic from the UE, yes, its not = applicable; sure, we can add that note explicitly. Thanks >> 16. There is not enough information about how the MAG or the LMA >> decide which traffic to offload. There is some handwaving about >> interacting with a policy server and the I-D says it is out of >> scope. But it would be useful to understand more about how this is >> expected to work. For example, how does the MAG choose the traffic >> selectors? >>=20 >=20 > That is a operator policy decision. There is no hand waiving there, = its a configuration option. Should the spec recommend a specific flow = that needs to be offloaded ? Does DSMIP spec specific what flow needs to = be assigned to what access ? The mechanism is only allowing a mechanism = and the peers to negotiate offload policy. >=20 > Raj> The comparison with DSMIP6 spec is invalid. The MN in the case of = DSMIP6 makes the decision of which traffic/flow to switch from one = interface to another. It is an MN decision. In this case, the network = and some policy store is making the decision. So the question is : What = is the basis for such a decision? Because the MN/user has no awareness = of the traffic being shunted off via another access network. >=20 This goes back to the previous discussion point of MN awareness >> 17. Is the NAT co-located with the MAG? >>=20 >=20 > The offloaded traffic flows have to NAT translated. If that NAT = function is collocated on the MAG, or outside is a deployment option >=20 >=20 > Raj> If the NAT is not collocated with the MAG, do you have another = tunnel to the NAT? =20 >=20 Why do we need a tunnel ? For private IP conflict ? Depends on the = topology of the network. If the operator wants to hide this traffic from = the access network, the NAT function can be collocated on the gateway, = or routed using some VLAN to the NAT gateway. We can add this = consideration on this. >> 18. What happens if the MAG and LMA are in different domains (visited >> and home networks)? Is there an issue in such a scenario? >>=20 >=20 > Per RFC 5213 definition, PMIPv6 is for local mobility, with the = protocol signaling between two peers in the same domain. >=20 > Raj> So are you saying that the MAG/LMA are always in the same domain? = There is no roaming (between operators) possibility with PMIP6? >=20 They are always in the same PMIPv6 domain. Roaming is within a local = mobility domain. >> 19. The bandwidth and characteristics of the connectivity at the >> access network may be different from what is at the home network >> (LMA). The performance and user experience may be degarded when the >> traffic is offloaded via the access network. The end-user has no >> awareness of the traffic being offloaded. How do you handle this >> situation?=20 >>=20 >=20 >=20 > That is the nature of offload. Traffic which does not require any = services such as mobility are chosen for offload. Those offloaded flows = are not assured for any SLA's from the home operator. The traffic = treatment is based on the resources in the access network and that is = the case for home routed traffic as well (on the MN to MAG path). With = respect to end-user awareness, there is no awareness same as with any = NAT deployment, NAT64, DSLite or any other approach, the end-user is not = aware of such translation. >=20 > Raj> I still have a problem with the comment about the = network/operator deciding unilaterally about whether certain traffic = needs a capability like mobility or not. This relates to the previous discussion point. This is a network-based solution. What can we do to tell the terminal ? = This is the same consideration as the case of NAT64, MN is not aware of = his traffic getting NAT'd out.=20 Sri --Apple-Mail=_DFA312FD-9F19-4A8B-8EC1-D525AA2919A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Basavaraj.Patil@nokia.com>= ; <Basavaraj.Patil@nokia.com>= ; wrote:


Inline: 

From: Sri Gundavelli <sgundave@cisco.com>
Date: Thursday, May 24, 2012 = 7:11 PM
To: Basavaraj Patil <basavaraj.patil@nokia.com>= ;
Cc: Netext <netext@ietf.org>, "draft= -ietf-netext-pmipv6-sipto-option@tools.ietf.org" <draft= -ietf-netext-pmipv6-sipto-option@tools.ietf.org>
Subject: Re: [netext] Review of = I-D draft-ietf-netext-pmipv6-sipto-option

Thanks for the review.  Comments inline ..



On May 24, 2012, at 3:19 PM, <Basavaraj.Patil@nokia.com>= ; <Basavaraj.Patil@nokia.com>= ; wrote:


My review comments for this I-D below:

General comment: The document quality needs improvement before it
would be considered ready for being forwarded to the IESG. There is = a
lack of readability in this I-D. Authors assume that readers are
familiar with 3GPP architectures or offloading features. Recommend
explaining the problem and proposed solution much more clearly.

1. The abstract is intended to at least give a high level = perspective
on what the I-D is about. Current abstract does not do that. Other
than the authors or someone following this work very closely, I = doubt
if anyone can understand what this document is specifying.



   This specification defines a =
mechanism and a related mobility option
   for carrying IPv4 Offload traffic selectors between a mobile access
   gateway and a local mobility anchor in a Proxy Mobile IPv6 domain.
   Based on the received offload flow selectors from the local mobility
   anchor, a mobile access gateway can enable offload traffic rule on
   the selected IPv4 flows.


This is a feature extension to an existing protocol. Its hard to = provide the complete context in the Abstract. Its just stating the two = peers LMA and MAG can negotiate an offload policy, so those offload = support can be enabled.

Raj> So you expect the user to know what offload means? The term = "IPv4 offload traffic selectors" or "enable offload traffic" are used = without setting the context.
=

Please suggest some text. I don think I can write an Abstract = without using any technical terms. Offload is a generic term known to = the mobile community. The target audience for this spec is a developer = working in this field and I'd expect them to know this term. We can add = explanation in the terminology = section.




2. What are "access technology domains"?


Ex: WLAN
Will clarify with examples


3. "For providing IP mobility support to a mobile node irrespective = of the
  access network to which it is attached." ???? Rephrase.


Ok

4. "the 3GPP S2a Proxy Mobile IPv6 [TS23402] interface," Is this = an
interface or a reference point?


reference pt. will reword it


5. "...is providing the needed protocol glue." Protocol glue for = what?


will reword it


6. " The mobile node's IP traffic is
  always tunneled back from the mobile access gateway = [RFC5213] in the
  access network to the local mobility anchor in the home = network."

  The MN could use the local address provided by the = access-network
  for some applications, right? Just having the S2a interface = does
  not imply that all traffic is routed back to the LMA, = right?


Yes, the access network can assign an IP address. That is for IPv6 = and assuming there is prefix coloring, or other mechanisms for the = mobile to identify that local address. But, we already stated this = document is for IPv4-only traffic offload support. There we don't have mechanisms to assign multiple IPv4 addresses over = DHCPv4; we can only assign a single IPv4 address. So, that IPv4 address = is either a local address, or the home address.

Raj> Agree. 


7. "Not all IP traffic need to be
  routed back to the home network, some of the non-essential = traffic
  which does not require IP mobility support can be offloaded = at the
  mobile access gateway in the access network."

  What is non-essential traffic? Can you give some examples. = And what
  happens if such traffic does not have IP mobility = support?


Traffic which does not require any services such as mobility, QoS = or inline services =85 will add clarifying text

Raj> How does the MAG/LMA or policy server determine if traffic = is considered essential? How do these elements know whether that = application which is generating the traffic needs mobility, QoS etc. or = not? As an example, a user could be streaming some video over HTTP. If the policy says that HTTP traffic can be offloaded, = that application will suffer a break in session continuity. How do you = deal with such a scenario? The session would be uninterrupted if it was = not offloaded. 
=


Operator enables some firewall policy and blocks the = traffic, what will the user do ? Operator enabling this firewall policy = or the Offload policy should have the same = considerations. 



8. "This approach provides
  greater leverage and efficient usage of the mobile packet = core which
  help lowering transport cost."

  Greater leverage of what? Sounds like too much of marketing = buzz in
  what is intended to be a technical spec.


Will reword it


9. Definition of IP Traffic Offload in Sec 2.2 is lacking clarity = in
the context of this I-D. It would be good to define what is meant by
IP Traffic offload in the 3GPP operator scenario.


Per your other comment, will have minimal text on 3GPP terminology = or usage.

Raj> I would even suggest that instead of using the term = offload, you could say something like traffic breakout at the = MAG. 
=


Will reword the text to explain this more = clearly




10. Is this specification applicable to 3GPP network deployments = only?


This is a feature in standard PMIPv6 architecture; we can leave it = there

Raj> The I-D implies applicability to 3GPP network deployments (as = you can see from the intro section) as well as the use of terms like = PCRF, S2a etc. If you want to make it a generic capability of PMIP6, = then you need to clean up the text = accordingly. 


Ok, 3GPP is just an = example



11. "The selectors that are delivered to the mobile access gateway = can be
  used to classify the traffic, so it can be offloaded to the = local
  access network. "

  What is the local access network?


reworded to "access network"



12. "The details related to DHCP transactions, or Router
  Advertisements on the access link are not shown here."

  Are these part of the MN attachment to the MAG process?


They are missing as they are not relevant to core part of the = discussion. There is change on the MN-MAG interface, or to the address = assignment procedures.
 Will add a statement covering that.

Raj> What is the MN-MAG interface change that you are referring = to? I thought there is no interaction with the MN in this spec.
=


typo .."there is no = change"




13. Figure 2 can be improved


Ok. Will try



14. "This would not have no effect =85"

fixed, thanks



15. What happens to IPsec tunnel-mode encrypted traffic? The I-D = does
not say anything about such traffic whether it can be offloaded.


IPsec Tunnel mode ESP is applied on the flows that are routed = through the tunnel and is not applied on offloaded traffic. 

Raj> Hmmm=85 Not sure I understand your comment above. Are you = saying that offloading is not applicable to such Ipsec traffic? If so, = please state in the I-D.
=

The tunnel mode ESP is on the MAG - LMA tunnel. The MAG splits the = traffic, some traffic go out the gateway and some go through the tunnel. = The tunneled traffic gets ESP policy.
If you are referring to = the IPsec traffic from the UE, yes, its not applicable; sure, we can add = that note explicitly. = Thanks




16. There is not enough information about how the MAG or the = LMA
decide which traffic to offload. There is some handwaving about
interacting with a policy server and the I-D says it is out of
scope. But it would be useful to understand more about how this is
expected to work. For example, how does the MAG choose the traffic
selectors?


That is a operator policy decision. There is no hand waiving there, = its a configuration option. Should the spec recommend a specific flow = that needs to be offloaded ? Does DSMIP spec specific what flow needs to = be assigned to what access ? The mechanism is only allowing a mechanism and the peers to negotiate offload = policy.

Raj> The comparison with DSMIP6 spec is invalid. The MN in the = case of DSMIP6 makes the decision of which traffic/flow to switch from = one interface to another. It is an MN decision. In this case, the = network and some policy store is making the decision. So the question is : What is the basis for such a decision? Because the = MN/user has no awareness of the traffic being shunted off via another = access network.
=


=
This goes back to the previous discussion point of MN = awareness




17. Is the NAT co-located with the MAG?


The offloaded traffic flows have to NAT translated. If that NAT = function is collocated on the MAG, or outside is a deployment = option


Raj> If the NAT is not collocated with the MAG, do you have = another tunnel to the NAT?    
=


Why do we need a tunnel ? For private IP conflict = ? Depends on the topology of the network. If the operator wants to = hide this traffic from the access network, the NAT function can be = collocated on the gateway, or routed using some VLAN to the NAT gateway. = We can add this consideration on = this.






18. What happens if the MAG and LMA are in different domains = (visited
and home networks)? Is there an issue in such a scenario?


Per RFC 5213 definition, PMIPv6 is for local mobility, with the = protocol signaling between two peers in the same domain.

Raj> So are you saying that the MAG/LMA are always in the same = domain? There is no roaming (between operators) possibility with = PMIP6?
=

They are always in the same PMIPv6 domain. Roaming is within a = local mobility = domain.




19. The bandwidth and characteristics of the connectivity at = the
access network may be different from what is at the home network
(LMA). The performance and user experience may be degarded when the
traffic is offloaded via the access network. The end-user has no
awareness of the traffic being offloaded. How do you handle this
situation? 



That is the nature of offload. Traffic which does not require any = services such as mobility are chosen for offload. Those offloaded flows = are not assured for any SLA's from the home operator. The traffic = treatment is based on the resources in the access network and that is the case for home routed traffic as well (on the MN = to MAG path). With respect to end-user awareness, there is no = awareness same as with any NAT deployment, NAT64, DSLite or any other = approach, the end-user is not aware of such translation.

Raj> I still have a problem with the comment about the = network/operator deciding unilaterally about whether certain traffic = needs a capability like mobility or = not.


This = relates to the previous discussion point.
This is a = network-based solution. What can we do to tell the terminal ? This is = the same consideration as the case of NAT64, MN is not aware of his = traffic getting NAT'd = out. 


Sri


= --Apple-Mail=_DFA312FD-9F19-4A8B-8EC1-D525AA2919A4-- From cjbc@it.uc3m.es Mon May 28 00:29:20 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D4E21F8507 for ; Mon, 28 May 2012 00:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhtKtVnhQWBx for ; Mon, 28 May 2012 00:29:19 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id AEC7221F84FA for ; Mon, 28 May 2012 00:29:18 -0700 (PDT) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 56100604; Mon, 28 May 2012 09:29:14 +0200 (CEST) Message-ID: <1338190154.4381.9.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Basavaraj.Patil@nokia.com Date: Mon, 28 May 2012 09:29:14 +0200 In-Reply-To: References: Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-EMqeDrBRCAjp1tybtuJr" X-Mailer: Evolution 3.2.2-1+b1 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-18850.006 X-TM-AS-Result: No--13.902-7.0-31-1 X-imss-scan-details: No--13.902-7.0-31-1 Cc: netext@ietf.org Subject: Re: [netext] Consensus call on adopting I-D draft-liebsch-netext-pmip6-qos as WG document X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 07:29:20 -0000 --=-EMqeDrBRCAjp1tybtuJr Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi, Should the Netext WG adopt this I-D as a WG document? 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 On Wed, 2012-05-23 at 19:01 +0000, Basavaraj.Patil@nokia.com wrote: > Hello, >=20 > The authors of the I-D: Quality of Service Option for Proxy Mobile IPv6 > > http://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-01.txt >=20 > 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. >=20 > The crux of the proposal is to extend PMIP6 signaling to enable support > for QoS. >=20 > Abstract >=20 > 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. >=20 >=20 > Please review the I-D and respond by June 6th with your opinion. > Respond to the following question: >=20 > Should the Netext WG adopt this I-D as a WG document? >=20 > Yes [ ] > No [ ] >=20 > Thank you. > -Chairs >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --=20 Carlos Jes=FAs 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=20 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-EMqeDrBRCAjp1tybtuJr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk/DKUoACgkQNdy6TdFwT2c1pACfQm+kZidpsQMKho268hzEXk8V j10An2pbDepKMTp5yudsVEDJxbPlA8xz =8zPk -----END PGP SIGNATURE----- --=-EMqeDrBRCAjp1tybtuJr-- From yiu_lee@cable.comcast.com Mon May 28 07:54:07 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C3221F8619 for ; Mon, 28 May 2012 07:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.231 X-Spam-Level: X-Spam-Status: No, score=-105.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZaFsS2tdgP9 for ; Mon, 28 May 2012 07:54:07 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 2129021F85C6 for ; Mon, 28 May 2012 07:54:07 -0700 (PDT) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.19004701; Mon, 28 May 2012 08:38:27 -0600 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.28]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0283.003; Mon, 28 May 2012 10:54:03 -0400 From: "Lee, Yiu" To: "netext@ietf.org" Thread-Topic: [netext] Consensus call on adopting I-D draft-liebsch-netext-pmip6-qos as WG document Thread-Index: AQHNPOG4YXdey+NWpkKF2NFy+6+yBg== Date: Mon, 28 May 2012 14:54:02 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [24.40.55.71] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3421047241_12156" MIME-Version: 1.0 Subject: Re: [netext] Consensus call on adopting I-D draft-liebsch-netext-pmip6-qos as WG document X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 14:54:08 -0000 --B_3421047241_12156 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I think this draft does address the QoS part of PMIP, I support to adopt this draft as WG item. On 5/23/12 3:01 PM, "Basavaraj.Patil@nokia.com" wrote: > >Hello, > >The authors of the I-D: Quality of Service Option for Proxy Mobile IPv6 > >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 > >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext --B_3421047241_12156 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBS3oDQM z01fVdU2vH6tAG7vRiDnFTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA1MjgxNDU0MDFaMA0GCSqGSIb3DQEBAQUABIIBAEva2Z02wIsUnPqCSA5rKoJp V9bBwmM62wvfzqNTkz9yK3nV2KFzAreDth9i4/brICN0ZUFQaMyNvluNuVGjUMtiyZTPW0G+ FLUwktoIKM0t8a2Cn8wYYgUoDXCj/EpBOfIldw8pKCwOOu543a8IcRaKkmLMRs+2twncNrCL tDgXgJ7A2ZdQ5bJEUo4Sz8T+e1kVMif3F8V/neesQ5482tJsgAE25gKv73YTQ82N7hc8qLYZ PVb9tF4rxZny2iloMjGqVT5wtQbKdgeX6w2WSQe4b+TR37voGylVsA98yJZMz0JN/SPWjEYO NC2KHD9jPj2m89IHWfumtdi+MU42HDA= --B_3421047241_12156-- From charliep@computer.org Tue May 29 15:11:40 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2CD11E8074 for ; Tue, 29 May 2012 15:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NLmFnO0RQbh for ; Tue, 29 May 2012 15:11:37 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id AA29021F8618 for ; Tue, 29 May 2012 15:11:37 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.255.187]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1SZUdc-0004XT-UU; Tue, 29 May 2012 18:11:37 -0400 Message-ID: <4FC5498C.8030105@computer.org> Date: Tue, 29 May 2012 15:11:24 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8649c1d8f3ed6816a22a7c176e2e9eaba0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Cc: netext@ietf.org Subject: Re: [netext] Consensus call on adopting I-D draft-liebsch-netext-pmip6-qos as WG document X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 22:11:40 -0000 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. On 5/23/2012 12:01 PM, Basavaraj.Patil@nokia.com wrote: > Hello, > > The authors of the I-D: Quality of Service Option for Proxy Mobile IPv6 > > 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 > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > -- Regards, Charlie P. From denghui02@gmail.com Tue May 29 18:52:11 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB2211E815D for ; Tue, 29 May 2012 18:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.853 X-Spam-Level: X-Spam-Status: No, score=-102.853 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpzkHNIKJY6Q for ; Tue, 29 May 2012 18:52:11 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1372B11E80E1 for ; Tue, 29 May 2012 18:52:11 -0700 (PDT) Received: by yenq13 with SMTP id q13so3108519yen.31 for ; Tue, 29 May 2012 18:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8RFfEIX1UIaXsHh1A4U3vTIHjEXChLgGHojpf+eaJGM=; b=EcWd8rX/4YwE/IB0BWmPfUypY4xKdILS5/iAKiezeNYeVPYsOL/DrUfnQgDHydWJTh KtoM9IL0y7u57Xglh8pIlrX9OjjWynimG7fTQ2QJh6yCCjveYbymHk2GYmpAmvXvPd+3 Y0vHqckad+nU5na2Kf/zFbmmMyspxDAipxHOA4qFRlQybROPuy5Eh8JKDYwZR9mzt3XK SfmGN/ndmxqyL9S/P0wmRzBFs02CvFtQGTza1A12bAODH7KqqolrSAtaTZ1g+TPv6bch /i8ZbnAYESx6aZ5OYeFJc+SWWsykO/FErdc1XuEGLraAAWRc8UAZqYOsgF7bLgFLe8Q1 0ckg== MIME-Version: 1.0 Received: by 10.101.134.19 with SMTP id l19mr4215104ann.57.1338342730615; Tue, 29 May 2012 18:52:10 -0700 (PDT) Received: by 10.147.88.1 with HTTP; Tue, 29 May 2012 18:52:10 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 May 2012 09:52:10 +0800 Message-ID: From: Hui Deng To: Basavaraj.Patil@nokia.com Content-Type: multipart/alternative; boundary=001636c92aa00bcc5804c137330b Cc: netext@ietf.org Subject: Re: [netext] Consensus call on adopting I-D draft-liebsch-netext-pmip6-qos as WG document X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 01:52:12 -0000 --001636c92aa00bcc5804c137330b Content-Type: text/plain; charset=ISO-8859-1 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 > > Hello, > > The authors of the I-D: Quality of Service Option for Proxy Mobile IPv6 > > 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: > > > Thank you. > -Chairs > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > --001636c92aa00bcc5804c137330b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello
=A0
I have seen this draft=A0updated by differentiating necessary QoS attr= ibutes and Relevant QoS Attributes=A0.
This is a good revision, thanks for update.
Should the Netext WG adopt this I-D as a WG document?

Yes =A0 [= X]
No =A0 =A0[ =A0]

Best,
=A0
-Hui
=A0
2012/5/24 <Basavaraj.Patil@nokia.com>

Hello,

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

have requested the adoption of this I-D as a WG document.
T= he 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 sig= naling to enable support
for QoS.

Abstract

=A0 This specif= ication defines a new mobility option that can be used by
=A0 the mobili= ty entities in the Proxy Mobile IPv6 domain to exchange
=A0 Quality of Service parameters associated with a subscriber's IP
= =A0 flows. =A0Using the QoS option, the local mobility anchor and the
= =A0 mobile access gateway can exchange available QoS attributes and
=A0 = associated values. =A0This enables QoS policing and labeling of packets
=A0 to enforce QoS differentiation on the path between the local mobility=A0 anchor and the mobile access gateway. =A0Furthermore, making QoS
= =A0 parameters available on the MAG enables mapping these parameters to
= =A0 QoS rules being specific to the access technology which operates
=A0 below the mobile access gateway. =A0After such mapping, QoS rules can=A0 be enforced on the access technology components, such as an IEEE
= =A0 802.11e Wireless LAN controller.


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


Thank you.
-Chairs

= _______________________________________________
netext mailing list
<= a href=3D"mailto:netext@ietf.org">netext@ietf.org
https://www.ietf.o= rg/mailman/listinfo/netext

--001636c92aa00bcc5804c137330b-- From zhou.xingyue@zte.com.cn Tue May 29 20:29:50 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F17021F8686; Tue, 29 May 2012 20:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.79 X-Spam-Level: X-Spam-Status: No, score=-92.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtCpPt5C9gH7; Tue, 29 May 2012 20:29:48 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id D093421F8644; Tue, 29 May 2012 20:29:47 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 286203502467742; Wed, 30 May 2012 11:29:42 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 52926.3502467742; Wed, 30 May 2012 11:29:42 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q4U3TZJo098186; Wed, 30 May 2012 11:29:35 +0800 (GMT-8) (envelope-from zhou.xingyue@zte.com.cn) In-Reply-To: To: netext@ietf.org, netext-bounces@ietf.org MIME-Version: 1.0 X-KeepSent: B3602C2C:EBC3C3C1-48257A0E:001299C9; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.xingyue@zte.com.cn Date: Wed, 30 May 2012 11:29:11 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-05-30 11:29:36, Serialize complete at 2012-05-30 11:29:36 Content-Type: multipart/alternative; boundary="=_alternative 001327DC48257A0E_=" X-MAIL: mse02.zte.com.cn q4U3TZJo098186 Subject: [netext] =?gb2312?b?tPC4tDogIENvbnNlbnN1cyBjYWxsIG9uIGFkb3B0aW5n?= =?gb2312?b?IEktRCBkcmFmdC1saWVic2NoLW5ldGV4dC1wbWlwNi1xb3MgYXMgV0cgZG9j?= =?gb2312?b?dW1lbnQ=?= X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 03:29:50 -0000 This is a multipart message in MIME format. --=_alternative 001327DC48257A0E_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpBZnRlciByZWFkaW5nIHRocm91Z2ggdGhpcyB2ZXJzaW9uIG9mIGRyYWZ0LCBJ IGJlbGlldmUgaXQgcHJvdmlkZXMgYSANCmZsZXhpYmxlIHdheSB0byBQTUlQdjYgaW4gUW9TIHJl bGF0ZWQgbmV0d29yayBhcmNoaXRlY3R1cmUuIEkgc3VwcG9ydCB0aGlzIA0KZHJhZnQgYWRvcHRl ZCBhcyBhIFdHIGRyYWZ0Lg0KDQpTaG91bGQgdGhlIE5ldGV4dCBXRyBhZG9wdCB0aGlzIEktRCBh cyBhIFdHIGRvY3VtZW50Pw0KDQpZZXMgICBbIFggXQ0KTm8gICAgWyAgXQ0KDQpCZXN0IFJlZ2Fy ZHMsDQpKb3kgWmhvdQ0KDQoNCg0KDQo8QmFzYXZhcmFqLlBhdGlsQG5va2lhLmNvbT4gDQq3orz+ yMs6ICBuZXRleHQtYm91bmNlc0BpZXRmLm9yZw0KMjAxMi0wNS0yNCAwMzowMQ0KDQrK1bz+yMsN CjxuZXRleHRAaWV0Zi5vcmc+DQqzrcvNDQoNCtb3zOINCltuZXRleHRdIENvbnNlbnN1cyBjYWxs IG9uIGFkb3B0aW5nIEktRCBkcmFmdC1saWVic2NoLW5ldGV4dC1wbWlwNi1xb3MgYXMgDQpXRyBk b2N1bWVudA0KDQoNCg0KDQoNCg0KDQpIZWxsbywNCg0KVGhlIGF1dGhvcnMgb2YgdGhlIEktRDog UXVhbGl0eSBvZiBTZXJ2aWNlIE9wdGlvbiBmb3IgUHJveHkgTW9iaWxlIElQdjYNCjxkcmFmdC1s aWVic2NoLW5ldGV4dC1wbWlwNi1xb3M+DQpodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWxp ZWJzY2gtbmV0ZXh0LXBtaXA2LXFvcy0wMS50eHQNCg0KaGF2ZSByZXF1ZXN0ZWQgdGhlIGFkb3B0 aW9uIG9mIHRoaXMgSS1EIGFzIGEgV0cgZG9jdW1lbnQuDQpUaGUgSS1EIGl0c2VsZiBoYXMgYmVl biBwcmVzZW50ZWQgYXQgSUVURjgzIGFuZCBoYXMgYWxzbyBiZWVuIHJldmlld2VkIGJ5DQptdWx0 aXBsZSBXRyBtZW1iZXJzLg0KDQpUaGUgY3J1eCBvZiB0aGUgcHJvcG9zYWwgaXMgdG8gZXh0ZW5k IFBNSVA2IHNpZ25hbGluZyB0byBlbmFibGUgc3VwcG9ydA0KZm9yIFFvUy4NCg0KQWJzdHJhY3QN Cg0KICAgVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgYSBuZXcgbW9iaWxpdHkgb3B0aW9uIHRo YXQgY2FuIGJlIHVzZWQgYnkNCiAgIHRoZSBtb2JpbGl0eSBlbnRpdGllcyBpbiB0aGUgUHJveHkg TW9iaWxlIElQdjYgZG9tYWluIHRvIGV4Y2hhbmdlDQogICBRdWFsaXR5IG9mIFNlcnZpY2UgcGFy YW1ldGVycyBhc3NvY2lhdGVkIHdpdGggYSBzdWJzY3JpYmVyJ3MgSVANCiAgIGZsb3dzLiAgVXNp bmcgdGhlIFFvUyBvcHRpb24sIHRoZSBsb2NhbCBtb2JpbGl0eSBhbmNob3IgYW5kIHRoZQ0KICAg bW9iaWxlIGFjY2VzcyBnYXRld2F5IGNhbiBleGNoYW5nZSBhdmFpbGFibGUgUW9TIGF0dHJpYnV0 ZXMgYW5kDQogICBhc3NvY2lhdGVkIHZhbHVlcy4gIFRoaXMgZW5hYmxlcyBRb1MgcG9saWNpbmcg YW5kIGxhYmVsaW5nIG9mIHBhY2tldHMNCiAgIHRvIGVuZm9yY2UgUW9TIGRpZmZlcmVudGlhdGlv biBvbiB0aGUgcGF0aCBiZXR3ZWVuIHRoZSBsb2NhbCBtb2JpbGl0eQ0KICAgYW5jaG9yIGFuZCB0 aGUgbW9iaWxlIGFjY2VzcyBnYXRld2F5LiAgRnVydGhlcm1vcmUsIG1ha2luZyBRb1MNCiAgIHBh cmFtZXRlcnMgYXZhaWxhYmxlIG9uIHRoZSBNQUcgZW5hYmxlcyBtYXBwaW5nIHRoZXNlIHBhcmFt ZXRlcnMgdG8NCiAgIFFvUyBydWxlcyBiZWluZyBzcGVjaWZpYyB0byB0aGUgYWNjZXNzIHRlY2hu b2xvZ3kgd2hpY2ggb3BlcmF0ZXMNCiAgIGJlbG93IHRoZSBtb2JpbGUgYWNjZXNzIGdhdGV3YXku ICBBZnRlciBzdWNoIG1hcHBpbmcsIFFvUyBydWxlcyBjYW4NCiAgIGJlIGVuZm9yY2VkIG9uIHRo ZSBhY2Nlc3MgdGVjaG5vbG9neSBjb21wb25lbnRzLCBzdWNoIGFzIGFuIElFRUUNCiAgIDgwMi4x MWUgV2lyZWxlc3MgTEFOIGNvbnRyb2xsZXIuDQoNCg0KUGxlYXNlIHJldmlldyB0aGUgSS1EIGFu ZCByZXNwb25kIGJ5IEp1bmUgNnRoIHdpdGggeW91ciBvcGluaW9uLg0KUmVzcG9uZCB0byB0aGUg Zm9sbG93aW5nIHF1ZXN0aW9uOg0KDQpTaG91bGQgdGhlIE5ldGV4dCBXRyBhZG9wdCB0aGlzIEkt RCBhcyBhIFdHIGRvY3VtZW50Pw0KDQpZZXMgICBbICBdDQpObyAgICBbICBdDQoNClRoYW5rIHlv dS4NCi1DaGFpcnMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCm5ldGV4dCBtYWlsaW5nIGxpc3QNCm5ldGV4dEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRleHQNCg0KDQoNCg== --=_alternative 001327DC48257A0E_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIGFsbCw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFmdGVyIHJlYWRpbmcgdGhyb3Vn aCB0aGlzIHZlcnNpb24gb2YNCmRyYWZ0LCBJIGJlbGlldmUgaXQgcHJvdmlkZXMgYSBmbGV4aWJs ZSB3YXkgdG8gUE1JUHY2IGluIFFvUyByZWxhdGVkIG5ldHdvcmsNCmFyY2hpdGVjdHVyZS4gSSBz dXBwb3J0IHRoaXMgZHJhZnQgYWRvcHRlZCBhcyBhIFdHIGRyYWZ0LjwvZm9udD4NCjxicj4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPlNob3VsZCB0aGUgTmV0ZXh0IFdHIGFkb3B0IHRoaXMgSS1EIGFz IGEgV0cgZG9jdW1lbnQ/PGJyPg0KPGJyPg0KWWVzICZuYnNwOyBbIFggXTxicj4NCk5vICZuYnNw OyAmbmJzcDtbICZuYnNwO108L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PkJlc3QgUmVnYXJkcyw8L2ZvbnQ+PC90dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+Sm95IFpob3U8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lk dGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+PGI+Jmx0O0Jhc2F2YXJhai5QYXRpbEBub2tpYS5jb20mZ3Q7PC9iPg0K PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNw O25ldGV4dC1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPjIwMTItMDUtMjQgMDM6MDE8L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxl IHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Jmx0O25ldGV4dEBpZXRmLm9yZyZndDs8L2ZvbnQ+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3 zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPltuZXRl eHRdIENvbnNlbnN1cyBjYWxsIG9uIGFkb3B0aW5nDQpJLUQgZHJhZnQtbGllYnNjaC1uZXRleHQt cG1pcDYtcW9zIGFzIFdHIGRvY3VtZW50PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8 YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj48YnI+DQpIZWxsbyw8YnI+DQo8YnI+DQpUaGUgYXV0 aG9ycyBvZiB0aGUgSS1EOiBRdWFsaXR5IG9mIFNlcnZpY2UgT3B0aW9uIGZvciBQcm94eSBNb2Jp bGUgSVB2Njxicj4NCiZsdDtkcmFmdC1saWVic2NoLW5ldGV4dC1wbWlwNi1xb3MmZ3Q7PGJyPg0K aHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1saWVic2NoLW5ldGV4dC1wbWlwNi1xb3MtMDEu dHh0PGJyPg0KPGJyPg0KaGF2ZSByZXF1ZXN0ZWQgdGhlIGFkb3B0aW9uIG9mIHRoaXMgSS1EIGFz IGEgV0cgZG9jdW1lbnQuPGJyPg0KVGhlIEktRCBpdHNlbGYgaGFzIGJlZW4gcHJlc2VudGVkIGF0 IElFVEY4MyBhbmQgaGFzIGFsc28gYmVlbiByZXZpZXdlZA0KYnk8YnI+DQptdWx0aXBsZSBXRyBt ZW1iZXJzLjxicj4NCjxicj4NClRoZSBjcnV4IG9mIHRoZSBwcm9wb3NhbCBpcyB0byBleHRlbmQg UE1JUDYgc2lnbmFsaW5nIHRvIGVuYWJsZSBzdXBwb3J0PGJyPg0KZm9yIFFvUy48YnI+DQo8YnI+ DQpBYnN0cmFjdDxicj4NCjxicj4NCiAmbmJzcDsgVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMg YSBuZXcgbW9iaWxpdHkgb3B0aW9uIHRoYXQgY2FuIGJlIHVzZWQNCmJ5PGJyPg0KICZuYnNwOyB0 aGUgbW9iaWxpdHkgZW50aXRpZXMgaW4gdGhlIFByb3h5IE1vYmlsZSBJUHY2IGRvbWFpbiB0byBl eGNoYW5nZTxicj4NCiAmbmJzcDsgUXVhbGl0eSBvZiBTZXJ2aWNlIHBhcmFtZXRlcnMgYXNzb2Np YXRlZCB3aXRoIGEgc3Vic2NyaWJlcidzIElQPGJyPg0KICZuYnNwOyBmbG93cy4gJm5ic3A7VXNp bmcgdGhlIFFvUyBvcHRpb24sIHRoZSBsb2NhbCBtb2JpbGl0eSBhbmNob3IgYW5kDQp0aGU8YnI+ DQogJm5ic3A7IG1vYmlsZSBhY2Nlc3MgZ2F0ZXdheSBjYW4gZXhjaGFuZ2UgYXZhaWxhYmxlIFFv UyBhdHRyaWJ1dGVzIGFuZDxicj4NCiAmbmJzcDsgYXNzb2NpYXRlZCB2YWx1ZXMuICZuYnNwO1Ro aXMgZW5hYmxlcyBRb1MgcG9saWNpbmcgYW5kIGxhYmVsaW5nDQpvZiBwYWNrZXRzPGJyPg0KICZu YnNwOyB0byBlbmZvcmNlIFFvUyBkaWZmZXJlbnRpYXRpb24gb24gdGhlIHBhdGggYmV0d2VlbiB0 aGUgbG9jYWwgbW9iaWxpdHk8YnI+DQogJm5ic3A7IGFuY2hvciBhbmQgdGhlIG1vYmlsZSBhY2Nl c3MgZ2F0ZXdheS4gJm5ic3A7RnVydGhlcm1vcmUsIG1ha2luZw0KUW9TPGJyPg0KICZuYnNwOyBw YXJhbWV0ZXJzIGF2YWlsYWJsZSBvbiB0aGUgTUFHIGVuYWJsZXMgbWFwcGluZyB0aGVzZSBwYXJh bWV0ZXJzDQp0bzxicj4NCiAmbmJzcDsgUW9TIHJ1bGVzIGJlaW5nIHNwZWNpZmljIHRvIHRoZSBh Y2Nlc3MgdGVjaG5vbG9neSB3aGljaCBvcGVyYXRlczxicj4NCiAmbmJzcDsgYmVsb3cgdGhlIG1v YmlsZSBhY2Nlc3MgZ2F0ZXdheS4gJm5ic3A7QWZ0ZXIgc3VjaCBtYXBwaW5nLCBRb1MNCnJ1bGVz IGNhbjxicj4NCiAmbmJzcDsgYmUgZW5mb3JjZWQgb24gdGhlIGFjY2VzcyB0ZWNobm9sb2d5IGNv bXBvbmVudHMsIHN1Y2ggYXMgYW4gSUVFRTxicj4NCiAmbmJzcDsgODAyLjExZSBXaXJlbGVzcyBM QU4gY29udHJvbGxlci48YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2UgcmV2aWV3IHRoZSBJLUQgYW5k IHJlc3BvbmQgYnkgSnVuZSA2dGggd2l0aCB5b3VyIG9waW5pb24uPGJyPg0KUmVzcG9uZCB0byB0 aGUgZm9sbG93aW5nIHF1ZXN0aW9uOjxicj4NCjxicj4NClNob3VsZCB0aGUgTmV0ZXh0IFdHIGFk b3B0IHRoaXMgSS1EIGFzIGEgV0cgZG9jdW1lbnQ/PGJyPg0KPGJyPg0KWWVzICZuYnNwOyBbICZu YnNwO108YnI+DQpObyAmbmJzcDsgJm5ic3A7WyAmbmJzcDtdPGJyPg0KPGJyPg0KVGhhbmsgeW91 Ljxicj4NCi1DaGFpcnM8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCm5ldGV4dCBtYWlsaW5nIGxpc3Q8YnI+DQpuZXRleHRAaWV0 Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGV4dDxi cj4NCjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0K --=_alternative 001327DC48257A0E_=-- From Dirk.von-Hugo@telekom.de Wed May 30 01:31:44 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E6C21F86A7 for ; Wed, 30 May 2012 01:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7fwmBsEn9FC for ; Wed, 30 May 2012 01:31:43 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 11A6321F85C4 for ; Wed, 30 May 2012 01:31:38 -0700 (PDT) Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 30 May 2012 10:31:36 +0200 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE113472.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 30 May 2012 10:31:35 +0200 From: To: , Date: Wed, 30 May 2012 10:31:34 +0200 Thread-Topic: [netext] Consensus call on adopting I-D draft-liebsch-netext-pmip6-qos as WG document Thread-Index: AQHNORaDzXXBLSQQaEiNUGHX4GFi75biA0sw Message-ID: <05C81A773E48DD49B181B04BA21A342A27A427E608@HE113484.emea1.cds.t-internal.com> References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netext] Consensus call on adopting I-D draft-liebsch-netext-pmip6-qos as WG document X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 08:31:44 -0000 Hi all, chairs and authors, Should the Netext WG adopt this I-D as a WG document? 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 dur= ing 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 c= ontrol (and between different LMAs) is not within scope, right? Some nits I detected ... On p.10: , which is is a =3D> , which is a (i.e. pBA). =3D> (i.e. PBA). (assuming it is Proxy Binding Acknowledgement) On p.20: Priority-Level: is of type unsigned 32 bit integer, and it used =3D> Priori= ty-Level: is of type unsigned 32 bit integer, and is used Thanks and best regards! Dirk -----Urspr=FCngliche Nachricht----- Von: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] Im Auftrag vo= n Basavaraj.Patil@nokia.com Gesendet: Mittwoch, 23. Mai 2012 21:02 An: netext@ietf.org Betreff: [netext] Consensus call on adopting I-D draft-liebsch-netext-pmip6= -qos as WG document Hello, The authors of the I-D: Quality of Service Option for Proxy Mobile IPv6 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 _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From Marco.Liebsch@neclab.eu Wed May 30 05:38:53 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B9021F85A1 for ; Wed, 30 May 2012 05:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfPWiXQJEWUZ for ; Wed, 30 May 2012 05:38:51 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7B07721F8573 for ; Wed, 30 May 2012 05:38:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 0CA34100086; Wed, 30 May 2012 14:38:51 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebfVCDwkjdWd; Wed, 30 May 2012 14:38:50 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id DAE0410006D; Wed, 30 May 2012 14:38:35 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.172]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Wed, 30 May 2012 14:38:33 +0200 From: Marco Liebsch To: "Charles E. Perkins" , "Basavaraj.Patil@nokia.com" Thread-Topic: [netext] Consensus call on adopting I-D draft-liebsch-netext-pmip6-qos as WG document Thread-Index: AQHNORaDzXXBLSQQaEiNUGHX4GFi75bhPEQAgADmrwA= Date: Wed, 30 May 2012 12:38:31 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D24DEA88D@Polydeuces.office.hd> References: <4FC5498C.8030105@computer.org> In-Reply-To: <4FC5498C.8030105@computer.org> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" Subject: Re: [netext] Consensus call on adopting I-D draft-liebsch-netext-pmip6-qos as WG document X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 12:38:53 -0000 Hi Charlie, thanks for your feedback and please see inline for my view on your comments= . >-----Original Message----- >From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf >Of Charles E. Perkins >Sent: Mittwoch, 30. Mai 2012 00:11 >To: Basavaraj.Patil@nokia.com >Cc: netext@ietf.org >Subject: Re: [netext] Consensus call on adopting I-D draft-liebsch-netext- >pmip6-qos as WG document > > >Hello folks, > >I read the document. I think it would be worthwhile to accept as a workin= g >group document. > >Yes [ X ] >No [ ] > > >I have some comments below. > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >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 jus= t >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 attri= butes. So, I see advantage in also providing options that carry QoS attributes whi= ch are intrinsically bound to the QCI, such as for latency requirements and possib= ly packet error rate. > >Editorial comments: > >"supports enforcement of solely" --> > "only supports enforcement of" > also, citation needed here. > >"is considered in" --> "is deployed in" Ok > >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? Yes, but possibly using a different protocol. > >"The following QoS parameters are good to negotiate" ... > This is a very ambiguous formulation Agree. We'll find something better. > >"Specifically, the following parameters" ... > the three items should be in an > indented list (perhaps numbered) Ok. > >Sentence starting "Upon accepting a Proxy Binding"... > 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.=20 [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 Anc= hor SHOULD validate the received QoS parameters and, where appropriate, adjust = the QoS parameters and send the approved QoS parameters back to the Mobile Acce= ss Gateway with the Proxy Binding Acknowledgement using the QoS option. > >"is as specified" --> "are as specified" > --> BUT: some parameters are NOT > "per session", so the sentence > contradicts earlier text. Ok, we'll revise and make it consistent. > >"for using it in" --> "for use with" Ok. > >"TS Format": What are the values of the other > 254 values? If undefined, what is the intention > for defining future values? I don't think that field is interpreted in the same way as the TS Format fi= eld 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 o= nly 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 th= e Option header but need to describe that other values are for future use (and FFS).=20 > >"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. > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D True, the ARP is more related to 3GPP utilizing the bearer concepts.=20 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 > >Regards, >Charlie P. > > >On 5/23/2012 12:01 PM, Basavaraj.Patil@nokia.com wrote: >> Hello, >> >> The authors of the I-D: Quality of Service Option for Proxy Mobile >> IPv6 >> 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 packet= s >> to enforce QoS differentiation on the path between the local mobilit= y >> 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 >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> >> > > >-- >Regards, >Charlie P. > >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext From mgrayson@cisco.com Wed May 30 05:42:33 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00C621F8650 for ; Wed, 30 May 2012 05:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfJ7x530Pwa5 for ; Wed, 30 May 2012 05:42:32 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 5708D21F85CC for ; Wed, 30 May 2012 05:42:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mgrayson@cisco.com; l=1983; q=dns/txt; s=iport; t=1338381752; x=1339591352; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=FDzJ2QBmpayaQQeQueQlrOJyKhaDJcTAlAs+cTxoeec=; b=kjCpPILfIIMScO8RYUVDeOmUBF/yv9cpnfSQUaIXg1eCVucqj4akqfjs b2hcjOGNplOXJNLxiK5bgWAfWRTjl7aGN8+pntjVdbMprsDI6gxmBm5oc HcmC4GD7LXCxJV83tgHiYAnTMll716nMOt7Jv90OlbjPuXpBYbgNKXUSo E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFYVxk+Q/khM/2dsb2JhbABEtA2BB4IXAQEBBAEBAQ8BHQo0FwQCAQgiBhgGASYwAgQBEggBGYdpC5kWoBSPZ2ADoyWBZoJi X-IronPort-AV: E=Sophos;i="4.75,683,1330905600"; d="scan'208";a="5152146" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 30 May 2012 12:42:31 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q4UCgVvZ014477; Wed, 30 May 2012 12:42:31 GMT Received: from xmb-ams-110.cisco.com ([144.254.74.85]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 May 2012 14:42:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 May 2012 14:42:19 +0200 Message-ID: <511106E94A591D468E6EF41F5F1DCA43071A6660@XMB-AMS-110.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call on adopting I-D draft-liebsch-netext-pmip6-qos as WG document Thread-Index: AQHNPOG4YXdey+NWpkKF2NFy+6+yBpbiSMVA References: From: "Mark Grayson (mgrayson)" To: , X-OriginalArrivalTime: 30 May 2012 12:42:30.0991 (UTC) FILETIME=[ADA935F0:01CD3E61] Subject: Re: [netext] Consensus call on adopting I-D draft-liebsch-netext-pmip6-qos as WG document X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 12:42:34 -0000 Being able to send QoS information on-path is useful for certain PMIPv6 deployments and therefore I support adoption as WG document Mark -----Original Message----- On 5/23/12 3:01 PM, "Basavaraj.Patil@nokia.com" wrote: > >Hello, > >The authors of the I-D: Quality of Service Option for Proxy Mobile IPv6 >=20 >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=20 >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 > >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext From Marco.Liebsch@neclab.eu Wed May 30 05:43:56 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3230921F8650 for ; Wed, 30 May 2012 05:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKSNiDZpaF4h for ; Wed, 30 May 2012 05:43:55 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1D09A21F85CC for ; Wed, 30 May 2012 05:43:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 2B17B100086; Wed, 30 May 2012 14:43:57 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83PfPINC-ByG; Wed, 30 May 2012 14:43:57 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 0C65A10006D; Wed, 30 May 2012 14:43:42 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.172]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Wed, 30 May 2012 14:43:18 +0200 From: Marco Liebsch To: "Dirk.von-Hugo@telekom.de" , "Basavaraj.Patil@nokia.com" , "netext@ietf.org" Thread-Topic: [netext] Consensus call on adopting I-D draft-liebsch-netext-pmip6-qos as WG document Thread-Index: AQHNORaDzXXBLSQQaEiNUGHX4GFi75biA0swgABN12A= Date: Wed, 30 May 2012 12:43:17 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D24DEA8AE@Polydeuces.office.hd> References: <05C81A773E48DD49B181B04BA21A342A27A427E608@HE113484.emea1.cds.t-internal.com> In-Reply-To: <05C81A773E48DD49B181B04BA21A342A27A427E608@HE113484.emea1.cds.t-internal.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netext] Consensus call on adopting I-D draft-liebsch-netext-pmip6-qos as WG document X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 12:43:56 -0000 Hi Dirk, thanks for spotting the nits, we'll take them into account in the next revi= sion. marco >-----Original Message----- >From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf >Of Dirk.von-Hugo@telekom.de >Sent: Mittwoch, 30. Mai 2012 10:32 >To: Basavaraj.Patil@nokia.com; netext@ietf.org >Subject: Re: [netext] Consensus call on adopting I-D draft-liebsch-netext- >pmip6-qos as WG document > >Hi all, chairs and authors, > >Should the Netext WG adopt this I-D as a WG document? > >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 =3D> , which is a >(i.e. pBA). =3D> (i.e. PBA). (assuming it is Proxy Binding Acknowledgement= ) On >p.20: >Priority-Level: is of type unsigned 32 bit integer, and it used =3D> Prior= ity-Level: >is of type unsigned 32 bit integer, and is used > >Thanks and best regards! >Dirk > >-----Urspr=FCngliche Nachricht----- >Von: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] Im Auftrag >von Basavaraj.Patil@nokia.com >Gesendet: Mittwoch, 23. Mai 2012 21:02 >An: netext@ietf.org >Betreff: [netext] Consensus call on adopting I-D draft-liebsch-netext-pmip= 6- >qos as WG document > > >Hello, > >The authors of the I-D: Quality of Service Option for Proxy Mobile IPv6 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 fo= r >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 > >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext From carlw@mcsr-labs.org Wed May 30 06:50:57 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422E321F85CE for ; Wed, 30 May 2012 06:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwfEAnooqgDz for ; Wed, 30 May 2012 06:50:56 -0700 (PDT) Received: from mail149c38.carrierzone.com (mail149c38.carrierzone.com [66.175.56.179]) by ietfa.amsl.com (Postfix) with ESMTP id 0E92021F85C7 for ; Wed, 30 May 2012 06:50:53 -0700 (PDT) X-Authenticated-User: carlw.mcsr-labs.org Received: from [65.97.0.218] ([65.97.0.218]) (authenticated bits=0) by mail149c38.carrierzone.com (8.13.6/8.13.1) with ESMTP id q4UDog8U015859; Wed, 30 May 2012 13:50:46 +0000 User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Wed, 30 May 2012 09:50:32 -0400 From: Carl Williams To: , Message-ID: Thread-Topic: [netext] Consensus call on adopting I-D draft-liebsch-netext-pmip6-qos as WG document In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-CSC: 0 X-CHA: v=1.1 cv=mwlFAaDA+ikO7kMzgKjtEAO1h4y7OmPpnUzlklLDj+M= c=1 sm=1 a=W-hxRJO8TvsA:10 a=YO5yXtn_fj0A:10 a=Gzqcop6RMF0A:10 a=kj9zAlcOel0A:10 a=omW0zo2dLPRlZWyMxoOMzg==:17 a=9qxNCY_qAAAA:8 a=r7pn9qH2i6Sw7kM8xKgA:9 a=CjuIK1q_8ugA:10 a=1pxjJC3EenQA:10 a=omW0zo2dLPRlZWyMxoOMzg==:117 X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A010202.4FC625BB.000D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Subject: Re: [netext] Consensus call on adopting I-D draft-liebsch-netext-pmip6-qos as WG document X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 13:50:57 -0000 I support the adoption of this I-D as a WG document. 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 [X] No [ ] On 5/23/12 3:01 PM, "Basavaraj.Patil@nokia.com" wrote: > >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 [ ] >