From nobody Tue Jun 10 09:10:32 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7BF31A019B; Tue, 10 Jun 2014 09:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7DfIpmgAiyg; Tue, 10 Jun 2014 09:10:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0C91A01CB; Tue, 10 Jun 2014 09:10:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140610161027.20562.23037.idtracker@ietfa.amsl.com> Date: Tue, 10 Jun 2014 09:10:27 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/iRP_CIUxULkExYC6smYb8FestYI Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-08.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2014 16:10:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : EAP Attributes for WiFi - EPC Integration Authors : Ravi Valmikam Rajeev Koodli Filename : draft-ietf-netext-wifi-epc-eap-attributes-08.txt Pages : 15 Date : 2014-06-10 Abstract: With WiFi emerging as a trusted access network for service providers, it has become important to provide functions commonly available in 3G and 4G networks in WiFi access networks as well. Such functions include Access Point Name (APN) Selection, multiple Packet Data Network (PDN) connections and seamless mobility between WiFi and 3G/4G networks. The EAP/AKA (and EAP/AKA') protocol is required for mobile devices to access the mobile Evolved Packet Core (EPC) via trusted WiFi networks. This document defines a few new EAP attributes to enable the above-mentioned functions in trusted WiFi access networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-wifi-epc-eap-attributes/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-wifi-epc-eap-attributes-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-wifi-epc-eap-attributes-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 10 09:20:09 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10EFC1B2829 for ; Tue, 10 Jun 2014 09:19:57 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCc84Bffh86v for ; Tue, 10 Jun 2014 09:19:53 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B24931B280E for ; Tue, 10 Jun 2014 09:19:52 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z12so4008506wgg.1 for ; Tue, 10 Jun 2014 09:19:51 -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=UnWyXcWv7keFb1iI/OREUX197acfkd89ubo0gk2QZBw=; b=Qt01iWwNGemFID6+i/cjKj4oqWviz52Vng+GYGcEtuwvMdwQHQXkbLeo8oFK8EgB1m uAk3wl8upr8TcmGafw1UqvdnrFso7cGFr5bAFPvBqHd5rQGPaLmYKpCBq92KUusKOneU u+AwK+MdcSDKzFNG6d/WHiWPNPBm4okgjPPssSsSu744SKWPUxAkX+ilqr/8JRdiw1aU 8ppGgv7WY8lS6nEN8mi8MzZgX0Tbi4VfKfbEl2gQA2iKvnM5pG/SMebA2zpQjrGELHlE djmlCOO05k5MIN4sGFzX7hFuWsV2OxcT/TEv4IgQuBxjKe2sOt1TzuWfeENAJKnWF1Fq hZOQ== MIME-Version: 1.0 X-Received: by 10.180.105.72 with SMTP id gk8mr39314148wib.32.1402417190923; Tue, 10 Jun 2014 09:19:50 -0700 (PDT) Received: by 10.195.11.132 with HTTP; Tue, 10 Jun 2014 09:19:50 -0700 (PDT) In-Reply-To: <536BB1A7.80205@innovationslab.net> References: <536A5721.8000100@innovationslab.net> <536B91F2.3080607@innovationslab.net> <536BB1A7.80205@innovationslab.net> Date: Tue, 10 Jun 2014 09:19:50 -0700 Message-ID: From: Rajeev Koodli To: Brian Haberman Content-Type: multipart/alternative; boundary=f46d0442685a7e072304fb7db2e2 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/7tXLsmkcsHyIn3c_bWQZcvM5DlY Cc: "Koodli, Rajeev" , Basavaraj Patil , "draft-ietf-netext-wifi-epc-eap-attributes@tools.ietf.org" , "netext@ietf.org" Subject: Re: [netext] AD Evaluation: draft-ietf-netext-wifi-epc-eap-attributes X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2014 16:19:57 -0000 --f46d0442685a7e072304fb7db2e2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Brian, we have submitted a new version reflecting the comments/conversation. http://www.ietf.org/internet-drafts/draft-ietf-netext-wifi-epc-eap-attribut= es-08.txt I have revised the draft based on what we agreed on. - introduced a new registry for various sub-types - expanded security considerations - clarified multiple issues - fixed ID nits I have left the AT_HANDOVER_SESSION_ID as is, since combining it with HANDOVER_INDICATION introduces clumsy header logic. Please have a look. Thanks. -Rajeev On Thu, May 8, 2014 at 9:32 AM, Brian Haberman wrote: > Hi Rajeev, > > On 5/8/14 12:28 PM, Rajeev Koodli wrote: > > Hi Brian, > > > > > > On Thu, May 8, 2014 at 7:17 AM, Brian Haberman >wrote: > > > >>> The encoding would follow 3GPP TS 23.003 as do the attributes in RFC > >> 4187. > >>> Will mention this. > >>> > >> > >> I see a single reference to ASCII encoding for the username string in > >> 4187. Is ASCII encoding assumed here as well? > >> > >> > > Rajeev> Yes, and I would refer to 3GPP TS 23.003 (as 4187 does). > > > > > > That works. > > > >>>> > >>>> 14. The Security Considerations section tells me nothing. Are there > new > >>>> threats with these new pieces of information flowing across the > network? > >>>> What are the privacy implications of these messages? Can any of the > >>>> possible threat vectors be minimized? > >>> > >>> We are basically following RFC 4187 here. The relevant part is 12.7 > which > >>> refers to new attribute types: > >>> > >>> > >>> "As described in Section 8, EAP-AKA allows the protocol to be extende= d > >>> by defining new attribute types. When defining such attributes, i= t > >>> should be noted that any extra attributes included in > >>> EAP-Request/AKA-Identity or EAP-Response/AKA-Identity packets are > not > >>> included in the MACs later on, and thus some other precautions must > >>> be taken to avoid modifications to them.=C2=B2 > >>> > >>> > >>> We do not have attributes that fit this requirement ( I=C2=B9ll doubl= e check > >>> again). > >>> In any case, we can refer to this text. > >> > >> The security considerations in 4187 are quite detailed in some > >> instances. I think it would be good to document any potential > >> security/privacy issues that could arise if these new attributes are > >> abused in some way. > >> > >> > > 4187 is extensive because the attributes there have to do with the > EAP-AKA > > mechanism itself. > > > > The attributes here are not related to the EAP-AKA itself, but extensio= ns > > carried along with the EAP-AKA messages. > > > > Let me think about this further. > > Sure. I want to make sure we head off any late issues when the Sec-Dir > review occurs. > > Regards, > Brian > > > --f46d0442685a7e072304fb7db2e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Brian,

we have submit= ted a new version reflecting the comments/conversation.=C2=A0

I have revised the draft based on what we agreed = on.=C2=A0

- introduced a new registry for various = sub-types
- expanded security considerations
- clarifie= d multiple issues
- fixed ID nits
=C2=A0
I have left the AT_HANDOVER= _SESSION_ID as is, since combining it with HANDOVER_INDICATION introduces c= lumsy header logic. =C2=A0

Please have a look.

Thanks.

-Rajeev



On Thu= , May 8, 2014 at 9:32 AM, Brian Haberman <brian@innovationslab.net<= /a>> wrote:
Hi Rajeev,

On 5/8/14 12:28 PM, Rajeev Koodli wrote:
> Hi Brian,
>
>
> On Thu, May 8, 2014 at 7:17 AM, Brian Haberman <brian@innovationslab.net>wrote:
>
>>> The encoding would follow 3GPP TS 23.003 as do the attributes = in RFC
>> 4187.
>>> Will mention this.
>>>
>>
>> I see a single reference to ASCII encoding for the username string= in
>> 4187. =C2=A0Is ASCII encoding assumed here as well?
>>
>>
> Rajeev> Yes, and I would refer to 3GPP TS 23.003 (as 4187 does). >
>

That works.


>>>>
>>>> 14. The Security Considerations section tells me nothing. = =C2=A0Are there new
>>>> threats with these new pieces of information flowing acros= s the network?
>>>> What are the privacy implications of these messages? =C2= =A0Can any of the
>>>> possible threat vectors be minimized?
>>>
>>> We are basically following RFC 4187 here. The relevant part is= 12.7 which
>>> refers to new attribute types:
>>>
>>>
>>> "As described in Section 8, EAP-AKA allows the protocol t= o be extended
>>> =C2=A0 =C2=A0by defining new attribute types. =C2=A0When defin= ing such attributes, it
>>> =C2=A0 =C2=A0should be noted that any extra attributes include= d in
>>> =C2=A0 =C2=A0EAP-Request/AKA-Identity or EAP-Response/AKA-Iden= tity packets are not
>>> included in the MACs later on, and thus some other precautions= must
>>> =C2=A0 =C2=A0be taken to avoid modifications to them.=C2=B2 >>>
>>>
>>> We do not have attributes that fit this requirement ( I=C2=B9l= l double check
>>> again).
>>> In any case, we can refer to this text.
>>
>> The security considerations in 4187 are quite detailed in some
>> instances. =C2=A0I think it would be good to document any potentia= l
>> security/privacy issues that could arise if these new attributes a= re
>> abused in some way.
>>
>>
> 4187 is extensive because the attributes there have to do with the EAP= -AKA
> mechanism itself.
>
> The attributes here are not related to the EAP-AKA itself, but extensi= ons
> carried along with the EAP-AKA messages.
>
> Let me think about this further.

Sure. =C2=A0I want to make sure we head off any late issues when the = Sec-Dir
review occurs.

Regards,
Brian



--f46d0442685a7e072304fb7db2e2-- From nobody Tue Jun 10 10:52:52 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30E21A0239 for ; Tue, 10 Jun 2014 10:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBfNszH0AvKi for ; Tue, 10 Jun 2014 10:52:20 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCBD21A0260 for ; Tue, 10 Jun 2014 10:52:20 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id BD11088119; Tue, 10 Jun 2014 10:52:20 -0700 (PDT) Received: from 102523818.rudm2.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 2D24C71C0002; Tue, 10 Jun 2014 10:52:20 -0700 (PDT) Message-ID: <539745CA.10602@innovationslab.net> Date: Tue, 10 Jun 2014 13:52:10 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Rajeev Koodli References: <536A5721.8000100@innovationslab.net> <536B91F2.3080607@innovationslab.net> <536BB1A7.80205@innovationslab.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9PpTw56hmIO7OvL1cPMMK55fLMFF82OUM" Archived-At: http://mailarchive.ietf.org/arch/msg/netext/N1UTa6M8T2CI3nl-QzN6UF4lGa0 Cc: "Koodli, Rajeev" , Basavaraj Patil , "draft-ietf-netext-wifi-epc-eap-attributes@tools.ietf.org" , "netext@ietf.org" Subject: Re: [netext] AD Evaluation: draft-ietf-netext-wifi-epc-eap-attributes X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2014 17:52:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9PpTw56hmIO7OvL1cPMMK55fLMFF82OUM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Rajeev, The changes look reasonable. I will start IETF Last Call shortly. Regards, Brian On 6/10/14 12:19 PM, Rajeev Koodli wrote: > Hi Brian, >=20 > we have submitted a new version reflecting the comments/conversation. >=20 > http://www.ietf.org/internet-drafts/draft-ietf-netext-wifi-epc-eap-attr= ibutes-08.txt >=20 > I have revised the draft based on what we agreed on. >=20 > - introduced a new registry for various sub-types > - expanded security considerations > - clarified multiple issues > - fixed ID nits >=20 > I have left the AT_HANDOVER_SESSION_ID as is, since combining it with > HANDOVER_INDICATION introduces clumsy header logic. >=20 > Please have a look. >=20 > Thanks. >=20 > -Rajeev >=20 >=20 >=20 > On Thu, May 8, 2014 at 9:32 AM, Brian Haberman > wrote: >=20 >> Hi Rajeev, >> >> On 5/8/14 12:28 PM, Rajeev Koodli wrote: >>> Hi Brian, >>> >>> >>> On Thu, May 8, 2014 at 7:17 AM, Brian Haberman >> wrote: >>> >>>>> The encoding would follow 3GPP TS 23.003 as do the attributes in RF= C >>>> 4187. >>>>> Will mention this. >>>>> >>>> >>>> I see a single reference to ASCII encoding for the username string i= n >>>> 4187. Is ASCII encoding assumed here as well? >>>> >>>> >>> Rajeev> Yes, and I would refer to 3GPP TS 23.003 (as 4187 does). >>> >>> >> >> That works. >> >> >>>>>> >>>>>> 14. The Security Considerations section tells me nothing. Are the= re >> new >>>>>> threats with these new pieces of information flowing across the >> network? >>>>>> What are the privacy implications of these messages? Can any of t= he >>>>>> possible threat vectors be minimized? >>>>> >>>>> We are basically following RFC 4187 here. The relevant part is 12.7= >> which >>>>> refers to new attribute types: >>>>> >>>>> >>>>> "As described in Section 8, EAP-AKA allows the protocol to be exten= ded >>>>> by defining new attribute types. When defining such attributes,= it >>>>> should be noted that any extra attributes included in >>>>> EAP-Request/AKA-Identity or EAP-Response/AKA-Identity packets ar= e >> not >>>>> included in the MACs later on, and thus some other precautions must= >>>>> be taken to avoid modifications to them.=B2 >>>>> >>>>> >>>>> We do not have attributes that fit this requirement ( I=B9ll double= check >>>>> again). >>>>> In any case, we can refer to this text. >>>> >>>> The security considerations in 4187 are quite detailed in some >>>> instances. I think it would be good to document any potential >>>> security/privacy issues that could arise if these new attributes are= >>>> abused in some way. >>>> >>>> >>> 4187 is extensive because the attributes there have to do with the >> EAP-AKA >>> mechanism itself. >>> >>> The attributes here are not related to the EAP-AKA itself, but extens= ions >>> carried along with the EAP-AKA messages. >>> >>> Let me think about this further. >> >> Sure. I want to make sure we head off any late issues when the Sec-Di= r >> review occurs. >> >> Regards, >> Brian >> >> >> >=20 --9PpTw56hmIO7OvL1cPMMK55fLMFF82OUM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTl0XQAAoJEBOZRqCi7goqcuIH+QExQo4yc14iNXaWXTe5uCbV LRAlrNZOMSnbXRwkeua06O1NBrFG2SRh8DCtIa1x3/1/DSoc5h3b3EgKSU38J+zM sYNyBNj2xpyI3ldB3tNNrL90MPQyty6S6ZN8xfi8GCI/i7GXuRIqzblglO4oRLbe QqkM159V2IjwBDQ93QOBysFiHoKT+fD2QQGy5OeKjDAb5MzptZJwazVk2VGb0Lye ki082beLkpEmSOVClAZUE8BsIkU6VkCbaWgWrQJDvRRiGGR1zueNHP9jFeM5O3aC UX3INJkuX3RFATTSOMUDJu246MGuXg/MjYL9zwYF3Hzspuy/kCBboAWMDskEf5o= =7mGa -----END PGP SIGNATURE----- --9PpTw56hmIO7OvL1cPMMK55fLMFF82OUM-- From nobody Tue Jun 10 11:02:59 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8711A0259; Tue, 10 Jun 2014 11:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFBxv-g-w2cD; Tue, 10 Jun 2014 11:02:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA2C1A026E; Tue, 10 Jun 2014 11:02:44 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140610180244.23213.49514.idtracker@ietfa.amsl.com> Date: Tue, 10 Jun 2014 11:02:44 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/bn3u5k2wul-h2wJGqAJl1no4MMg Cc: netext@ietf.org Subject: [netext] Last Call: (EAP Attributes for WiFi - EPC Integration) to Informational RFC X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.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, 10 Jun 2014 18:02:46 -0000 The IESG has received a request from the Network-Based Mobility Extensions WG (netext) to consider the following document: - 'EAP Attributes for WiFi - EPC Integration' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-06-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract With WiFi emerging as a trusted access network for service providers, it has become important to provide functions commonly available in 3G and 4G networks in WiFi access networks as well. Such functions include Access Point Name (APN) Selection, multiple Packet Data Network (PDN) connections and seamless mobility between WiFi and 3G/4G networks. The EAP/AKA (and EAP/AKA') protocol is required for mobile devices to access the mobile Evolved Packet Core (EPC) via trusted WiFi networks. This document defines a few new EAP attributes to enable the above-mentioned functions in trusted WiFi access networks. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-netext-wifi-epc-eap-attributes/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-netext-wifi-epc-eap-attributes/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Jun 13 10:12:37 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345411A0178; Fri, 13 Jun 2014 10:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RktDEYJCIpyt; Fri, 13 Jun 2014 10:12:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B721B297B; Fri, 13 Jun 2014 10:12:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140613171234.7810.56593.idtracker@ietfa.amsl.com> Date: Fri, 13 Jun 2014 10:12:34 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/lpPn54wX8D8lhOQTfhdf-5bnXYQ Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jun 2014 17:12:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : Proxy Mobile IPv6 Extensions to Support Flow Mobility Author : Carlos J. Bernardos Filename : draft-ietf-netext-pmipv6-flowmob-09.txt Pages : 24 Date : 2014-06-13 Abstract: Proxy Mobile IPv6 allows a mobile node to connect to the same Proxy Mobile IPv6 domain through different interfaces. This document describes extensions to the Proxy Mobile IPv6 protocol that are required to support network based flow mobility over multiple physical interfaces. The extensions described in this document consist on the operations performed by the local mobility anchor and the mobile access gateway to manage the prefixes assigned to the different interfaces of the mobile node, as well as how the forwarding policies are handled by the network to ensure consistent flow mobility management. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmipv6-flowmob/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pmipv6-flowmob-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-pmipv6-flowmob-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 13 10:16:30 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6004E1A0203 for ; Fri, 13 Jun 2014 10:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.552 X-Spam-Level: X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F_DStsvlZCTN for ; Fri, 13 Jun 2014 10:16:26 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A9EE1B29B9 for ; Fri, 13 Jun 2014 10:16:25 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 20FC37ED6 for ; Fri, 13 Jun 2014 19:16:24 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id 14A137BF2 for ; Fri, 13 Jun 2014 19:16:24 +0200 (CEST) Message-ID: <1402679783.4063.11.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: netext@ietf.org Date: Fri, 13 Jun 2014 19:16:23 +0200 Organization: Universidad Carlos III de Madrid Content-Type: multipart/mixed; boundary="=-6xdYOAYoOJfMFCVKauF/" X-Mailer: Evolution 3.8.5-2+b3 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20756.001 X-TM-AS-Result: No--18.146-7.0-31-1 X-imss-scan-details: No--18.146-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/rTZ-WCLJzGfbeXghjQY6UZqMeJE Subject: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt] X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 13 Jun 2014 17:16:29 -0000 --=-6xdYOAYoOJfMFCVKauF/ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Hi, As agreed in London, I've updated the flow mobility draft to include also the FMI/FMA signaling option (in addition to the use of Update Notifications). The draft also includes a mechanism to allow selecting which one of the two signaling mechanisms to use. In my personal opinion, it'd be much cleaner and simpler to just specify one signaling mechanism, but this is up to the WG to decide. Comments, reviews and discussion on this new revision would be welcome. Hopefully we could get at least a new revision before Toronto. Thanks, Carlos --=-6xdYOAYoOJfMFCVKauF/ Content-Disposition: inline Content-Description: Forwarded message - [netext] I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt Content-Type: message/rfc822 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on antispam.uc3m.es X-Spam-Level: X-Spam-Status: No, score=1.0 required=3.0 tests=AWL,BAYES_00,NO_REAL_NAME, SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.7-deb X-Original-To: cjbc@it.uc3m.es Delivered-To: cjbc@correo03.uc3m.es Received: from smtp01.uc3m.es (pip-L01.uc3m.es [163.117.176.61]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by correo03.uc3m.es (Postfix) with ESMTPS id 4E98242DD1; Fri, 13 Jun 2014 19:12:40 +0200 (CEST) Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTPS id 914DCC3ABC1; Fri, 13 Jun 2014 19:12:38 +0200 (CEST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1681D1B29B4; Fri, 13 Jun 2014 10:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1402679557; bh=O+dMxaKRZm708AU2gvsPiZAPxU8FeI9yX14GhY1b4Qk=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=v3QF1X1WV3IeOgDI7LOwmNaghloXtcQjBCmT2B3STBZJ6urAC/2YQOc+M51Ue97Or 7XtfDDiPLdWKjXn9Lc9MWDXTajrXcdCG+mtUK9OksHHqLsbAyRq6FDispq8GlhbFDE EOcwNjt5eAeXXmp6ji0G4wDd/TGN8hXLBmTPeTTw= X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com X-Virus-Scanned: amavisd-new at amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B721B297B; Fri, 13 Jun 2014 10:12:34 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140613171234.7810.56593.idtracker@ietfa.amsl.com> Date: Fri, 13 Jun 2014 10:12:34 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/lpPn54wX8D8lhOQTfhdf-5bnXYQ Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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: , Content-Type: text/plain; charset="us-ascii" Errors-To: netext-bounces@ietf.org Sender: "netext" X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (smtp01.uc3m.es); Fri, 13 Jun 2014 19:12:39 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20756.000 Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : Proxy Mobile IPv6 Extensions to Support Flow Mobility Author : Carlos J. Bernardos Filename : draft-ietf-netext-pmipv6-flowmob-09.txt Pages : 24 Date : 2014-06-13 Abstract: Proxy Mobile IPv6 allows a mobile node to connect to the same Proxy Mobile IPv6 domain through different interfaces. This document describes extensions to the Proxy Mobile IPv6 protocol that are required to support network based flow mobility over multiple physical interfaces. The extensions described in this document consist on the operations performed by the local mobility anchor and the mobile access gateway to manage the prefixes assigned to the different interfaces of the mobile node, as well as how the forwarding policies are handled by the network to ensure consistent flow mobility management. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmipv6-flowmob/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pmipv6-flowmob-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-pmipv6-flowmob-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext --=-6xdYOAYoOJfMFCVKauF/-- From nobody Wed Jun 18 07:27:05 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E011A0279; Wed, 18 Jun 2014 07:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZjVNX9C8WRr; Wed, 18 Jun 2014 07:27:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF90B1A0262; Wed, 18 Jun 2014 07:26:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140618142659.13649.29958.idtracker@ietfa.amsl.com> Date: Wed, 18 Jun 2014 07:26:59 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/avqmSzk0E3VtfT35BSdzduUgovc Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmip-cp-up-separation-04.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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, 18 Jun 2014 14:27:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : Separation of Control and User Plane for Proxy Mobile IPv6 Authors : Ryuji Wakikawa Rajesh S. Pazhyannur Sri Gundavelli Charles E. Perkins Filename : draft-ietf-netext-pmip-cp-up-separation-04.txt Pages : 10 Date : 2014-06-18 Abstract: This document specifies a method to split the Control Plane (CP) and User Plane (UP) for a Proxy Mobile IPv6 based network infrastructure. Existing specifications allow a mobile access gateway (MAG) to separate its control and user plane using the Alternate Care of address mobility option for IPv6, or Alternate IPv4 Care of Address option for IPv4. However, the current specification does not provide any mechanism allowing the local mobility anchor (LMA) to perform an analogous functional split. To remedy that shortcoming, this document specifies a mobility option enabling a LMA to provide an alternate LMA address to be used for the bi-directional user plane traffic between the MAG and LMA. With this new option, a LMA will be able to use an IP address for its user plane which is different than the IP address used for the control plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmip-cp-up-separation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pmip-cp-up-separation-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-pmip-cp-up-separation-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 18 07:27:07 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05BB1A0263 for ; Wed, 18 Jun 2014 07:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVFC2f8nffMB; Wed, 18 Jun 2014 07:27:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 279931A0264; Wed, 18 Jun 2014 07:27:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: netext-chairs@tools.ietf.org, draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org, netext@ietf.org, brian@innovationslab.net X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140618142700.13649.96094.idtracker@ietfa.amsl.com> Date: Wed, 18 Jun 2014 07:27:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/UB_IQwl91i90faLlOI9fZA8a-08 Subject: [netext] New Version Notification - draft-ietf-netext-pmip-cp-up-separation-04.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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, 18 Jun 2014 14:27:02 -0000 A new version (-04) has been submitted for draft-ietf-netext-pmip-cp-up-separation: http://www.ietf.org/internet-drafts/draft-ietf-netext-pmip-cp-up-separation-04.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmip-cp-up-separation/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-pmip-cp-up-separation-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Wed Jun 18 07:30:19 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45AA01A026F for ; Wed, 18 Jun 2014 07:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kou6l1Bge4Zy for ; Wed, 18 Jun 2014 07:30:16 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DDD01A025F for ; Wed, 18 Jun 2014 07:30:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5542; q=dns/txt; s=iport; t=1403101818; x=1404311418; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=stAhR0tW8M9CJZjIV5RK+gNXmlps1ImeXwZF6PYl+S8=; b=FF/nFZYMuCWIx4fDRvaoTqY/fG9GEY8g1X4rnC7/JorRSKghmsNL6gz3 aIaYNwA9FsMeGKxFK3dFooN2vojEuQNexWHAzkH3CSzxXnJeApHq/N9Kz MTnYpxUXUAgeDFnA8t9TzWLKFXHKDEde/4vD9/kEhlCXYuKJj7mM1/FZg s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkIAMKhoVOtJA2K/2dsb2JhbABagw1STgyqEwEBAQEBAQUBkWmGbFMBgQkWdYQDAQEBBAEBATc0HQEIGB43CyUCBAESG4gnDcxsEwSFYokahEMEmkOTWINCgjA X-IronPort-AV: E=Sophos;i="5.01,501,1400025600"; d="scan'208";a="54079080" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-6.cisco.com with ESMTP; 18 Jun 2014 14:30:17 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s5IEUFsf011942 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Jun 2014 14:30:15 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.12]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Wed, 18 Jun 2014 09:30:15 -0500 From: "Sri Gundavelli (sgundave)" To: "Sri Gundavelli (sgundave)" , Brian Haberman , "draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org" , "netext@ietf.org" Thread-Topic: [netext] AD Evaluation: draft-ietf-netext-pmip-cp-up-separation Thread-Index: AQHPiwHRewW/NSf/N0m9K2Y0PmCVpw== Date: Wed, 18 Jun 2014 14:30:14 +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.3.120616 x-originating-ip: [10.32.246.215] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/xv7nfObcWdyotrLTK35cFfBGUug Subject: Re: [netext] AD Evaluation: draft-ietf-netext-pmip-cp-up-separation X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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, 18 Jun 2014 14:30:18 -0000 Hi Brian, We just posted -04 version. It includes the changes that we discussed. Regards Sri On 5/27/14 12:00 PM, "Sri Gundavelli (sgundave)" wrote: >Thanks Brian. We will post the revised I-D. > >Regards >Sri > > > >On 5/27/14 11:58 AM, "Brian Haberman" wrote: > >>Sri, >> I believe your proposed changes help clarify the text. Go ahead >>and submit an update with all the changes discussed. >> >>Regards, >>Brian >> >> >>On 5/27/14 1:05 PM, Sri Gundavelli (sgundave) wrote: >>> Hi Brian, >>>=20 >>> Sorry for the delay. Please see inline. >>>=20 >>>=20 >>> On 5/22/14 4:57 AM, "Brian Haberman" wrote: >>>=20 >>>> Hi Sri, >>>> >>>>>> >>>>>> 2. What is the plan for the publication of the CP separation >>>>>> requirements document that is referenced in this document? It seems >>>>>> rather silly to publish the solution spec before the requirements. >>>>>> Should they advance together? Incorporate the requirements into >>>>>>this >>>>>> document? >>>>> >>>>> >>>>> >>>>> We have the following text that talks about the assumptions around >>>>>this >>>>> interface. The draft is primarily driving this definition for the >>>>> deployment-scenario where the CP and DP functions exist on the same >>>>>IP >>>>> node. Figure-1 reflects this. However, the draft does not disallow >>>>>the >>>>> separation of CP and DP functions across different IP nodes. That's >>>>> surely >>>>> the goal here. But, there is no desire to mandate one specific >>>>>interface >>>>> between CP and DP entities. That interface may emerge as a generic >>>>> interface and this draft (PMIP-split-CP-DP) being one of the >>>>> applications >>>>> leveraging that interface. The interface can be based on OpenFlow, >>>>> FORCES, >>>>> some vendor specific interface, or the referenced draft based on >>>>> extensions to routing control plane. There is no dependency on one >>>>> specific interface for realizing the CP/DP split per this spec. Most >>>>> likely vendors may not agree on a single interface between a >>>>>controller >>>>> and a data plane node and so we tried to stay neutral on that aspect. >>>>> >>>>> >>>>> >>>>> --- >>>>> Section 1: >>>>> >>>>> Note that the interface between the control and user plane is out >>>>>of >>>>> scope in this document. It is required to setup a data path on >>>>>the >>>>> user plane according to the control signaling on the control >>>>>plane. >>>>> Several IETF working groups are addressing this interface as >>>>> described in [RFC5415], [RFC5812], [RFC5810], >>>>> [I-D.matsushima-stateless-uplane-vepc]. Techniques from Software >>>>> Defined Networking (SDN) [RFC7149] may also be applied. >>>>> >>>> >>>> The above makes sense and would be a good addition to the draft, but I >>>> am still a little concerned with the text surrounding the reference to >>>> draft-wakikawa-req-mobile-cp-separation. I think that it is the >>>>wording: >>>> >>>> >>>> This separation brings more flexible deployment and management of LMA >>>> and MAG(s) of Proxy Mobile IP as described in >>>> [I-D.wakikawa-req-mobile-cp-separation]. To meet this requirement... >>>> >>>> >>>> Should I parse this as the reference to the draft is only to relate >>>>the >>>> use cases rather than the actual requirements? If so, I could change >>>> "To meet this requirement" to "To facilitate this approach" or >>>>something >>>> similar. >>>=20 >>>=20 >>> Reference to I-D.matsushima is intended to be an example. >>>=20 >>>=20 >>> How about the following text: >>>=20 >>> OLD: >>> Note that the interface between the control and user plane is out of >>> scope in this document. It is required to setup a data path on the >>> user plane according to the control signaling on the control plane. >>> Several IETF working groups are addressing this interface as >>> described in [RFC5415], [RFC5812], [RFC5810], >>> [I-D.matsushima-stateless-uplane-vepc]. Techniques from Software >>> Defined Networking (SDN) [RFC7149] may also be applied. >>>=20 >>>=20 >>>=20 >>> NEW: >>>=20 >>> The LMA-CP and the LMA-DP functions are typically deployed on the same >>>IP >>> node and in such scenario the interface between these functions is >>> internal to the implementation. Deployments may also choose to split >>>the >>> LMA-CP and the LMA-DP functions across IP nodes. In such deployment >>> models, there needs to be a protocol interface between the LMA-CP and >>>the >>> LMA-DP functions and which is outside the scope of this document. >>>Possible >>> options for such interface include OpenFlow [Ref-1], FORCES [Ref-2], >>>use >>> of routing infrastructure [I-D.matsushima-stateless-uplane-vepc] or >>>vendor >>> specific approaches. This specification does not mandate a approach, or >>>a >>> specific protocol interface and views this interface as a generic >>> interface relevant more broadly for other protocol systems as well (Ex: >>> IPSec, L2TP, Mobile IPv6). >>>=20 >>>=20 >>>=20 >>> Regards >>> Sri >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> >>>> Or am I missing something? >>>> >>>> Regards, >>>> Brian >>>> >> > >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext From nobody Wed Jun 18 07:49:42 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6011A026D for ; Wed, 18 Jun 2014 07:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTTOSBUv35O1 for ; Wed, 18 Jun 2014 07:49:35 -0700 (PDT) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 007FD1A010A for ; Wed, 18 Jun 2014 07:49:34 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id n16so2082613oag.6 for ; Wed, 18 Jun 2014 07:49: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=M3E+1+NF6oTdmzxIaisef42G4Ewk8pzSXxGUfXxi8VQ=; b=cV95aq65SeYUjpq0CTJMxvsq72ISmst+3NoFkn/ELQYU1qABY27/xybbgRgmW265eC rA+F2yN2kDNfslHGguM67VIvt2rFmaD0/oLodbo5svio9o3LT/K2Ebj4m+EUFlRcPURD 48ctBbYqeWP4hkNTVBo7dGuE14rypBDcQwRMBPkafMF9n4twZnlrFoD5+G9YmbvMIWnp 3A65IfKJ0RoSk8+d9uS+S/D04FlZs/8tXhGa7wm74G4OKsUNR1m4Kmrm3Qw5D1BPfppU p6EMs5NQYsGHH/OJg4lDCBPsaUz0RQ63qR1egVoD9GmiMvhFzjWbBfXE92lWppwjjoW8 tuaA== MIME-Version: 1.0 X-Received: by 10.60.73.129 with SMTP id l1mr2599033oev.2.1403102974283; Wed, 18 Jun 2014 07:49:34 -0700 (PDT) Received: by 10.182.123.14 with HTTP; Wed, 18 Jun 2014 07:49:34 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Jun 2014 09:49:34 -0500 Message-ID: From: Basavaraj Patil To: "netext@ietf.org" Content-Type: multipart/alternative; boundary=001a113600105e273204fc1d5e4c Archived-At: http://mailarchive.ietf.org/arch/msg/netext/rztsF-wDPUoR36_Dv5q3PuHT_t8 Subject: [netext] Fwd: Consensus call to adopt I-D: draft-pazhyannur-netext-civic-location-ani-subopt-02.txt as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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, 18 Jun 2014 14:49:40 -0000 --001a113600105e273204fc1d5e4c Content-Type: text/plain; charset=UTF-8 Consensus call for this I-D has ended. There is a need to have this extension for PMIP6 and there is sufficient support for adoption. Authors: Please go ahead and submit the I-D as WG document. -Chairs ---------- Forwarded message ---------- From: Basavaraj Patil Date: Thu, May 8, 2014 at 9:33 AM Subject: Consensus call to adopt I-D: draft-pazhyannur-netext-civic-location-ani-subopt-02.txt as WG doc To: "netext@ietf.org" Hello, At the London IETF (89) there was consensus in the room to adopt the I-D: Extensions to the PMIPv6 Access Network Identifier Option as a Netext WG document. This document is a standards track I-D. This is a consensus call to adopt it. Please voice your opinion by May 22nd via the mailing list. Question to WG: Do you support the adoption of I-D: draft-pazhyannur-netext-civic-location-ani-subopt-02.txt as a Netext WG document? Yes [ ] No [ ] -Chairs -- Basavaraj Patil -- Basavaraj Patil --001a113600105e273204fc1d5e4c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Consensus call for this I-D has ended. Ther= e is a need to have this extension for PMIP6 and there is sufficient suppor= t for adoption.

Authors: Please go ahead and submit the = I-D as WG document.

-Chairs

---------- Fo= rwarded message ----------
From: Basavaraj= Patil <bpati= l1@gmail.com>
Date: Thu, May 8, 2014 at 9:33 AM
Subject: Consensus call to adopt I-D: = draft-pazhyannur-netext-civic-location-ani-subopt-02.txt as WG doc
To: &= quot;netext@ietf.org" <netext@ietf.org>



Hello,

At the Lo= ndon IETF (89) there was consensus in the room to adopt the I-D:
= 
E=
xtensions to the PMIPv6 Access Network Identifier Option
<draft-pazhyannur-netext-civic-location-ani-subopt-02.txt> as a Netex=
t WG document. This document is a standards track I-D.
This is a consen=
sus call to adopt it. Please voice your opinion by May 22nd via the mailing=
 list.
Q=
uestion to WG:
Do you support the adoption of I-D: draft-pazhyannur-netext-civic-location-ani-subopt-02.txt as a=
 Netext WG document?
<=
span style=3D"font-family:arial">
Yes [ ]
<=
span style=3D"font-family:arial">No [ ]
-Chairs

--
Basavaraj Patil



--
Basavaraj Patil
--001a113600105e273204fc1d5e4c-- From nobody Wed Jun 18 13:37:01 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F471A031D; Wed, 18 Jun 2014 13:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 865S4EZ3skJp; Wed, 18 Jun 2014 13:36:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9DD91A030F; Wed, 18 Jun 2014 13:36:45 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140618203645.8263.27035.idtracker@ietfa.amsl.com> Date: Wed, 18 Jun 2014 13:36:45 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/KP5S6N9D5BoWHc4DEBFFqiR2IfE Cc: netext@ietf.org Subject: [netext] Last Call: (Separation of Control and User Plane for Proxy Mobile IPv6) to Proposed Standard X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.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: Wed, 18 Jun 2014 20:36:48 -0000 The IESG has received a request from the Network-Based Mobility Extensions WG (netext) to consider the following document: - 'Separation of Control and User Plane for Proxy Mobile IPv6' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-07-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a method to split the Control Plane (CP) and User Plane (UP) for a Proxy Mobile IPv6 based network infrastructure. Existing specifications allow a mobile access gateway (MAG) to separate its control and user plane using the Alternate Care of address mobility option for IPv6, or Alternate IPv4 Care of Address option for IPv4. However, the current specification does not provide any mechanism allowing the local mobility anchor (LMA) to perform an analogous functional split. To remedy that shortcoming, this document specifies a mobility option enabling a LMA to provide an alternate LMA address to be used for the bi-directional user plane traffic between the MAG and LMA. With this new option, a LMA will be able to use an IP address for its user plane which is different than the IP address used for the control plane. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-netext-pmip-cp-up-separation/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-netext-pmip-cp-up-separation/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Jun 18 21:41:22 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6411C1A020F for ; Wed, 18 Jun 2014 21:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.042 X-Spam-Level: X-Spam-Status: No, score=-0.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uvPjhn95hnW for ; Wed, 18 Jun 2014 21:41:18 -0700 (PDT) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id 099A21A01E5 for ; Wed, 18 Jun 2014 21:41:17 -0700 (PDT) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 6CC151748161 for ; Thu, 19 Jun 2014 13:41:13 +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 BgEvA1C0dA6a for ; Thu, 19 Jun 2014 13:41:11 +0900 (JST) Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [172.19.90.145]) by mandala.kddilabs.jp (Postfix) with ESMTP id 312661748169 for ; Thu, 19 Jun 2014 13:41:00 +0900 (JST) Received: from [127.0.0.1] (dhcp197.west-4f.cn.kddilabs.jp [172.19.124.197]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id 7D2B41BAAA for ; Thu, 19 Jun 2014 13:25:58 +0900 (JST) Message-ID: <53A269DB.6050504@kddilabs.jp> Date: Thu, 19 Jun 2014 13:40:59 +0900 From: Hidetoshi Yokota User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "netext@ietf.org" References: <1402679783.4063.11.camel@acorde.it.uc3m.es> In-Reply-To: <1402679783.4063.11.camel@acorde.it.uc3m.es> Content-Type: multipart/alternative; boundary="------------040605050105090205040705" Archived-At: http://mailarchive.ietf.org/arch/msg/netext/B-ugL8-NJ4aE8t71Gr5sCEnpOJ4 Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt] X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jun 2014 04:41:20 -0000 This is a multi-part message in MIME format. --------------040605050105090205040705 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hello Carlos, Thanks for updating the draft. I have a couple of questions and comments: o In Section 3.2.1, which is the shared prefix case, there is no message exchange between the LMA and MAG, so there is no flow information on the MAG side. It should work in the sense of routing, but if, for example, each flow has a specific QoS, the MAG should also need to know which flow should go on which QoS path especially for upstream traffic towards the LMA. Or, the MAG may want to send a trigger for flow mobility to the MN (the exact mechanism is out of scope). Some mobility signaling should be there, too. o In Section 3.3, FMI/FMA are revived considering the case where UPN is not supported, but they convey very little information. There is no special information that cannot be conveyed by the existing messages. Since RFC7077 is now a proposed standard, I cannot think of a situation where the UPN/UPA are not supported, nevertheless FMI/FMA are supported.It rather seems more natural to mandate the support of RFC7077 or to mandate FMI/FMA for all flow mobility operations. Also, when compared with UPN/UPA case in Figure 4, FMI/FMA seem to convey different set of parameters in Figure 7. Could you clarify it a little bit more please? o In Section 3.3, just above Figure 7, there is a description: "..., and the type of flow mobility operation (add flow)", but does RFC6089 define such an operation code? This kind of operation should also be defined in the draft. Regards, -- Hidetoshi Yokota KDDI R&D Laboratories, Inc. e-mail:yokota@kddilabs.jp (2014/06/14 2:16), Carlos Jesu's Bernardos Cano wrote: > Hi, > > As agreed in London, I've updated the flow mobility draft to include > also the FMI/FMA signaling option (in addition to the use of Update > Notifications). The draft also includes a mechanism to allow selecting > which one of the two signaling mechanisms to use. > > In my personal opinion, it'd be much cleaner and simpler to just specify > one signaling mechanism, but this is up to the WG to decide. > > Comments, reviews and discussion on this new revision would be welcome. > Hopefully we could get at least a new revision before Toronto. > > Thanks, > > Carlos > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --------------040605050105090205040705 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hello Carlos,

Thanks for updating the draft.
I have a couple of questions and comments:

o In Section 3.2.1, which is the shared prefix case, there is no message exchange between the LMA and MAG, so there is no flow information on the MAG side. It should work in the sense of routing, but if, for example, each flow has a specific QoS, the MAG should also need to know which flow should go on which QoS path especially for upstream traffic towards the LMA. Or, the MAG may want to send a trigger for flow mobility to the MN (the exact mechanism is out of scope).  Some mobility signaling should be there, too.

o In Section 3.3, FMI/FMA are revived considering the case where UPN is not supported, but they convey very little information. There is no special information that cannot be conveyed by the existing messages. Since RFC7077 is now a proposed standard, I cannot think of a situation where the UPN/UPA are not supported, nevertheless FMI/FMA are supported. It rather seems more natural to mandate the support of RFC7077 or to mandate FMI/FMA for all flow mobility operations.
Also, when compared with UPN/UPA case in Figure 4, FMI/FMA seem to convey different set of parameters in Figure 7. Could you clarify it a little bit more please?

o In Section 3.3, just above Figure 7, there is a description: "..., and the type of flow mobility operation (add flow)", but does RFC6089 define such an operation code? This kind of operation should also be defined in the draft.

Regards,
 
-- 
Hidetoshi Yokota

KDDI R&D Laboratories, Inc.
e-mail:yokota@kddilabs.jp
(2014/06/14 2:16), Carlos Jesús Bernardos Cano wrote:
Hi,

As agreed in London, I've updated the flow mobility draft to include
also the FMI/FMA signaling option (in addition to the use of Update
Notifications). The draft also includes a mechanism to allow selecting
which one of the two signaling mechanisms to use.

In my personal opinion, it'd be much cleaner and simpler to just specify
one signaling mechanism, but this is up to the WG to decide.

Comments, reviews and discussion on this new revision would be welcome.
Hopefully we could get at least a new revision before Toronto.

Thanks,

Carlos



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

--------------040605050105090205040705-- From nobody Thu Jun 19 01:32:29 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EFF1A035D for ; Thu, 19 Jun 2014 01:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYU5aUv_V5gX for ; Thu, 19 Jun 2014 01:32:24 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1B251A035A for ; Thu, 19 Jun 2014 01:32:23 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 3BF66190325; Thu, 19 Jun 2014 10:32:22 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 0DFB3158052; Thu, 19 Jun 2014 10:32:22 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Thu, 19 Jun 2014 10:32:21 +0200 From: To: Hidetoshi Yokota , "netext@ietf.org" Thread-Topic: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt] Thread-Index: AQHPhys5AbUdXqAtfE2ZhajeqdtPppt3wXeAgABeDrA= Date: Thu, 19 Jun 2014 08:32:21 +0000 Message-ID: <12960_1403166742_53A2A016_12960_14955_1_81C77F07008CA24F9783A98CFD706F711425DBD6@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <1402679783.4063.11.camel@acorde.it.uc3m.es> <53A269DB.6050504@kddilabs.jp> In-Reply-To: <53A269DB.6050504@kddilabs.jp> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: multipart/alternative; boundary="_000_81C77F07008CA24F9783A98CFD706F711425DBD6PEXCVZYM12corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.19.30021 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/uzWYymhNy6RmP8bhVuCgTtvQ3so Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt] X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jun 2014 08:32:28 -0000 --_000_81C77F07008CA24F9783A98CFD706F711425DBD6PEXCVZYM12corpo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Hidetoshi/all, Release -08 mandates RFC7077 and the doc was good, IMHO. But, in London, we= have decided (group consensus) to reintroduce FMI/FMA to avoid dependency = between RFC. Now, it's true that introducing 2 options for message format m= akes the solution more complex for little added-value (no major differences= between messages)... So, maybe the question is "is it good or bad to have = RFC dependency?" then update the draft according the answer... Pierrick De : netext [mailto:netext-bounces@ietf.org] De la part de Hidetoshi Yokota Envoy=E9 : jeudi 19 juin 2014 06:41 =C0 : netext@ietf.org Objet : Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.= txt] Hello Carlos, Thanks for updating the draft. I have a couple of questions and comments: o In Section 3.2.1, which is the shared prefix case, there is no message ex= change between the LMA and MAG, so there is no flow information on the MAG = side. It should work in the sense of routing, but if, for example, each flo= w has a specific QoS, the MAG should also need to know which flow should go= on which QoS path especially for upstream traffic towards the LMA. Or, the= MAG may want to send a trigger for flow mobility to the MN (the exact mech= anism is out of scope). Some mobility signaling should be there, too. o In Section 3.3, FMI/FMA are revived considering the case where UPN is not= supported, but they convey very little information. There is no special in= formation that cannot be conveyed by the existing messages. Since RFC7077 i= s now a proposed standard, I cannot think of a situation where the UPN/UPA = are not supported, nevertheless FMI/FMA are supported. It rather seems more= natural to mandate the support of RFC7077 or to mandate FMI/FMA for all fl= ow mobility operations. Also, when compared with UPN/UPA case in Figure 4, FMI/FMA seem to convey d= ifferent set of parameters in Figure 7. Could you clarify it a little bit m= ore please? o In Section 3.3, just above Figure 7, there is a description: "..., and th= e type of flow mobility operation (add flow)", but does RFC6089 define such= an operation code? This kind of operation should also be defined in the dr= aft. Regards, -- Hidetoshi Yokota KDDI R&D Laboratories, Inc. e-mail:yokota@kddilabs.jp (2014/06/14 2:16), Carlos Jes=FAs Bernardos Cano wrote: Hi, As agreed in London, I've updated the flow mobility draft to include also the FMI/FMA signaling option (in addition to the use of Update Notifications). The draft also includes a mechanism to allow selecting which one of the two signaling mechanisms to use. In my personal opinion, it'd be much cleaner and simpler to just specify one signaling mechanism, but this is up to the WG to decide. Comments, reviews and discussion on this new revision would be welcome. Hopefully we could get at least a new revision before Toronto. Thanks, Carlos _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_81C77F07008CA24F9783A98CFD706F711425DBD6PEXCVZYM12corpo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Hidetos= hi/all,

 = ;

Release -0= 8 mandates RFC7077 and the doc was good, IMHO. But, in London, we have deci= ded (group consensus) to reintroduce FMI/FMA to avoid dependency between RFC. Now, it’s true that introducing 2 options for message f= ormat makes the solution more complex for little added-value (no major diff= erences between messages)… So, maybe the question is “is it goo= d or bad to have RFC dependency?” then update the draft according the answer...

 = ;

Pierrick

 = ;

De := netext [mailto:netext-bounces@ietf.org] De la part de Hidetoshi Yokota
Envoy=E9 : jeudi 19 juin 2014 06:41
=C0 : netext@ietf.org
Objet : Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6= -flowmob-09.txt]

 

Hello Carlos,

Thanks for updating the draft.
I have a couple of questions and comments:

o = In Section 3.2.1, which is the shared prefix case, there is no message exch= ange between the LMA and MAG, so there is no flow information on the MAG si= de. It should work in the sense of routing, but if, for example, each flow has a specific QoS, the MAG should also need to know wh= ich flow should go on which QoS path especially for upstream traffic toward= s the LMA. Or, the MAG may want to send a trigger for flow mobility to the = MN (the exact mechanism is out of scope).  Some mobility signaling should be there, too.

o In Section 3.3, FMI/FMA are revived considering the case where UPN is not= supported, but they convey very little information. There is no special in= formation that cannot be conveyed by the existing messages. Since RFC7077 i= s now a proposed standard, I cannot think of a situation where the UPN/UPA are not supported, nevertheless FMI= /FMA are supported. It rather seems more natural to mandate the support of = RFC7077 or to mandate FMI/FMA for all flow mobility operations.
Also, when compared with UPN/UPA case in Figure 4, FMI/FMA seem to convey d= ifferent set of parameters in Figure 7. Could you clarify it a little bit m= ore please?

o In Section 3.3, just above Figure 7, there is a description: "..., a= nd the type of flow mobility operation (add flow)", but does RFC6089 d= efine such an operation code? This kind of operation should also be defined= in the draft.

Regards,

-- 
Hidetoshi Yokota
 
KDDI R&D Laboratories, Inc.
e-mail:yokota@kddilabs.jp=

 

(2014/06/14 2:16), Carlos Jes=FAs Bernardos Cano wro= te:

Hi,
 
As agreed in London, I've updated the flow mobility draft to include
also the FMI/FMA signaling option (in addition to the use of Update
Notifications). The draft also includes a mechanism to allow selecting=

which one of the two signaling mechanisms to use.
 
In my personal opinion, it'd be much cleaner and simpler to just speci=
fy
one signaling mechanism, but this is up to the WG to decide.
 
Comments, reviews and discussion on this new revision would be welcome=
.
Hopefully we could get at least a new revision before Toronto.
 
Thanks,
 
Carlos




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

 

______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_81C77F07008CA24F9783A98CFD706F711425DBD6PEXCVZYM12corpo_-- From nobody Thu Jun 19 06:46:13 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398C51A0394 for ; Thu, 19 Jun 2014 06:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJzS_fdDH9M6 for ; Thu, 19 Jun 2014 06:46:08 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E8D71A01F3 for ; Thu, 19 Jun 2014 06:46:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17005; q=dns/txt; s=iport; t=1403185569; x=1404395169; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=T4xe/nVbgsgGhiSji+WFTxV5yL7UsrRlhPEn7ikVXMI=; b=IGDjGNJ0Nh8YXiQEs2gtCinyezIfuRRHujgQEsD64euQg+PhDXgMA2Ax 7fpAnHGNU5Y98InTVfB9iQdEUd3ENmXMmDretn9p39gmVR96g5j7tmoIG aWiSe8W07s3r6aUEFmDY2xC43zObUEQ/gR1U2VDFIlR9vx8jTJTD3NAJj c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnoGACbpolOtJV2R/2dsb2JhbABagkZHUlqqFQEBAQEBAQUBkWgBhmtTAYEHFnWEAwEBAQQBAQEqQR0BCBEDAQIoLgsUCQgCBAESG4gnDc40EwSFYogyDgMBPwwBCgEGhD0EjGGNYpNYg0KBdzk X-IronPort-AV: E=Sophos;i="5.01,507,1400025600"; d="scan'208,217";a="334243420" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-2.cisco.com with ESMTP; 19 Jun 2014 13:46:08 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s5JDk7XB023815 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Jun 2014 13:46:07 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.12]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Thu, 19 Jun 2014 08:46:06 -0500 From: "Sri Gundavelli (sgundave)" To: "pierrick.seite@orange.com" , Hidetoshi Yokota , "netext@ietf.org" Thread-Topic: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt] Thread-Index: AQHPi8TR0IEEZfjF1kSgp0XOwPNryQ== Date: Thu, 19 Jun 2014 13:46:06 +0000 Message-ID: In-Reply-To: <12960_1403166742_53A2A016_12960_14955_1_81C77F07008CA24F9783A98CFD706F711425DBD6@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.215] Content-Type: multipart/alternative; boundary="_000_CFC8369913F9B1sgundaveciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/Fpy7OIuPJf5f2sh0Icvxc9yh_9A Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt] X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jun 2014 13:46:11 -0000 --_000_CFC8369913F9B1sgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Pierrick, After the NETEXT meeting in London, we had some offline discussions with Ra= jiv and folks. There is agreement to use the RFC-7077 (UPN) messaging forma= t for FMI/FMA. So, the Flow Mobility spec may refer to this message as FMI/= FMA, but the underneath messaging format will confirm to RFC-7077 format an= d will have references to RFC-7077. We are not going to define a new MH mes= sage. This closes the key issue of using two notification approaches in the= same spec. AFAIK, no one has any objection to this. If any does, its now t= ime to speak up :) Regards Sri From: "pierrick.seite@orange.com" > Date: Thursday, June 19, 2014 1:32 AM To: Hidetoshi Yokota >, "nete= xt@ietf.org" > Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09= .txt] Hi Hidetoshi/all, Release -08 mandates RFC7077 and the doc was good, IMHO. But, in London, we= have decided (group consensus) to reintroduce FMI/FMA to avoid dependency = between RFC. Now, it=92s true that introducing 2 options for message format= makes the solution more complex for little added-value (no major differenc= es between messages)=85 So, maybe the question is =93is it good or bad to h= ave RFC dependency?=94 then update the draft according the answer... Pierrick De : netext [mailto:netext-bounces@ietf.org] De la part de Hidetoshi Yokota Envoy=E9 : jeudi 19 juin 2014 06:41 =C0 : netext@ietf.org Objet : Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.= txt] Hello Carlos, Thanks for updating the draft. I have a couple of questions and comments: o In Section 3.2.1, which is the shared prefix case, there is no message ex= change between the LMA and MAG, so there is no flow information on the MAG = side. It should work in the sense of routing, but if, for example, each flo= w has a specific QoS, the MAG should also need to know which flow should go= on which QoS path especially for upstream traffic towards the LMA. Or, the= MAG may want to send a trigger for flow mobility to the MN (the exact mech= anism is out of scope). Some mobility signaling should be there, too. o In Section 3.3, FMI/FMA are revived considering the case where UPN is not= supported, but they convey very little information. There is no special in= formation that cannot be conveyed by the existing messages. Since RFC7077 i= s now a proposed standard, I cannot think of a situation where the UPN/UPA = are not supported, nevertheless FMI/FMA are supported. It rather seems more= natural to mandate the support of RFC7077 or to mandate FMI/FMA for all fl= ow mobility operations. Also, when compared with UPN/UPA case in Figure 4, FMI/FMA seem to convey d= ifferent set of parameters in Figure 7. Could you clarify it a little bit m= ore please? o In Section 3.3, just above Figure 7, there is a description: "..., and th= e type of flow mobility operation (add flow)", but does RFC6089 define such= an operation code? This kind of operation should also be defined in the dr= aft. Regards, -- Hidetoshi Yokota KDDI R&D Laboratories, Inc. e-mail:yokota@kddilabs.jp (2014/06/14 2:16), Carlos Jes=FAs Bernardos Cano wrote: Hi, As agreed in London, I've updated the flow mobility draft to include also the FMI/FMA signaling option (in addition to the use of Update Notifications). The draft also includes a mechanism to allow selecting which one of the two signaling mechanisms to use. In my personal opinion, it'd be much cleaner and simpler to just specify one signaling mechanism, but this is up to the WG to decide. Comments, reviews and discussion on this new revision would be welcome. Hopefully we could get at least a new revision before Toronto. Thanks, Carlos _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_CFC8369913F9B1sgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2FB80D403C86774FAB9B73F482EF0629@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Pierrick,

After the NETEXT meeting in London, we had some offline discussions wi= th Rajiv and folks. There is agreement to use the RFC-7077 (UPN) messaging = format for FMI/FMA. So, the Flow Mobility spec may refer to this message as= FMI/FMA, but the underneath messaging format will confirm to RFC-7077 format and will have references to RFC-707= 7. We are not going to define a new MH message. This closes the key issue o= f using two notification approaches in the same spec. AFAIK, no one has any= objection to this. If any does, its now time to speak up :)

Regards
Sri


From: "pierrick.seite@orange.com" <pierrick.seite@orange.com>
Date: Thursday, June 19, 2014 1:32 = AM
To: Hidetoshi Yokota <yokota@kddilabs.jp>, "netext@ietf.org" <netext@ietf.org>
Subject: Re: [netext] [Fwd: I-D Act= ion: draft-ietf-netext-pmipv6-flowmob-09.txt]

Hi Hidetoshi/all,

 

Release -08 mandate= s RFC7077 and the doc was good, IMHO. But, in London, we have decided (grou= p consensus) to reintroduce FMI/FMA to avoid dependency between RFC. Now, it=92s true that introducing 2 options = for message format makes the solution more complex for little added-value (= no major differences between messages)=85 So, maybe the question is =93is i= t good or bad to have RFC dependency?=94 then update the draft according the answer...

 

Pierrick=

 

De : netext= [mailto:netext-bounces@ietf.org= ] De la part de Hidetoshi Yokota
Envoy=E9 : jeudi 19 juin 2014 06:41
=C0 : netext@ietf.org Objet : Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6= -flowmob-09.txt]

 

Hello Carlos,

Thanks for updating the draft.
I have a couple of questions and comments:

o In Section 3.2.1, wh= ich is the shared prefix case, there is no message exchange between the LMA= and MAG, so there is no flow information on the MAG side. It should work i= n the sense of routing, but if, for example, each flow has a specific QoS, the MAG should also need to know wh= ich flow should go on which QoS path especially for upstream traffic toward= s the LMA. Or, the MAG may want to send a trigger for flow mobility to the = MN (the exact mechanism is out of scope).  Some mobility signaling should be there, too.

o In Section 3.3, FMI/FMA are revived considering the case where UPN is not= supported, but they convey very little information. There is no special in= formation that cannot be conveyed by the existing messages. Since RFC7077 i= s now a proposed standard, I cannot think of a situation where the UPN/UPA are not supported, nevertheless FMI= /FMA are supported. It rather seems more natural to mandate the support of = RFC7077 or to mandate FMI/FMA for all flow mobility operations.
Also, when compared with UPN/UPA case in Figure 4, FMI/FMA seem to convey d= ifferent set of parameters in Figure 7. Could you clarify it a little bit m= ore please?

o In Section 3.3, just above Figure 7, there is a description: "..., a= nd the type of flow mobility operation (add flow)", but does RFC6089 d= efine such an operation code? This kind of operation should also be defined= in the draft.

Regards,

-- 
Hidetoshi Yokota
 
KDDI R&D Laboratories, Inc.
e-mail:yokota@kddilabs.jp=

 

(2014/06/14 2:16), Carlos Jes=FAs Bernardos Cano wro= te:

Hi,
 
As agreed in London, I've updated the flow mobility draft to include
also the FMI/FMA signaling option (in addition to the use of Update
Notifications). The draft also includes a mechanism to allow selecting=

which one of the two signaling mechanisms to use.
 
In my personal opinion, it'd be much cleaner and simpler to just speci=
fy
one signaling mechanism, but this is up to the WG to decide.
 
Comments, reviews and discussion on this new revision would be welcome=
.
Hopefully we could get at least a new revision before Toronto.
 
Thanks,
 
Carlos




_______________________________________________
netext mailing list
netext@ietf.org

https://www.i=
etf.org/mailman/listinfo/netext

 

______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_CFC8369913F9B1sgundaveciscocom_-- From nobody Thu Jun 19 10:36:54 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6301A02AE for ; Thu, 19 Jun 2014 10:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.552 X-Spam-Level: X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6CnaXcpNZJC for ; Thu, 19 Jun 2014 10:36:50 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B87941A00B1 for ; Thu, 19 Jun 2014 10:36:48 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id D72801516496; Thu, 19 Jun 2014 19:36:46 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [192.168.1.190] (82.158.201.225.dyn.user.ono.com [82.158.201.225]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id A124111BF0F2; Thu, 19 Jun 2014 19:36:46 +0200 (CEST) Message-ID: <1403199406.4456.36.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Hidetoshi Yokota Date: Thu, 19 Jun 2014 19:36:46 +0200 In-Reply-To: <53A269DB.6050504@kddilabs.jp> References: <1402679783.4063.11.camel@acorde.it.uc3m.es> <53A269DB.6050504@kddilabs.jp> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5-2+b3 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20768.000 X-TM-AS-Result: No--31.809-7.0-31-1 X-imss-scan-details: No--31.809-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/CFQMFVbDrhlYLdFLfdt-6txt8Vo Cc: "netext@ietf.org" Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt] X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jun 2014 17:36:53 -0000 Hi Hidetoshi, Thanks for your comments. Please see inline below. On Thu, 2014-06-19 at 13:40 +0900, Hidetoshi Yokota wrote: > Hello Carlos, > > Thanks for updating the draft. > I have a couple of questions and comments: > > o In Section 3.2.1, which is the shared prefix case, there is no > message exchange between the LMA and MAG, so there is no flow > information on the MAG side. It should work in the sense of routing, > but if, for example, each flow has a specific QoS, the MAG should also > need to know which flow should go on which QoS path especially for > upstream traffic towards the LMA. Or, the MAG may want to send a > trigger for flow mobility to the MN (the exact mechanism is out of > scope). Some mobility signaling should be there, too. [Carlos] There was a discussion on this in the past (don't remember exactly when, but I recall that Rajeev was one of the drivers) and the group decision was to make the signaling at the prefix level, not at flow level. If the group think there is value on supporting flow-granularity signaling, we could add it. > > o In Section 3.3, FMI/FMA are revived considering the case where UPN > is not supported, but they convey very little information. There is no > special information that cannot be conveyed by the existing messages. > Since RFC7077 is now a proposed standard, I cannot think of a > situation where the UPN/UPA are not supported, nevertheless FMI/FMA > are supported. It rather seems more natural to mandate the support of > RFC7077 or to mandate FMI/FMA for all flow mobility operations. > Also, when compared with UPN/UPA case in Figure 4, FMI/FMA seem to > convey different set of parameters in Figure 7. Could you clarify it a > little bit more please? > [Carlos] As Pierrick has already replied to you, there was discussion in London about supporting both mechanisms. I think this deserves another thread on the mailing list devoted to that discussion. As I expressed in a previous e-mail, my personal opinion as WG member is that we should go for just one signaling mechanism (being UPN/UPA my preference), but here I'm acting as the editor of the document and I just updated the document to reflect the consensus of the room in London. > o In Section 3.3, just above Figure 7, there is a description: "..., > and the type of flow mobility operation (add flow)", but does RFC6089 > define such an operation code? This kind of operation should also be > defined in the draft. [Carlos] By "add", a lifetime higher than 0 is meant (as 0 means "remove"). I agree this should be clarified in the document. Thanks for the comment. Once again, thanks for your comments! Carlos > > Regards, > -- > Hidetoshi Yokota > > KDDI R&D Laboratories, Inc. > e-mail:yokota@kddilabs.jp > > > (2014/06/14 2:16), Carlos Jesús Bernardos Cano wrote: > > > Hi, > > > > As agreed in London, I've updated the flow mobility draft to include > > also the FMI/FMA signaling option (in addition to the use of Update > > Notifications). The draft also includes a mechanism to allow selecting > > which one of the two signaling mechanisms to use. > > > > In my personal opinion, it'd be much cleaner and simpler to just specify > > one signaling mechanism, but this is up to the WG to decide. > > > > Comments, reviews and discussion on this new revision would be welcome. > > Hopefully we could get at least a new revision before Toronto. > > > > Thanks, > > > > Carlos > > > > > > _______________________________________________ > > 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 nobody Thu Jun 19 11:09:25 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0181A0085 for ; Thu, 19 Jun 2014 11:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEwiUneZJ7PI for ; Thu, 19 Jun 2014 11:09:15 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 498A21A0291 for ; Thu, 19 Jun 2014 11:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19826; q=dns/txt; s=iport; t=1403201356; x=1404410956; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=nyUlEHdjP+KeF4ov0CS7QHKsUOquJBMtc3iOB+23Ea0=; b=LGr0BJTbh24gYwdRV5BJamxKQOYc/b3GN+afU1WR4LjVQ5PIpvIaMXzf RzVmj6IkDJuMji6QCqB0Zo5Biae12z/nZM35lPVKn3oX6+sJu0wIQ71Qq WqDpFIyfq+bxdv90zhBht3fm2T6enQJ8IadLLLj/d51hfiBlsA/5t1DZQ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkHAF0mo1OtJV2Y/2dsb2JhbABZgkZHUk4MqhYBAQEBAQEFAZFoAYZrUwGBCxZ1hAMBAQEEAQEBKkEdAQgRAwECKC4LFAkIAgQBEhuIJw3ODBMEhWKIMg4DAT8MAQoBBoQ9BIxhjWKTWINCgXc5 X-IronPort-AV: E=Sophos; i="5.01,508,1400025600"; d="scan'208,217"; a="54477575" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP; 19 Jun 2014 18:09:15 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s5JI9EtC026247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Jun 2014 18:09:14 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.12]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Thu, 19 Jun 2014 13:09:13 -0500 From: "Sri Gundavelli (sgundave)" To: "Sri Gundavelli (sgundave)" , "pierrick.seite@orange.com" , Hidetoshi Yokota , "netext@ietf.org" Thread-Topic: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt] Thread-Index: AQHPi+mTAbUdXqAtfE2ZhajeqdtPpg== Date: Thu, 19 Jun 2014 18:09:13 +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.3.120616 x-originating-ip: [10.32.246.215] Content-Type: multipart/alternative; boundary="_000_CFC8717613FB6Csgundaveciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/1oaGb77wPVaFhZ1Bxd2I3p1TTdk Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt] X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jun 2014 18:09:20 -0000 --_000_CFC8717613FB6Csgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Carlos/All, Can we plan to close this work in the next few days. AFAIK, this FMI/FMA is= sue is now resolved. If you still doubt the consensus on this issue, we can= wait for 2 days for any comments and post the next rev. I'm hoping we will close this work this week and go LC on Monday (if chairs= agree). Waiting for Toronto meeting can delay the work by another few mont= hs. Regards Sri From: Sri Gundavelli > Date: Thursday, June 19, 2014 6:46 AM To: "pierrick.seite@orange.com" >, Hidetoshi Yokota >, "netext@ietf.org" > Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09= .txt] Hi Pierrick, After the NETEXT meeting in London, we had some offline discussions with Ra= jiv and folks. There is agreement to use the RFC-7077 (UPN) messaging forma= t for FMI/FMA. So, the Flow Mobility spec may refer to this message as FMI/= FMA, but the underneath messaging format will confirm to RFC-7077 format an= d will have references to RFC-7077. We are not going to define a new MH mes= sage. This closes the key issue of using two notification approaches in the= same spec. AFAIK, no one has any objection to this. If any does, its now t= ime to speak up :) Regards Sri From: "pierrick.seite@orange.com" > Date: Thursday, June 19, 2014 1:32 AM To: Hidetoshi Yokota >, "nete= xt@ietf.org" > Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09= .txt] Hi Hidetoshi/all, Release -08 mandates RFC7077 and the doc was good, IMHO. But, in London, we= have decided (group consensus) to reintroduce FMI/FMA to avoid dependency = between RFC. Now, it=92s true that introducing 2 options for message format= makes the solution more complex for little added-value (no major differenc= es between messages)=85 So, maybe the question is =93is it good or bad to h= ave RFC dependency?=94 then update the draft according the answer... Pierrick De : netext [mailto:netext-bounces@ietf.org] De la part de Hidetoshi Yokota Envoy=E9 : jeudi 19 juin 2014 06:41 =C0 : netext@ietf.org Objet : Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.= txt] Hello Carlos, Thanks for updating the draft. I have a couple of questions and comments: o In Section 3.2.1, which is the shared prefix case, there is no message ex= change between the LMA and MAG, so there is no flow information on the MAG = side. It should work in the sense of routing, but if, for example, each flo= w has a specific QoS, the MAG should also need to know which flow should go= on which QoS path especially for upstream traffic towards the LMA. Or, the= MAG may want to send a trigger for flow mobility to the MN (the exact mech= anism is out of scope). Some mobility signaling should be there, too. o In Section 3.3, FMI/FMA are revived considering the case where UPN is not= supported, but they convey very little information. There is no special in= formation that cannot be conveyed by the existing messages. Since RFC7077 i= s now a proposed standard, I cannot think of a situation where the UPN/UPA = are not supported, nevertheless FMI/FMA are supported. It rather seems more= natural to mandate the support of RFC7077 or to mandate FMI/FMA for all fl= ow mobility operations. Also, when compared with UPN/UPA case in Figure 4, FMI/FMA seem to convey d= ifferent set of parameters in Figure 7. Could you clarify it a little bit m= ore please? o In Section 3.3, just above Figure 7, there is a description: "..., and th= e type of flow mobility operation (add flow)", but does RFC6089 define such= an operation code? This kind of operation should also be defined in the dr= aft. Regards, -- Hidetoshi Yokota KDDI R&D Laboratories, Inc. e-mail:yokota@kddilabs.jp (2014/06/14 2:16), Carlos Jes=FAs Bernardos Cano wrote: Hi, As agreed in London, I've updated the flow mobility draft to include also the FMI/FMA signaling option (in addition to the use of Update Notifications). The draft also includes a mechanism to allow selecting which one of the two signaling mechanisms to use. In my personal opinion, it'd be much cleaner and simpler to just specify one signaling mechanism, but this is up to the WG to decide. Comments, reviews and discussion on this new revision would be welcome. Hopefully we could get at least a new revision before Toronto. Thanks, Carlos _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_CFC8717613FB6Csgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Carlos/All,

Can we plan to close this work in the next few days. AFAIK, this FMI/F= MA issue is now resolved. If you still doubt the consensus on this issue, w= e can wait for 2 days for any comments and post the next rev.

I'm hoping we will close this work this week and go LC on Monday (if c= hairs agree). Waiting for Toronto meeting can delay the work by another few= months.


Regards
Sri

From: Sri Gundavelli <sgundave@cisco.com>
Date: Thursday, June 19, 2014 6:46 = AM
To: "pierrick.seite@orange.com" <pierrick.seite@orange.com>, Hidetoshi = Yokota <yokota@kddilabs.jp>= , "netext@ietf.org" <netext@ietf.org>
Subject: Re: [netext] [Fwd: I-D Act= ion: draft-ietf-netext-pmipv6-flowmob-09.txt]

Hi Pierrick,

After the NETEXT meeting in London, we had some offline discussions wi= th Rajiv and folks. There is agreement to use the RFC-7077 (UPN) messaging = format for FMI/FMA. So, the Flow Mobility spec may refer to this message as= FMI/FMA, but the underneath messaging format will confirm to RFC-7077 format and will have references to RFC-707= 7. We are not going to define a new MH message. This closes the key issue o= f using two notification approaches in the same spec. AFAIK, no one has any= objection to this. If any does, its now time to speak up :)

Regards
Sri


From: "pierrick.seite@orange.com" <pierrick.seite@orange.com>
Date: Thursday, June 19, 2014 1:32 = AM
To: Hidetoshi Yokota <yokota@kddilabs.jp>, "netext@ietf.org" <netext@ietf.org>
Subject: Re: [netext] [Fwd: I-D Act= ion: draft-ietf-netext-pmipv6-flowmob-09.txt]

Hi Hidetoshi/all,

 

Release -08 mandate= s RFC7077 and the doc was good, IMHO. But, in London, we have decided (grou= p consensus) to reintroduce FMI/FMA to avoid dependency between RFC. Now, it=92s true that introducing 2 options = for message format makes the solution more complex for little added-value (= no major differences between messages)=85 So, maybe the question is =93is i= t good or bad to have RFC dependency?=94 then update the draft according the answer...

 

Pierrick=

 

De : netext= [mailto:netext-bounces@ietf.org= ] De la part de Hidetoshi Yokota
Envoy=E9 : jeudi 19 juin 2014 06:41
=C0 : netext@ietf.org Objet : Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6= -flowmob-09.txt]

 

Hello Carlos,

Thanks for updating the draft.
I have a couple of questions and comments:

o In Section 3.2.1, wh= ich is the shared prefix case, there is no message exchange between the LMA= and MAG, so there is no flow information on the MAG side. It should work i= n the sense of routing, but if, for example, each flow has a specific QoS, the MAG should also need to know wh= ich flow should go on which QoS path especially for upstream traffic toward= s the LMA. Or, the MAG may want to send a trigger for flow mobility to the = MN (the exact mechanism is out of scope).  Some mobility signaling should be there, too.

o In Section 3.3, FMI/FMA are revived considering the case where UPN is not= supported, but they convey very little information. There is no special in= formation that cannot be conveyed by the existing messages. Since RFC7077 i= s now a proposed standard, I cannot think of a situation where the UPN/UPA are not supported, nevertheless FMI= /FMA are supported. It rather seems more natural to mandate the support of = RFC7077 or to mandate FMI/FMA for all flow mobility operations.
Also, when compared with UPN/UPA case in Figure 4, FMI/FMA seem to convey d= ifferent set of parameters in Figure 7. Could you clarify it a little bit m= ore please?

o In Section 3.3, just above Figure 7, there is a description: "..., a= nd the type of flow mobility operation (add flow)", but does RFC6089 d= efine such an operation code? This kind of operation should also be defined= in the draft.

Regards,

-- 
Hidetoshi Yokota
 
KDDI R&D Laboratories, Inc.
e-mail:yokota@kddilabs.jp=

 

(2014/06/14 2:16), Carlos Jes=FAs Bernardos Cano wro= te:

Hi,
 
As agreed in London, I've updated the flow mobility draft to include
also the FMI/FMA signaling option (in addition to the use of Update
Notifications). The draft also includes a mechanism to allow selecting=

which one of the two signaling mechanisms to use.
 
In my personal opinion, it'd be much cleaner and simpler to just speci=
fy
one signaling mechanism, but this is up to the WG to decide.
 
Comments, reviews and discussion on this new revision would be welcome=
.
Hopefully we could get at least a new revision before Toronto.
 
Thanks,
 
Carlos




_______________________________________________
netext mailing list
netext@ietf.org

https://www.i=
etf.org/mailman/listinfo/netext

 

______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_CFC8717613FB6Csgundaveciscocom_-- From nobody Thu Jun 19 15:53:01 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B0E1A01A8 for ; Thu, 19 Jun 2014 15:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfGM6TWrWkFF for ; Thu, 19 Jun 2014 15:52:54 -0700 (PDT) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C846F1A0183 for ; Thu, 19 Jun 2014 15:52:53 -0700 (PDT) Received: by mail-yh0-f45.google.com with SMTP id t59so2257211yho.18 for ; Thu, 19 Jun 2014 15:52:53 -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=dfOtF7tPfAMa/+qrnSVgML4OyKOAlIFWBpiXV36VUkw=; b=f87xrm+2xusWJEUJGmrKvMWyT8znujOm7s79QzpVklfQQd0Gqq8dylgJRdhpkAFqig fs6RmgsqX5bn7LfIP6lD5YCmAgvEDbD9WoRraahHUwXeeytEgx66wMLKK0FNYi0ZOKYI 0txajgNUc6Vp7aJybI0XR/wVLIH/809drUx+3FP3aO5Ux3AFv378G6m63CSRGTR603x2 E6MXT1gI+OTmGk5v+o9ayEC6PiciVKUtLX3bEmZtkuA2dNMoDJQu/1afVzzb71f9AI7K ubhHuESDQXfR40p3QXIv34sM/M5RYM0L6H+TrqJOtNoW8ImKvXZTdoGXy8MyOA1SRs9w Ar1A== MIME-Version: 1.0 X-Received: by 10.236.53.163 with SMTP id g23mr2270464yhc.15.1403218373073; Thu, 19 Jun 2014 15:52:53 -0700 (PDT) Received: by 10.170.156.130 with HTTP; Thu, 19 Jun 2014 15:52:53 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 Jun 2014 17:52:53 -0500 Message-ID: From: Behcet Sarikaya To: "Sri Gundavelli (sgundave)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netext/NVVztKgw0WuRi5V4EATEb05V-UA Cc: "netext@ietf.org" Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt] X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jun 2014 22:52:58 -0000 On Thu, Jun 19, 2014 at 1:09 PM, Sri Gundavelli (sgundave) wrote: > Hi Carlos/All, > > Can we plan to close this work in the next few days. AFAIK, this FMI/FMA > issue is now resolved. If you still doubt the consensus on this issue, we > can wait for 2 days for any comments and post the next rev. > This draft is in no way close WG LC. At the outset Raj has set out very clearly the direction for this work in his mail way back on March 3, 2011 http://www.ietf.org/mail-archive/web/netext/current/msg01839.html Quote Flow mobility in the context of Proxy MIP6 is the switching of a flow by the LMA from MAGx to MAGy when the MN is attached to the LMA via multipl= e interfaces through different MAGs. The LMA makes the decision to move a flow based on some policy. Unquote No mention of LMA-initiated flow mobility can be found in this draft. Use case scenario 1, common set of prefixes is not feasible. MN can get different prefixes even on a single interface, what is the point of considering same prefix on all interfaces? If we remove Use Case 1 then there are no use cases. This draft needs to be reworked. Regards, Behcet > I'm hoping we will close this work this week and go LC on Monday (if chai= rs > agree). Waiting for Toronto meeting can delay the work by another few > months. > > > Regards > Sri > > From: Sri Gundavelli > Date: Thursday, June 19, 2014 6:46 AM > To: "pierrick.seite@orange.com" , Hidetoshi > Yokota , "netext@ietf.org" > > Subject: Re: [netext] [Fwd: I-D Action: > draft-ietf-netext-pmipv6-flowmob-09.txt] > > Hi Pierrick, > > After the NETEXT meeting in London, we had some offline discussions with > Rajiv and folks. There is agreement to use the RFC-7077 (UPN) messaging > format for FMI/FMA. So, the Flow Mobility spec may refer to this message = as > FMI/FMA, but the underneath messaging format will confirm to RFC-7077 for= mat > and will have references to RFC-7077. We are not going to define a new MH > message. This closes the key issue of using two notification approaches i= n > the same spec. AFAIK, no one has any objection to this. If any does, its = now > time to speak up :) > > Regards > Sri > > > From: "pierrick.seite@orange.com" > Date: Thursday, June 19, 2014 1:32 AM > To: Hidetoshi Yokota , "netext@ietf.org" > > Subject: Re: [netext] [Fwd: I-D Action: > draft-ietf-netext-pmipv6-flowmob-09.txt] > > Hi Hidetoshi/all, > > > > Release -08 mandates RFC7077 and the doc was good, IMHO. But, in London, = we > have decided (group consensus) to reintroduce FMI/FMA to avoid dependency > between RFC. Now, it=E2=80=99s true that introducing 2 options for messag= e format > makes the solution more complex for little added-value (no major differen= ces > between messages)=E2=80=A6 So, maybe the question is =E2=80=9Cis it good = or bad to have RFC > dependency?=E2=80=9D then update the draft according the answer... > > > > Pierrick > > > > De : netext [mailto:netext-bounces@ietf.org] De la part de Hidetoshi Yoko= ta > Envoy=C3=A9 : jeudi 19 juin 2014 06:41 > =C3=80 : netext@ietf.org > Objet : Re: [netext] [Fwd: I-D Action: > draft-ietf-netext-pmipv6-flowmob-09.txt] > > > > Hello Carlos, > > Thanks for updating the draft. > I have a couple of questions and comments: > > o In Section 3.2.1, which is the shared prefix case, there is no message > exchange between the LMA and MAG, so there is no flow information on the = MAG > side. It should work in the sense of routing, but if, for example, each f= low > has a specific QoS, the MAG should also need to know which flow should go= on > which QoS path especially for upstream traffic towards the LMA. Or, the M= AG > may want to send a trigger for flow mobility to the MN (the exact mechani= sm > is out of scope). Some mobility signaling should be there, too. > > o In Section 3.3, FMI/FMA are revived considering the case where UPN is n= ot > supported, but they convey very little information. There is no special > information that cannot be conveyed by the existing messages. Since RFC70= 77 > is now a proposed standard, I cannot think of a situation where the UPN/U= PA > are not supported, nevertheless FMI/FMA are supported. It rather seems mo= re > natural to mandate the support of RFC7077 or to mandate FMI/FMA for all f= low > mobility operations. > Also, when compared with UPN/UPA case in Figure 4, FMI/FMA seem to convey > different set of parameters in Figure 7. Could you clarify it a little bi= t > more please? > > o In Section 3.3, just above Figure 7, there is a description: "..., and = the > type of flow mobility operation (add flow)", but does RFC6089 define such= an > operation code? This kind of operation should also be defined in the draf= t. > > Regards, > > -- > > Hidetoshi Yokota > > > > KDDI R&D Laboratories, Inc. > > e-mail:yokota@kddilabs.jp > > > > (2014/06/14 2:16), Carlos Jes=C3=BAs Bernardos Cano wrote: > > Hi, > > > > As agreed in London, I've updated the flow mobility draft to include > > also the FMI/FMA signaling option (in addition to the use of Update > > Notifications). The draft also includes a mechanism to allow selecting > > which one of the two signaling mechanisms to use. > > > > In my personal opinion, it'd be much cleaner and simpler to just specify > > one signaling mechanism, but this is up to the WG to decide. > > > > Comments, reviews and discussion on this new revision would be welcome. > > Hopefully we could get at least a new revision before Toronto. > > > > Thanks, > > > > Carlos > > > > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From nobody Thu Jun 19 16:11:49 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D7E1A019D for ; Thu, 19 Jun 2014 16:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGdt_dsOQd0F for ; Thu, 19 Jun 2014 16:11:37 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 439891A0183 for ; Thu, 19 Jun 2014 16:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8027; q=dns/txt; s=iport; t=1403219497; x=1404429097; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=3amTBsMFB27aY8WPgA8zzJQA3OTRXTXD8lhPU9cWEvo=; b=NVkd1g2c1APPKBvIJHh0dRnu6EjXCKuR7m7duw/Zrvc5MTwqwG3fspW0 jhRBYz9PDZyK5SXB6tdRORrct9UtStMA2ULTPFSWUc3mMmVreJPh+U0jA ptbFfqRgC41IGjnaaMBcqPo/5FPAhzJfi8jp+lC3ztzXXd0gdPahfIMMy o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtwFAM5to1OtJV2R/2dsb2JhbABZgw1SWqoaAQEBAQEBBQGRaoZsUwGBDBZ1hAMBAQEDAQEBAWsLBQ0BCBEDAQIBJygGCxQJCAIEDgUJEogTAwkIDcZQDYZGF4VihnGBQQ4CAgEcLgUCBQaEPQSYSoF5jViGAINCbIFE X-IronPort-AV: E=Sophos;i="5.01,509,1400025600"; d="scan'208";a="334370516" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-2.cisco.com with ESMTP; 19 Jun 2014 23:11:22 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s5JNBLjZ013138 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Jun 2014 23:11:21 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.12]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Thu, 19 Jun 2014 18:11:21 -0500 From: "Sri Gundavelli (sgundave)" To: "sarikaya@ieee.org" Thread-Topic: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt] Thread-Index: AQHPjBPIAbUdXqAtfE2ZhajeqdtPpg== Date: Thu, 19 Jun 2014 23:11:20 +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.3.120616 x-originating-ip: [10.32.246.215] Content-Type: text/plain; charset="Windows-1252" Content-ID: <618344FC988FB84ABCC1BEB5D6936114@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/EutmK1drGXkP0sOp-zUF0uLhDYw Cc: "netext@ietf.org" Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt] X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jun 2014 23:11:47 -0000 Behcet, > This draft is in no way close WG LC. That has been just your comment since day-1. AFAIK, no one in the WG is able to understand the technical issue you are raising, other than these vague comments.=20 If you see a technical issue, explain it, challenge us and we are up for it. If you cannot, park the issue and its time to move forward. FWIW, Suresh, when chairing the WG in one of the meetings did a poll in the room and no one agreed with your views. So, its time to move on .. Sri On 6/19/14 3:52 PM, "Behcet Sarikaya" wrote: >On Thu, Jun 19, 2014 at 1:09 PM, Sri Gundavelli (sgundave) > wrote: >> Hi Carlos/All, >> >> Can we plan to close this work in the next few days. AFAIK, this FMI/FMA >> issue is now resolved. If you still doubt the consensus on this issue, >>we >> can wait for 2 days for any comments and post the next rev. >> > >This draft is in no way close WG LC. > >At the outset Raj has set out very clearly the direction for this work >in his mail way back on March 3, 2011 >http://www.ietf.org/mail-archive/web/netext/current/msg01839.html > >Quote >Flow mobility in the context of Proxy MIP6 is the switching of a flow >by the LMA from MAGx to MAGy when the MN is attached to the LMA via >multiple >interfaces through different MAGs. The LMA makes the decision to move >a flow based on some policy. >Unquote > >No mention of LMA-initiated flow mobility can be found in this draft. >Use case scenario 1, common set of prefixes is not feasible. >MN can get different prefixes even on a single interface, what is the >point of considering same prefix on all interfaces? > >If we remove Use Case 1 then there are no use cases. > >This draft needs to be reworked. > >Regards, > >Behcet > > >> I'm hoping we will close this work this week and go LC on Monday (if >>chairs >> agree). Waiting for Toronto meeting can delay the work by another few >> months. >> >> >> Regards >> Sri >> >> From: Sri Gundavelli >> Date: Thursday, June 19, 2014 6:46 AM >> To: "pierrick.seite@orange.com" , Hidetoshi >> Yokota , "netext@ietf.org" >> >> Subject: Re: [netext] [Fwd: I-D Action: >> draft-ietf-netext-pmipv6-flowmob-09.txt] >> >> Hi Pierrick, >> >> After the NETEXT meeting in London, we had some offline discussions with >> Rajiv and folks. There is agreement to use the RFC-7077 (UPN) messaging >> format for FMI/FMA. So, the Flow Mobility spec may refer to this >>message as >> FMI/FMA, but the underneath messaging format will confirm to RFC-7077 >>format >> and will have references to RFC-7077. We are not going to define a new >>MH >> message. This closes the key issue of using two notification approaches >>in >> the same spec. AFAIK, no one has any objection to this. If any does, >>its now >> time to speak up :) >> >> Regards >> Sri >> >> >> From: "pierrick.seite@orange.com" >> Date: Thursday, June 19, 2014 1:32 AM >> To: Hidetoshi Yokota , "netext@ietf.org" >> >> Subject: Re: [netext] [Fwd: I-D Action: >> draft-ietf-netext-pmipv6-flowmob-09.txt] >> >> Hi Hidetoshi/all, >> >> >> >> Release -08 mandates RFC7077 and the doc was good, IMHO. But, in >>London, we >> have decided (group consensus) to reintroduce FMI/FMA to avoid >>dependency >> between RFC. Now, it=B9s true that introducing 2 options for message >>format >> makes the solution more complex for little added-value (no major >>differences >> between messages)=8A So, maybe the question is =B3is it good or bad to h= ave >>RFC >> dependency?=B2 then update the draft according the answer... >> >> >> >> Pierrick >> >> >> >> De : netext [mailto:netext-bounces@ietf.org] De la part de Hidetoshi >>Yokota >> Envoy=E9 : jeudi 19 juin 2014 06:41 >> =C0 : netext@ietf.org >> Objet : Re: [netext] [Fwd: I-D Action: >> draft-ietf-netext-pmipv6-flowmob-09.txt] >> >> >> >> Hello Carlos, >> >> Thanks for updating the draft. >> I have a couple of questions and comments: >> >> o In Section 3.2.1, which is the shared prefix case, there is no message >> exchange between the LMA and MAG, so there is no flow information on >>the MAG >> side. It should work in the sense of routing, but if, for example, each >>flow >> has a specific QoS, the MAG should also need to know which flow should >>go on >> which QoS path especially for upstream traffic towards the LMA. Or, the >>MAG >> may want to send a trigger for flow mobility to the MN (the exact >>mechanism >> is out of scope). Some mobility signaling should be there, too. >> >> o In Section 3.3, FMI/FMA are revived considering the case where UPN is >>not >> supported, but they convey very little information. There is no special >> information that cannot be conveyed by the existing messages. Since >>RFC7077 >> is now a proposed standard, I cannot think of a situation where the >>UPN/UPA >> are not supported, nevertheless FMI/FMA are supported. It rather seems >>more >> natural to mandate the support of RFC7077 or to mandate FMI/FMA for all >>flow >> mobility operations. >> Also, when compared with UPN/UPA case in Figure 4, FMI/FMA seem to >>convey >> different set of parameters in Figure 7. Could you clarify it a little >>bit >> more please? >> >> o In Section 3.3, just above Figure 7, there is a description: "..., >>and the >> type of flow mobility operation (add flow)", but does RFC6089 define >>such an >> operation code? This kind of operation should also be defined in the >>draft. >> >> Regards, >> >> -- >> >> Hidetoshi Yokota >> >> >> >> KDDI R&D Laboratories, Inc. >> >> e-mail:yokota@kddilabs.jp >> >> >> >> (2014/06/14 2:16), Carlos Jes=FAs Bernardos Cano wrote: >> >> Hi, >> >> >> >> As agreed in London, I've updated the flow mobility draft to include >> >> also the FMI/FMA signaling option (in addition to the use of Update >> >> Notifications). The draft also includes a mechanism to allow selecting >> >> which one of the two signaling mechanisms to use. >> >> >> >> In my personal opinion, it'd be much cleaner and simpler to just specify >> >> one signaling mechanism, but this is up to the WG to decide. >> >> >> >> Comments, reviews and discussion on this new revision would be welcome. >> >> Hopefully we could get at least a new revision before Toronto. >> >> >> >> Thanks, >> >> >> >> Carlos >> >> >> >> >> _______________________________________________ >> >> netext mailing list >> >> netext@ietf.org >> >> https://www.ietf.org/mailman/listinfo/netext >> >> >> >>=20 >>_________________________________________________________________________ >>________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >>recu >> ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme >>ou >> falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >>been >> modified, changed or falsified. >> Thank you. >> >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> From nobody Sat Jun 21 17:47:29 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D431B284B for ; Sat, 21 Jun 2014 17:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.958 X-Spam-Level: ** X-Spam-Status: No, score=2.958 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IPppmSLZtRi for ; Sat, 21 Jun 2014 17:47:25 -0700 (PDT) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id C72C01B2848 for ; Sat, 21 Jun 2014 17:47:24 -0700 (PDT) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 63767174817D; Sun, 22 Jun 2014 09:47:20 +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 q7l7wcVyWtvR; Sun, 22 Jun 2014 09:47:18 +0900 (JST) Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [172.19.90.145]) by mandala.kddilabs.jp (Postfix) with ESMTP id 5D3411748118; Sun, 22 Jun 2014 09:47:18 +0900 (JST) Received: from [127.0.0.1] (unknown [10.8.0.6]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id C60591B866; Sun, 22 Jun 2014 09:32:12 +0900 (JST) Message-ID: <53A6277F.6080608@kddilabs.jp> Date: Sun, 22 Jun 2014 09:46:55 +0900 From: Hidetoshi Yokota User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?UTF-8?B?Q2FybG9zIEplc8O6cyBCZXJuYXJkb3MgQ2Fubw==?= References: <1402679783.4063.11.camel@acorde.it.uc3m.es> <53A269DB.6050504@kddilabs.jp> <1403199406.4456.36.camel@acorde.it.uc3m.es> In-Reply-To: <1403199406.4456.36.camel@acorde.it.uc3m.es> Content-Type: multipart/alternative; boundary="------------050007050105040405020704" Archived-At: http://mailarchive.ietf.org/arch/msg/netext/2nvlSQvJKn-A0L-V6sMUw9Femmo Cc: "netext@ietf.org" Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt] X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jun 2014 00:47:27 -0000 This is a multi-part message in MIME format. --------------050007050105040405020704 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Carlos, Thanks for your response and the discussion is getting more active towards the WGLC! Please see inline: (2014/06/20 2:36), Carlos Jesús Bernardos Cano wrote: > Hi Hidetoshi, > > Thanks for your comments. Please see inline below. > > On Thu, 2014-06-19 at 13:40 +0900, Hidetoshi Yokota wrote: >> Hello Carlos, >> >> Thanks for updating the draft. >> I have a couple of questions and comments: >> >> o In Section 3.2.1, which is the shared prefix case, there is no >> message exchange between the LMA and MAG, so there is no flow >> information on the MAG side. It should work in the sense of routing, >> but if, for example, each flow has a specific QoS, the MAG should also >> need to know which flow should go on which QoS path especially for >> upstream traffic towards the LMA. Or, the MAG may want to send a >> trigger for flow mobility to the MN (the exact mechanism is out of >> scope). Some mobility signaling should be there, too. > [Carlos] There was a discussion on this in the past (don't remember > exactly when, but I recall that Rajeev was one of the drivers) and the > group decision was to make the signaling at the prefix level, not at > flow level. If the group think there is value on supporting > flow-granularity signaling, we could add it. Flow movement at the prefix level is ok, but the new MAG needs to know which flow(s) is/are coming within that prefix to link it/them to proper QoS path(s) and optionally to inform the MN about it. Actual use cases would require more than just routing. >> o In Section 3.3, FMI/FMA are revived considering the case where UPN >> is not supported, but they convey very little information. There is no >> special information that cannot be conveyed by the existing messages. >> Since RFC7077 is now a proposed standard, I cannot think of a >> situation where the UPN/UPA are not supported, nevertheless FMI/FMA >> are supported. It rather seems more natural to mandate the support of >> RFC7077 or to mandate FMI/FMA for all flow mobility operations. >> Also, when compared with UPN/UPA case in Figure 4, FMI/FMA seem to >> convey different set of parameters in Figure 7. Could you clarify it a >> little bit more please? >> > [Carlos] As Pierrick has already replied to you, there was discussion in > London about supporting both mechanisms. I think this deserves another > thread on the mailing list devoted to that discussion. As I expressed in > a previous e-mail, my personal opinion as WG member is that we should go > for just one signaling mechanism (being UPN/UPA my preference), but here > I'm acting as the editor of the document and I just updated the document > to reflect the consensus of the room in London. I see, but Sri has a different view on it. Let's discuss it on the ML. I also prefer to stick to one set of signaling messages. >> o In Section 3.3, just above Figure 7, there is a description: "..., >> and the type of flow mobility operation (add flow)", but does RFC6089 >> define such an operation code? This kind of operation should also be >> defined in the draft. > [Carlos] By "add", a lifetime higher than 0 is meant (as 0 means > "remove"). I agree this should be clarified in the document. Thanks for > the comment. Not only clarifying the text, but also more explicit mobility operation commands such as "add" or "remove" should be defined rather than using the lifetime value. This would be more true if the flow movement is at the prefix level; you don't want to lose all flows with the same prefix by setting the lifetime value to zero for removing just one flow. Please take it into consideration. Regards, -- Hidetoshi Yokota KDDI R&D Laboratories, Inc. e-mail:yokota@kddilabs.jp > Once again, thanks for your comments! > > Carlos > >> Regards, >> -- >> Hidetoshi Yokota >> >> KDDI R&D Laboratories, Inc. >> e-mail:yokota@kddilabs.jp >> >> >> (2014/06/14 2:16), Carlos Jesús Bernardos Cano wrote: >> >>> Hi, >>> >>> As agreed in London, I've updated the flow mobility draft to include >>> also the FMI/FMA signaling option (in addition to the use of Update >>> Notifications). The draft also includes a mechanism to allow selecting >>> which one of the two signaling mechanisms to use. >>> >>> In my personal opinion, it'd be much cleaner and simpler to just specify >>> one signaling mechanism, but this is up to the WG to decide. >>> >>> Comments, reviews and discussion on this new revision would be welcome. >>> Hopefully we could get at least a new revision before Toronto. >>> >>> Thanks, >>> >>> Carlos >>> >>> >>> _______________________________________________ >>> 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 > > > > --------------050007050105040405020704 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Carlos,

Thanks for your response and the discussion is getting more active towards the WGLC!

Please see inline:
(2014/06/20 2:36), Carlos Jesús Bernardos Cano wrote:
Hi Hidetoshi,

Thanks for your comments. Please see inline below.

On Thu, 2014-06-19 at 13:40 +0900, Hidetoshi Yokota wrote:

Hello Carlos,

Thanks for updating the draft. 
I have a couple of questions and comments:

o In Section 3.2.1, which is the shared prefix case, there is no
message exchange between the LMA and MAG, so there is no flow
information on the MAG side. It should work in the sense of routing,
but if, for example, each flow has a specific QoS, the MAG should also
need to know which flow should go on which QoS path especially for
upstream traffic towards the LMA. Or, the MAG may want to send a
trigger for flow mobility to the MN (the exact mechanism is out of
scope).  Some mobility signaling should be there, too.

[Carlos] There was a discussion on this in the past (don't remember
exactly when, but I recall that Rajeev was one of the drivers) and the
group decision was to make the signaling at the prefix level, not at
flow level. If the group think there is value on supporting
flow-granularity signaling, we could add it.

Flow movement at the prefix level is ok, but the new MAG needs to know which flow(s) is/are coming within that prefix to link it/them to proper QoS path(s) and optionally to inform the MN about it. Actual use cases would require more than just routing.


      

        
o In Section 3.3, FMI/FMA are revived considering the case where UPN
is not supported, but they convey very little information. There is no
special information that cannot be conveyed by the existing messages.
Since RFC7077 is now a proposed standard, I cannot think of a
situation where the UPN/UPA are not supported, nevertheless FMI/FMA
are supported. It rather seems more natural to mandate the support of
RFC7077 or to mandate FMI/FMA for all flow mobility operations.
Also, when compared with UPN/UPA case in Figure 4, FMI/FMA seem to
convey different set of parameters in Figure 7. Could you clarify it a
little bit more please?



      

      
[Carlos] As Pierrick has already replied to you, there was discussion in
London about supporting both mechanisms. I think this deserves another
thread on the mailing list devoted to that discussion. As I expressed in
a previous e-mail, my personal opinion as WG member is that we should go
for just one signaling mechanism (being UPN/UPA my preference), but here
I'm acting as the editor of the document and I just updated the document
to reflect the consensus of the room in London.


    

    

      I see, but Sri has a different view on it. Let's discuss it on the
      ML. I also prefer to stick to one set of signaling messages.

      

    
    

      

      

        
o In Section 3.3, just above Figure 7, there is a description: "...,
and the type of flow mobility operation (add flow)", but does RFC6089
define such an operation code? This kind of operation should also be
defined in the draft.


      

      
[Carlos] By "add", a lifetime higher than 0 is meant (as 0 means
"remove"). I agree this should be clarified in the document. Thanks for
the comment.


    

    

    Not only clarifying the
      text, but also more explicit mobility operation commands such as
      "add" or "remove" should be defined rather than using the lifetime
      value. This would be more true if the flow movement is at the
      prefix level; you don't want to lose all flows with the same
      prefix by setting the lifetime value to zero for removing just one
      flow. Please take it into consideration.

      

      Regards,

    
-- 
Hidetoshi Yokota

KDDI R&D Laboratories, Inc.
e-mail:yokota@kddilabs.jp

    

    

      
Once again, thanks for your comments!

Carlos



      

        
Regards,
-- 
Hidetoshi Yokota

KDDI R&D Laboratories, Inc.
e-mail:yokota@kddilabs.jp


(2014/06/14 2:16), Carlos Jesús Bernardos Cano wrote:



        

          
Hi,

As agreed in London, I've updated the flow mobility draft to include
also the FMI/FMA signaling option (in addition to the use of Update
Notifications). The draft also includes a mechanism to allow selecting
which one of the two signaling mechanisms to use.

In my personal opinion, it'd be much cleaner and simpler to just specify
one signaling mechanism, but this is up to the WG to decide.

Comments, reviews and discussion on this new revision would be welcome.
Hopefully we could get at least a new revision before Toronto.

Thanks,

Carlos


_______________________________________________
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


      

      






    

    

  


--------------050007050105040405020704--


From nobody Mon Jun 23 12:37:42 2014
Return-Path: 
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6877F1A037F for ; Mon, 23 Jun 2014 12:37:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.9
X-Spam-Level: 
X-Spam-Status: No, score=0.9 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlG4A0sTvZ01 for ; Mon, 23 Jun 2014 12:37:38 -0700 (PDT)
Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C5DA1A02A3 for ; Mon, 23 Jun 2014 12:37:37 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id n15so4724209wiw.5 for ; Mon, 23 Jun 2014 12:37:36 -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=eOgFxObdXWLgaSLLZys2Fl7nDwYoo87DOuiOpeNS1v8=; b=fJdKc/wxfvukUbzxd8QwuvB+Mbzx4TLnnq9QCSERI//Hbf7scP54woUJIJXSt9kzyH KHgKeiVVmmY3Cf1bBuiOK0vAgp9rPaQVV3up5nKMMQi5o40JsbIEzuB+TrMs0QJrqAdi 08/SxudNdlwGMg3vwYas4Fkr9fU076UoF9amnpERSb1ygPAqwFxWbs2HjQ935JgU9bA+ AVxmD4RWufl1WG4odSk4koFa0maq+bLE34xw07caiMHNvxbHmw//Prq6qIqLcQISWJW8 xO/SEIpERz2DeNvW6udzt6g/a65u1/JBfxzomPi+sJN8Xbn3u7OtAEBVemD7B14wwf8t Ouog==
MIME-Version: 1.0
X-Received: by 10.194.88.199 with SMTP id bi7mr30879722wjb.79.1403552256062; Mon, 23 Jun 2014 12:37:36 -0700 (PDT)
Received: by 10.195.11.132 with HTTP; Mon, 23 Jun 2014 12:37:36 -0700 (PDT)
In-Reply-To: 
References: <12960_1403166742_53A2A016_12960_14955_1_81C77F07008CA24F9783A98CFD706F711425DBD6@PEXCVZYM12.corporate.adroot.infra.ftgroup> 
Date: Mon, 23 Jun 2014 12:37:36 -0700
Message-ID: 
From: Rajeev Koodli 
To: "Sri Gundavelli (sgundave)" 
Content-Type: multipart/alternative; boundary=047d7bf10b12a5799404fc85f970
Archived-At: http://mailarchive.ietf.org/arch/msg/netext/lqUvmpgpCMzVtFHViEx2IpY77Hs
Cc: "netext@ietf.org" 
Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt]
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.15
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, 23 Jun 2014 19:37:40 -0000

--047d7bf10b12a5799404fc85f970
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Yes, but just to be clear: The Flow Mobility ID defines FMI/FMA messages
which use the same format as UPN with the new Code values.

-Rajeev



On Thu, Jun 19, 2014 at 6:46 AM, Sri Gundavelli (sgundave) <
sgundave@cisco.com> wrote:

>  Hi Pierrick,
>
>  After the NETEXT meeting in London, we had some offline discussions with
> Rajiv and folks. There is agreement to use the RFC-7077 (UPN) messaging
> format for FMI/FMA. So, the Flow Mobility spec may refer to this message =
as
> FMI/FMA, but the underneath messaging format will confirm to RFC-7077
> format and will have references to RFC-7077. We are not going to define a
> new MH message. This closes the key issue of using two notification
> approaches in the same spec. AFAIK, no one has any objection to this. If
> any does, its now time to speak up :)
>
>  Regards
> Sri
>
>
>   From: "pierrick.seite@orange.com" 
> Date: Thursday, June 19, 2014 1:32 AM
> To: Hidetoshi Yokota , "netext@ietf.org" <
> netext@ietf.org>
> Subject: Re: [netext] [Fwd: I-D Action:
> draft-ietf-netext-pmipv6-flowmob-09.txt]
>
>   Hi Hidetoshi/all,
>
>
>
> Release -08 mandates RFC7077 and the doc was good, IMHO. But, in London,
> we have decided (group consensus) to reintroduce FMI/FMA to avoid
> dependency between RFC. Now, it=E2=80=99s true that introducing 2 options=
 for
> message format makes the solution more complex for little added-value (no
> major differences between messages)=E2=80=A6 So, maybe the question is =
=E2=80=9Cis it good
> or bad to have RFC dependency?=E2=80=9D then update the draft according t=
he
> answer...
>
>
>
> Pierrick
>
>
>
> *De :* netext [mailto:netext-bounces@ietf.org ] =
*De
> la part de* Hidetoshi Yokota
> *Envoy=C3=A9 :* jeudi 19 juin 2014 06:41
> *=C3=80 :* netext@ietf.org
> *Objet :* Re: [netext] [Fwd: I-D Action:
> draft-ietf-netext-pmipv6-flowmob-09.txt]
>
>
>
> Hello Carlos,
>
> Thanks for updating the draft.
> I have a couple of questions and comments:
>
> o In Section 3.2.1, which is the shared prefix case, there is no message
> exchange between the LMA and MAG, so there is no flow information on the
> MAG side. It should work in the sense of routing, but if, for example, ea=
ch
> flow has a specific QoS, the MAG should also need to know which flow shou=
ld
> go on which QoS path especially for upstream traffic towards the LMA. Or,
> the MAG may want to send a trigger for flow mobility to the MN (the exact
> mechanism is out of scope).  Some mobility signaling should be there, too=
.
>
> o In Section 3.3, FMI/FMA are revived considering the case where UPN is
> not supported, but they convey very little information. There is no speci=
al
> information that cannot be conveyed by the existing messages. Since RFC70=
77
> is now a proposed standard, I cannot think of a situation where the UPN/U=
PA
> are not supported, nevertheless FMI/FMA are supported. It rather seems mo=
re
> natural to mandate the support of RFC7077 or to mandate FMI/FMA for all
> flow mobility operations.
> Also, when compared with UPN/UPA case in Figure 4, FMI/FMA seem to convey
> different set of parameters in Figure 7. Could you clarify it a little bi=
t
> more please?
>
> o In Section 3.3, just above Figure 7, there is a description: "..., and
> the type of flow mobility operation (add flow)", but does RFC6089 define
> such an operation code? This kind of operation should also be defined in
> the draft.
>
> Regards,
>
>  --
>
> Hidetoshi Yokota
>
>
>
> KDDI R&D Laboratories, Inc.
>
> e-mail:yokota@kddilabs.jp
>
>
>
> (2014/06/14 2:16), Carlos Jes=C3=BAs Bernardos Cano wrote:
>
> Hi,
>
>
>
> As agreed in London, I've updated the flow mobility draft to include
>
> also the FMI/FMA signaling option (in addition to the use of Update
>
> Notifications). The draft also includes a mechanism to allow selecting
>
> which one of the two signaling mechanisms to use.
>
>
>
> In my personal opinion, it'd be much cleaner and simpler to just specify
>
> one signaling mechanism, but this is up to the WG to decide.
>
>
>
> Comments, reviews and discussion on this new revision would be welcome.
>
> Hopefully we could get at least a new revision before Toronto.
>
>
>
> Thanks,
>
>
>
> Carlos
>
>
>
>
>  _______________________________________________
>
> netext mailing list
>
> netext@ietf.org
>
> https://www.ietf.org/mailman/listinfo/netext
>
>
>
> _________________________________________________________________________=
________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re=
cu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme o=
u falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged i=
nformation that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>
>
> _______________________________________________
> netext mailing list
> netext@ietf.org
> https://www.ietf.org/mailman/listinfo/netext
>
>

--047d7bf10b12a5799404fc85f970
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Yes, but just to be clear: The Flow Mobility ID d=
efines FMI/FMA messages which use the same format as UPN with the new Code =
values.=C2=A0

-Rajeev




On Thu, Jun 19, 2014 at 6:46 AM, Sri Gun=
davelli (sgundave) <sgundave@cisco.com> wrote:








Hi Pierrick,







After the NETEXT meeting in London, we had some offline discussions wi=
th Rajiv and folks. There is agreement to use the RFC-7077 (UPN) messaging =
format for FMI/FMA. So, the Flow Mobility spec may refer to this message as=
 FMI/FMA, but the underneath messaging
 format will confirm to RFC-7077 format and will have references to RFC-707=
7. We are not going to define a new MH message. This closes the key issue o=
f using two notification approaches in the same spec. AFAIK, no one has any=
 objection to this. If any does,
 its now time to speak up :)







Regards


Sri















From: "pierrick.seite@orange.com"=
 <pierric=
k.seite@orange.com>


Date: Thursday, June 19, 2014 1:32 =
AM

To: Hidetoshi Yokota <yokota@kddilabs.jp>, &=
quot;netext@ietf.org" <netext@ie=
tf.org>


Subject: Re: [netext] [Fwd: I-D Act=
ion: draft-ietf-netext-pmipv6-flowmob-09.txt]

















Hi Hidetoshi/all,


=C2=A0

Release -08 mandates RFC7077 =
and the doc was good, IMHO. But, in London, we have decided (group consensu=
s) to reintroduce FMI/FMA to
 avoid dependency between RFC. Now, it=E2=80=99s true that introducing 2 op=
tions for message format makes the solution more complex for little added-v=
alue (no major differences between messages)=E2=80=A6 So, maybe the questio=
n is =E2=80=9Cis it good or bad to have RFC dependency?=E2=80=9D
 then update the draft according the answer...


=C2=A0

Pierrick=



=C2=A0







De=C2=A0: netext [mailto:netext-bounces@ietf.o=
rg]
De la part de Hidetoshi Yokota

Envoy=C3=A9=C2=A0: jeudi 19 juin 2014 06:41

=C3=80=C2=A0: n=
etext@ietf.org

Objet=C2=A0: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6=
-flowmob-09.txt]






=C2=A0


Hel=
lo Carlos,



Thanks for updating the draft. 

I have a couple of questions and comments:



o In Section 3.2.1, which =
is the shared prefix case, there is no message exchange between the LMA and=
 MAG, so there is no flow information on the MAG side. It should work in th=
e sense of routing, but if, for
 example, each flow has a specific QoS, the MAG should also need to know wh=
ich flow should go on which QoS path especially for upstream traffic toward=
s the LMA. Or, the MAG may want to send a trigger for flow mobility to the =
MN (the exact mechanism is out of
 scope).=C2=A0 Some mobility signaling should be there, too.



o In Section 3.3, FMI/FMA are revived considering the case where UPN is not=
 supported, but they convey very little information. There is no special in=
formation that cannot be conveyed by the existing messages. Since RFC7077 i=
s now a proposed standard, I cannot
 think of a situation where the UPN/UPA are not supported, nevertheless FMI=
/FMA are supported. It rather seems more natural to mandate the support of =
RFC7077 or to mandate FMI/FMA for all flow mobility operations.

Also, when compared with UPN/UPA case in Figure 4, FMI/FMA seem to convey d=
ifferent set of parameters in Figure 7. Could you clarify it a little bit m=
ore please?



o In Section 3.3, just above Figure 7, there is a description: "..., a=
nd the type of flow mobility operation (add flow)", but does RFC6089 d=
efine such an operation code? This kind of operation should also be defined=
 in the draft.




Regards,






-- 


Hidetoshi Yokota


=C2=A0


KDDI R&D Laboratories, Inc.


e-mail:=
yokota@kddilabs.jp


=C2=A0<=
/p>



(2014/06/14 2:16), Carlos Jes=C3=BAs Bernardos Cano =
wrote:






Hi,


=C2=A0


As agreed in London, I've updated the flow mobility draft to inclu=
de


also the FMI/FMA signaling option (in addition to the use of Update=



Notifications). The draft also includes a mechanism to allow selecting=



which one of the two signaling mechanisms to use.


=C2=A0


In my personal opinion, it'd be much cleaner and simpler to just s=
pecify


one signaling mechanism, but this is up to the WG to decide.=



=C2=A0


Comments, reviews and discussion on this new revision would be welcome=
.


Hopefully we could get at least a new revision before Toronto.<=
u>


=C2=A0


Thanks,


=C2=A0


Carlos











_______________________________________________


netext mailing list


netext@ietf.org


https://www.ietf.org/mailman/listinfo/netext




=C2=A0






______________________________________________________________________=
___________________________________________________

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

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












_______________________________________________

netext mailing list

netext@ietf.org

=
https://www.ietf.org/mailman/listinfo/netext





--047d7bf10b12a5799404fc85f970--


From nobody Tue Jun 24 17:03:34 2014
Return-Path: 
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156F31B29E2 for ; Tue, 24 Jun 2014 17:03:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.658
X-Spam-Level: **
X-Spam-Status: No, score=2.658 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIW87OiIWwfl for ; Tue, 24 Jun 2014 17:03:31 -0700 (PDT)
Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id B057F1B29DE for ; Tue, 24 Jun 2014 17:03:30 -0700 (PDT)
Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 353121748172; Wed, 25 Jun 2014 09:03:29 +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 98zbMBY4w3ns; Wed, 25 Jun 2014 09:03:28 +0900 (JST)
Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [172.19.90.145]) by mandala.kddilabs.jp (Postfix) with ESMTP id B2471174811B; Wed, 25 Jun 2014 09:02:26 +0900 (JST)
Received: from [127.0.0.1] (dhcp197.west-4f.cn.kddilabs.jp [172.19.124.197]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id 9B3141B9AB; Wed, 25 Jun 2014 08:47:17 +0900 (JST)
Message-ID: <53AA1194.8080509@kddilabs.jp>
Date: Wed, 25 Jun 2014 09:02:28 +0900
From: Hidetoshi Yokota 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Rajeev Koodli ,  Sri Gundavelli 
References: <12960_1403166742_53A2A016_12960_14955_1_81C77F07008CA24F9783A98CFD706F711425DBD6@PEXCVZYM12.corporate.adroot.infra.ftgroup>	 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040609010700090007040504"
Archived-At: http://mailarchive.ietf.org/arch/msg/netext/AxjTc6mIdFZc2SJPuHHc2est_z8
Cc: "netext@ietf.org" 
Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt]
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Jun 2014 00:03:34 -0000

This is a multi-part message in MIME format.
--------------040609010700090007040504
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

Hi Rajeev,

"New Code" values mean new MH Types or different ones? If your intention
is to define new MH types with exactly the same format as UPN/UPA, then
it would be better to define a new flag or notification reason in UPN/UPA.

Regards,
--
Hidetoshi

(2014/06/24 4:37), Rajeev Koodli wrote:
>
> Yes, but just to be clear: The Flow Mobility ID defines FMI/FMA
> messages which use the same format as UPN with the new Code values.
>
> -Rajeev
>
>
>
> On Thu, Jun 19, 2014 at 6:46 AM, Sri Gundavelli (sgundave)
> > wrote:
>
>     Hi Pierrick,
>
>     After the NETEXT meeting in London, we had some offline
>     discussions with Rajiv and folks. There is agreement to use the
>     RFC-7077 (UPN) messaging format for FMI/FMA. So, the Flow Mobility
>     spec may refer to this message as FMI/FMA, but the underneath
>     messaging format will confirm to RFC-7077 format and will have
>     references to RFC-7077. We are not going to define a new MH
>     message. This closes the key issue of using two notification
>     approaches in the same spec. AFAIK, no one has any objection to
>     this. If any does, its now time to speak up :)
>
>     Regards
>     Sri
>
>
>     From: "pierrick.seite@orange.com
>     "      >
>     Date: Thursday, June 19, 2014 1:32 AM
>     To: Hidetoshi Yokota      >, "netext@ietf.org
>     " >
>     Subject: Re: [netext] [Fwd: I-D Action:
>     draft-ietf-netext-pmipv6-flowmob-09.txt]
>
>     Hi Hidetoshi/all,
>
>     Release -08 mandates RFC7077 and the doc was good, IMHO. But, in
>     London, we have decided (group consensus) to reintroduce FMI/FMA
>     to avoid dependency between RFC. Now, it$B!G(Bs true that introducing 2
>     options for message format makes the solution more complex for
>     little added-value (no major differences between messages)$B!D(B So,
>     maybe the question is $B!H(Bis it good or bad to have RFC dependency?$B!I(B
>     then update the draft according the answer...
>
>     Pierrick
>
>     *De :*netext [mailto:netext-bounces@ietf.org] *De la part de*
>     Hidetoshi Yokota
>     *Envoye' :* jeudi 19 juin 2014 06:41
>     *A` :* netext@ietf.org 
>     *Objet :* Re: [netext] [Fwd: I-D Action:
>     draft-ietf-netext-pmipv6-flowmob-09.txt]
>
>     Hello Carlos,
>
>     Thanks for updating the draft.
>     I have a couple of questions and comments:
>
>     o In Section 3.2.1, which is the shared prefix case, there is no
>     message exchange between the LMA and MAG, so there is no flow
>     information on the MAG side. It should work in the sense of
>     routing, but if, for example, each flow has a specific QoS, the
>     MAG should also need to know which flow should go on which QoS
>     path especially for upstream traffic towards the LMA. Or, the MAG
>     may want to send a trigger for flow mobility to the MN (the exact
>     mechanism is out of scope). Some mobility signaling should be
>     there, too.
>
>     o In Section 3.3, FMI/FMA are revived considering the case where
>     UPN is not supported, but they convey very little information.
>     There is no special information that cannot be conveyed by the
>     existing messages. Since RFC7077 is now a proposed standard, I
>     cannot think of a situation where the UPN/UPA are not supported,
>     nevertheless FMI/FMA are supported. It rather seems more natural
>     to mandate the support of RFC7077 or to mandate FMI/FMA for all
>     flow mobility operations.
>     Also, when compared with UPN/UPA case in Figure 4, FMI/FMA seem to
>     convey different set of parameters in Figure 7. Could you clarify
>     it a little bit more please?
>
>     o In Section 3.3, just above Figure 7, there is a description:
>     "..., and the type of flow mobility operation (add flow)", but
>     does RFC6089 define such an operation code? This kind of operation
>     should also be defined in the draft.
>
>     Regards,
>
>     -- 
>
>     Hidetoshi Yokota
>
>      
>
>     KDDI R&D Laboratories, Inc.
>
>     e-mail:yokota@kddilabs.jp 
>
>     (2014/06/14 2:16), Carlos Jesu's Bernardos Cano wrote:
>
>         Hi,
>
>          
>
>         As agreed in London, I've updated the flow mobility draft to include
>
>         also the FMI/FMA signaling option (in addition to the use of Update
>
>         Notifications). The draft also includes a mechanism to allow selecting
>
>         which one of the two signaling mechanisms to use.
>
>          
>
>         In my personal opinion, it'd be much cleaner and simpler to just specify
>
>         one signaling mechanism, but this is up to the WG to decide.
>
>          
>
>         Comments, reviews and discussion on this new revision would be welcome.
>
>         Hopefully we could get at least a new revision before Toronto.
>
>          
>
>         Thanks,
>
>          
>
>         Carlos
>
>
>
>
>         _______________________________________________
>
>         netext mailing list
>
>         netext@ietf.org 
>
>         https://www.ietf.org/mailman/listinfo/netext
>
>     _________________________________________________________________________________________________________________________
>
>     Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>     pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>     a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>     Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>     This message and its attachments may contain confidential or privileged information that may be protected by law;
>     they should not be distributed, used or copied without authorisation.
>     If you have received this email in error, please notify the sender and delete this message and its attachments.
>     As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>     Thank you.
>
>
>     _______________________________________________
>     netext mailing list
>     netext@ietf.org 
>     https://www.ietf.org/mailman/listinfo/netext
>


--------------040609010700090007040504
Content-Type: text/html; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi Rajeev,

      

      "New Code" values mean new MH Types or different ones? If your
      intention is to define new MH types with exactly the same format
      as UPN/UPA, then it would be better to define a new flag or
      notification reason in UPN/UPA.

      

      Regards,

      --

      Hidetoshi

      

    
    
(2014/06/24 4:37), Rajeev Koodli wrote:

    

    

      


        
Yes, but just to be clear: The Flow Mobility ID defines
          FMI/FMA messages which use the same format as UPN with the new
          Code values. 

        


        

        
-Rajeev

        


        

        

          

          

          
On Thu, Jun 19, 2014 at 6:46 AM, Sri
            Gundavelli (sgundave) <sgundave@cisco.com> wrote:

            

              

                
Hi Pierrick,

                


                

                
After the NETEXT meeting in London, we had some
                  offline discussions with Rajiv and folks. There is
                  agreement to use the RFC-7077 (UPN) messaging format
                  for FMI/FMA. So, the Flow Mobility spec may refer to
                  this message as FMI/FMA, but the underneath messaging
                  format will confirm to RFC-7077 format and will have
                  references to RFC-7077. We are not going to define a
                  new MH message. This closes the key issue of using two
                  notification approaches in the same spec. AFAIK, no
                  one has any objection to this. If any does, its now
                  time to speak up :)

                


                

                
Regards

                
Sri

                


                

                


                

                
                  

                    From: "pierrick.seite@orange.com"
                    <pierrick.seite@orange.com>

                    Date: Thursday,
                    June 19, 2014 1:32 AM

                    To: Hidetoshi
                    Yokota <yokota@kddilabs.jp>,
                    "netext@ietf.org"
                    <netext@ietf.org>

                    Subject: Re:
                    [netext] [Fwd: I-D Action:
                    draft-ietf-netext-pmipv6-flowmob-09.txt]

                  

                  

                    

                      


                      

                      

                        

                          

                            
Hi Hidetoshi/all,

                            
 

                            
Release -08 mandates
                                RFC7077 and the doc was good, IMHO. But,
                                in London, we have decided (group
                                consensus) to reintroduce FMI/FMA to
                                avoid dependency between RFC. Now, it$B!G(Bs
                                true that introducing 2 options for
                                message format makes the solution more
                                complex for little added-value (no major
                                differences between messages)$B!D(B So, maybe
                                the question is $B!H(Bis it good or bad to
                                have RFC dependency?$B!I(B then update the
                                draft according the answer...

                            
 

                            
Pierrick

                            
 

                            

                              

                                

                                  
De :
                                      netext [mailto:netext-bounces@ietf.org]
                                      De la part de Hidetoshi
                                      Yokota

                                      Envoyé : jeudi 19 juin 2014
                                      06:41

                                      À : netext@ietf.org

                                      Objet : Re: [netext] [Fwd:
                                      I-D Action:
                                      draft-ietf-netext-pmipv6-flowmob-09.txt]

                                

                              

                              
 

                              
Hello
                                  Carlos,

                                  

                                  Thanks for updating the draft. 

                                  I have a couple of questions and
                                  comments:

                                

                                o
                                  In Section 3.2.1, which is the shared
                                  prefix case, there is no message
                                  exchange between the LMA and MAG, so
                                  there is no flow information on the
                                  MAG side. It should work in the sense
                                  of routing, but if, for example, each
                                  flow has a specific QoS, the MAG
                                  should also need to know which flow
                                  should go on which QoS path especially
                                  for upstream traffic towards the LMA.
                                  Or, the MAG may want to send a trigger
                                  for flow mobility to the MN (the exact
                                  mechanism is out of scope).  Some
                                  mobility signaling should be there,
                                  too.

                                  

                                  o In Section 3.3, FMI/FMA are revived
                                  considering the case where UPN is not
                                  supported, but they convey very little
                                  information. There is no special
                                  information that cannot be conveyed by
                                  the existing messages. Since RFC7077
                                  is now a proposed standard, I cannot
                                  think of a situation where the UPN/UPA
                                  are not supported, nevertheless
                                  FMI/FMA are supported. It rather seems
                                  more natural to mandate the support of
                                  RFC7077 or to mandate FMI/FMA for all
                                  flow mobility operations.

                                  Also, when compared with UPN/UPA case
                                  in Figure 4, FMI/FMA seem to convey
                                  different set of parameters in Figure
                                  7. Could you clarify it a little bit
                                  more please?

                                  

                                  o In Section 3.3, just above Figure 7,
                                  there is a description: "..., and the
                                  type of flow mobility operation (add
                                  flow)", but does RFC6089 define such
                                  an operation code? This kind of
                                  operation should also be defined in
                                  the draft.

                                  

                                  Regards,

                                  

                                

                              
-- 

                              
Hidetoshi Yokota

                              
 

                              
KDDI R&D Laboratories, Inc.

                              
e-mail:yokota@kddilabs.jp

                              
 

                              

                                
(2014/06/14 2:16),
                                  Carlos Jesús Bernardos Cano wrote:

                              

                              

                                
Hi,

                                
 

                                
As agreed in London, I've updated the flow mobility draft to include

                                
also the FMI/FMA signaling option (in addition to the use of Update

                                
Notifications). The draft also includes a mechanism to allow selecting

                                
which one of the two signaling mechanisms to use.

                                
 

                                
In my personal opinion, it'd be much cleaner and simpler to just specify

                                
one signaling mechanism, but this is up to the WG to decide.

                                
 

                                
Comments, reviews and discussion on this new revision would be welcome.

                                
Hopefully we could get at least a new revision before Toronto.

                                
 

                                
Thanks,

                                
 

                                
Carlos

                                


                                  

                                  

                                

                                
_______________________________________________

                                
netext mailing list

                                
netext@ietf.org

                                
https://www.ietf.org/mailman/listinfo/netext

                              

                              
 

                            

                          

                          
_________________________________________________________________________________________________________________________

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

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


                        

                      

                    

                  

                
              

              

              _______________________________________________

              netext mailing list

              netext@ietf.org

              https://www.ietf.org/mailman/listinfo/netext

              

            

          

        

      

    

    

  


--------------040609010700090007040504--


From nobody Wed Jun 25 10:51:39 2014
Return-Path: 
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1B71B2D97 for ; Wed, 25 Jun 2014 10:51:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.552
X-Spam-Level: 
X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysi_4d5rgkoc for ; Wed, 25 Jun 2014 10:51:30 -0700 (PDT)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F6261B2D90 for ; Wed, 25 Jun 2014 10:51:30 -0700 (PDT)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id BD4D28B7677; Wed, 25 Jun 2014 19:51:28 +0200 (CEST)
X-uc3m-safe: yes
X-uc3m-safe: yes
Received: from [192.168.49.75] (93-57-93-58.ip163.fastwebnet.it [93.57.93.58]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id D935F767924; Wed, 25 Jun 2014 19:51:27 +0200 (CEST)
Message-ID: <1403718683.11909.2.camel@acorde.it.uc3m.es>
From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano 
To: Hidetoshi Yokota 
Date: Wed, 25 Jun 2014 19:51:23 +0200
In-Reply-To: <53A6277F.6080608@kddilabs.jp>
References: <1402679783.4063.11.camel@acorde.it.uc3m.es> <53A269DB.6050504@kddilabs.jp> <1403199406.4456.36.camel@acorde.it.uc3m.es> <53A6277F.6080608@kddilabs.jp>
Organization: Universidad Carlos III de Madrid
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.8.5-2+b3 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20780.001
X-TM-AS-Result: No--27.893-7.0-31-1
X-imss-scan-details: No--27.893-7.0-31-1
Archived-At: http://mailarchive.ietf.org/arch/msg/netext/v4bRy-bxrntDfc3v6O2UWDxwBxM
Cc: "netext@ietf.org" 
Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt]
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Jun 2014 17:51:35 -0000

Hi Hidetoshi,

On Sun, 2014-06-22 at 09:46 +0900, Hidetoshi Yokota wrote:
> Hi Carlos,
> 
> Thanks for your response and the discussion is getting more active
> towards the WGLC!
> 
> Please see inline:
> 
> (2014/06/20 2:36), Carlos Jesús Bernardos Cano wrote:
> 
> > Hi Hidetoshi,
> > 
> > Thanks for your comments. Please see inline below.
> > 
> > On Thu, 2014-06-19 at 13:40 +0900, Hidetoshi Yokota wrote:
> > > Hello Carlos,
> > > 
> > > Thanks for updating the draft. 
> > > I have a couple of questions and comments:
> > > 
> > > o In Section 3.2.1, which is the shared prefix case, there is no
> > > message exchange between the LMA and MAG, so there is no flow
> > > information on the MAG side. It should work in the sense of routing,
> > > but if, for example, each flow has a specific QoS, the MAG should also
> > > need to know which flow should go on which QoS path especially for
> > > upstream traffic towards the LMA. Or, the MAG may want to send a
> > > trigger for flow mobility to the MN (the exact mechanism is out of
> > > scope).  Some mobility signaling should be there, too.
> > [Carlos] There was a discussion on this in the past (don't remember
> > exactly when, but I recall that Rajeev was one of the drivers) and the
> > group decision was to make the signaling at the prefix level, not at
> > flow level. If the group think there is value on supporting
> > flow-granularity signaling, we could add it.
> 
> Flow movement at the prefix level is ok, but the new MAG needs to know
> which flow(s) is/are coming within that prefix to link it/them to
> proper QoS path(s) and optionally to inform the MN about it. Actual
> use cases would require more than just routing.

Yes, I see your point here, as this was originally discussed. I'd like
to know what the feeling of the WG on this matter.
> 
> > > o In Section 3.3, FMI/FMA are revived considering the case where UPN
> > > is not supported, but they convey very little information. There is no
> > > special information that cannot be conveyed by the existing messages.
> > > Since RFC7077 is now a proposed standard, I cannot think of a
> > > situation where the UPN/UPA are not supported, nevertheless FMI/FMA
> > > are supported. It rather seems more natural to mandate the support of
> > > RFC7077 or to mandate FMI/FMA for all flow mobility operations.
> > > Also, when compared with UPN/UPA case in Figure 4, FMI/FMA seem to
> > > convey different set of parameters in Figure 7. Could you clarify it a
> > > little bit more please?
> > > 
> > [Carlos] As Pierrick has already replied to you, there was discussion in
> > London about supporting both mechanisms. I think this deserves another
> > thread on the mailing list devoted to that discussion. As I expressed in
> > a previous e-mail, my personal opinion as WG member is that we should go
> > for just one signaling mechanism (being UPN/UPA my preference), but here
> > I'm acting as the editor of the document and I just updated the document
> > to reflect the consensus of the room in London.
> 
> I see, but Sri has a different view on it. Let's discuss it on the ML.
> I also prefer to stick to one set of signaling messages.

Based on the discussion, I'm going to send an updated version with just
one set of signaling messages (either later today or tomorrow).
> 
> > > o In Section 3.3, just above Figure 7, there is a description: "...,
> > > and the type of flow mobility operation (add flow)", but does RFC6089
> > > define such an operation code? This kind of operation should also be
> > > defined in the draft.
> > [Carlos] By "add", a lifetime higher than 0 is meant (as 0 means
> > "remove"). I agree this should be clarified in the document. Thanks for
> > the comment.
> 
> Not only clarifying the text, but also more explicit mobility
> operation commands such as "add" or "remove" should be defined rather
> than using the lifetime value. This would be more true if the flow
> movement is at the prefix level; you don't want to lose all flows with
> the same prefix by setting the lifetime value to zero for removing
> just one flow. Please take it into consideration.

Let's go back to this once we have the new version with one single
signaling mechanism.

Thanks,

Carlos

> 
> Regards,
> -- 
> Hidetoshi Yokota
> 
> KDDI R&D Laboratories, Inc.
> e-mail:yokota@kddilabs.jp
> 
> > Once again, thanks for your comments!
> > 
> > Carlos
> > 
> > > Regards,
> > 


From nobody Wed Jun 25 15:03:07 2014
Return-Path: 
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C48CB1B27CB; Wed, 25 Jun 2014 15:03:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aD54v9OjiBO5; Wed, 25 Jun 2014 15:03:01 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7621B27BD; Wed, 25 Jun 2014 15:03:01 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.5.0.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140625220301.8706.95576.idtracker@ietfa.amsl.com>
Date: Wed, 25 Jun 2014 15:03:01 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/netext/JfqiQjuy4RBhbfLKNlLxFLc39gU
Cc: netext@ietf.org
Subject: [netext] I-D Action: draft-ietf-netext-pmipv6-flowmob-10.txt
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Jun 2014 22:03:03 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF.

        Title           : Proxy Mobile IPv6 Extensions to Support Flow Mobility
        Author          : Carlos J. Bernardos
	Filename        : draft-ietf-netext-pmipv6-flowmob-10.txt
	Pages           : 22
	Date            : 2014-06-25

Abstract:
   Proxy Mobile IPv6 allows a mobile node to connect to the same Proxy
   Mobile IPv6 domain through different interfaces.  This document
   describes extensions to the Proxy Mobile IPv6 protocol that are
   required to support network based flow mobility over multiple
   physical interfaces.

   The extensions described in this document consist on the operations
   performed by the local mobility anchor and the mobile access gateway
   to manage the prefixes assigned to the different interfaces of the
   mobile node, as well as how the forwarding policies are handled by
   the network to ensure consistent flow mobility management.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netext-pmipv6-flowmob/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-netext-pmipv6-flowmob-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-pmipv6-flowmob-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Jun 25 15:05:33 2014
Return-Path: 
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07A51B27D7 for ; Wed, 25 Jun 2014 15:05:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.552
X-Spam-Level: 
X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWdetcgqmM8N for ; Wed, 25 Jun 2014 15:05:26 -0700 (PDT)
Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB8551B27C3 for ; Wed, 25 Jun 2014 15:05:25 -0700 (PDT)
Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 9DA1E15166B9; Thu, 26 Jun 2014 00:05:23 +0200 (CEST)
X-uc3m-safe: yes
X-uc3m-safe: yes
Received: from [192.168.49.75] (93-57-93-58.ip163.fastwebnet.it [93.57.93.58]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id 22DD29D3393; Thu, 26 Jun 2014 00:05:23 +0200 (CEST)
Message-ID: <1403733921.11909.19.camel@acorde.it.uc3m.es>
From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano 
To: "Sri Gundavelli (sgundave)" 
Date: Thu, 26 Jun 2014 00:05:21 +0200
In-Reply-To: 
References: 
Organization: Universidad Carlos III de Madrid
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.8.5-2+b3 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20780.002
X-TM-AS-Result: No--33.211-7.0-31-1
X-imss-scan-details: No--33.211-7.0-31-1
Archived-At: http://mailarchive.ietf.org/arch/msg/netext/DkfY4rk4-qF8ll3f2zel0WxcdA4
Cc: "netext@ietf.org" 
Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt]
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Jun 2014 22:05:30 -0000

Hi,

I've just posted -10, now including only one single signaling
mechanisms, as discussed on the ML.

I think this version is ready for WGLC.

Carlos

On Thu, 2014-06-19 at 18:09 +0000, Sri Gundavelli (sgundave) wrote:
> Hi Carlos/All,
> 
> 
> Can we plan to close this work in the next few days. AFAIK, this
> FMI/FMA issue is now resolved. If you still doubt the consensus on
> this issue, we can wait for 2 days for any comments and post the next
> rev.
> 
> 
> I'm hoping we will close this work this week and go LC on Monday (if
> chairs agree). Waiting for Toronto meeting can delay the work by
> another few months.
> 
> 
> 
> 
> Regards
> Sri
> 
> 
> From: Sri Gundavelli 
> Date: Thursday, June 19, 2014 6:46 AM
> To: "pierrick.seite@orange.com" , Hidetoshi
> Yokota , "netext@ietf.org" 
> Subject: Re: [netext] [Fwd: I-D Action:
> draft-ietf-netext-pmipv6-flowmob-09.txt]
> 
> 
> 
> Hi Pierrick,
> 
> 
> After the NETEXT meeting in London, we had some offline discussions
> with Rajiv and folks. There is agreement to use the RFC-7077 (UPN)
> messaging format for FMI/FMA. So, the Flow Mobility spec may refer to
> this message as FMI/FMA, but the underneath messaging format will
> confirm to RFC-7077 format and will have references to RFC-7077. We
> are not going to define a new MH message. This closes the key issue of
> using two notification approaches in the same spec. AFAIK, no one has
> any objection to this. If any does, its now time to speak up :)
> 
> 
> Regards
> Sri
> 
> 
> 
> 
> From: "pierrick.seite@orange.com" 
> Date: Thursday, June 19, 2014 1:32 AM
> To: Hidetoshi Yokota , "netext@ietf.org"
> 
> Subject: Re: [netext] [Fwd: I-D Action:
> draft-ietf-netext-pmipv6-flowmob-09.txt]
> 
> 
> 
> Hi Hidetoshi/all,
> 
>  
> 
> Release -08 mandates RFC7077 and the doc was good, IMHO. But, in
> London, we have decided (group consensus) to reintroduce FMI/FMA to
> avoid dependency between RFC. Now, it’s true that introducing 2
> options for message format makes the solution more complex for little
> added-value (no major differences between messages)… So, maybe the
> question is “is it good or bad to have RFC dependency?” then update
> the draft according the answer...
> 
>  
> 
> Pierrick
> 
>  
> 
> De : netext [mailto:netext-bounces@ietf.org] De la part de Hidetoshi
> Yokota
> Envoyé : jeudi 19 juin 2014 06:41
> À : netext@ietf.org
> Objet : Re: [netext] [Fwd: I-D Action:
> draft-ietf-netext-pmipv6-flowmob-09.txt]
> 
> 
>  
> 
> Hello Carlos,
> 
> Thanks for updating the draft. 
> I have a couple of questions and comments:
> 
> o In Section 3.2.1, which is the shared prefix case, there is no
> message exchange between the LMA and MAG, so there is no flow
> information on the MAG side. It should work in the sense of routing,
> but if, for example, each flow has a specific QoS, the MAG should also
> need to know which flow should go on which QoS path especially for
> upstream traffic towards the LMA. Or, the MAG may want to send a
> trigger for flow mobility to the MN (the exact mechanism is out of
> scope).  Some mobility signaling should be there, too.
> 
> o In Section 3.3, FMI/FMA are revived considering the case where UPN
> is not supported, but they convey very little information. There is no
> special information that cannot be conveyed by the existing messages.
> Since RFC7077 is now a proposed standard, I cannot think of a
> situation where the UPN/UPA are not supported, nevertheless FMI/FMA
> are supported. It rather seems more natural to mandate the support of
> RFC7077 or to mandate FMI/FMA for all flow mobility operations.
> Also, when compared with UPN/UPA case in Figure 4, FMI/FMA seem to
> convey different set of parameters in Figure 7. Could you clarify it a
> little bit more please?
> 
> o In Section 3.3, just above Figure 7, there is a description: "...,
> and the type of flow mobility operation (add flow)", but does RFC6089
> define such an operation code? This kind of operation should also be
> defined in the draft.
> 
> Regards,
> 
> 
> 
> -- 
> Hidetoshi Yokota
>  
> KDDI R&D Laboratories, Inc.
> e-mail:yokota@kddilabs.jp
> 
>  
> 
> (2014/06/14 2:16), Carlos Jesús Bernardos Cano wrote:
> 
> 
>         Hi,
>          
>         As agreed in London, I've updated the flow mobility draft to include
>         also the FMI/FMA signaling option (in addition to the use of Update
>         Notifications). The draft also includes a mechanism to allow selecting
>         which one of the two signaling mechanisms to use.
>          
>         In my personal opinion, it'd be much cleaner and simpler to just specify
>         one signaling mechanism, but this is up to the WG to decide.
>          
>         Comments, reviews and discussion on this new revision would be welcome.
>         Hopefully we could get at least a new revision before Toronto.
>          
>         Thanks,
>          
>         Carlos
>         
>         
>         
>         
>         _______________________________________________
>         netext mailing list
>         netext@ietf.org
>         https://www.ietf.org/mailman/listinfo/netext
> 
>  
> 
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> _______________________________________________
> netext mailing list
> netext@ietf.org
> https://www.ietf.org/mailman/listinfo/netext



From nobody Sun Jun 29 06:32:20 2014
Return-Path: 
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0C11A04AC for ; Sun, 29 Jun 2014 06:32:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level: 
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lk04b6XF2ej8 for ; Sun, 29 Jun 2014 06:32:17 -0700 (PDT)
Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6A851A04A2 for ; Sun, 29 Jun 2014 06:32:17 -0700 (PDT)
Received: by mail-pd0-f175.google.com with SMTP id v10so6781412pde.20 for ; Sun, 29 Jun 2014 06:32:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=1qnVf7YahQ0AYnXXELEkXVtfHkwokI5dJid0s3c/r58=; b=SX/O2gUK5PwtdSGtEsu9QA5Q4YypDKdL+KzUhYPKydRm2zn8VVMT6+Tb784WMpp9xx j5Jb4N/ARBz9s8uUHqs/01U7SHvYfo/SGMOKJxrgB0GT6c/O6cu06N8eVYVRyt8CVUL9 dEtfuGOlW1+xNI5iOkRHG6NRg4GWi/JfcJVHCkK8EVFR4HXv/bPmU/tSnHf4pHXahV9H qKVRB2AioWo5aWU6XBKI9Jaog79CgisrJOox2AeYu0ZL0ASfBpBnjJBWPuN0kbtTfSMO Jk/enFruX8ITQJGR4S+P3+eDbzG5EqhTXNLoolXpqbql4vCTjy/1urn4dy0ePdhrEuql exXw==
X-Received: by 10.68.223.202 with SMTP id qw10mr44132279pbc.163.1404048737485;  Sun, 29 Jun 2014 06:32:17 -0700 (PDT)
Received: from [192.168.0.2] (KD125052188134.ppp-bb.dion.ne.jp. [125.52.188.134]) by mx.google.com with ESMTPSA id fk4sm83472127pab.23.2014.06.29.06.32.12 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 29 Jun 2014 06:32:16 -0700 (PDT)
Message-ID: <53B0155E.2050002@gmail.com>
Date: Sun, 29 Jun 2014 22:32:14 +0900
From: Hidetoshi Yokota 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: =?UTF-8?B?Q2FybG9zIEplc8O6cyBCZXJuYXJkb3MgQ2Fubw==?= , Sri Gundavelli 
References:  <1403733921.11909.19.camel@acorde.it.uc3m.es>
In-Reply-To: <1403733921.11909.19.camel@acorde.it.uc3m.es>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netext/wideWaOxN5uvytxIQUbzUSTqE8U
Cc: "netext@ietf.org" 
Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt]
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.15
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, 29 Jun 2014 13:32:19 -0000

Hi Carlos,

I briefly reviewed the updated draft and have a couple of comments.

o The messages named as FMI/FMA in this document are actually UPN/UPA, 
so the description is confusing since it looks as if new messages were 
defined. I would propose a new flag or notification reason/status code 
to indicate that UPN/UPA are used for flow mobility.

o In the previous version, FMI could convey the Flow ID mobility option, 
but the latest version can convey only HNPs. This looks like a 
degradation and I'm not sure how both LMA and MAG can share the same 
flow mobility cache.

o The flow mobility operation such as "add" or "remove" should be able 
to specify the targeted flow. To this end, the Flow ID mobility option 
in RFC6089 should be used. The flow binding action sub-option defined in 
RFC7109 can be used for the flow mobility operation.

Please take these points into consideration.

Regards,
--
Hidetoshi

(2014/06/26 7:05), Carlos Jesús Bernardos Cano wrote:
> Hi,
>
> I've just posted -10, now including only one single signaling
> mechanisms, as discussed on the ML.
>
> I think this version is ready for WGLC.
>
> Carlos
>
> On Thu, 2014-06-19 at 18:09 +0000, Sri Gundavelli (sgundave) wrote:
>> Hi Carlos/All,
>>
>>
>> Can we plan to close this work in the next few days. AFAIK, this
>> FMI/FMA issue is now resolved. If you still doubt the consensus on
>> this issue, we can wait for 2 days for any comments and post the next
>> rev.
>>
>>
>> I'm hoping we will close this work this week and go LC on Monday (if
>> chairs agree). Waiting for Toronto meeting can delay the work by
>> another few months.
>>
>>
>>
>>
>> Regards
>> Sri
>>
>>
>> From: Sri Gundavelli 
>> Date: Thursday, June 19, 2014 6:46 AM
>> To: "pierrick.seite@orange.com" , Hidetoshi
>> Yokota , "netext@ietf.org" 
>> Subject: Re: [netext] [Fwd: I-D Action:
>> draft-ietf-netext-pmipv6-flowmob-09.txt]
>>
>>
>>
>> Hi Pierrick,
>>
>>
>> After the NETEXT meeting in London, we had some offline discussions
>> with Rajiv and folks. There is agreement to use the RFC-7077 (UPN)
>> messaging format for FMI/FMA. So, the Flow Mobility spec may refer to
>> this message as FMI/FMA, but the underneath messaging format will
>> confirm to RFC-7077 format and will have references to RFC-7077. We
>> are not going to define a new MH message. This closes the key issue of
>> using two notification approaches in the same spec. AFAIK, no one has
>> any objection to this. If any does, its now time to speak up :)
>>
>>
>> Regards
>> Sri
>>
>>
>>
>>
>> From: "pierrick.seite@orange.com" 
>> Date: Thursday, June 19, 2014 1:32 AM
>> To: Hidetoshi Yokota , "netext@ietf.org"
>> 
>> Subject: Re: [netext] [Fwd: I-D Action:
>> draft-ietf-netext-pmipv6-flowmob-09.txt]
>>
>>
>>
>> Hi Hidetoshi/all,
>>
>>   
>>
>> Release -08 mandates RFC7077 and the doc was good, IMHO. But, in
>> London, we have decided (group consensus) to reintroduce FMI/FMA to
>> avoid dependency between RFC. Now, it’s true that introducing 2
>> options for message format makes the solution more complex for little
>> added-value (no major differences between messages)… So, maybe the
>> question is “is it good or bad to have RFC dependency?” then update
>> the draft according the answer...
>>
>>   
>>
>> Pierrick
>>
>>   
>>
>> De : netext [mailto:netext-bounces@ietf.org] De la part de Hidetoshi
>> Yokota
>> Envoyé : jeudi 19 juin 2014 06:41
>> À : netext@ietf.org
>> Objet : Re: [netext] [Fwd: I-D Action:
>> draft-ietf-netext-pmipv6-flowmob-09.txt]
>>
>>
>>   
>>
>> Hello Carlos,
>>
>> Thanks for updating the draft.
>> I have a couple of questions and comments:
>>
>> o In Section 3.2.1, which is the shared prefix case, there is no
>> message exchange between the LMA and MAG, so there is no flow
>> information on the MAG side. It should work in the sense of routing,
>> but if, for example, each flow has a specific QoS, the MAG should also
>> need to know which flow should go on which QoS path especially for
>> upstream traffic towards the LMA. Or, the MAG may want to send a
>> trigger for flow mobility to the MN (the exact mechanism is out of
>> scope).  Some mobility signaling should be there, too.
>>
>> o In Section 3.3, FMI/FMA are revived considering the case where UPN
>> is not supported, but they convey very little information. There is no
>> special information that cannot be conveyed by the existing messages.
>> Since RFC7077 is now a proposed standard, I cannot think of a
>> situation where the UPN/UPA are not supported, nevertheless FMI/FMA
>> are supported. It rather seems more natural to mandate the support of
>> RFC7077 or to mandate FMI/FMA for all flow mobility operations.
>> Also, when compared with UPN/UPA case in Figure 4, FMI/FMA seem to
>> convey different set of parameters in Figure 7. Could you clarify it a
>> little bit more please?
>>
>> o In Section 3.3, just above Figure 7, there is a description: "...,
>> and the type of flow mobility operation (add flow)", but does RFC6089
>> define such an operation code? This kind of operation should also be
>> defined in the draft.
>>
>> Regards,
>>
>>
>>
>> -- 
>> Hidetoshi Yokota
>>   
>> KDDI R&D Laboratories, Inc.
>> e-mail:yokota@kddilabs.jp
>>
>>   
>>
>> (2014/06/14 2:16), Carlos Jesús Bernardos Cano wrote:
>>
>>
>>          Hi,
>>           
>>          As agreed in London, I've updated the flow mobility draft to include
>>          also the FMI/FMA signaling option (in addition to the use of Update
>>          Notifications). The draft also includes a mechanism to allow selecting
>>          which one of the two signaling mechanisms to use.
>>           
>>          In my personal opinion, it'd be much cleaner and simpler to just specify
>>          one signaling mechanism, but this is up to the WG to decide.
>>           
>>          Comments, reviews and discussion on this new revision would be welcome.
>>          Hopefully we could get at least a new revision before Toronto.
>>           
>>          Thanks,
>>           
>>          Carlos
>>          
>>          
>>          
>>          
>>          _______________________________________________
>>          netext mailing list
>>          netext@ietf.org
>>          https://www.ietf.org/mailman/listinfo/netext
>>
>>   
>>
>>
>> _________________________________________________________________________________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>> Thank you.
>> _______________________________________________
>> netext mailing list
>> netext@ietf.org
>> https://www.ietf.org/mailman/listinfo/netext
>
>
>
>