From Basavaraj.Patil@nokia.com Tue Feb 1 15:43:56 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA0063A7019 for ; Tue, 1 Feb 2011 15:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.366 X-Spam-Level: X-Spam-Status: No, score=-103.366 tagged_above=-999 required=5 tests=[AWL=-0.767, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcEsCqx5aXuZ for ; Tue, 1 Feb 2011 15:43:56 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id D76903A7006 for ; Tue, 1 Feb 2011 15:43:55 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p11NlAG1006962 for ; Wed, 2 Feb 2011 01:47:13 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Feb 2011 01:47:06 +0200 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 2 Feb 2011 00:47:05 +0100 Received: from 008-AM1MPN1-005.mgdnok.nokia.com ([169.254.4.149]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi; Wed, 2 Feb 2011 00:47:05 +0100 From: To: Thread-Topic: Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLwmpURzmRlysrlUidlexdQorGZA== Date: Tue, 1 Feb 2011 23:47:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Feb 2011 23:47:06.0203 (UTC) FILETIME=[5534B2B0:01CBC26A] X-Nokia-AV: Clean Subject: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 23:43:56 -0000 Hello, We have discussed the flow mobility solutions for Proxy MIP6 previously at IETFs 78 and 79.=20 This is a consensus call for adopting this I-D: draft-bernardos-netext-pmipv6-flowmob-02 as the working group document. I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt The consensus call will expire on Feb 15th, 2011. Please indicate your support or concerns in adopting this I-D as the WG baseline document on the mailing list.=20 Please note that this I-D will serve as the baseline in the WG and will be developed further based on input and feedback from WG members. -Basavaraj From sfaccinstd@gmail.com Tue Feb 1 18:36:16 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EE2C3A7121 for ; Tue, 1 Feb 2011 18:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CA9+8OFhrG5a for ; Tue, 1 Feb 2011 18:36:15 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 149393A7126 for ; Tue, 1 Feb 2011 18:36:14 -0800 (PST) Received: by qwi2 with SMTP id 2so7874064qwi.31 for ; Tue, 01 Feb 2011 18:39:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZLDuJpFHMINkhEqBE6b43SATNxvpy+6IpOd2JEb1XHM=; b=DktBEK1HuZLrzkQw+P8x7qGigBZULNtNXerTjIgtO9pewksQHnk3BjIaOBgubfh/LB i3DHXyGDwU1/uQIDhjqJkHOm85SMthudn5b+l/vKojXR19v4edQBwGVpTNGHQxHEN1/0 SCSZLlyzHiMsdLPTzav08QpssXBKKlavkyJ6g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=aPNbdOyoBsFsZ4l5krAXbJ/DrAutXUubY91iVJHLdv/LWt6bdG32o2eQaceZwPh50c jV9lbBU5CCcN3lMg9bCienD/TsXNn34qRW3kbZtk/ub+yFL5GUnX5RQYktzHTF54H8ac /AbWhQKBslUht0QTke6KbGNZEo4P9LR4s6sn8= MIME-Version: 1.0 Received: by 10.224.11.83 with SMTP id s19mr1826051qas.93.1296614371900; Tue, 01 Feb 2011 18:39:31 -0800 (PST) Received: by 10.229.20.70 with HTTP; Tue, 1 Feb 2011 18:39:31 -0800 (PST) In-Reply-To: References: Date: Tue, 1 Feb 2011 18:39:31 -0800 Message-ID: From: stefano faccin To: Basavaraj.Patil@nokia.com Content-Type: multipart/alternative; boundary=0015175cda5e0c3e27049b438fba Cc: netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 02:36:16 -0000 --0015175cda5e0c3e27049b438fba Content-Type: text/plain; charset=ISO-8859-1 Raj, thanks for the email. I need to apologize in advance if my questions have already been answered before (though I cannot find a conclusive answer anywhere). I think that a protocol that is developed in NETEXT (or other groups) should have at least a potential realistic scenario for applicability. In terms of applicability, though it is not part of the protocol definition per se, unless there are solutions in place for either the host to indicate to the network where the flows should be routed or for the LMA to receive somehow from somewhere some policies, the solution cannot really provide flow mobility since there is no way to decide which flows are routed where. If we are thinking about a host-based solution, I have not yet seen a solution as to how the host can indicate to the MAG and ultimately to the MAG which flows should be routed on each access. If we are relying on modifications of layer 2 protocols, aren't we defining a solution that works only with some technologies (since for other access technologies it is rather unrealistic to modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-based solution, can we hear of at least one example of a real-life scenario where the LMA would receive such policies, and how such delivery would happen? Also, should there be a solution to have policies in the LMA, how does the LMA actually decide to route flows on one access or the other? E.g., if some flows need to be routed on certain WLAN networks, but shall not be routed on other WLAN networks, how does the LMA know which specific WLAN network the host is connected to? Perhaps I missed the ability for the MAG to know e.g. the WLAN SSID and provide it to the LMA, in which case I would appreciate if somebody could highlight to me where that is defined. I think that, though not integral to the protocol specification, understanding what framework the protocol would/needs to fit in is rather important. Cheers, Stefano On Tue, Feb 1, 2011 at 3:47 PM, wrote: > > Hello, > > We have discussed the flow mobility solutions for Proxy MIP6 previously at > IETFs 78 and 79. > This is a consensus call for adopting this I-D: > draft-bernardos-netext-pmipv6-flowmob-02 > as the working group document. > I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt > > The consensus call will expire on Feb 15th, 2011. Please indicate your > support or concerns in adopting this I-D as the WG baseline document on > the mailing list. > > Please note that this I-D will serve as the baseline in the WG and will be > developed further based on input and feedback from WG members. > > -Basavaraj > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > -- Stefano M. Faccin ================== May the Force be with you --0015175cda5e0c3e27049b438fba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Raj,
thanks for the email.

I need to apologize in advance if my q= uestions have already been answered before (though I cannot find a conclusi= ve answer anywhere).

I think that a protocol that is developed in NE= TEXT (or other groups) should have at least a potential realistic scenario = for applicability.

In terms of applicability, though it is not part of the protocol defini= tion per se, unless there are solutions in place for either the host to ind= icate to the network where the flows should be routed or for the LMA to rec= eive somehow from somewhere some policies, the solution cannot really provi= de flow mobility since there is no way to decide which flows are routed whe= re. If we are thinking about a host-based solution, I have not yet seen a s= olution as to how the host can indicate to the MAG and ultimately to the MA= G which flows should be routed on each access. If we are relying on modific= ations of layer 2 protocols, aren't we defining a solution that works o= nly with some technologies (since for other access technologies it is rathe= r unrealistic to modify L2 for IP flow mobility purposes)? If we are thinki= ng of an LMA-based solution, can we hear of at least one example of a real-= life scenario where the LMA would receive such policies, and how such deliv= ery would happen? Also, should there be a solution to have policies in the = LMA, how does the LMA actually decide to route flows on one access or the o= ther? E.g., if some flows need to be routed on certain WLAN networks, but s= hall not be routed on other WLAN networks, how does the LMA know which spec= ific WLAN network the host is connected to? Perhaps I missed the ability fo= r the MAG to know e.g. the WLAN SSID and provide it to the LMA, in which ca= se I would appreciate if somebody could highlight to me where that is defin= ed.

I think that, though not integral to the protocol specification, unders= tanding what framework the protocol would/needs to fit in is rather importa= nt.

Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM, = <Basavaraj.Patil@nokia.com> wrote:

Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= br> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-p= mipv6-flowmob-02.txt

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= br> developed further based on input and feedback from WG members.

-Basavaraj

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



--
Stefano M. Faccin
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
May the Force be = with you
--0015175cda5e0c3e27049b438fba-- From sgundave@cisco.com Tue Feb 1 19:39:49 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87AE93A6E88 for ; Tue, 1 Feb 2011 19:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.401 X-Spam-Level: X-Spam-Status: No, score=-9.401 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rf0rB-SdOB9b for ; Tue, 1 Feb 2011 19:39:42 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 013A63A6916 for ; Tue, 1 Feb 2011 19:39:41 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIFAFZhSE2rR7Hu/2dsb2JhbACCRaFnZ3OhMZsXgnyCVwSFE4cQg0iDEA Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 02 Feb 2011 03:43:00 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p123h01C010354; Wed, 2 Feb 2011 03:43:00 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Feb 2011 19:43:00 -0800 Received: from 10.32.246.211 ([10.32.246.211]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Wed, 2 Feb 2011 03:42:59 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 01 Feb 2011 19:43:29 -0800 From: Sri Gundavelli To: stefano faccin , Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvCi1rPuc0aCsMBvkmm4jXNUEknTA== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3379434209_79490096" X-OriginalArrivalTime: 02 Feb 2011 03:43:00.0419 (UTC) FILETIME=[49C6A930:01CBC28B] Cc: netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 03:39:49 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3379434209_79490096 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Stefano: These are valid points and some good comments. Let me share my thoughts. Carlo=B9s draft is not assuming any new MN-AR interface. Its going with the assumption there is established policy on the mobile and on the LMA, which allows the mobile to select the access network at a flow level granularity, without requiring any explicit signaling between the MAG and the MN. To large part this is all about out of band policy interface, such as ANDSF, towards the UE, leading to the assumption that magically the MN and the LMA are in sync with respect to flow policies, access selection and they will make the right forwarding decision. Secondly, the flow policy decisions nee= d not be based on the specific WLAN network, but it is implicitly driven by the MAG =AD LMA security relation, where the MAG attachment to the WLAN network transitively allows the LMA to make the flow policy decisions based on the MAG identity. If the WLAN network is not trusted, there is truly no MAG in that network, where the LMA shares a security relation with that node. There are still some open issues on this draft that needs to be discussed i= n the WG. On the approaches to allow more a flow aggregate movement, that is a discussion point. There are issues that we need to discuss, supporting split link model, or eliminating some favorite brand of signaling message (FMA) and riding on PBU/PBA and just with one FMI trigger, and on the aspects around MN applying the flow policies by flow mirroring. We have no agreement on those issues yet. Its just a base draft, for further discussion and resolving those issues. But, hope that is not a stopper for base draft selection. =20 Sri On 2/1/11 6:39 PM, "stefano faccin" wrote: > Raj, > thanks for the email. >=20 > I need to apologize in advance if my questions have already been answered > before (though I cannot find a conclusive answer anywhere). >=20 > I think that a protocol that is developed in NETEXT (or other groups) sho= uld > have at least a potential realistic scenario for applicability. >=20 > In terms of applicability, though it is not part of the protocol definiti= on > per se, unless there are solutions in place for either the host to indica= te to > the network where the flows should be routed or for the LMA to receive so= mehow > from somewhere some policies, the solution cannot really provide flow mob= ility > since there is no way to decide which flows are routed where. If we are > thinking about a host-based solution, I have not yet seen a solution as t= o how > the host can indicate to the MAG and ultimately to the MAG which flows sh= ould > be routed on each access. If we are relying on modifications of layer 2 > protocols, aren't we defining a solution that works only with some > technologies (since for other access technologies it is rather unrealisti= c to > modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-ba= sed > solution, can we hear of at least one example of a real-life scenario whe= re > the LMA would receive such policies, and how such delivery would happen? = Also, > should there be a solution to have policies in the LMA, how does the LMA > actually decide to route flows on one access or the other? E.g., if some = flows > need to be routed on certain WLAN networks, but shall not be routed on ot= her > WLAN networks, how does the LMA know which specific WLAN network the host= is > connected to? Perhaps I missed the ability for the MAG to know e.g. the W= LAN > SSID and provide it to the LMA, in which case I would appreciate if someb= ody > could highlight to me where that is defined. >=20 > I think that, though not integral to the protocol specification, understa= nding > what framework the protocol would/needs to fit in is rather important. >=20 > Cheers, > Stefano >=20 >=20 > On Tue, Feb 1, 2011 at 3:47 PM, wrote: >>=20 >> Hello, >>=20 >> We have discussed the flow mobility solutions for Proxy MIP6 previously = at >> IETFs 78 and 79. >> This is a consensus call for adopting this I-D: >> draft-bernardos-netext-pmipv6-flowmob-02 >> as the working group document. >> I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt >>=20 >> The consensus call will expire on Feb 15th, 2011. Please indicate your >> support or concerns in adopting this I-D as the WG baseline document on >> the mailing list. >>=20 >> Please note that this I-D will serve as the baseline in the WG and will = be >> developed further based on input and feedback from WG members. >>=20 >> -Basavaraj >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >=20 >=20 --B_3379434209_79490096 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmi= pv6-flowmob as WG doc Hi Stefano:

These are valid points and some good comments. Let me share my thoughts.
Carlo’s draft is not assuming any new MN-AR interface. Its going with= the assumption there is established policy on the mobile and on the LMA, wh= ich allows the mobile to select the access network at a flow level granulari= ty, without requiring any explicit signaling between the MAG and the MN. To = large part this is all about out of band policy interface, such as ANDSF, to= wards the UE, leading to the assumption that magically the MN and the LMA ar= e in sync with respect to flow policies, access selection and they will make= the right forwarding decision. Secondly, the flow policy decisions need not= be based on the specific WLAN network, but it is implicitly driven by the M= AG – LMA security relation, where the MAG attachment to the WLAN netwo= rk transitively allows the LMA to make the flow policy decisions based on th= e MAG identity. If the WLAN network is not trusted, there is truly no MAG in= that network, where the LMA shares a security relation with that node.

There are still some open issues on this draft that needs to be discussed i= n the WG.  On the approaches to allow more a flow aggregate movement, t= hat is a discussion point. There are issues that we need to discuss, support= ing split link model, or eliminating some favorite brand of signaling messag= e (FMA) and riding on PBU/PBA and just with one FMI trigger, and on the aspe= cts around MN applying the flow policies by flow mirroring. We have no agree= ment on those issues yet.

Its just a base draft, for further discussion and resolving those issues. B= ut, hope that is not a stopper for base draft selection.
 

Sri





On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicate= to the network where the flows should be routed or for the LMA to receive s= omehow from somewhere some policies, the solution cannot really provide flow= mobility since there is no way to decide which flows are routed where. If w= e are thinking about a host-based solution, I have not yet seen a solution a= s to how the host can indicate to the MAG and ultimately to the MAG which fl= ows should be routed on each access. If we are relying on modifications of l= ayer 2 protocols, aren't we defining a solution that works only with some te= chnologies (since for other access technologies it is rather unrealistic to = modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-based= solution, can we hear of at least one example of a real-life scenario where= the LMA would receive such policies, and how such delivery would happen? Al= so, should there be a solution to have policies in the LMA, how does the LMA= actually decide to route flows on one access or the other? E.g., if some fl= ows need to be routed on certain WLAN networks, but shall not be routed on o= ther WLAN networks, how does the LMA know which specific WLAN network the ho= st is connected to? Perhaps I missed the ability for the MAG to know e.g. th= e WLAN SSID and provide it to the LMA, in which case I would appreciate if s= omebody could highlight to me where that is defined.

I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important. <= BR>
Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM,  <Basavaraj.Patil@nokia.com> wrote:
<= SPAN STYLE=3D'font-size:11pt'>
Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= BR> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt<= /a>

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= BR> developed further based on input and feedback from WG members.

-Basavaraj

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

--B_3379434209_79490096-- From sfaccinstd@gmail.com Tue Feb 1 20:26:23 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D1DA3A7141 for ; Tue, 1 Feb 2011 20:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.298 X-Spam-Level: X-Spam-Status: No, score=-102.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+QDLAy1Tkgx for ; Tue, 1 Feb 2011 20:26:21 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 61FFB3A67D3 for ; Tue, 1 Feb 2011 20:25:59 -0800 (PST) Received: by qyj19 with SMTP id 19so7864964qyj.10 for ; Tue, 01 Feb 2011 20:29:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QdgeLkQhkqRwjZPzYEpcezyM+ICoUpDpQ3EkMjK21ug=; b=g1KXcPIUmULQTBIwA683GtFB2GRg8jg67CdUPAocMaeDMU8kn0BRcrKxK9Ai/IFcJ1 aYrqYOa7l++Kf6PuaaRrj4QxdQlnDUxS3CdfYGZLkWP+8436lalI7SouZ4ZcqIxcT4N+ Pr80lKARteFnbf9/vx6rkKanidqJdY/Kuu+tY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WcDxKdzktfxq+4oov1MAuzruFIoIx9B96vpaQfKlLDYqbpI+4d+HqlGhhkN91P7e7z +rG0DCHUWE1BE6NgDIouF/GZqigsorv3U/FdE3AVqHtkqO2y8ufuB2LoCELDdKtDilLf nSpISfP2+Zlb6uRUuB7TLzae+E+fPlsnwWenc= MIME-Version: 1.0 Received: by 10.229.43.72 with SMTP id v8mr1810302qce.290.1296620955648; Tue, 01 Feb 2011 20:29:15 -0800 (PST) Received: by 10.229.20.70 with HTTP; Tue, 1 Feb 2011 20:29:15 -0800 (PST) In-Reply-To: References: Date: Tue, 1 Feb 2011 20:29:15 -0800 Message-ID: From: stefano faccin To: Sri Gundavelli Content-Type: multipart/alternative; boundary=0016e64bc18c7844ac049b45171b Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 04:26:23 -0000 --0016e64bc18c7844ac049b45171b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sri, thanks for the reply. I'd like to comment on the "the flow policy decisions need not be based on the specific WLAN network". Does it mean, as I believe it does, that the current solution would not allow an operator deploying such solution to decide to route flows over a specific WLAN or not depending on which specific WLAN the MN is connected to? E.g. the operator or the entity in control of the decisions for the routing may want to direct certain traffic always over WLANs that the operator deploys, and instead route only some of the traffic over WLANs of roaming partners or of the MN user home. How does this solution support that scenario if the LMA is not told specifically which WLAN the MN is connected to? From a deployment point of view, I do no= t believe we can afford to leave out this scenario. Please note that the establishment of a security relationship between the MN and the MAG, and a specific MAG identity, cannot guarantee that the LMA knows which specific WLAN access network the MN is connected to. Assuming that would severely restrict the deployment scenarios. As for the MN and the LMA being magically in synch, I am very concerned about a "glass ball" solution. You mention ANDSF defined by 3GPP as a solution for this "out of band" delivery of policy. Fair enough, however there is an issue with that. ANDSF is designed specific to be a MN-centric solution where policies are provisioned in the MN and the MN decides which network technologies and access networks it needs to connect to, under what conditions, and which IP traffic needs to be routed on such accesses. No IP point of attachment in the network (i.e. the PDN GW in 3GPP that is the LMA in PMIPv6) is aware under any conditions of such policy. Therefore, even if in order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would unfortunately not provide a solution unless the MN can communicate to the MAG and the LMA the decisions the MN has taken based on the ANDSF policies. I believe the key point here is that we need to understand how the solution can be realistically applied to a real scenario, and that we need to ensure that important and realistic deployment scenarios are not excluded by the solution. Cheers, Stefano On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli wrote: > Hi Stefano: > > These are valid points and some good comments. Let me share my thoughts. > > Carlo=92s draft is not assuming any new MN-AR interface. Its going with t= he > assumption there is established policy on the mobile and on the LMA, whic= h > allows the mobile to select the access network at a flow level granularit= y, > without requiring any explicit signaling between the MAG and the MN. To > large part this is all about out of band policy interface, such as ANDSF, > towards the UE, leading to the assumption that magically the MN and the L= MA > are in sync with respect to flow policies, access selection and they will > make the right forwarding decision. Secondly, the flow policy decisions n= eed > not be based on the specific WLAN network, but it is implicitly driven by > the MAG =96 LMA security relation, where the MAG attachment to the WLAN > network transitively allows the LMA to make the flow policy decisions bas= ed > on the MAG identity. If the WLAN network is not trusted, there is truly n= o > MAG in that network, where the LMA shares a security relation with that > node. > > There are still some open issues on this draft that needs to be discussed > in the WG. On the approaches to allow more a flow aggregate movement, th= at > is a discussion point. There are issues that we need to discuss, supporti= ng > split link model, or eliminating some favorite brand of signaling message > (FMA) and riding on PBU/PBA and just with one FMI trigger, and on the > aspects around MN applying the flow policies by flow mirroring. We have n= o > agreement on those issues yet. > > Its just a base draft, for further discussion and resolving those issues. > But, hope that is not a stopper for base draft selection. > > > Sri > > > > > > > On 2/1/11 6:39 PM, "stefano faccin" wrote: > > Raj, > thanks for the email. > > I need to apologize in advance if my questions have already been answered > before (though I cannot find a conclusive answer anywhere). > > I think that a protocol that is developed in NETEXT (or other groups) > should have at least a potential realistic scenario for applicability. > > In terms of applicability, though it is not part of the protocol definiti= on > per se, unless there are solutions in place for either the host to indica= te > to the network where the flows should be routed or for the LMA to receive > somehow from somewhere some policies, the solution cannot really provide > flow mobility since there is no way to decide which flows are routed wher= e. > If we are thinking about a host-based solution, I have not yet seen a > solution as to how the host can indicate to the MAG and ultimately to the > MAG which flows should be routed on each access. If we are relying on > modifications of layer 2 protocols, aren't we defining a solution that wo= rks > only with some technologies (since for other access technologies it is > rather unrealistic to modify L2 for IP flow mobility purposes)? If we are > thinking of an LMA-based solution, can we hear of at least one example of= a > real-life scenario where the LMA would receive such policies, and how suc= h > delivery would happen? Also, should there be a solution to have policies = in > the LMA, how does the LMA actually decide to route flows on one access or > the other? E.g., if some flows need to be routed on certain WLAN networks= , > but shall not be routed on other WLAN networks, how does the LMA know whi= ch > specific WLAN network the host is connected to? Perhaps I missed the abil= ity > for the MAG to know e.g. the WLAN SSID and provide it to the LMA, in whic= h > case I would appreciate if somebody could highlight to me where that is > defined. > > I think that, though not integral to the protocol specification, > understanding what framework the protocol would/needs to fit in is rather > important. > > Cheers, > Stefano > > > On Tue, Feb 1, 2011 at 3:47 PM, wrote: > > > Hello, > > We have discussed the flow mobility solutions for Proxy MIP6 previously a= t > IETFs 78 and 79. > This is a consensus call for adopting this I-D: > draft-bernardos-netext-pmipv6-flowmob-02 > as the working group document. > I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt > > The consensus call will expire on Feb 15th, 2011. Please indicate your > support or concerns in adopting this I-D as the WG baseline document on > the mailing list. > > Please note that this I-D will serve as the baseline in the WG and will b= e > developed further based on input and feedback from WG members. > > -Basavaraj > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > > > --=20 Stefano M. Faccin =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D May the Force be with you --0016e64bc18c7844ac049b45171b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sri,thanks for the reply.

I'd like to comment on the "<= font style=3D"font-family: arial,helvetica,sans-serif;" face=3D"Calibri, Ve= rdana, Helvetica, Arial" size=3D"1">the flow policy decisions need no= t be based on the specific WLAN network". Does it mean, as I believe i= t does, that the current solution would not allow an operator deploying suc= h solution to decide to route flows over a specific WLAN or not depending o= n which specific WLAN the MN is connected to? E.g. the operator or the enti= ty in control of the decisions for the routing may want to direct certain t= raffic always over WLANs that the operator deploys, and instead route only = some of the traffic over WLANs of roaming partners or of the MN user home. = How does this solution support that scenario if the LMA is not told specifi= cally which WLAN the MN is connected to? From a deployment point of view, I= do not believe we can afford to leave out this scenario. Please note that = the establishment of a security relationship between the MN and the MAG, an= d a specific MAG identity, cannot guarantee that the LMA knows which specif= ic WLAN access network the MN is connected to. Assuming that would severely= restrict the deployment scenarios.

As for the MN and the LMA being magically in synch, I am very concerned= about a "glass ball" solution. You mention ANDSF defined by 3GPP= as a solution for this "out of band" delivery of policy. Fair en= ough, however there is an issue with that. ANDSF is designed specific to be= a MN-centric solution where policies are provisioned in the MN and the MN = decides which network technologies and access networks it needs to connect = to, under what conditions, and which IP traffic needs to be routed on such = accesses. No IP point of attachment in the network (i.e. the PDN GW in 3GPP= that is the LMA in PMIPv6) is aware under any conditions of such policy. T= herefore, even if in order to apply this solution to 3GPP we wanted to use = ANDSF, ANDSF would unfortunately not provide a solution unless the MN can c= ommunicate to the MAG and the LMA the decisions the MN has taken based on t= he ANDSF policies.

I believe the key point here is that we need to understand how the solu= tion can be realistically applied to a real scenario, and that we need to e= nsure that important and realistic deployment scenarios are not excluded by= the solution.

Cheers,
Stefano

On Tue, Feb= 1, 2011 at 7:43 PM, Sri Gundavelli <sgundave@cisco.com> wrote:
Hi Stefano:

These are valid points and some good comments. Let me share my thoughts.
Carlo=92s draft is not assuming any new MN-AR interface. Its going with the= assumption there is established policy on the mobile and on the LMA, which= allows the mobile to select the access network at a flow level granularity= , without requiring any explicit signaling between the MAG and the MN. To l= arge part this is all about out of band policy interface, such as ANDSF, to= wards the UE, leading to the assumption that magically the MN and the LMA a= re in sync with respect to flow policies, access selection and they will ma= ke the right forwarding decision. Secondly, the flow policy decisions need = not be based on the specific WLAN network, but it is implicitly driven by t= he MAG =96 LMA security relation, where the MAG attachment to the WLAN netw= ork transitively allows the LMA to make the flow policy decisions based on = the MAG identity. If the WLAN network is not trusted, there is truly no MAG= in that network, where the LMA shares a security relation with that node.<= br>
There are still some open issues on this draft that needs to be discussed i= n the WG. =A0On the approaches to allow more a flow aggregate movement, tha= t is a discussion point. There are issues that we need to discuss, supporti= ng split link model, or eliminating some favorite brand of signaling messag= e (FMA) and riding on PBU/PBA and just with one FMI trigger, and on the asp= ects around MN applying the flow policies by flow mirroring. We have no agr= eement on those issues yet.

Its just a base draft, for further discussion and resolving those issues. B= ut, hope that is not a stopper for base draft selection.
=A0

Sri






On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com> wrote:

Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicat= e to the network where the flows should be routed or for the LMA to receive= somehow from somewhere some policies, the solution cannot really provide f= low mobility since there is no way to decide which flows are routed where. = If we are thinking about a host-based solution, I have not yet seen a solut= ion as to how the host can indicate to the MAG and ultimately to the MAG wh= ich flows should be routed on each access. If we are relying on modificatio= ns of layer 2 protocols, aren't we defining a solution that works only = with some technologies (since for other access technologies it is rather un= realistic to modify L2 for IP flow mobility purposes)? If we are thinking o= f an LMA-based solution, can we hear of at least one example of a real-life= scenario where the LMA would receive such policies, and how such delivery = would happen? Also, should there be a solution to have policies in the LMA,= how does the LMA actually decide to route flows on one access or the other= ? E.g., if some flows need to be routed on certain WLAN networks, but shall= not be routed on other WLAN networks, how does the LMA know which specific= WLAN network the host is connected to? Perhaps I missed the ability for th= e MAG to know e.g. the WLAN SSID and provide it to the LMA, in which case I= would appreciate if somebody could highlight to me where that is defined.<= br>
I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important. =

Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM, =A0<Basavaraj.Patil@nokia.com> wrote:

Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= br> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-p= mipv6-flowmob-02.txt

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= br> developed further based on input and feedback from WG members.

-Basavaraj

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





--
Stefano M. Faccin
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
May the Force be = with you
--0016e64bc18c7844ac049b45171b-- From sgundave@cisco.com Tue Feb 1 21:02:27 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0802F3A6E02 for ; Tue, 1 Feb 2011 21:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.335 X-Spam-Level: X-Spam-Status: No, score=-9.335 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2vL0xSSgvuq for ; Tue, 1 Feb 2011 21:02:14 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 875CC3A6E11 for ; Tue, 1 Feb 2011 21:02:14 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0GAAZ1SE2rRN+J/2dsb2JhbACCRZQshgcBhzNnc6E7mxKCfIJXBIR4hmeDL4J/ Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 02 Feb 2011 05:05:32 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p1255Wk8007183; Wed, 2 Feb 2011 05:05:32 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Feb 2011 21:05:32 -0800 Received: from 10.32.246.211 ([10.32.246.211]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Wed, 2 Feb 2011 05:05:31 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 01 Feb 2011 21:06:01 -0800 From: Sri Gundavelli To: stefano faccin Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvCluJv4yEZ7t95RkC7ho4CK1mPdA== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3379439161_79730726" X-OriginalArrivalTime: 02 Feb 2011 05:05:32.0655 (UTC) FILETIME=[D189E7F0:01CBC296] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 05:02:27 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3379439161_79730726 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Stefano, Thanks for the discussion. As you say, the ANDSF policies are allowing the MN a.) to make the right network attachment decision and b.) make the access selection on a flow basis. This same policy that is present in the ANDSF server, is available for the network nodes as well. I=B9m not sure, with out this assumption the solution can work for all currently listed cases. We clearly need the MN an= d the LMA to be in synch with respect to the configured policy. How, that is done, I guess we will not try to know. I thought even in 3GPP, this is the implied assumption ? But, this is for you to clarify. Not specifically for IFOM where UE and PDN GW/HA are negotiating the flow policies, but generall= y that the PDN GW and the ANDSF policy server will have synchronized policies= . The MAG and the LMA have the ability to carry this flow policy information in signaling messages and influence the access selection. The policy is a opaque object, with extensible formats, when carried in the signaling plane= , should allow the LMA/MAG to apply those access policies, while assuming MN is following the same rules. These policies can surely reflect the specific WLAN access/operator specific rule. I=B9m surely with you, the lack of MN-AR interface is surely an issue and I see that. But, we need to understand, what are the limitations with the approach of out of band policy interface= s and what will be the solution limitations. If we need to tie the flow movement at the prefix granularity and rely on the natural ND interface in the form of RA PIO option, more like PDN offload in MAPCON, or at the granularity of a flow level, is open for discussion. I want to simplify thi= s draft for sure, we can surely discuss each of these issues on the WG draft. Regards Sri On 2/1/11 8:29 PM, "stefano faccin" wrote: > Sri, > thanks for the reply. >=20 > I'd like to comment on the "the flow policy decisions need not be based o= n the > specific WLAN network". Does it mean, as I believe it does, that the curr= ent > solution would not allow an operator deploying such solution to decide to > route flows over a specific WLAN or not depending on which specific WLAN = the > MN is connected to? E.g. the operator or the entity in control of the > decisions for the routing may want to direct certain traffic always over = WLANs > that the operator deploys, and instead route only some of the traffic ove= r > WLANs of roaming partners or of the MN user home. How does this solution > support that scenario if the LMA is not told specifically which WLAN the = MN is > connected to? From a deployment point of view, I do not believe we can af= ford > to leave out this scenario. Please note that the establishment of a secur= ity > relationship between the MN and the MAG, and a specific MAG identity, can= not > guarantee that the LMA knows which specific WLAN access network the MN is > connected to. Assuming that would severely restrict the deployment scenar= ios. >=20 > As for the MN and the LMA being magically in synch, I am very concerned a= bout > a "glass ball" solution. You mention ANDSF defined by 3GPP as a solution = for > this "out of band" delivery of policy. Fair enough, however there is an i= ssue > with that. ANDSF is designed specific to be a MN-centric solution where > policies are provisioned in the MN and the MN decides which network > technologies and access networks it needs to connect to, under what > conditions, and which IP traffic needs to be routed on such accesses. No = IP > point of attachment in the network (i.e. the PDN GW in 3GPP that is the L= MA in > PMIPv6) is aware under any conditions of such policy. Therefore, even if = in > order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would > unfortunately not provide a solution unless the MN can communicate to the= MAG > and the LMA the decisions the MN has taken based on the ANDSF policies. >=20 > I believe the key point here is that we need to understand how the soluti= on > can be realistically applied to a real scenario, and that we need to ensu= re > that important and realistic deployment scenarios are not excluded by the > solution. >=20 > Cheers, > Stefano >=20 > On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli wrote= : >> Hi Stefano: >>=20 >> These are valid points and some good comments. Let me share my thoughts. >>=20 >> Carlo=B9s draft is not assuming any new MN-AR interface. Its going with th= e >> assumption there is established policy on the mobile and on the LMA, whi= ch >> allows the mobile to select the access network at a flow level granulari= ty, >> without requiring any explicit signaling between the MAG and the MN. To = large >> part this is all about out of band policy interface, such as ANDSF, towa= rds >> the UE, leading to the assumption that magically the MN and the LMA are = in >> sync with respect to flow policies, access selection and they will make = the >> right forwarding decision. Secondly, the flow policy decisions need not = be >> based on the specific WLAN network, but it is implicitly driven by the M= AG =AD >> LMA security relation, where the MAG attachment to the WLAN network >> transitively allows the LMA to make the flow policy decisions based on t= he >> MAG identity. If the WLAN network is not trusted, there is truly no MAG = in >> that network, where the LMA shares a security relation with that node. >>=20 >> There are still some open issues on this draft that needs to be discusse= d in >> the WG. =A0On the approaches to allow more a flow aggregate movement, that= is a >> discussion point. There are issues that we need to discuss, supporting s= plit >> link model, or eliminating some favorite brand of signaling message (FMA= ) and >> riding on PBU/PBA and just with one FMI trigger, and on the aspects arou= nd MN >> applying the flow policies by flow mirroring. We have no agreement on th= ose >> issues yet. >>=20 >> Its just a base draft, for further discussion and resolving those issues= . >> But, hope that is not a stopper for base draft selection. >> =A0 >>=20 >> Sri >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2/1/11 6:39 PM, "stefano faccin" > > wrote: >>=20 >>> Raj, >>> thanks for the email. >>>=20 >>> I need to apologize in advance if my questions have already been answer= ed >>> before (though I cannot find a conclusive answer anywhere). >>>=20 >>> I think that a protocol that is developed in NETEXT (or other groups) s= hould >>> have at least a potential realistic scenario for applicability. >>>=20 >>> In terms of applicability, though it is not part of the protocol defini= tion >>> per se, unless there are solutions in place for either the host to indi= cate >>> to the network where the flows should be routed or for the LMA to recei= ve >>> somehow from somewhere some policies, the solution cannot really provid= e >>> flow mobility since there is no way to decide which flows are routed wh= ere. >>> If we are thinking about a host-based solution, I have not yet seen a >>> solution as to how the host can indicate to the MAG and ultimately to t= he >>> MAG which flows should be routed on each access. If we are relying on >>> modifications of layer 2 protocols, aren't we defining a solution that = works >>> only with some technologies (since for other access technologies it is >>> rather unrealistic to modify L2 for IP flow mobility purposes)? If we a= re >>> thinking of an LMA-based solution, can we hear of at least one example = of a >>> real-life scenario where the LMA would receive such policies, and how s= uch >>> delivery would happen? Also, should there be a solution to have policie= s in >>> the LMA, how does the LMA actually decide to route flows on one access = or >>> the other? E.g., if some flows need to be routed on certain WLAN networ= ks, >>> but shall not be routed on other WLAN networks, how does the LMA know w= hich >>> specific WLAN network the host is connected to? Perhaps I missed the ab= ility >>> for the MAG to know e.g. the WLAN SSID and provide it to the LMA, in wh= ich >>> case I would appreciate if somebody could highlight to me where that is >>> defined. >>>=20 >>> I think that, though not integral to the protocol specification, >>> understanding what framework the protocol would/needs to fit in is rath= er >>> important.=20 >>>=20 >>> Cheers, >>> Stefano >>>=20 >>>=20 >>> On Tue, Feb 1, 2011 at 3:47 PM, =A0>> > wrote: >>>>=20 >>>> Hello, >>>>=20 >>>> We have discussed the flow mobility solutions for Proxy MIP6 previousl= y at >>>> IETFs 78 and 79. >>>> This is a consensus call for adopting this I-D: >>>> draft-bernardos-netext-pmipv6-flowmob-02 >>>> as the working group document. >>>> I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.t= xt >>>>=20 >>>> The consensus call will expire on Feb 15th, 2011. Please indicate your >>>> support or concerns in adopting this I-D as the WG baseline document o= n >>>> the mailing list. >>>>=20 >>>> Please note that this I-D will serve as the baseline in the WG and wil= l be >>>> developed further based on input and feedback from WG members. >>>>=20 >>>> -Basavaraj >>>>=20 >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>=20 >>>=20 >=20 >=20 --B_3379439161_79730726 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmi= pv6-flowmob as WG doc Hi Stefano,

Thanks for the discussion.

As you say, the ANDSF policies are allowing the MN a.) to make the right ne= twork attachment decision and b.) make the access selection on a flow basis.= This same policy that is present in the ANDSF server, is available for the = network nodes as well. I’m not sure, with out this assumption the solu= tion can work for all currently listed cases. We clearly need the MN and the= LMA to be in synch with respect to the configured policy. How, that is done= , I guess we will not try to know.  I thought even in 3GPP, this is the= implied assumption ? But, this is for you to clarify. Not specifically for = IFOM where UE and PDN GW/HA are negotiating the flow policies, but generally= that the PDN GW and the ANDSF policy server will have synchronized policies= . The MAG and the LMA have the ability to carry this flow policy information= in signaling messages and influence the access selection. The policy is a o= paque object, with extensible formats, when carried in the signaling plane, = should allow the LMA/MAG to apply those access policies, while assuming MN i= s following the same rules. These policies can surely reflect the specific W= LAN access/operator specific rule. I’m surely with you, the lack of MN= -AR interface is surely an issue and I see that. But, we need to understand,= what are the limitations with the approach of  out of band policy inte= rfaces and what will be the solution limitations. If we need to tie the flow= movement at the prefix granularity and rely on the natural ND interface in = the form of RA PIO option, more like PDN offload in MAPCON, or at the granul= arity of a flow level, is open for discussion. I want to simplify this draft= for sure, we can surely discuss each of these issues on the WG draft.


Regards
Sri





On 2/1/11 8:29 PM, "stefano faccin" <sfaccinstd@gmail.com> wrote:

Sri,
thanks for the reply.

I'd like to comment on the "the flow policy decisions n= eed not be based on the specific WLAN network". Does it mean, as I beli= eve it does, that the current solution would not allow an operator deploying= such solution to decide to route flows over a specific WLAN or not dependin= g on which specific WLAN the MN is connected to? E.g. the operator or the en= tity in control of the decisions for the routing may want to direct certain = traffic always over WLANs that the operator deploys, and instead route only = some of the traffic over WLANs of roaming partners or of the MN user home. H= ow does this solution support that scenario if the LMA is not told specifica= lly which WLAN the MN is connected to? From a deployment point of view, I do= not believe we can afford to leave out this scenario. Please note that the = establishment of a security relationship between the MN and the MAG, and a s= pecific MAG identity, cannot guarantee that the LMA knows which specific WLA= N access network the MN is connected to. Assuming that would severely restri= ct the deployment scenarios.

As for the MN and the LMA being magically in synch, I am very concerned abo= ut a "glass ball" solution. You mention ANDSF defined by 3GPP as a= solution for this "out of band" delivery of policy. Fair enough, = however there is an issue with that. ANDSF is designed specific to be a MN-c= entric solution where policies are provisioned in the MN and the MN decides = which network technologies and access networks it needs to connect to, under= what conditions, and which IP traffic needs to be routed on such accesses. = No IP point of attachment in the network (i.e. the PDN GW in 3GPP that is th= e LMA in PMIPv6) is aware under any conditions of such policy. Therefore, ev= en if in order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF = would unfortunately not provide a solution unless the MN can communicate to = the MAG and the LMA the decisions the MN has taken based on the ANDSF polici= es.

I believe the key point here is that we need to understand how the solution= can be realistically applied to a real scenario, and that we need to ensure= that important and realistic deployment scenarios are not excluded by the s= olution.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli <sgundave@cisco.com> wrote:
<= SPAN STYLE=3D'font-size:11pt'>Hi Stefano:

These are valid points and some good comments. Let me share my thoughts.
Carlo’s draft is not assuming any new MN-AR interface. Its going with= the assumption there is established policy on the mobile and on the LMA, wh= ich allows the mobile to select the access network at a flow level granulari= ty, without requiring any explicit signaling between the MAG and the MN. To = large part this is all about out of band policy interface, such as ANDSF, to= wards the UE, leading to the assumption that magically the MN and the LMA ar= e in sync with respect to flow policies, access selection and they will make= the right forwarding decision. Secondly, the flow policy decisions need not= be based on the specific WLAN network, but it is implicitly driven by the M= AG – LMA security relation, where the MAG attachment to the WLAN netwo= rk transitively allows the LMA to make the flow policy decisions based on th= e MAG identity. If the WLAN network is not trusted, there is truly no MAG in= that network, where the LMA shares a security relation with that node.

There are still some open issues on this draft that needs to be discussed i= n the WG. =A0On the approaches to allow more a flow aggregate movement, that i= s a discussion point. There are issues that we need to discuss, supporting s= plit link model, or eliminating some favorite brand of signaling message (FM= A) and riding on PBU/PBA and just with one FMI trigger, and on the aspects a= round MN applying the flow policies by flow mirroring. We have no agreement = on those issues yet.

Its just a base draft, for further discussion and resolving those issues. B= ut, hope that is not a stopper for base draft selection.
=A0

Sri






On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <htt= p://sfaccinstd@gmail.com> > wrote:

<= SPAN STYLE=3D'font-size:11pt'>Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicate= to the network where the flows should be routed or for the LMA to receive s= omehow from somewhere some policies, the solution cannot really provide flow= mobility since there is no way to decide which flows are routed where. If w= e are thinking about a host-based solution, I have not yet seen a solution a= s to how the host can indicate to the MAG and ultimately to the MAG which fl= ows should be routed on each access. If we are relying on modifications of l= ayer 2 protocols, aren't we defining a solution that works only with some te= chnologies (since for other access technologies it is rather unrealistic to = modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-based= solution, can we hear of at least one example of a real-life scenario where= the LMA would receive such policies, and how such delivery would happen? Al= so, should there be a solution to have policies in the LMA, how does the LMA= actually decide to route flows on one access or the other? E.g., if some fl= ows need to be routed on certain WLAN networks, but shall not be routed on o= ther WLAN networks, how does the LMA know which specific WLAN network the ho= st is connected to? Perhaps I missed the ability for the MAG to know e.g. th= e WLAN SSID and provide it to the LMA, in which case I would appreciate if s= omebody could highlight to me where that is defined.

I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important. <= BR>
Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM, =A0<Ba= savaraj.Patil@nokia.com <h= ttp://Basavaraj.Patil@nokia.com> > wrote:
<= SPAN STYLE=3D'font-size:11pt'>
Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= BR> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt<= /a>

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= BR> developed further based on input and feedback from WG members.

-Basavaraj

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



--B_3379439161_79730726-- From pierrick.seite@orange-ftgroup.com Wed Feb 2 08:42:42 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B3A63A6D79 for ; Wed, 2 Feb 2011 08:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMV-qAJ4pdF4 for ; Wed, 2 Feb 2011 08:42:41 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 265753A6D2C for ; Wed, 2 Feb 2011 08:42:41 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 15F276C0002; Wed, 2 Feb 2011 17:46:29 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 0B3726C0001; Wed, 2 Feb 2011 17:46:29 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Feb 2011 17:45:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Feb 2011 17:45:58 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46201795F8D@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLwmpURzmRlysrlUidlexdQorGZJPuaC+w References: From: To: , X-OriginalArrivalTime: 02 Feb 2011 16:45:59.0167 (UTC) FILETIME=[AB4AB8F0:01CBC2F8] Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 16:42:42 -0000 Hi, I've one concern about this I-D. Section 3.2 describes three mobility = scenarios. The second one is about different set of prefixes per = interface and focus on mobility triggered by L2 attachment. This = scenario is quite confusing... I mean, obviously L2 attachment is a = trigger for mobility but it is not specific to the scenario where MAGs = manage different sets of prefixes; L2 attachment could also trigger = mobility when prefix is shared between interface. Anyway, this text is = about trigger for mobility and should be out of the scope of this draft. = Besides, text after figure 4 clearly says that trigger and handover = decision making is out of scope; I can't agree more. So, even if -02 improved, I think this draft should be clarified again = by focusing on basic flow mobility operations, i.e. scenario 1 and 3 of = section 3.2. In my understanding these operations are: the LMA maintains = a collection of BCE and controls mobility, i.e. decides how to use these = BCEs. To perform handover, i.e. apply LMA decision, we have two = scenarios: 1) move flow or 2) move HNP. Additionally, when MAGs use = different sets of prefixes, we need piece of protocol between LMA and = MAGs, or PMIP behaviour modification, to allow the new MAG updating its = routing state.=20 BR, Pierrick > -----Message d'origine----- > De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la = part > de Basavaraj.Patil@nokia.com > Envoy=E9=A0: mercredi 2 f=E9vrier 2011 00:47 > =C0=A0: netext@ietf.org > Objet=A0: [netext] Consensus call to adopt I-D: = draft-bernardos-netext- > pmipv6-flowmob as WG doc >=20 >=20 > Hello, >=20 > We have discussed the flow mobility solutions for Proxy MIP6 = previously at > IETFs 78 and 79. > This is a consensus call for adopting this I-D: > draft-bernardos-netext-pmipv6-flowmob-02 > as the working group document. > I-D: = http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt >=20 > The consensus call will expire on Feb 15th, 2011. Please indicate your > support or concerns in adopting this I-D as the WG baseline document = on > the mailing list. >=20 > Please note that this I-D will serve as the baseline in the WG and = will be > developed further based on input and feedback from WG members. >=20 > -Basavaraj >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From sfaccinstd@gmail.com Wed Feb 2 09:05:22 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B7793A6C01 for ; Wed, 2 Feb 2011 09:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.948 X-Spam-Level: X-Spam-Status: No, score=-102.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWp4p3-GdIkj for ; Wed, 2 Feb 2011 09:05:19 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 05EDD3A6B58 for ; Wed, 2 Feb 2011 09:05:18 -0800 (PST) Received: by qwi2 with SMTP id 2so194800qwi.31 for ; Wed, 02 Feb 2011 09:08:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yRTYw3kObp01Xi8Jo4+y4Z00OK1JEG9WxO8F89ubR6E=; b=Z4s1CgM5FUhxqeXjtzYKWISv/aX0Qe/chRUbg2IqA8895MgYyZDC4slRsVdEuuWu7P cL8PpkshZlTyGC2sHlm0H3mp6B65oxjBJToHfv/UIX+UChsID/QF06smOqNDfPbe5aSA ryGxQgoXcT7U1XC+ffKWBZHYfcyk06bCQfehg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UZarxNqogzzcagfeb/Q9I6Niz9p48YMXCuqShsf3vnApgA/muQ47rGtczS63d6Hozi /havvsMWnEsW8uizDAese/jhc9sLI3YH1TTqYW2vWotiqb7AuO1Ka5AeWdeNUnBTf5lA 9CjJuiZ3UksQliKU4FE+8RpH+fPf1un/3MWGs= MIME-Version: 1.0 Received: by 10.224.20.72 with SMTP id e8mr7929857qab.193.1296666518542; Wed, 02 Feb 2011 09:08:38 -0800 (PST) Received: by 10.229.20.70 with HTTP; Wed, 2 Feb 2011 09:08:38 -0800 (PST) In-Reply-To: References: Date: Wed, 2 Feb 2011 09:08:38 -0800 Message-ID: From: stefano faccin To: Sri Gundavelli Content-Type: multipart/alternative; boundary=0015175cdae63adf0f049b4fb348 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 17:05:22 -0000 --0015175cdae63adf0f049b4fb348 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sri, thanks for the reply. Can you clarify in which system or scenario ANDSF is available to network entities as well? There is no such availability in 3GPP, and making such information available would require considerable architectural changes, therefore the applicability of this solution to what seems to be the only realistic scenario hinges on 3GPP making considerable architectural changes. I would therefore not be so hastily concluding that the ANDSF information is available to the LMA and underestimate what it would really take to make the solution applicable. If we cannot guarantee that there is at least one realistic solution to hav= e the MNa nd LMA in synch, how do we expect that this solution is applicable at all? In 3GPP there is no need to have such implicit assumption, be cause 1) the MN is provided policies explicitly through the ANDSF, and 2) it is the MN and only the MN that makes IP flow mobility decisions and communicates them explicitly (with well defined signalling) to the LMA, and therefore no magic is needed. There is no need in 3GPP to have the ANDSF an= d PDN GW policies synchronized, since the PDN GW does not use such policies. Sri, in the end it is a matter of whether we develop a solution that will rely on some unknown magic to be deployed, or a solution that we know can b= e deployed in at least one way because there are solutions to what I consider major open issues. Cheers, Stefano On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli wrote: > Hi Stefano, > > Thanks for the discussion. > > As you say, the ANDSF policies are allowing the MN a.) to make the right > network attachment decision and b.) make the access selection on a flow > basis. This same policy that is present in the ANDSF server, is available > for the network nodes as well. I=92m not sure, with out this assumption t= he > solution can work for all currently listed cases. We clearly need the MN = and > the LMA to be in synch with respect to the configured policy. How, that i= s > done, I guess we will not try to know. I thought even in 3GPP, this is t= he > implied assumption ? But, this is for you to clarify. Not specifically fo= r > IFOM where UE and PDN GW/HA are negotiating the flow policies, but genera= lly > that the PDN GW and the ANDSF policy server will have synchronized polici= es. > The MAG and the LMA have the ability to carry this flow policy informatio= n > in signaling messages and influence the access selection. The policy is a > opaque object, with extensible formats, when carried in the signaling pla= ne, > should allow the LMA/MAG to apply those access policies, while assuming M= N > is following the same rules. These policies can surely reflect the specif= ic > WLAN access/operator specific rule. I=92m surely with you, the lack of MN= -AR > interface is surely an issue and I see that. But, we need to understand, > what are the limitations with the approach of out of band policy interfa= ces > and what will be the solution limitations. If we need to tie the flow > movement at the prefix granularity and rely on the natural ND interface i= n > the form of RA PIO option, more like PDN offload in MAPCON, or at the > granularity of a flow level, is open for discussion. I want to simplify t= his > draft for sure, we can surely discuss each of these issues on the WG draf= t. > > > Regards > Sri > > > > > > > On 2/1/11 8:29 PM, "stefano faccin" wrote: > > Sri, > thanks for the reply. > > I'd like to comment on the "the flow policy decisions need not be based o= n > the specific WLAN network". Does it mean, as I believe it does, that the > current solution would not allow an operator deploying such solution to > decide to route flows over a specific WLAN or not depending on which > specific WLAN the MN is connected to? E.g. the operator or the entity in > control of the decisions for the routing may want to direct certain traff= ic > always over WLANs that the operator deploys, and instead route only some = of > the traffic over WLANs of roaming partners or of the MN user home. How do= es > this solution support that scenario if the LMA is not told specifically > which WLAN the MN is connected to? From a deployment point of view, I do = not > believe we can afford to leave out this scenario. Please note that the > establishment of a security relationship between the MN and the MAG, and = a > specific MAG identity, cannot guarantee that the LMA knows which specific > WLAN access network the MN is connected to. Assuming that would severely > restrict the deployment scenarios. > > As for the MN and the LMA being magically in synch, I am very concerned > about a "glass ball" solution. You mention ANDSF defined by 3GPP as a > solution for this "out of band" delivery of policy. Fair enough, however > there is an issue with that. ANDSF is designed specific to be a MN-centri= c > solution where policies are provisioned in the MN and the MN decides whic= h > network technologies and access networks it needs to connect to, under wh= at > conditions, and which IP traffic needs to be routed on such accesses. No = IP > point of attachment in the network (i.e. the PDN GW in 3GPP that is the L= MA > in PMIPv6) is aware under any conditions of such policy. Therefore, even = if > in order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF wou= ld > unfortunately not provide a solution unless the MN can communicate to the > MAG and the LMA the decisions the MN has taken based on the ANDSF policie= s. > > I believe the key point here is that we need to understand how the soluti= on > can be realistically applied to a real scenario, and that we need to ensu= re > that important and realistic deployment scenarios are not excluded by the > solution. > > Cheers, > Stefano > > On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli wrote= : > > Hi Stefano: > > These are valid points and some good comments. Let me share my thoughts. > > Carlo=92s draft is not assuming any new MN-AR interface. Its going with t= he > assumption there is established policy on the mobile and on the LMA, whic= h > allows the mobile to select the access network at a flow level granularit= y, > without requiring any explicit signaling between the MAG and the MN. To > large part this is all about out of band policy interface, such as ANDSF, > towards the UE, leading to the assumption that magically the MN and the L= MA > are in sync with respect to flow policies, access selection and they will > make the right forwarding decision. Secondly, the flow policy decisions n= eed > not be based on the specific WLAN network, but it is implicitly driven by > the MAG =96 LMA security relation, where the MAG attachment to the WLAN > network transitively allows the LMA to make the flow policy decisions bas= ed > on the MAG identity. If the WLAN network is not trusted, there is truly n= o > MAG in that network, where the LMA shares a security relation with that > node. > > There are still some open issues on this draft that needs to be discussed > in the WG. On the approaches to allow more a flow aggregate movement, th= at > is a discussion point. There are issues that we need to discuss, supporti= ng > split link model, or eliminating some favorite brand of signaling message > (FMA) and riding on PBU/PBA and just with one FMI trigger, and on the > aspects around MN applying the flow policies by flow mirroring. We have n= o > agreement on those issues yet. > > Its just a base draft, for further discussion and resolving those issues. > But, hope that is not a stopper for base draft selection. > > > Sri > > > > > > > On 2/1/11 6:39 PM, "stefano faccin" http://sfaccinstd@gmail.com> > wrote: > > Raj, > thanks for the email. > > I need to apologize in advance if my questions have already been answered > before (though I cannot find a conclusive answer anywhere). > > I think that a protocol that is developed in NETEXT (or other groups) > should have at least a potential realistic scenario for applicability. > > In terms of applicability, though it is not part of the protocol definiti= on > per se, unless there are solutions in place for either the host to indica= te > to the network where the flows should be routed or for the LMA to receive > somehow from somewhere some policies, the solution cannot really provide > flow mobility since there is no way to decide which flows are routed wher= e. > If we are thinking about a host-based solution, I have not yet seen a > solution as to how the host can indicate to the MAG and ultimately to the > MAG which flows should be routed on each access. If we are relying on > modifications of layer 2 protocols, aren't we defining a solution that wo= rks > only with some technologies (since for other access technologies it is > rather unrealistic to modify L2 for IP flow mobility purposes)? If we are > thinking of an LMA-based solution, can we hear of at least one example of= a > real-life scenario where the LMA would receive such policies, and how suc= h > delivery would happen? Also, should there be a solution to have policies = in > the LMA, how does the LMA actually decide to route flows on one access or > the other? E.g., if some flows need to be routed on certain WLAN networks= , > but shall not be routed on other WLAN networks, how does the LMA know whi= ch > specific WLAN network the host is connected to? Perhaps I missed the abil= ity > for the MAG to know e.g. the WLAN SSID and provide it to the LMA, in whic= h > case I would appreciate if somebody could highlight to me where that is > defined. > > I think that, though not integral to the protocol specification, > understanding what framework the protocol would/needs to fit in is rather > important. > > Cheers, > Stefano > > > On Tue, Feb 1, 2011 at 3:47 PM, http://Basavaraj.Patil@nokia.com> > wrote: > > > Hello, > > We have discussed the flow mobility solutions for Proxy MIP6 previously a= t > IETFs 78 and 79. > This is a consensus call for adopting this I-D: > draft-bernardos-netext-pmipv6-flowmob-02 > as the working group document. > I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt > > The consensus call will expire on Feb 15th, 2011. Please indicate your > support or concerns in adopting this I-D as the WG baseline document on > the mailing list. > > Please note that this I-D will serve as the baseline in the WG and will b= e > developed further based on input and feedback from WG members. > > -Basavaraj > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > > > > > --=20 Stefano M. Faccin =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D May the Force be with you --0015175cdae63adf0f049b4fb348 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sri,
thanks for the reply. Can you clarify in which system or scenario A= NDSF is available to network entities as well? There is no such availabilit= y in 3GPP, and making such information available would require considerable= architectural changes, therefore the applicability of this solution to wha= t seems to be the only realistic scenario hinges on 3GPP making considerabl= e architectural changes. I would therefore not be so hastily concluding tha= t the ANDSF information is available to the LMA and underestimate what it w= ould really take to make the solution applicable.

If we cannot guarantee that there is at least one realistic solution to= have the MNa nd LMA in synch, how do we expect that this solution is appli= cable at all? In 3GPP there is no need to have such implicit assumption, be= cause 1) the MN is provided policies explicitly through the ANDSF, and 2) = it is the MN and only the MN that makes IP flow mobility decisions and comm= unicates them explicitly (with well defined signalling) to the LMA, and the= refore no magic is needed. There is no need in 3GPP to have the ANDSF and P= DN GW policies synchronized, since the PDN GW does not use such policies. <= br>
Sri, in the end it is a matter of whether we develop a solution that wi= ll rely on some unknown magic to be deployed, or a solution that we know ca= n be deployed in at least one way because there are solutions to what I con= sider major open issues.

Cheers,
Stefano

On Tue, Feb 1, 201= 1 at 9:06 PM, Sri Gundavelli <sgundave@cisco.com> wrote:
Hi Stefano,

Thanks for the discussion.

As you say, the ANDSF policies are allowing the MN a.) to make the right ne= twork attachment decision and b.) make the access selection on a flow basis= . This same policy that is present in the ANDSF server, is available for th= e network nodes as well. I=92m not sure, with out this assumption the solut= ion can work for all currently listed cases. We clearly need the MN and the= LMA to be in synch with respect to the configured policy. How, that is don= e, I guess we will not try to know. =A0I thought even in 3GPP, this is the = implied assumption ? But, this is for you to clarify. Not specifically for = IFOM where UE and PDN GW/HA are negotiating the flow policies, but generall= y that the PDN GW and the ANDSF policy server will have synchronized polici= es. The MAG and the LMA have the ability to carry this flow policy informat= ion in signaling messages and influence the access selection. The policy is= a opaque object, with extensible formats, when carried in the signaling pl= ane, should allow the LMA/MAG to apply those access policies, while assumin= g MN is following the same rules. These policies can surely reflect the spe= cific WLAN access/operator specific rule. I=92m surely with you, the lack o= f MN-AR interface is surely an issue and I see that. But, we need to unders= tand, what are the limitations with the approach of =A0out of band policy i= nterfaces and what will be the solution limitations. If we need to tie the = flow movement at the prefix granularity and rely on the natural ND interfac= e in the form of RA PIO option, more like PDN offload in MAPCON, or at the = granularity of a flow level, is open for discussion. I want to simplify thi= s draft for sure, we can surely discuss each of these issues on the WG draf= t.


Regards
Sri






On 2/1/11 8:29 PM, "stefano faccin" <sfaccinstd@gmail.com> wrote:

Sri,
thanks for the reply.

I'd like to comment on the "the flow policy = decisions need not be based on the specific WLAN network". Does it mea= n, as I believe it does, that the current solution would not allow an opera= tor deploying such solution to decide to route flows over a specific WLAN o= r not depending on which specific WLAN the MN is connected to? E.g. the ope= rator or the entity in control of the decisions for the routing may want to= direct certain traffic always over WLANs that the operator deploys, and in= stead route only some of the traffic over WLANs of roaming partners or of t= he MN user home. How does this solution support that scenario if the LMA is= not told specifically which WLAN the MN is connected to? From a deployment= point of view, I do not believe we can afford to leave out this scenario. = Please note that the establishment of a security relationship between the M= N and the MAG, and a specific MAG identity, cannot guarantee that the LMA k= nows which specific WLAN access network the MN is connected to. Assuming th= at would severely restrict the deployment scenarios.

As for the MN and the LMA being magically in synch, I am very concerned abo= ut a "glass ball" solution. You mention ANDSF defined by 3GPP as = a solution for this "out of band" delivery of policy. Fair enough= , however there is an issue with that. ANDSF is designed specific to be a M= N-centric solution where policies are provisioned in the MN and the MN deci= des which network technologies and access networks it needs to connect to, = under what conditions, and which IP traffic needs to be routed on such acce= sses. No IP point of attachment in the network (i.e. the PDN GW in 3GPP tha= t is the LMA in PMIPv6) is aware under any conditions of such policy. There= fore, even if in order to apply this solution to 3GPP we wanted to use ANDS= F, ANDSF would unfortunately not provide a solution unless the MN can commu= nicate to the MAG and the LMA the decisions the MN has taken based on the A= NDSF policies.

I believe the key point here is that we need to understand how the solution= can be realistically applied to a real scenario, and that we need to ensur= e that important and realistic deployment scenarios are not excluded by the= solution.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli <sgundave@cisco.com> wrote:
Hi Stefano:

These are valid points and some good comments. Let me share my thoughts.
Carlo=92s draft is not assuming any new MN-AR interface. Its going with the= assumption there is established policy on the mobile and on the LMA, which= allows the mobile to select the access network at a flow level granularity= , without requiring any explicit signaling between the MAG and the MN. To l= arge part this is all about out of band policy interface, such as ANDSF, to= wards the UE, leading to the assumption that magically the MN and the LMA a= re in sync with respect to flow policies, access selection and they will ma= ke the right forwarding decision. Secondly, the flow policy decisions need = not be based on the specific WLAN network, but it is implicitly driven by t= he MAG =96 LMA security relation, where the MAG attachment to the WLAN netw= ork transitively allows the LMA to make the flow policy decisions based on = the MAG identity. If the WLAN network is not trusted, there is truly no MAG= in that network, where the LMA shares a security relation with that node.<= br>
There are still some open issues on this draft that needs to be discussed i= n the WG. =A0On the approaches to allow more a flow aggregate movement, tha= t is a discussion point. There are issues that we need to discuss, supporti= ng split link model, or eliminating some favorite brand of signaling messag= e (FMA) and riding on PBU/PBA and just with one FMI trigger, and on the asp= ects around MN applying the flow policies by flow mirroring. We have no agr= eement on those issues yet.

Its just a base draft, for further discussion and resolving those issues. B= ut, hope that is not a stopper for base draft selection.
=A0

Sri






On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com> > wrote:

Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicat= e to the network where the flows should be routed or for the LMA to receive= somehow from somewhere some policies, the solution cannot really provide f= low mobility since there is no way to decide which flows are routed where. = If we are thinking about a host-based solution, I have not yet seen a solut= ion as to how the host can indicate to the MAG and ultimately to the MAG wh= ich flows should be routed on each access. If we are relying on modificatio= ns of layer 2 protocols, aren't we defining a solution that works only = with some technologies (since for other access technologies it is rather un= realistic to modify L2 for IP flow mobility purposes)? If we are thinking o= f an LMA-based solution, can we hear of at least one example of a real-life= scenario where the LMA would receive such policies, and how such delivery = would happen? Also, should there be a solution to have policies in the LMA,= how does the LMA actually decide to route flows on one access or the other= ? E.g., if some flows need to be routed on certain WLAN networks, but shall= not be routed on other WLAN networks, how does the LMA know which specific= WLAN network the host is connected to? Perhaps I missed the ability for th= e MAG to know e.g. the WLAN SSID and provide it to the LMA, in which case I= would appreciate if somebody could highlight to me where that is defined.<= br>
I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important. =

Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM, =A0<Basavaraj.Patil@nokia.com <http://Basavaraj.Patil@nok= ia.com> > wrote:

Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= br> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-p= mipv6-flowmob-02.txt

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= br> developed further based on input and feedback from WG members.

-Basavaraj

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







--
Stefano M. Faccin
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
May the Force be = with you
--0015175cdae63adf0f049b4fb348-- From rkoodli@cisco.com Wed Feb 2 09:33:36 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9D953A6D92 for ; Wed, 2 Feb 2011 09:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.665 X-Spam-Level: X-Spam-Status: No, score=-109.665 tagged_above=-999 required=5 tests=[AWL=-0.463, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2PfE5KlI9ek for ; Wed, 2 Feb 2011 09:33:30 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 63EDA3A6D67 for ; Wed, 2 Feb 2011 09:33:30 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAAolSU2tJV2b/2dsb2JhbACCRaFvZ3OgYZsjhVMEhHiGaYMwgwA Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-1.cisco.com with ESMTP; 02 Feb 2011 17:36:49 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p12Hanma027737; Wed, 2 Feb 2011 17:36:49 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Feb 2011 11:36:49 -0600 Received: from 10.21.147.70 ([10.21.147.70]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Wed, 2 Feb 2011 17:36:49 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Wed, 02 Feb 2011 09:55:13 -0800 From: Rajeev Koodli To: stefano faccin , Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvDAlcrfHOX4MwGxE+Ik5TuN7wnhg== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3379485313_51605619" X-OriginalArrivalTime: 02 Feb 2011 17:36:49.0546 (UTC) FILETIME=[C5759EA0:01CBC2FF] Cc: netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 17:33:36 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3379485313_51605619 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Stefano, Thanks for your input. I expect the LMA interacting with PCRF for policy rules specific to the subscriber for different RAT types. You are right that the LMA does not know the SSID the mobile is connected to. It=B9s not clear if the MAG can get that from the MN either without additional signaling. However, the LMA knows that the MN is connected to WLAN; so it can apply the policy at the RAT type level. Are you thinking of the MN connecting to more than one WLAN network (and each of those connections coming back to the LMA)? If so, please explain the scenario. Regards, -Rajeev On 2/1/11 6:39 PM, "stefano faccin" wrote: > Raj, > thanks for the email. >=20 > I need to apologize in advance if my questions have already been answered > before (though I cannot find a conclusive answer anywhere). >=20 > I think that a protocol that is developed in NETEXT (or other groups) sho= uld > have at least a potential realistic scenario for applicability. >=20 > In terms of applicability, though it is not part of the protocol definiti= on > per se, unless there are solutions in place for either the host to indica= te to > the network where the flows should be routed or for the LMA to receive so= mehow > from somewhere some policies, the solution cannot really provide flow mob= ility > since there is no way to decide which flows are routed where. If we are > thinking about a host-based solution, I have not yet seen a solution as t= o how > the host can indicate to the MAG and ultimately to the MAG which flows sh= ould > be routed on each access. If we are relying on modifications of layer 2 > protocols, aren't we defining a solution that works only with some > technologies (since for other access technologies it is rather unrealisti= c to > modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-ba= sed > solution, can we hear of at least one example of a real-life scenario whe= re > the LMA would receive such policies, and how such delivery would happen? = Also, > should there be a solution to have policies in the LMA, how does the LMA > actually decide to route flows on one access or the other? E.g., if some = flows > need to be routed on certain WLAN networks, but shall not be routed on ot= her > WLAN networks, how does the LMA know which specific WLAN network the host= is > connected to? Perhaps I missed the ability for the MAG to know e.g. the W= LAN > SSID and provide it to the LMA, in which case I would appreciate if someb= ody > could highlight to me where that is defined. >=20 > I think that, though not integral to the protocol specification, understa= nding > what framework the protocol would/needs to fit in is rather important. >=20 > Cheers, > Stefano >=20 >=20 > On Tue, Feb 1, 2011 at 3:47 PM, wrote: >>=20 >> Hello, >>=20 >> We have discussed the flow mobility solutions for Proxy MIP6 previously = at >> IETFs 78 and 79. >> This is a consensus call for adopting this I-D: >> draft-bernardos-netext-pmipv6-flowmob-02 >> as the working group document. >> I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt >>=20 >> The consensus call will expire on Feb 15th, 2011. Please indicate your >> support or concerns in adopting this I-D as the WG baseline document on >> the mailing list. >>=20 >> Please note that this I-D will serve as the baseline in the WG and will = be >> developed further based on input and feedback from WG members. >>=20 >> -Basavaraj >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >=20 >=20 --B_3379485313_51605619 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmi= pv6-flowmob as WG doc
Hi Stefano,

Thanks for your input.

I expect the LMA interacting with PCRF for policy rules specific to the sub= scriber for different RAT types.
You are right that the LMA does not know the SSID the mobile is connected t= o. It’s not clear if the MAG can get that from the MN either without a= dditional signaling. However, the LMA knows that the MN is connected to WLAN= ; so it can apply the policy at the RAT type level. Are you thinking of the = MN connecting to more than one WLAN network (and each of those connections c= oming back to the LMA)? If so, please explain the scenario.

Regards,

-Rajeev



On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicate= to the network where the flows should be routed or for the LMA to receive s= omehow from somewhere some policies, the solution cannot really provide flow= mobility since there is no way to decide which flows are routed where. If w= e are thinking about a host-based solution, I have not yet seen a solution a= s to how the host can indicate to the MAG and ultimately to the MAG which fl= ows should be routed on each access. If we are relying on modifications of l= ayer 2 protocols, aren't we defining a solution that works only with some te= chnologies (since for other access technologies it is rather unrealistic to = modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-based= solution, can we hear of at least one example of a real-life scenario where= the LMA would receive such policies, and how such delivery would happen? Al= so, should there be a solution to have policies in the LMA, how does the LMA= actually decide to route flows on one access or the other? E.g., if some fl= ows need to be routed on certain WLAN networks, but shall not be routed on o= ther WLAN networks, how does the LMA know which specific WLAN network the ho= st is connected to? Perhaps I missed the ability for the MAG to know e.g. th= e WLAN SSID and provide it to the LMA, in which case I would appreciate if s= omebody could highlight to me where that is defined.

I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important. <= BR>
Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM,  <Basavaraj.Patil@nokia.com> wrote:
<= SPAN STYLE=3D'font-size:11pt'>
Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= BR> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt<= /a>

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= BR> developed further based on input and feedback from WG members.

-Basavaraj

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

--B_3379485313_51605619-- From cjbc@it.uc3m.es Wed Feb 2 09:33:52 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D85763A6D7C for ; Wed, 2 Feb 2011 09:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5sk+scJVJ3g for ; Wed, 2 Feb 2011 09:33:50 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 752C73A6D93 for ; Wed, 2 Feb 2011 09:33:50 -0800 (PST) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 29E75844920; Wed, 2 Feb 2011 18:37:06 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: pierrick.seite@orange-ftgroup.com In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46201795F8D@ftrdmel0.rd.francetelecom.fr> References: <843DA8228A1BA74CA31FB4E111A5C46201795F8D@ftrdmel0.rd.francetelecom.fr> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-7mqmKCdX90ZLKVwTXvwO" Organization: Universidad Carlos III de Madrid Date: Wed, 02 Feb 2011 18:38:08 +0100 Message-ID: <1296668288.3032.90.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17932.000 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 17:33:53 -0000 --=-7mqmKCdX90ZLKVwTXvwO Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Pierrick, Thanks for your comments. See some of mine below. On Wed, 2011-02-02 at 17:45 +0100, pierrick.seite@orange-ftgroup.com wrote: > Hi, >=20 > I've one concern about this I-D. Section 3.2 describes three mobility > scenarios. The second one is about different set of prefixes per > interface and focus on mobility triggered by L2 attachment. This > scenario is quite confusing... I mean, obviously L2 attachment is a > trigger for mobility but it is not specific to the scenario where MAGs > manage different sets of prefixes; L2 attachment could also trigger > mobility when prefix is shared between interface. Anyway, this text is Agree. The point is that when the same prefix(es) is shared between interfaces, there is no need for any signaling for the LMA to perform flow mobility, while for the case of different prefixes we need (at least to ensure that the routing state at the MAG is correct). That's the reason we structure the draft in this way, though I agree it can be improved. > about trigger for mobility and should be out of the scope of this > draft. Besides, text after figure 4 clearly says that trigger and > handover decision making is out of scope; I can't agree more. >=20 > So, even if -02 improved, I think this draft should be clarified again > by focusing on basic flow mobility operations, i.e. scenario 1 and 3 > of section 3.2. In my understanding these operations are: the LMA > maintains a collection of BCE and controls mobility, i.e. decides how > to use these BCEs. To perform handover, i.e. apply LMA decision, we > have two scenarios: 1) move flow or 2) move HNP. Additionally, when > MAGs use different sets of prefixes, we need piece of protocol between > LMA and MAGs, or PMIP behaviour modification, to allow the new MAG > updating its routing state.=20 Right, and the draft basically include some procedures to do so. We are aware that there are some alternative/redundant mechanisms described in the current draft. We wanted to have feedback from the WG on which ones should be adopted and further refined. Carlos >=20 > BR, > Pierrick >=20 > > -----Message d'origine----- > > De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la par= t > > de Basavaraj.Patil@nokia.com > > Envoy=E9 : mercredi 2 f=E9vrier 2011 00:47 > > =C0 : netext@ietf.org > > Objet : [netext] Consensus call to adopt I-D: draft-bernardos-netext- > > pmipv6-flowmob as WG doc > >=20 > >=20 > > Hello, > >=20 > > We have discussed the flow mobility solutions for Proxy MIP6 previously= at > > IETFs 78 and 79. > > This is a consensus call for adopting this I-D: > > draft-bernardos-netext-pmipv6-flowmob-02 > > as the working group document. > > I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.tx= t > >=20 > > The consensus call will expire on Feb 15th, 2011. Please indicate your > > support or concerns in adopting this I-D as the WG baseline document on > > the mailing list. > >=20 > > Please note that this I-D will serve as the baseline in the WG and will= be > > developed further based on input and feedback from WG members. > >=20 > > -Basavaraj > >=20 > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-7mqmKCdX90ZLKVwTXvwO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1JloAACgkQNdy6TdFwT2fr2ACeKYbsDk07009JbxAbCZzErdw0 Xw8AoOCRXu/0Yg/t9+kPK9vSNuPiy5rZ =piKk -----END PGP SIGNATURE----- --=-7mqmKCdX90ZLKVwTXvwO-- From sfaccinstd@gmail.com Wed Feb 2 09:53:29 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 001013A6CE7 for ; Wed, 2 Feb 2011 09:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.165 X-Spam-Level: X-Spam-Status: No, score=-103.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0EV5DJBIdUB for ; Wed, 2 Feb 2011 09:53:24 -0800 (PST) Received: from mail-qy0-f194.google.com (mail-qy0-f194.google.com [209.85.216.194]) by core3.amsl.com (Postfix) with ESMTP id E4A693A6D79 for ; Wed, 2 Feb 2011 09:53:23 -0800 (PST) Received: by qyk4 with SMTP id 4so18260qyk.1 for ; Wed, 02 Feb 2011 09:56:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=aXys+MnJTgXIcCGhCk+tqZBIAEA6VpTbuU/y5bu03Zw=; b=xOCEoIew4yvkJ05+T1SJyTGHaMV87BCmGHVz14d2YIBKzqTgsTGHc6kQtSrtamieYr o2zWdi0ism1x/UwqRmgImTJ87refLScF+h+N8Ph0E4I9IE4p0/UvEmQOt6kky+4Xjuz8 VAIDn/zDkYX5MlOqVA62ZrJpxr8o4GDo9/fd8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TjRTO76hCcrZKUsx4OKkQcyg1jHShsGx43AqjLd/HYIjbDkcY0U1Enc54HAHTYtcW+ idK245LKWbmlgLFfZ4YmFQ9XijJXFkqwIoxiyXDwfo47DW+CKwW94EbPe472L+sYpJXh y5//7lvpt7/7Rxegt9p353+UEbxrLXdObh53E= MIME-Version: 1.0 Received: by 10.229.91.194 with SMTP id o2mr8409578qcm.138.1296669402764; Wed, 02 Feb 2011 09:56:42 -0800 (PST) Received: by 10.229.20.70 with HTTP; Wed, 2 Feb 2011 09:56:42 -0800 (PST) In-Reply-To: References: Date: Wed, 2 Feb 2011 09:56:42 -0800 Message-ID: From: stefano faccin To: Rajeev Koodli Content-Type: multipart/alternative; boundary=0016364ee6402497e7049b505fe5 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 17:53:29 -0000 --0016364ee6402497e7049b505fe5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello rajeev, the use of PCRF is an interesting suggestion. However, unfortunately, PCRF does not contain any policies or information that will tell the LMA what ar= e the policies to be used for decisions of IP flow mobility. This is not part of current PCC functionality, and there is no work ongoing or planned to extend PCC in such way. Therefore, the applicability of the solution in thi= s draft would hinge on hypotetical future solutions and not on a current solution for the open issues, which brings us back to my point that we are defining a solution with open issues for which there is not a single realistic solution out there, thus making this draft not applicable to a real scenario. I am not thinking of the UE connecting to more than one WLAN at the same time, but the UE being able to connect to different WLANs (one at a time) because the UE is e.g. provisioned with a list of SSIDs or the UE discovers a hotspot somewhere. I am talking about the scenario where the UE is capabl= e to connect to WLAN, but the operator has different policies wrt which WLAN the UE should use or not. If you have followed the work in 3GPP, it is clear that operators have interest in applying policies not only at RAT level, but also at access network level (please see how ANDSF was defined and why). I guess we can al= l agree that an operator deploying PMIP-based mobility may be interested in having policies that allow traffic on the WLAN the operator owns or that belongs to a roaming partner, while not allowing traffic on WLAN of other operators for which it might need to pay an extra fee or where e.g. no QoS can be guaranteed. That means that the entity deciding whether traffic need= s to be routed on WLAN or not cannot just consider "WLAN is available", but "WLAN SSIDx is available", so that the decision can be based on the operato= r preferences as to which WLAN certain traffic needs to be routed on. If the draft allows decisions to be made only at the RAT level, then we hav= e an issue because we are defining a solution that should be applicable to 3GPP but does not meet the deployment scenarios of interest. In other words= , if we want to make this solution applicable e.g. to 3GPP, we need to be abl= e to provide the same functionality available today in 3GPP with other solution in order to satisfy the use cases supported by 3GPP, and not step backwards in terms of what can be supported. Cheers, Stefano On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli wrote: > > Hi Stefano, > > Thanks for your input. > > I expect the LMA interacting with PCRF for policy rules specific to the > subscriber for different RAT types. > You are right that the LMA does not know the SSID the mobile is connected > to. It=92s not clear if the MAG can get that from the MN either without > additional signaling. However, the LMA knows that the MN is connected to > WLAN; so it can apply the policy at the RAT type level. Are you thinking = of > the MN connecting to more than one WLAN network (and each of those > connections coming back to the LMA)? If so, please explain the scenario. > > Regards, > > -Rajeev > > > > > On 2/1/11 6:39 PM, "stefano faccin" wrote: > > Raj, > thanks for the email. > > I need to apologize in advance if my questions have already been answered > before (though I cannot find a conclusive answer anywhere). > > I think that a protocol that is developed in NETEXT (or other groups) > should have at least a potential realistic scenario for applicability. > > In terms of applicability, though it is not part of the protocol definiti= on > per se, unless there are solutions in place for either the host to indica= te > to the network where the flows should be routed or for the LMA to receive > somehow from somewhere some policies, the solution cannot really provide > flow mobility since there is no way to decide which flows are routed wher= e. > If we are thinking about a host-based solution, I have not yet seen a > solution as to how the host can indicate to the MAG and ultimately to the > MAG which flows should be routed on each access. If we are relying on > modifications of layer 2 protocols, aren't we defining a solution that wo= rks > only with some technologies (since for other access technologies it is > rather unrealistic to modify L2 for IP flow mobility purposes)? If we are > thinking of an LMA-based solution, can we hear of at least one example of= a > real-life scenario where the LMA would receive such policies, and how suc= h > delivery would happen? Also, should there be a solution to have policies = in > the LMA, how does the LMA actually decide to route flows on one access or > the other? E.g., if some flows need to be routed on certain WLAN networks= , > but shall not be routed on other WLAN networks, how does the LMA know whi= ch > specific WLAN network the host is connected to? Perhaps I missed the abil= ity > for the MAG to know e.g. the WLAN SSID and provide it to the LMA, in whic= h > case I would appreciate if somebody could highlight to me where that is > defined. > > I think that, though not integral to the protocol specification, > understanding what framework the protocol would/needs to fit in is rather > important. > > Cheers, > Stefano > > > On Tue, Feb 1, 2011 at 3:47 PM, wrote: > > > Hello, > > We have discussed the flow mobility solutions for Proxy MIP6 previously a= t > IETFs 78 and 79. > This is a consensus call for adopting this I-D: > draft-bernardos-netext-pmipv6-flowmob-02 > as the working group document. > I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt > > The consensus call will expire on Feb 15th, 2011. Please indicate your > support or concerns in adopting this I-D as the WG baseline document on > the mailing list. > > Please note that this I-D will serve as the baseline in the WG and will b= e > developed further based on input and feedback from WG members. > > -Basavaraj > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > > > --=20 Stefano M. Faccin =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D May the Force be with you --0016364ee6402497e7049b505fe5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello rajeev,
the use of PCRF is an interesting suggestion. However, unf= ortunately, PCRF does not contain any policies or information that will tel= l the LMA what are the policies to be used for decisions of IP flow mobilit= y. This is not part of current PCC functionality, and there is no work ongo= ing or planned to extend PCC in such way. Therefore, the applicability of t= he solution in this draft would hinge on hypotetical future solutions and n= ot on a current solution for the open issues, which brings us back to my po= int that we are defining a solution with open issues for which there is not= a single realistic solution out there, thus making this draft not applicab= le to a real scenario.

I am not thinking of the UE connecting to more than one WLAN at the same ti= me, but the UE being able to connect to different WLANs (one at a time) bec= ause the UE is e.g. provisioned with a list of SSIDs or the UE discovers a = hotspot somewhere. I am=20 talking about the scenario where the UE is capable to connect to WLAN,=20 but the operator has different policies wrt which WLAN the UE should use or not.

If you have followed the work in 3GPP, it is clear that ope= rators have interest in applying policies not only at RAT level, but also a= t access network level (please see how ANDSF was defined and why). I guess = we can all agree that an operator deploying PMIP-based mobility=20 may be interested in having policies that allow traffic on the WLAN the=20 operator owns or that belongs to a roaming partner, while not allowing=20 traffic on WLAN of other operators for which it might need to pay an=20 extra fee or where e.g. no QoS can be guaranteed. That means that the entit= y deciding whether traffic needs to be routed on WLAN or not cannot just co= nsider "WLAN is available", but "WLAN SSIDx is available&quo= t;, so that the decision can be based on the operator preferences as to whi= ch WLAN certain traffic needs to be routed on.

If the draft allows decisions to be made only at the RAT level, then we hav= e an issue because we are defining a solution that should be applicable to = 3GPP but does not meet the deployment scenarios of interest. In other words= , if we want to make this solution applicable e.g. to 3GPP, we need to be a= ble to provide the same functionality available today in 3GPP with other so= lution in order to satisfy the use cases supported by 3GPP, and not step ba= ckwards in terms of what can be supported.

Cheers,

Stefano

On Wed, Feb 2,= 2011 at 9:55 AM, Rajeev Koodli <rkoodli@cisco.com> wrote:

Hi Stefano,

Thanks for your input.

I expect the LMA interacting with PCRF for policy rules specific to the sub= scriber for different RAT types.
You are right that the LMA does not know the SSID the mobile is connected t= o. It=92s not clear if the MAG can get that from the MN either without addi= tional signaling. However, the LMA knows that the MN is connected to WLAN; = so it can apply the policy at the RAT type level. Are you thinking of the M= N connecting to more than one WLAN network (and each of those connections c= oming back to the LMA)? If so, please explain the scenario.

Regards,

-Rajeev




On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com> wrote:

Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicat= e to the network where the flows should be routed or for the LMA to receive= somehow from somewhere some policies, the solution cannot really provide f= low mobility since there is no way to decide which flows are routed where. = If we are thinking about a host-based solution, I have not yet seen a solut= ion as to how the host can indicate to the MAG and ultimately to the MAG wh= ich flows should be routed on each access. If we are relying on modificatio= ns of layer 2 protocols, aren't we defining a solution that works only = with some technologies (since for other access technologies it is rather un= realistic to modify L2 for IP flow mobility purposes)? If we are thinking o= f an LMA-based solution, can we hear of at least one example of a real-life= scenario where the LMA would receive such policies, and how such delivery = would happen? Also, should there be a solution to have policies in the LMA,= how does the LMA actually decide to route flows on one access or the other= ? E.g., if some flows need to be routed on certain WLAN networks, but shall= not be routed on other WLAN networks, how does the LMA know which specific= WLAN network the host is connected to? Perhaps I missed the ability for th= e MAG to know e.g. the WLAN SSID and provide it to the LMA, in which case I= would appreciate if somebody could highlight to me where that is defined.<= br>
I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important. =

Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM, =A0<Basavaraj.Patil@nokia.com> wrote:

Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= br> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-p= mipv6-flowmob-02.txt

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= br> developed further based on input and feedback from WG members.

-Basavaraj

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





--
Stefano M. Faccin
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
May the Force be = with you
--0016364ee6402497e7049b505fe5-- From rkoodli@cisco.com Wed Feb 2 10:22:59 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1AE13A6DB2 for ; Wed, 2 Feb 2011 10:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.619 X-Spam-Level: X-Spam-Status: No, score=-109.619 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQtU3+O5N1-y for ; Wed, 2 Feb 2011 10:22:48 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D0CCA3A6DAF for ; Wed, 2 Feb 2011 10:22:47 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwGAMMwSU2tJV2Z/2dsb2JhbACCRZQ1hgcBhzNnc6BWmyeFUwSEeIZpgzCDAA Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-2.cisco.com with ESMTP; 02 Feb 2011 18:26:07 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p12IQ7sO008225; Wed, 2 Feb 2011 18:26:07 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Feb 2011 12:26:06 -0600 Received: from 10.21.147.70 ([10.21.147.70]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Wed, 2 Feb 2011 18:26:06 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Wed, 02 Feb 2011 10:44:30 -0800 From: Rajeev Koodli To: stefano faccin Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvDCTmtCMhEXR6w0kyljEfoJ1YA0w== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3379488271_51785173" X-OriginalArrivalTime: 02 Feb 2011 18:26:06.0771 (UTC) FILETIME=[A81A5830:01CBC306] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 18:23:00 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3379488271_51785173 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Stefano, You make two interesting points: First, the defined solution should be useful for 3GPP deployments. Second, if it=B9s not defined today in 3GPP, it=B9= s not useful. I tend to agree with you on the first =AD 3GPP is a big potential customer. I cannot agree with your second point. There are multiple ways I could envision policy on the LMA. Locally configured policy is one (which we use today in deployments) that does not need Gx interaction. Gx extensions can be proposed in the future. I hope yo= u are not suggesting that these are not feasible choices. For the MN (IETF term for UE) to even connect to the MAG via WLAN today, yo= u need an IPsec termination point (ePDG). If the operator pre-configures the list of SSIDs or there is some out-of-band mechanism to inform the MN which SSID is =B3white-listed=B2, then I expect the MN to decide when to connect to the ePDG and hence the MAG. At this point, the MN is already on the WLAN th= e operator cares about I presume. There is no easy way for the network (LMA, MAG) to know what SSID the MN is connected to =AD the network has to either trust the software on the MN or th= e WLAN infrastructure has to provide the SSID information to the network. -Rajeev On 2/2/11 9:56 AM, "stefano faccin" wrote: > Hello rajeev, > the use of PCRF is an interesting suggestion. However, unfortunately, PCR= F > does not contain any policies or information that will tell the LMA what = are > the policies to be used for decisions of IP flow mobility. This is not pa= rt of > current PCC functionality, and there is no work ongoing or planned to ext= end > PCC in such way. Therefore, the applicability of the solution in this dra= ft > would hinge on hypotetical future solutions and not on a current solution= for > the open issues, which brings us back to my point that we are defining a > solution with open issues for which there is not a single realistic solut= ion > out there, thus making this draft not applicable to a real scenario. >=20 > I am not thinking of the UE connecting to more than one WLAN at the same = time, > but the UE being able to connect to different WLANs (one at a time) becau= se > the UE is e.g. provisioned with a list of SSIDs or the UE discovers a hot= spot > somewhere. I am talking about the scenario where the UE is capable to con= nect > to WLAN, but the operator has different policies wrt which WLAN the UE sh= ould > use or not. >=20 > If you have followed the work in 3GPP, it is clear that operators have > interest in applying policies not only at RAT level, but also at access > network level (please see how ANDSF was defined and why). I guess we can = all > agree that an operator deploying PMIP-based mobility may be interested in > having policies that allow traffic on the WLAN the operator owns or that > belongs to a roaming partner, while not allowing traffic on WLAN of other > operators for which it might need to pay an extra fee or where e.g. no Qo= S can > be guaranteed. That means that the entity deciding whether traffic needs = to be > routed on WLAN or not cannot just consider "WLAN is available", but "WLAN > SSIDx is available", so that the decision can be based on the operator > preferences as to which WLAN certain traffic needs to be routed on. >=20 > If the draft allows decisions to be made only at the RAT level, then we h= ave > an issue because we are defining a solution that should be applicable to = 3GPP > but does not meet the deployment scenarios of interest. In other words, i= f we > want to make this solution applicable e.g. to 3GPP, we need to be able to > provide the same functionality available today in 3GPP with other solutio= n in > order to satisfy the use cases supported by 3GPP, and not step backwards = in > terms of what can be supported. >=20 > Cheers, >=20 > Stefano >=20 > On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli wrote: >>=20 >> Hi Stefano, >>=20 >> Thanks for your input. >>=20 >> I expect the LMA interacting with PCRF for policy rules specific to the >> subscriber for different RAT types. >> You are right that the LMA does not know the SSID the mobile is connecte= d to. >> It=B9s not clear if the MAG can get that from the MN either without additi= onal >> signaling. However, the LMA knows that the MN is connected to WLAN; so i= t can >> apply the policy at the RAT type level. Are you thinking of the MN conne= cting >> to more than one WLAN network (and each of those connections coming back= to >> the LMA)? If so, please explain the scenario. >>=20 >> Regards, >>=20 >> -Rajeev >>=20 >>=20 >>=20 >>=20 >> On 2/1/11 6:39 PM, "stefano faccin" > > wrote: >>=20 >>> Raj, >>> thanks for the email. >>>=20 >>> I need to apologize in advance if my questions have already been answer= ed >>> before (though I cannot find a conclusive answer anywhere). >>>=20 >>> I think that a protocol that is developed in NETEXT (or other groups) s= hould >>> have at least a potential realistic scenario for applicability. >>>=20 >>> In terms of applicability, though it is not part of the protocol defini= tion >>> per se, unless there are solutions in place for either the host to indi= cate >>> to the network where the flows should be routed or for the LMA to recei= ve >>> somehow from somewhere some policies, the solution cannot really provid= e >>> flow mobility since there is no way to decide which flows are routed wh= ere. >>> If we are thinking about a host-based solution, I have not yet seen a >>> solution as to how the host can indicate to the MAG and ultimately to t= he >>> MAG which flows should be routed on each access. If we are relying on >>> modifications of layer 2 protocols, aren't we defining a solution that = works >>> only with some technologies (since for other access technologies it is >>> rather unrealistic to modify L2 for IP flow mobility purposes)? If we a= re >>> thinking of an LMA-based solution, can we hear of at least one example = of a >>> real-life scenario where the LMA would receive such policies, and how s= uch >>> delivery would happen? Also, should there be a solution to have policie= s in >>> the LMA, how does the LMA actually decide to route flows on one access = or >>> the other? E.g., if some flows need to be routed on certain WLAN networ= ks, >>> but shall not be routed on other WLAN networks, how does the LMA know w= hich >>> specific WLAN network the host is connected to? Perhaps I missed the ab= ility >>> for the MAG to know e.g. the WLAN SSID and provide it to the LMA, in wh= ich >>> case I would appreciate if somebody could highlight to me where that is >>> defined. >>>=20 >>> I think that, though not integral to the protocol specification, >>> understanding what framework the protocol would/needs to fit in is rath= er >>> important.=20 >>>=20 >>> Cheers, >>> Stefano >>>=20 >>>=20 >>> On Tue, Feb 1, 2011 at 3:47 PM, =A0>> > wrote: >>>>=20 >>>> Hello, >>>>=20 >>>> We have discussed the flow mobility solutions for Proxy MIP6 previousl= y at >>>> IETFs 78 and 79. >>>> This is a consensus call for adopting this I-D: >>>> draft-bernardos-netext-pmipv6-flowmob-02 >>>> as the working group document. >>>> I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.t= xt >>>>=20 >>>> The consensus call will expire on Feb 15th, 2011. Please indicate your >>>> support or concerns in adopting this I-D as the WG baseline document o= n >>>> the mailing list. >>>>=20 >>>> Please note that this I-D will serve as the baseline in the WG and wil= l be >>>> developed further based on input and feedback from WG members. >>>>=20 >>>> -Basavaraj >>>>=20 >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>=20 >>>=20 >=20 >=20 --B_3379488271_51785173 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmi= pv6-flowmob as WG doc
Hi Stefano,

You make two interesting points: First, the defined solution should be usef= ul for 3GPP deployments. Second, if it’s not defined today in 3= GPP, it’s not useful.

I tend to agree with you on the first – 3GPP is a big potential custo= mer.
I cannot agree with your second point.

There are multiple ways I could envision policy on the LMA. Locally configu= red policy is one (which we use today in deployments) that does not need Gx = interaction. Gx extensions can be proposed in the future. I hope you are not= suggesting that these are not feasible choices.

For the MN (IETF term for UE) to even connect to the MAG via WLAN today, yo= u need an IPsec termination point (ePDG). If the operator pre-configures the= list of SSIDs or there is some out-of-band mechanism to inform the MN which= SSID is “white-listed”, then I expect the MN to decide when to = connect to the ePDG and hence the MAG. At this point, the MN is already on t= he WLAN the operator cares about I presume.
There is no easy way for the network (LMA, MAG) to know what SSID the MN is= connected to – the network has to either trust the software on the MN= or the WLAN infrastructure has to provide the SSID information to the netwo= rk.

-Rajeev


On 2/2/11 9:56 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Hello rajeev,
the use of PCRF is an interesting suggestion. However, unfortunately, PCRF = does not contain any policies or information that will tell the LMA what are= the policies to be used for decisions of IP flow mobility. This is not part= of current PCC functionality, and there is no work ongoing or planned to ex= tend PCC in such way. Therefore, the applicability of the solution in this d= raft would hinge on hypotetical future solutions and not on a current soluti= on for the open issues, which brings us back to my point that we are definin= g a solution with open issues for which there is not a single realistic solu= tion out there, thus making this draft not applicable to a real scenario.
I am not thinking of the UE connecting to more than one WLAN at the same ti= me, but the UE being able to connect to different WLANs (one at a time) beca= use the UE is e.g. provisioned with a list of SSIDs or the UE discovers a ho= tspot somewhere. I am talking about the scenario where the UE is capable to = connect to WLAN, but the operator has different policies wrt which WLAN the = UE should use or not.

If you have followed the work in 3GPP, it is clear that operators have inte= rest in applying policies not only at RAT level, but also at access network = level (please see how ANDSF was defined and why). I guess we can all agree t= hat an operator deploying PMIP-based mobility may be interested in having po= licies that allow traffic on the WLAN the operator owns or that belongs to a= roaming partner, while not allowing traffic on WLAN of other operators for = which it might need to pay an extra fee or where e.g. no QoS can be guarante= ed. That means that the entity deciding whether traffic needs to be routed o= n WLAN or not cannot just consider "WLAN is available", but "= WLAN SSIDx is available", so that the decision can be based on the oper= ator preferences as to which WLAN certain traffic needs to be routed on.
If the draft allows decisions to be made only at the RAT level, then we hav= e an issue because we are defining a solution that should be applicable to 3= GPP but does not meet the deployment scenarios of interest. In other words, = if we want to make this solution applicable e.g. to 3GPP, we need to be able= to provide the same functionality available today in 3GPP with other soluti= on in order to satisfy the use cases supported by 3GPP, and not step backwar= ds in terms of what can be supported.

Cheers,

Stefano

On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli <rkoodli@cisco.com> wrote:
<= SPAN STYLE=3D'font-size:11pt'>
Hi Stefano,

Thanks for your input.

I expect the LMA interacting with PCRF for policy rules specific to the sub= scriber for different RAT types.
You are right that the LMA does not know the SSID the mobile is connected t= o. It’s not clear if the MAG can get that from the MN either without a= dditional signaling. However, the LMA knows that the MN is connected to WLAN= ; so it can apply the policy at the RAT type level. Are you thinking of the = MN connecting to more than one WLAN network (and each of those connections c= oming back to the LMA)? If so, please explain the scenario.

Regards,

-Rajeev




On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <htt= p://sfaccinstd@gmail.com> > wrote:

<= SPAN STYLE=3D'font-size:11pt'>Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicate= to the network where the flows should be routed or for the LMA to receive s= omehow from somewhere some policies, the solution cannot really provide flow= mobility since there is no way to decide which flows are routed where. If w= e are thinking about a host-based solution, I have not yet seen a solution a= s to how the host can indicate to the MAG and ultimately to the MAG which fl= ows should be routed on each access. If we are relying on modifications of l= ayer 2 protocols, aren't we defining a solution that works only with some te= chnologies (since for other access technologies it is rather unrealistic to = modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-based= solution, can we hear of at least one example of a real-life scenario where= the LMA would receive such policies, and how such delivery would happen? Al= so, should there be a solution to have policies in the LMA, how does the LMA= actually decide to route flows on one access or the other? E.g., if some fl= ows need to be routed on certain WLAN networks, but shall not be routed on o= ther WLAN networks, how does the LMA know which specific WLAN network the ho= st is connected to? Perhaps I missed the ability for the MAG to know e.g. th= e WLAN SSID and provide it to the LMA, in which case I would appreciate if s= omebody could highlight to me where that is defined.

I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important. <= BR>
Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM, =A0<Ba= savaraj.Patil@nokia.com <h= ttp://Basavaraj.Patil@nokia.com> > wrote:
<= SPAN STYLE=3D'font-size:11pt'>
Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= BR> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt<= /a>

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= BR> developed further based on input and feedback from WG members.

-Basavaraj

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



--B_3379488271_51785173-- From sfaccinstd@gmail.com Wed Feb 2 10:46:54 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 828E23A6C3A for ; Wed, 2 Feb 2011 10:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.273 X-Spam-Level: X-Spam-Status: No, score=-103.273 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OY9+M3FGRqJz for ; Wed, 2 Feb 2011 10:46:52 -0800 (PST) Received: from mail-qy0-f194.google.com (mail-qy0-f194.google.com [209.85.216.194]) by core3.amsl.com (Postfix) with ESMTP id 979C23A67B7 for ; Wed, 2 Feb 2011 10:46:51 -0800 (PST) Received: by qyk4 with SMTP id 4so21867qyk.1 for ; Wed, 02 Feb 2011 10:50:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+MTRr4Z/zyyMG3mjxb7Svhh8qxMtRkEFZ3YRVXdLOY0=; b=DIHfJ3Cq8cuEs4hlACQZboiahFZTtLgVxNG5E5gi5LVB7qFQ30BBg4tfe5Cxvgbhzg CFVUZPT3jDU7MiAtxJxs52WxujHLnH/ThJAqoIdeZ3mXwCdrSbhCBVXa0BF85xQtdDwS xdgWyOYY/9ujUAPWLTq7Culx3F67PMXmmUikQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MMFtEFRRTp9QAeg8/nJT0BZyePjN+AveVA4XwIu4ORLVBMv+dU04d6mFT65maO3TJD ZQk6SbglpoGAOpfpCgZO7lDhmKn65Oo9VkRiShIYNXKtdaYagIQ857PpONNKaksNg3Wk q2GwgAqXAEl9LY/0LBe8a+A9MKJDyO8wkCxJk= MIME-Version: 1.0 Received: by 10.229.233.19 with SMTP id jw19mr6708327qcb.24.1296672611328; Wed, 02 Feb 2011 10:50:11 -0800 (PST) Received: by 10.229.20.70 with HTTP; Wed, 2 Feb 2011 10:50:11 -0800 (PST) In-Reply-To: References: Date: Wed, 2 Feb 2011 10:50:11 -0800 Message-ID: From: stefano faccin To: Rajeev Koodli Content-Type: multipart/alternative; boundary=0016363b8b706365c6049b511eb7 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 18:46:54 -0000 --0016363b8b706365c6049b511eb7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Raj, thanks for the reply. If the LMA has statically configured policies, how do we ensure that the MN has the same policies? That would mean implicitly assuming that the policie= s provisioned to the MN by the ANDSF "always" match what has been set in the LMA, which I think it is unrealistic because the policies change over time, and every time you need to update all the LMAs, which has a considerable operational cost. Instead, if we leave the MN to make the choice, there are easy and well specified mechanisms that allow the provisioning of policies in the MN and for the MN to make such decision and communicate it to the network, so that the network can As for extensions to Gx, I am not stating that in theory one could extend Gx. However, at present such solution does not exists, and without it, I do not see how the draft is applicable to 3GPP that is at present the only potential customer identified (I guess I did not see any other identified?) Even assuming that Gx could be modified, the issue of the per-access networ= k granularity remains. Even if the LMA has the right policies in place, the LMA has no way of knowing exactly what access network of a specific access technology (e.g. which SSID for WLAN0 the MN is connecting to. I cannot agree with your assumption below that if the MN connects to an SSI= D it is because the operator is OK with routing traffic on that SSID, and tha= t we should just "trust the software on the MN". There are two aspects to consider: 1) whether it is OK for certain traffic to be routed at all over a certain access access network of a specific access technology 2) how different traffic should be routed over different access networks of different access technologies Regarding these two points, the issue is whether the operator wants to allo= w traffic e.g. over a certain SSID or not. So, in that case, it is obvious as you say that if the MN has connected to an SSID configured by the operator in the MN, then traffic could be allowed over that SSID. However, we need t= o consider that 3GPP allows the decision of which WLAN the MN can connect to based on user preferences. This means that my MN can e.g. connect to my hom= e WLAN (which is not controlled necessarily by the operator and whose SSID th= e operator does not know) or to a coffee shop WLAN, even if the device does not have those SSID configured. Those are typical examples of untrusted WLA= N access networks. Therefore, in such cases, just because the MN has connecte= d to a WLAN SSID, does not mean that the operator wants to route certain traffic over that SSID just because the policy says "route traffic X over WLAN". That brings us to a solution that, if applied to 3GPP, provides less functionality than what is available and has been specified today, so back to my point above. Unfortunately, there is no solution I am aware of that allows the WLAN network to indicate to the MAG/LMA the specific SSID (and as you say, there is no easy solution for that). Due to this and the points above about polic= y provisioning, it means that the applicability of this solution to a real case like 3GPP depends on the feasibility of extending policy mechanisms in 3GPP, and the ability to have a solution where the WLAN network provides th= e SSID information to the MAG/LMA. Moreover, the provisioning of such SSID is not in the scope of IETF, but not even of 3GPP (since the interface between the WLAN AP and the ePDG is not defined), thus I wonder how this could be defined at all (I am afraid of asking what magic should happen here). So, now we have two big dependencies. In general, I am also wondering if there is a customer that has asked us to define this solution. I am not aware of any but I may have missed that. Cheers, Stefano On Wed, Feb 2, 2011 at 10:44 AM, Rajeev Koodli wrote: > > Hi Stefano, > > You make two interesting points: First, the defined solution should be > useful for 3GPP deployments. Second, if it=92s not defined *today* in 3GP= P, > it=92s not useful. > > I tend to agree with you on the first =96 3GPP is a big potential custome= r. > I cannot agree with your second point. > > There are multiple ways I could envision policy on the LMA. Locally > configured policy is one (which we use today in deployments) that does no= t > need Gx interaction. Gx extensions can be proposed in the future. I hope = you > are not suggesting that these are not feasible choices. > > For the MN (IETF term for UE) to even connect to the MAG via WLAN today, > you need an IPsec termination point (ePDG). If the operator pre-configure= s > the list of SSIDs or there is some out-of-band mechanism to inform the MN > which SSID is =93white-listed=94, then I expect the MN to decide when to = connect > to the ePDG and hence the MAG. At this point, the MN is already on the WL= AN > the operator cares about I presume. > There is no easy way for the network (LMA, MAG) to know what SSID the MN = is > connected to =96 the network has to either trust the software on the MN o= r the > WLAN infrastructure has to provide the SSID information to the network. > > -Rajeev > > > > On 2/2/11 9:56 AM, "stefano faccin" wrote: > > Hello rajeev, > the use of PCRF is an interesting suggestion. However, unfortunately, PCR= F > does not contain any policies or information that will tell the LMA what = are > the policies to be used for decisions of IP flow mobility. This is not pa= rt > of current PCC functionality, and there is no work ongoing or planned to > extend PCC in such way. Therefore, the applicability of the solution in t= his > draft would hinge on hypotetical future solutions and not on a current > solution for the open issues, which brings us back to my point that we ar= e > defining a solution with open issues for which there is not a single > realistic solution out there, thus making this draft not applicable to a > real scenario. > > I am not thinking of the UE connecting to more than one WLAN at the same > time, but the UE being able to connect to different WLANs (one at a time) > because the UE is e.g. provisioned with a list of SSIDs or the UE discove= rs > a hotspot somewhere. I am talking about the scenario where the UE is capa= ble > to connect to WLAN, but the operator has different policies wrt which WLA= N > the UE should use or not. > > If you have followed the work in 3GPP, it is clear that operators have > interest in applying policies not only at RAT level, but also at access > network level (please see how ANDSF was defined and why). I guess we can = all > agree that an operator deploying PMIP-based mobility may be interested in > having policies that allow traffic on the WLAN the operator owns or that > belongs to a roaming partner, while not allowing traffic on WLAN of other > operators for which it might need to pay an extra fee or where e.g. no Qo= S > can be guaranteed. That means that the entity deciding whether traffic ne= eds > to be routed on WLAN or not cannot just consider "WLAN is available", but > "WLAN SSIDx is available", so that the decision can be based on the opera= tor > preferences as to which WLAN certain traffic needs to be routed on. > > If the draft allows decisions to be made only at the RAT level, then we > have an issue because we are defining a solution that should be applicabl= e > to 3GPP but does not meet the deployment scenarios of interest. In other > words, if we want to make this solution applicable e.g. to 3GPP, we need = to > be able to provide the same functionality available today in 3GPP with ot= her > solution in order to satisfy the use cases supported by 3GPP, and not ste= p > backwards in terms of what can be supported. > > Cheers, > > Stefano > > On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli wrote: > > > Hi Stefano, > > Thanks for your input. > > I expect the LMA interacting with PCRF for policy rules specific to the > subscriber for different RAT types. > You are right that the LMA does not know the SSID the mobile is connected > to. It=92s not clear if the MAG can get that from the MN either without > additional signaling. However, the LMA knows that the MN is connected to > WLAN; so it can apply the policy at the RAT type level. Are you thinking = of > the MN connecting to more than one WLAN network (and each of those > connections coming back to the LMA)? If so, please explain the scenario. > > Regards, > > -Rajeev > > > > > On 2/1/11 6:39 PM, "stefano faccin" http://sfaccinstd@gmail.com> > wrote: > > Raj, > thanks for the email. > > I need to apologize in advance if my questions have already been answered > before (though I cannot find a conclusive answer anywhere). > > I think that a protocol that is developed in NETEXT (or other groups) > should have at least a potential realistic scenario for applicability. > > In terms of applicability, though it is not part of the protocol definiti= on > per se, unless there are solutions in place for either the host to indica= te > to the network where the flows should be routed or for the LMA to receive > somehow from somewhere some policies, the solution cannot really provide > flow mobility since there is no way to decide which flows are routed wher= e. > If we are thinking about a host-based solution, I have not yet seen a > solution as to how the host can indicate to the MAG and ultimately to the > MAG which flows should be routed on each access. If we are relying on > modifications of layer 2 protocols, aren't we defining a solution that wo= rks > only with some technologies (since for other access technologies it is > rather unrealistic to modify L2 for IP flow mobility purposes)? If we are > thinking of an LMA-based solution, can we hear of at least one example of= a > real-life scenario where the LMA would receive such policies, and how suc= h > delivery would happen? Also, should there be a solution to have policies = in > the LMA, how does the LMA actually decide to route flows on one access or > the other? E.g., if some flows need to be routed on certain WLAN networks= , > but shall not be routed on other WLAN networks, how does the LMA know whi= ch > specific WLAN network the host is connected to? Perhaps I missed the abil= ity > for the MAG to know e.g. the WLAN SSID and provide it to the LMA, in whic= h > case I would appreciate if somebody could highlight to me where that is > defined. > > I think that, though not integral to the protocol specification, > understanding what framework the protocol would/needs to fit in is rather > important. > > Cheers, > Stefano > > > On Tue, Feb 1, 2011 at 3:47 PM, http://Basavaraj.Patil@nokia.com> > wrote: > > > Hello, > > We have discussed the flow mobility solutions for Proxy MIP6 previously a= t > IETFs 78 and 79. > This is a consensus call for adopting this I-D: > draft-bernardos-netext-pmipv6-flowmob-02 > as the working group document. > I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt > > The consensus call will expire on Feb 15th, 2011. Please indicate your > support or concerns in adopting this I-D as the WG baseline document on > the mailing list. > > Please note that this I-D will serve as the baseline in the WG and will b= e > developed further based on input and feedback from WG members. > > -Basavaraj > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > > > > > --=20 Stefano M. Faccin =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D May the Force be with you --0016363b8b706365c6049b511eb7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Raj,
thanks for the reply.

If the LMA has statically configured p= olicies, how do we ensure that the MN has the same policies? That would mea= n implicitly assuming that the policies provisioned to the MN by the ANDSF = "always" match what has been set in the LMA, which I think it is = unrealistic because the policies change over time, and every time you need = to update all the LMAs, which has a considerable operational cost. Instead,= if we leave the MN to make the choice, there are easy and well specified m= echanisms that allow the provisioning of policies in the MN and for the MN = to make such decision and communicate it to the network, so that the networ= k can

As for extensions to Gx, I am not stating that in theory one could exte= nd Gx. However, at present such solution does not exists, and without it, I= do not see how the draft is applicable to 3GPP that is at present the only= potential customer identified (I guess I did not see any other identified?= )=A0

Even assuming that Gx could be modified, the issue of the per-access ne= twork granularity remains. Even if the LMA has the right policies in place,= the LMA has no way of knowing exactly what access network of a specific ac= cess technology (e.g. which SSID for WLAN0 the MN is connecting to.

I cannot agree with your assumption below that if the MN connects to an= SSID it is because the operator is OK with routing traffic on that SSID, a= nd that we should just "trust the software on the MN". There are = two aspects to consider:
1) whether it is OK for certain traffic to be routed at all over a certain = access access network of a specific access technology
2) how different t= raffic should be routed over different access networks of different access = technologies

Regarding these two points, the issue is whether the operator wants to = allow traffic e.g. over a certain SSID or not. So, in that case, it is obvi= ous as you say that if the MN has connected to an SSID configured by the op= erator in the MN, then traffic could be allowed over that SSID. However, we= need to consider that 3GPP allows the decision of which WLAN the MN can co= nnect to based on user preferences. This means that my MN can e.g. connect = to my home WLAN (which is not controlled necessarily by the operator and wh= ose SSID the operator does not know) or to a coffee shop WLAN, even if the = device does not have those SSID configured. Those are typical examples of u= ntrusted WLAN access networks. Therefore, in such cases, just because the M= N has connected to a WLAN SSID, does not mean that the operator wants to ro= ute certain traffic over that SSID just because the policy says "route= traffic X over WLAN".=A0

That brings us to a solution that, if applied to 3GPP, provides less=20 functionality than what is available and has been specified today, so=20 back to my point above.

Unfortunately, there is no solution I am aware of that allows the WLAN = network to indicate to the MAG/LMA the specific SSID (and as you say, there= is no easy solution for that). Due to this and the points above about poli= cy provisioning, it means that the applicability of this solution to a real= case like 3GPP depends on the feasibility of extending policy mechanisms i= n 3GPP, and the ability to have a solution where the WLAN network provides = the SSID information to the MAG/LMA. Moreover, the provisioning of such SSI= D is not in the scope of IETF, but not even of 3GPP (since the interface be= tween the WLAN AP and the ePDG is not defined), thus I wonder how this coul= d be defined at all (I am afraid of asking what magic should happen here). = So, now we have two big dependencies.

In general, I am also wondering if there is a customer that has asked u= s to define this solution. I am not aware of any but I may have missed that= .

Cheers,
Stefano

On Wed, Feb 2= , 2011 at 10:44 AM, Rajeev Koodli <rkoodli@cisco.com> wrote:

Hi Stefano,

You make two interesting points: First, the defined solution should be usef= ul for 3GPP deployments. Second, if it=92s not defined today in 3GPP= , it=92s not useful.

I tend to agree with you on the first =96 3GPP is a big potential customer.=
I cannot agree with your second point.

There are multiple ways I could envision policy on the LMA. Locally configu= red policy is one (which we use today in deployments) that does not need Gx= interaction. Gx extensions can be proposed in the future. I hope you are n= ot suggesting that these are not feasible choices.

For the MN (IETF term for UE) to even connect to the MAG via WLAN today, yo= u need an IPsec termination point (ePDG). If the operator pre-configures th= e list of SSIDs or there is some out-of-band mechanism to inform the MN whi= ch SSID is =93white-listed=94, then I expect the MN to decide when to conne= ct to the ePDG and hence the MAG. At this point, the MN is already on the W= LAN the operator cares about I presume.
There is no easy way for the network (LMA, MAG) to know what SSID the MN is= connected to =96 the network has to either trust the software on the MN or= the WLAN infrastructure has to provide the SSID information to the network= .

-Rajeev



On 2/2/11 9:56 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:

Hello rajeev,
the use of PCRF is an interesting suggestion. However, unfortunately, PCRF = does not contain any policies or information that will tell the LMA what ar= e the policies to be used for decisions of IP flow mobility. This is not pa= rt of current PCC functionality, and there is no work ongoing or planned to= extend PCC in such way. Therefore, the applicability of the solution in th= is draft would hinge on hypotetical future solutions and not on a current s= olution for the open issues, which brings us back to my point that we are d= efining a solution with open issues for which there is not a single realist= ic solution out there, thus making this draft not applicable to a real scen= ario.

I am not thinking of the UE connecting to more than one WLAN at the same ti= me, but the UE being able to connect to different WLANs (one at a time) bec= ause the UE is e.g. provisioned with a list of SSIDs or the UE discovers a = hotspot somewhere. I am talking about the scenario where the UE is capable = to connect to WLAN, but the operator has different policies wrt which WLAN = the UE should use or not.

If you have followed the work in 3GPP, it is clear that operators have inte= rest in applying policies not only at RAT level, but also at access network= level (please see how ANDSF was defined and why). I guess we can all agree= that an operator deploying PMIP-based mobility may be interested in having= policies that allow traffic on the WLAN the operator owns or that belongs = to a roaming partner, while not allowing traffic on WLAN of other operators= for which it might need to pay an extra fee or where e.g. no QoS can be gu= aranteed. That means that the entity deciding whether traffic needs to be r= outed on WLAN or not cannot just consider "WLAN is available", bu= t "WLAN SSIDx is available", so that the decision can be based on= the operator preferences as to which WLAN certain traffic needs to be rout= ed on.

If the draft allows decisions to be made only at the RAT level, then we hav= e an issue because we are defining a solution that should be applicable to = 3GPP but does not meet the deployment scenarios of interest. In other words= , if we want to make this solution applicable e.g. to 3GPP, we need to be a= ble to provide the same functionality available today in 3GPP with other so= lution in order to satisfy the use cases supported by 3GPP, and not step ba= ckwards in terms of what can be supported.

Cheers,

Stefano

On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli <rkoodli@cisco.com> wrote:

Hi Stefano,

Thanks for your input.

I expect the LMA interacting with PCRF for policy rules specific to the sub= scriber for different RAT types.
You are right that the LMA does not know the SSID the mobile is connected t= o. It=92s not clear if the MAG can get that from the MN either without addi= tional signaling. However, the LMA knows that the MN is connected to WLAN; = so it can apply the policy at the RAT type level. Are you thinking of the M= N connecting to more than one WLAN network (and each of those connections c= oming back to the LMA)? If so, please explain the scenario.

Regards,

-Rajeev




On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com> > wrote:

Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicat= e to the network where the flows should be routed or for the LMA to receive= somehow from somewhere some policies, the solution cannot really provide f= low mobility since there is no way to decide which flows are routed where. = If we are thinking about a host-based solution, I have not yet seen a solut= ion as to how the host can indicate to the MAG and ultimately to the MAG wh= ich flows should be routed on each access. If we are relying on modificatio= ns of layer 2 protocols, aren't we defining a solution that works only = with some technologies (since for other access technologies it is rather un= realistic to modify L2 for IP flow mobility purposes)? If we are thinking o= f an LMA-based solution, can we hear of at least one example of a real-life= scenario where the LMA would receive such policies, and how such delivery = would happen? Also, should there be a solution to have policies in the LMA,= how does the LMA actually decide to route flows on one access or the other= ? E.g., if some flows need to be routed on certain WLAN networks, but shall= not be routed on other WLAN networks, how does the LMA know which specific= WLAN network the host is connected to? Perhaps I missed the ability for th= e MAG to know e.g. the WLAN SSID and provide it to the LMA, in which case I= would appreciate if somebody could highlight to me where that is defined.<= br>
I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important. =

Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM, =A0<Basavaraj.Patil@nokia.com <http://Basavaraj.Patil@nok= ia.com> > wrote:

Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= br> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-p= mipv6-flowmob-02.txt

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= br> developed further based on input and feedback from WG members.

-Basavaraj

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







--
Stefano M. Faccin
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
May the Force be = with you
--0016363b8b706365c6049b511eb7-- From rkoodli@cisco.com Wed Feb 2 11:06:57 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD89D3A6B76 for ; Wed, 2 Feb 2011 11:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.581 X-Spam-Level: X-Spam-Status: No, score=-109.581 tagged_above=-999 required=5 tests=[AWL=-0.379, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyXXNnSmNefj for ; Wed, 2 Feb 2011 11:06:41 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 732573A67B7 for ; Wed, 2 Feb 2011 11:06:40 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwGAE87SU2tJXG//2dsb2JhbACCRZQ1hgcBhzNnc6BcmyqFUwSEeIZpgzCDAA Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rtp-iport-1.cisco.com with ESMTP; 02 Feb 2011 19:09:59 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p12J9x3r028774; Wed, 2 Feb 2011 19:09:59 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Feb 2011 13:09:59 -0600 Received: from 10.21.147.70 ([10.21.147.70]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Wed, 2 Feb 2011 19:09:58 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Wed, 02 Feb 2011 11:28:22 -0800 From: Rajeev Koodli To: stefano faccin Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvDD1p5PB7nk089WkWhKX70dfcsRg== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3379490903_51938318" X-OriginalArrivalTime: 02 Feb 2011 19:09:59.0102 (UTC) FILETIME=[C9182DE0:01CBC30C] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 19:06:58 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3379490903_51938318 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Stefano, Regardless of how the policy is configured on the LMA, there is a consistency of the rules which needs to be ensured regardless. Whatever the entity (OMA-DM?!) is that configures the policy has to ensure such a consistency. We can debate about how policy interaction works, but that=B9s another topic. I would note that there are choices here (modulo respective pros and cons). I didn=B9t suggest that an operator should just trust the software on a MN, although I suspect some device vendors might argue for their robustness (surprise?).=20 I would frame the WLAN access problem as whether the access is considered trusted or not. Accordingly, you apply the policy. -Rajeev On 2/2/11 10:50 AM, "stefano faccin" wrote: > Raj, > thanks for the reply. >=20 > If the LMA has statically configured policies, how do we ensure that the = MN > has the same policies? That would mean implicitly assuming that the polic= ies > provisioned to the MN by the ANDSF "always" match what has been set in th= e > LMA, which I think it is unrealistic because the policies change over tim= e, > and every time you need to update all the LMAs, which has a considerable > operational cost. Instead, if we leave the MN to make the choice, there a= re > easy and well specified mechanisms that allow the provisioning of policie= s in > the MN and for the MN to make such decision and communicate it to the net= work, > so that the network can >=20 > As for extensions to Gx, I am not stating that in theory one could extend= Gx. > However, at present such solution does not exists, and without it, I do n= ot > see how the draft is applicable to 3GPP that is at present the only poten= tial > customer identified (I guess I did not see any other identified?)=A0 >=20 > Even assuming that Gx could be modified, the issue of the per-access netw= ork > granularity remains. Even if the LMA has the right policies in place, the= LMA > has no way of knowing exactly what access network of a specific access > technology (e.g. which SSID for WLAN0 the MN is connecting to. >=20 > I cannot agree with your assumption below that if the MN connects to an S= SID > it is because the operator is OK with routing traffic on that SSID, and t= hat > we should just "trust the software on the MN". There are two aspects to > consider: > 1) whether it is OK for certain traffic to be routed at all over a certai= n > access access network of a specific access technology > 2) how different traffic should be routed over different access networks = of > different access technologies >=20 > Regarding these two points, the issue is whether the operator wants to al= low > traffic e.g. over a certain SSID or not. So, in that case, it is obvious = as > you say that if the MN has connected to an SSID configured by the operato= r in > the MN, then traffic could be allowed over that SSID. However, we need to > consider that 3GPP allows the decision of which WLAN the MN can connect t= o > based on user preferences. This means that my MN can e.g. connect to my h= ome > WLAN (which is not controlled necessarily by the operator and whose SSID = the > operator does not know) or to a coffee shop WLAN, even if the device does= not > have those SSID configured. Those are typical examples of untrusted WLAN > access networks. Therefore, in such cases, just because the MN has connec= ted > to a WLAN SSID, does not mean that the operator wants to route certain tr= affic > over that SSID just because the policy says "route traffic X over WLAN".=A0 >=20 > That brings us to a solution that, if applied to 3GPP, provides less > functionality than what is available and has been specified today, so bac= k to > my point above. >=20 > Unfortunately, there is no solution I am aware of that allows the WLAN ne= twork > to indicate to the MAG/LMA the specific SSID (and as you say, there is no= easy > solution for that). Due to this and the points above about policy > provisioning, it means that the applicability of this solution to a real = case > like 3GPP depends on the feasibility of extending policy mechanisms in 3G= PP, > and the ability to have a solution where the WLAN network provides the SS= ID > information to the MAG/LMA. Moreover, the provisioning of such SSID is no= t in > the scope of IETF, but not even of 3GPP (since the interface between the = WLAN > AP and the ePDG is not defined), thus I wonder how this could be defined = at > all (I am afraid of asking what magic should happen here). So, now we hav= e two > big dependencies. >=20 > In general, I am also wondering if there is a customer that has asked us = to > define this solution. I am not aware of any but I may have missed that. >=20 > Cheers, > Stefano >=20 > On Wed, Feb 2, 2011 at 10:44 AM, Rajeev Koodli wrote: >>=20 >> Hi Stefano, >>=20 >> You make two interesting points: First, the defined solution should be u= seful >> for 3GPP deployments. Second, if it=B9s not defined today in 3GPP, it=B9s no= t >> useful. >>=20 >> I tend to agree with you on the first =AD 3GPP is a big potential customer= . >> I cannot agree with your second point. >>=20 >> There are multiple ways I could envision policy on the LMA. Locally >> configured policy is one (which we use today in deployments) that does n= ot >> need Gx interaction. Gx extensions can be proposed in the future. I hope= you >> are not suggesting that these are not feasible choices. >>=20 >> For the MN (IETF term for UE) to even connect to the MAG via WLAN today,= you >> need an IPsec termination point (ePDG). If the operator pre-configures t= he >> list of SSIDs or there is some out-of-band mechanism to inform the MN wh= ich >> SSID is =B3white-listed=B2, then I expect the MN to decide when to connect t= o the >> ePDG and hence the MAG. At this point, the MN is already on the WLAN the >> operator cares about I presume. >> There is no easy way for the network (LMA, MAG) to know what SSID the MN= is >> connected to =AD the network has to either trust the software on the MN or= the >> WLAN infrastructure has to provide the SSID information to the network. >>=20 >> -Rajeev >>=20 >>=20 >>=20 >> On 2/2/11 9:56 AM, "stefano faccin" > > wrote: >>=20 >>> Hello rajeev, >>> the use of PCRF is an interesting suggestion. However, unfortunately, P= CRF >>> does not contain any policies or information that will tell the LMA wha= t are >>> the policies to be used for decisions of IP flow mobility. This is not = part >>> of current PCC functionality, and there is no work ongoing or planned t= o >>> extend PCC in such way. Therefore, the applicability of the solution in= this >>> draft would hinge on hypotetical future solutions and not on a current >>> solution for the open issues, which brings us back to my point that we = are >>> defining a solution with open issues for which there is not a single >>> realistic solution out there, thus making this draft not applicable to = a >>> real scenario. >>>=20 >>> I am not thinking of the UE connecting to more than one WLAN at the sam= e >>> time, but the UE being able to connect to different WLANs (one at a tim= e) >>> because the UE is e.g. provisioned with a list of SSIDs or the UE disco= vers >>> a hotspot somewhere. I am talking about the scenario where the UE is ca= pable >>> to connect to WLAN, but the operator has different policies wrt which W= LAN >>> the UE should use or not. >>>=20 >>> If you have followed the work in 3GPP, it is clear that operators have >>> interest in applying policies not only at RAT level, but also at access >>> network level (please see how ANDSF was defined and why). I guess we ca= n all >>> agree that an operator deploying PMIP-based mobility may be interested = in >>> having policies that allow traffic on the WLAN the operator owns or tha= t >>> belongs to a roaming partner, while not allowing traffic on WLAN of oth= er >>> operators for which it might need to pay an extra fee or where e.g. no = QoS >>> can be guaranteed. That means that the entity deciding whether traffic = needs >>> to be routed on WLAN or not cannot just consider "WLAN is available", b= ut >>> "WLAN SSIDx is available", so that the decision can be based on the ope= rator >>> preferences as to which WLAN certain traffic needs to be routed on. >>>=20 >>> If the draft allows decisions to be made only at the RAT level, then we= have >>> an issue because we are defining a solution that should be applicable t= o >>> 3GPP but does not meet the deployment scenarios of interest. In other w= ords, >>> if we want to make this solution applicable e.g. to 3GPP, we need to be= able >>> to provide the same functionality available today in 3GPP with other >>> solution in order to satisfy the use cases supported by 3GPP, and not s= tep >>> backwards in terms of what can be supported. >>>=20 >>> Cheers, >>>=20 >>> Stefano >>>=20 >>> On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli >> > wrote: >>>>=20 >>>> Hi Stefano, >>>>=20 >>>> Thanks for your input. >>>>=20 >>>> I expect the LMA interacting with PCRF for policy rules specific to th= e >>>> subscriber for different RAT types. >>>> You are right that the LMA does not know the SSID the mobile is connec= ted >>>> to. It=B9s not clear if the MAG can get that from the MN either without >>>> additional signaling. However, the LMA knows that the MN is connected = to >>>> WLAN; so it can apply the policy at the RAT type level. Are you thinki= ng of >>>> the MN connecting to more than one WLAN network (and each of those >>>> connections coming back to the LMA)? If so, please explain the scenari= o. >>>>=20 >>>> Regards, >>>>=20 >>>> -Rajeev >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2/1/11 6:39 PM, "stefano faccin" >>> > wrote: >>>>=20 >>>>> Raj, >>>>> thanks for the email. >>>>>=20 >>>>> I need to apologize in advance if my questions have already been answ= ered >>>>> before (though I cannot find a conclusive answer anywhere). >>>>>=20 >>>>> I think that a protocol that is developed in NETEXT (or other groups) >>>>> should have at least a potential realistic scenario for applicability= . >>>>>=20 >>>>> In terms of applicability, though it is not part of the protocol >>>>> definition per se, unless there are solutions in place for either the= host >>>>> to indicate to the network where the flows should be routed or for th= e LMA >>>>> to receive somehow from somewhere some policies, the solution cannot >>>>> really provide flow mobility since there is no way to decide which fl= ows >>>>> are routed where. If we are thinking about a host-based solution, I h= ave >>>>> not yet seen a solution as to how the host can indicate to the MAG an= d >>>>> ultimately to the MAG which flows should be routed on each access. If= we >>>>> are relying on modifications of layer 2 protocols, aren't we defining= a >>>>> solution that works only with some technologies (since for other acce= ss >>>>> technologies it is rather unrealistic to modify L2 for IP flow mobili= ty >>>>> purposes)? If we are thinking of an LMA-based solution, can we hear o= f at >>>>> least one example of a real-life scenario where the LMA would receive= such >>>>> policies, and how such delivery would happen? Also, should there be a >>>>> solution to have policies in the LMA, how does the LMA actually decid= e to >>>>> route flows on one access or the other? E.g., if some flows need to b= e >>>>> routed on certain WLAN networks, but shall not be routed on other WLA= N >>>>> networks, how does the LMA know which specific WLAN network the host = is >>>>> connected to? Perhaps I missed the ability for the MAG to know e.g. t= he >>>>> WLAN SSID and provide it to the LMA, in which case I would appreciate= if >>>>> somebody could highlight to me where that is defined. >>>>>=20 >>>>> I think that, though not integral to the protocol specification, >>>>> understanding what framework the protocol would/needs to fit in is ra= ther >>>>> important.=20 >>>>>=20 >>>>> Cheers, >>>>> Stefano >>>>>=20 >>>>>=20 >>>>> On Tue, Feb 1, 2011 at 3:47 PM, =A0>>>> > >>>>> wrote: >>>>>>=20 >>>>>> Hello, >>>>>>=20 >>>>>> We have discussed the flow mobility solutions for Proxy MIP6 previou= sly >>>>>> at >>>>>> IETFs 78 and 79. >>>>>> This is a consensus call for adopting this I-D: >>>>>> draft-bernardos-netext-pmipv6-flowmob-02 >>>>>> as the working group document. >>>>>> I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02= .txt >>>>>>=20 >>>>>> The consensus call will expire on Feb 15th, 2011. Please indicate yo= ur >>>>>> support or concerns in adopting this I-D as the WG baseline document= on >>>>>> the mailing list. >>>>>>=20 >>>>>> Please note that this I-D will serve as the baseline in the WG and w= ill >>>>>> be >>>>>> developed further based on input and feedback from WG members. >>>>>>=20 >>>>>> -Basavaraj >>>>>>=20 >>>>>> _______________________________________________ >>>>>> netext mailing list >>>>>> netext@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netext >>>>>=20 >>>>>=20 >>>=20 >>>=20 >=20 >=20 --B_3379490903_51938318 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmi= pv6-flowmob as WG doc
Stefano,

Regardless of how the policy is configured on the LMA, there is a consisten= cy of the rules which needs to be ensured regardless. Whatever the entity (O= MA-DM?!) is that configures the policy has to ensure such a consistency.

We can debate about how policy interaction works, but that’s another = topic. I would note that there are choices here (modulo respective pros and = cons).

I didn’t suggest that an operator should just trust the software on a= MN, although I suspect some device vendors might argue for their robustness= (surprise?).

I would frame the WLAN access problem as whether the access is considered t= rusted or not. Accordingly, you apply the policy.

-Rajeev


On 2/2/11 10:50 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Raj,
thanks for the reply.

If the LMA has statically configured policies, how do we ensure that the MN= has the same policies? That would mean implicitly assuming that the policie= s provisioned to the MN by the ANDSF "always" match what has been = set in the LMA, which I think it is unrealistic because the policies change = over time, and every time you need to update all the LMAs, which has a consi= derable operational cost. Instead, if we leave the MN to make the choice, th= ere are easy and well specified mechanisms that allow the provisioning of po= licies in the MN and for the MN to make such decision and communicate it to = the network, so that the network can

As for extensions to Gx, I am not stating that in theory one could extend G= x. However, at present such solution does not exists, and without it, I do n= ot see how the draft is applicable to 3GPP that is at present the only poten= tial customer identified (I guess I did not see any other identified?)=A0

Even assuming that Gx could be modified, the issue of the per-access networ= k granularity remains. Even if the LMA has the right policies in place, the = LMA has no way of knowing exactly what access network of a specific access t= echnology (e.g. which SSID for WLAN0 the MN is connecting to.

I cannot agree with your assumption below that if the MN connects to an SSI= D it is because the operator is OK with routing traffic on that SSID, and th= at we should just "trust the software on the MN". There are two as= pects to consider:
1) whether it is OK for certain traffic to be routed at all over a certain = access access network of a specific access technology
2) how different traffic should be routed over different access networks of= different access technologies

Regarding these two points, the issue is whether the operator wants to allo= w traffic e.g. over a certain SSID or not. So, in that case, it is obvious a= s you say that if the MN has connected to an SSID configured by the operator= in the MN, then traffic could be allowed over that SSID. However, we need t= o consider that 3GPP allows the decision of which WLAN the MN can connect to= based on user preferences. This means that my MN can e.g. connect to my hom= e WLAN (which is not controlled necessarily by the operator and whose SSID t= he operator does not know) or to a coffee shop WLAN, even if the device does= not have those SSID configured. Those are typical examples of untrusted WLA= N access networks. Therefore, in such cases, just because the MN has connect= ed to a WLAN SSID, does not mean that the operator wants to route certain tr= affic over that SSID just because the policy says "route traffic X over= WLAN".=A0

That brings us to a solution that, if applied to 3GPP, provides less functi= onality than what is available and has been specified today, so back to my p= oint above.

Unfortunately, there is no solution I am aware of that allows the WLAN netw= ork to indicate to the MAG/LMA the specific SSID (and as you say, there is n= o easy solution for that). Due to this and the points above about policy pro= visioning, it means that the applicability of this solution to a real case l= ike 3GPP depends on the feasibility of extending policy mechanisms in 3GPP, = and the ability to have a solution where the WLAN network provides the SSID = information to the MAG/LMA. Moreover, the provisioning of such SSID is not i= n the scope of IETF, but not even of 3GPP (since the interface between the W= LAN AP and the ePDG is not defined), thus I wonder how this could be defined= at all (I am afraid of asking what magic should happen here). So, now we ha= ve two big dependencies.

In general, I am also wondering if there is a customer that has asked us to= define this solution. I am not aware of any but I may have missed that.

Cheers,
Stefano

On Wed, Feb 2, 2011 at 10:44 AM, Rajeev Koodli <rkoodli@cisco.com> wrote:
<= SPAN STYLE=3D'font-size:11pt'>
Hi Stefano,

You make two interesting points: First, the defined solution should be usef= ul for 3GPP deployments. Second, if it’s not defined today in 3= GPP, it’s not useful.

I tend to agree with you on the first – 3GPP is a big potential custo= mer.
I cannot agree with your second point.

There are multiple ways I could envision policy on the LMA. Locally configu= red policy is one (which we use today in deployments) that does not need Gx = interaction. Gx extensions can be proposed in the future. I hope you are not= suggesting that these are not feasible choices.

For the MN (IETF term for UE) to even connect to the MAG via WLAN today, yo= u need an IPsec termination point (ePDG). If the operator pre-configures the= list of SSIDs or there is some out-of-band mechanism to inform the MN which= SSID is “white-listed”, then I expect the MN to decide when to = connect to the ePDG and hence the MAG. At this point, the MN is already on t= he WLAN the operator cares about I presume.
There is no easy way for the network (LMA, MAG) to know what SSID the MN is= connected to – the network has to either trust the software on the MN= or the WLAN infrastructure has to provide the SSID information to the netwo= rk.

-Rajeev



On 2/2/11 9:56 AM, "stefano faccin" <sfaccinstd@gmail.com <htt= p://sfaccinstd@gmail.com> > wrote:

<= SPAN STYLE=3D'font-size:11pt'>Hello rajeev,
the use of PCRF is an interesting suggestion. However, unfortunately, PCRF = does not contain any policies or information that will tell the LMA what are= the policies to be used for decisions of IP flow mobility. This is not part= of current PCC functionality, and there is no work ongoing or planned to ex= tend PCC in such way. Therefore, the applicability of the solution in this d= raft would hinge on hypotetical future solutions and not on a current soluti= on for the open issues, which brings us back to my point that we are definin= g a solution with open issues for which there is not a single realistic solu= tion out there, thus making this draft not applicable to a real scenario.
I am not thinking of the UE connecting to more than one WLAN at the same ti= me, but the UE being able to connect to different WLANs (one at a time) beca= use the UE is e.g. provisioned with a list of SSIDs or the UE discovers a ho= tspot somewhere. I am talking about the scenario where the UE is capable to = connect to WLAN, but the operator has different policies wrt which WLAN the = UE should use or not.

If you have followed the work in 3GPP, it is clear that operators have inte= rest in applying policies not only at RAT level, but also at access network = level (please see how ANDSF was defined and why). I guess we can all agree t= hat an operator deploying PMIP-based mobility may be interested in having po= licies that allow traffic on the WLAN the operator owns or that belongs to a= roaming partner, while not allowing traffic on WLAN of other operators for = which it might need to pay an extra fee or where e.g. no QoS can be guarante= ed. That means that the entity deciding whether traffic needs to be routed o= n WLAN or not cannot just consider "WLAN is available", but "= WLAN SSIDx is available", so that the decision can be based on the oper= ator preferences as to which WLAN certain traffic needs to be routed on.
If the draft allows decisions to be made only at the RAT level, then we hav= e an issue because we are defining a solution that should be applicable to 3= GPP but does not meet the deployment scenarios of interest. In other words, = if we want to make this solution applicable e.g. to 3GPP, we need to be able= to provide the same functionality available today in 3GPP with other soluti= on in order to satisfy the use cases supported by 3GPP, and not step backwar= ds in terms of what can be supported.

Cheers,

Stefano

On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli <rkoodli@cisco.com <http://rkood= li@cisco.com> > wrote:
<= SPAN STYLE=3D'font-size:11pt'>
Hi Stefano,

Thanks for your input.

I expect the LMA interacting with PCRF for policy rules specific to the sub= scriber for different RAT types.
You are right that the LMA does not know the SSID the mobile is connected t= o. It’s not clear if the MAG can get that from the MN either without a= dditional signaling. However, the LMA knows that the MN is connected to WLAN= ; so it can apply the policy at the RAT type level. Are you thinking of the = MN connecting to more than one WLAN network (and each of those connections c= oming back to the LMA)? If so, please explain the scenario.

Regards,

-Rajeev




On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <htt= p://sfaccinstd@gmail.com>  <http://sfaccinstd@gmail.com> > wrote:

<= SPAN STYLE=3D'font-size:11pt'>Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicate= to the network where the flows should be routed or for the LMA to receive s= omehow from somewhere some policies, the solution cannot really provide flow= mobility since there is no way to decide which flows are routed where. If w= e are thinking about a host-based solution, I have not yet seen a solution a= s to how the host can indicate to the MAG and ultimately to the MAG which fl= ows should be routed on each access. If we are relying on modifications of l= ayer 2 protocols, aren't we defining a solution that works only with some te= chnologies (since for other access technologies it is rather unrealistic to = modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-based= solution, can we hear of at least one example of a real-life scenario where= the LMA would receive such policies, and how such delivery would happen? Al= so, should there be a solution to have policies in the LMA, how does the LMA= actually decide to route flows on one access or the other? E.g., if some fl= ows need to be routed on certain WLAN networks, but shall not be routed on o= ther WLAN networks, how does the LMA know which specific WLAN network the ho= st is connected to? Perhaps I missed the ability for the MAG to know e.g. th= e WLAN SSID and provide it to the LMA, in which case I would appreciate if s= omebody could highlight to me where that is defined.

I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important. <= BR>
Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM, =A0<Ba= savaraj.Patil@nokia.com <h= ttp://Basavaraj.Patil@nokia.com>  <http://Basavaraj.Patil@nokia.com> > wrote:
<= SPAN STYLE=3D'font-size:11pt'>
Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= BR> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt<= /a>

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= BR> developed further based on input and feedback from WG members.

-Basavaraj

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





--B_3379490903_51938318-- From rkoodli@cisco.com Wed Feb 2 11:25:01 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 757CA3A6CDC for ; Wed, 2 Feb 2011 11:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.549 X-Spam-Level: X-Spam-Status: No, score=-109.549 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhCTss9DFsK2 for ; Wed, 2 Feb 2011 11:24:46 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 7E98A3A6DB1 for ; Wed, 2 Feb 2011 11:24:45 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApUCANM+SU2tJV2a/2dsb2JhbACCRZN1QIYHAYczZ3OgZJslhVMEhHiGaYMwgwA Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 02 Feb 2011 19:28:04 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p12JS4F5024216; Wed, 2 Feb 2011 19:28:04 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Feb 2011 13:28:04 -0600 Received: from 10.21.147.70 ([10.21.147.70]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Wed, 2 Feb 2011 19:28:03 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Wed, 02 Feb 2011 11:46:27 -0800 From: Rajeev Koodli To: "Giaretta, Gerardo" , stefano faccin Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLwmpURzmRlysrlUidlexdQorGZJPuBh2AgAD/2ICAAABrAIAADVoAgAABl4CAAAqrAP//dgAQgAAI8Vg= In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3379491987_51994305" X-OriginalArrivalTime: 02 Feb 2011 19:28:04.0395 (UTC) FILETIME=[4FFABFB0:01CBC30F] Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 19:25:01 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3379491987_51994305 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Gerardo, * my point is that someone/something is configuring the policy on the MN which needs to be in sync with the MN=B9s partner, i.e., the network. If this is not the case, please let me know. * The last I heard, PMIP6 is applicable on the eHRPD (trusted non-3GPP network). Also, 33.402 does not specify whether a particular type of access network (such as WLAN) is considered trusted or untrusted (although a majority of the WLAN access could be considered untrusted today). -Rajeev On 2/2/11 11:16 AM, "Giaretta, Gerardo" wrote: > Hi Rajeev, > =20 > A couple of considerations on this: > =20 > - This draft assumes there is consistency in the rules. This is a= new > requirement for the system architecture where this solution will be appli= ed. > There is no this requirement for other solutions already adopted by IETF = and > 3GPP. In my view this seems a fairly important issue. >=20 > - The routing decisions based on WLAN SSID are different from > trusted/untrusted. Note also that PMIPv6 cannot be used in trusted networ= ks so > it is not clear at all what you are referring to. >=20 > =20 > Gerardo=20 > =20 >=20 > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of > Rajeev Koodli > Sent: Wednesday, February 02, 2011 11:28 AM > To: stefano faccin > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > Subject: Re: [netext] Consensus call to adopt I-D: > draft-bernardos-netext-pmipv6-flowmob as WG doc > =20 >=20 > Stefano, >=20 > Regardless of how the policy is configured on the LMA, there is a consist= ency > of the rules which needs to be ensured regardless. Whatever the entity > (OMA-DM?!) is that configures the policy has to ensure such a consistency= . >=20 > We can debate about how policy interaction works, but that=B9s another topi= c. I > would note that there are choices here (modulo respective pros and cons). >=20 > I didn=B9t suggest that an operator should just trust the software on a MN, > although I suspect some device vendors might argue for their robustness > (surprise?).=20 >=20 > I would frame the WLAN access problem as whether the access is considered > trusted or not. Accordingly, you apply the policy. >=20 > -Rajeev >=20 >=20 > On 2/2/11 10:50 AM, "stefano faccin" wrote: > Raj, > thanks for the reply. >=20 > If the LMA has statically configured policies, how do we ensure that the = MN > has the same policies? That would mean implicitly assuming that the polic= ies > provisioned to the MN by the ANDSF "always" match what has been set in th= e > LMA, which I think it is unrealistic because the policies change over tim= e, > and every time you need to update all the LMAs, which has a considerable > operational cost. Instead, if we leave the MN to make the choice, there a= re > easy and well specified mechanisms that allow the provisioning of policie= s in > the MN and for the MN to make such decision and communicate it to the net= work, > so that the network can >=20 > As for extensions to Gx, I am not stating that in theory one could extend= Gx. > However, at present such solution does not exists, and without it, I do n= ot > see how the draft is applicable to 3GPP that is at present the only poten= tial > customer identified (I guess I did not see any other identified?) >=20 > Even assuming that Gx could be modified, the issue of the per-access netw= ork > granularity remains. Even if the LMA has the right policies in place, the= LMA > has no way of knowing exactly what access network of a specific access > technology (e.g. which SSID for WLAN0 the MN is connecting to. >=20 > I cannot agree with your assumption below that if the MN connects to an S= SID > it is because the operator is OK with routing traffic on that SSID, and t= hat > we should just "trust the software on the MN". There are two aspects to > consider: > 1) whether it is OK for certain traffic to be routed at all over a certai= n > access access network of a specific access technology > 2) how different traffic should be routed over different access networks = of > different access technologies >=20 > Regarding these two points, the issue is whether the operator wants to al= low > traffic e.g. over a certain SSID or not. So, in that case, it is obvious = as > you say that if the MN has connected to an SSID configured by the operato= r in > the MN, then traffic could be allowed over that SSID. However, we need to > consider that 3GPP allows the decision of which WLAN the MN can connect t= o > based on user preferences. This means that my MN can e.g. connect to my h= ome > WLAN (which is not controlled necessarily by the operator and whose SSID = the > operator does not know) or to a coffee shop WLAN, even if the device does= not > have those SSID configured. Those are typical examples of untrusted WLAN > access networks. Therefore, in such cases, just because the MN has connec= ted > to a WLAN SSID, does not mean that the operator wants to route certain tr= affic > over that SSID just because the policy says "route traffic X over WLAN". >=20 > That brings us to a solution that, if applied to 3GPP, provides less > functionality than what is available and has been specified today, so bac= k to > my point above. >=20 > Unfortunately, there is no solution I am aware of that allows the WLAN ne= twork > to indicate to the MAG/LMA the specific SSID (and as you say, there is no= easy > solution for that). Due to this and the points above about policy > provisioning, it means that the applicability of this solution to a real = case > like 3GPP depends on the feasibility of extending policy mechanisms in 3G= PP, > and the ability to have a solution where the WLAN network provides the SS= ID > information to the MAG/LMA. Moreover, the provisioning of such SSID is no= t in > the scope of IETF, but not even of 3GPP (since the interface between the = WLAN > AP and the ePDG is not defined), thus I wonder how this could be defined = at > all (I am afraid of asking what magic should happen here). So, now we hav= e two > big dependencies. >=20 > In general, I am also wondering if there is a customer that has asked us = to > define this solution. I am not aware of any but I may have missed that. >=20 > Cheers, > Stefano >=20 > On Wed, Feb 2, 2011 at 10:44 AM, Rajeev Koodli wrote: >=20 > Hi Stefano, >=20 > You make two interesting points: First, the defined solution should be us= eful > for 3GPP deployments. Second, if it=B9s not defined today in 3GPP, it=B9s not > useful. >=20 > I tend to agree with you on the first =AD 3GPP is a big potential customer. > I cannot agree with your second point. >=20 > There are multiple ways I could envision policy on the LMA. Locally confi= gured > policy is one (which we use today in deployments) that does not need Gx > interaction. Gx extensions can be proposed in the future. I hope you are = not > suggesting that these are not feasible choices. >=20 > For the MN (IETF term for UE) to even connect to the MAG via WLAN today, = you > need an IPsec termination point (ePDG). If the operator pre-configures th= e > list of SSIDs or there is some out-of-band mechanism to inform the MN whi= ch > SSID is =B3white-listed=B2, then I expect the MN to decide when to connect to= the > ePDG and hence the MAG. At this point, the MN is already on the WLAN the > operator cares about I presume. > There is no easy way for the network (LMA, MAG) to know what SSID the MN = is > connected to =AD the network has to either trust the software on the MN or = the > WLAN infrastructure has to provide the SSID information to the network. >=20 > -Rajeev >=20 >=20 >=20 > On 2/2/11 9:56 AM, "stefano faccin" > wrote: > Hello rajeev, > the use of PCRF is an interesting suggestion. However, unfortunately, PCR= F > does not contain any policies or information that will tell the LMA what = are > the policies to be used for decisions of IP flow mobility. This is not pa= rt of > current PCC functionality, and there is no work ongoing or planned to ext= end > PCC in such way. Therefore, the applicability of the solution in this dra= ft > would hinge on hypotetical future solutions and not on a current solution= for > the open issues, which brings us back to my point that we are defining a > solution with open issues for which there is not a single realistic solut= ion > out there, thus making this draft not applicable to a real scenario. >=20 > I am not thinking of the UE connecting to more than one WLAN at the same = time, > but the UE being able to connect to different WLANs (one at a time) becau= se > the UE is e.g. provisioned with a list of SSIDs or the UE discovers a hot= spot > somewhere. I am talking about the scenario where the UE is capable to con= nect > to WLAN, but the operator has different policies wrt which WLAN the UE sh= ould > use or not. >=20 > If you have followed the work in 3GPP, it is clear that operators have > interest in applying policies not only at RAT level, but also at access > network level (please see how ANDSF was defined and why). I guess we can = all > agree that an operator deploying PMIP-based mobility may be interested in > having policies that allow traffic on the WLAN the operator owns or that > belongs to a roaming partner, while not allowing traffic on WLAN of other > operators for which it might need to pay an extra fee or where e.g. no Qo= S can > be guaranteed. That means that the entity deciding whether traffic needs = to be > routed on WLAN or not cannot just consider "WLAN is available", but "WLAN > SSIDx is available", so that the decision can be based on the operator > preferences as to which WLAN certain traffic needs to be routed on. >=20 > If the draft allows decisions to be made only at the RAT level, then we h= ave > an issue because we are defining a solution that should be applicable to = 3GPP > but does not meet the deployment scenarios of interest. In other words, i= f we > want to make this solution applicable e.g. to 3GPP, we need to be able to > provide the same functionality available today in 3GPP with other solutio= n in > order to satisfy the use cases supported by 3GPP, and not step backwards = in > terms of what can be supported. >=20 > Cheers, >=20 > Stefano >=20 > On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli > wrote: >=20 > Hi Stefano, >=20 > Thanks for your input. >=20 > I expect the LMA interacting with PCRF for policy rules specific to the > subscriber for different RAT types. > You are right that the LMA does not know the SSID the mobile is connected= to. > It=B9s not clear if the MAG can get that from the MN either without additio= nal > signaling. However, the LMA knows that the MN is connected to WLAN; so it= can > apply the policy at the RAT type level. Are you thinking of the MN connec= ting > to more than one WLAN network (and each of those connections coming back = to > the LMA)? If so, please explain the scenario. >=20 > Regards, >=20 > -Rajeev >=20 >=20 >=20 >=20 > On 2/1/11 6:39 PM, "stefano faccin" > wrote: > Raj, > thanks for the email. >=20 > I need to apologize in advance if my questions have already been answered > before (though I cannot find a conclusive answer anywhere). >=20 > I think that a protocol that is developed in NETEXT (or other groups) sho= uld > have at least a potential realistic scenario for applicability. >=20 > In terms of applicability, though it is not part of the protocol definiti= on > per se, unless there are solutions in place for either the host to indica= te to > the network where the flows should be routed or for the LMA to receive so= mehow > from somewhere some policies, the solution cannot really provide flow mob= ility > since there is no way to decide which flows are routed where. If we are > thinking about a host-based solution, I have not yet seen a solution as t= o how > the host can indicate to the MAG and ultimately to the MAG which flows sh= ould > be routed on each access. If we are relying on modifications of layer 2 > protocols, aren't we defining a solution that works only with some > technologies (since for other access technologies it is rather unrealisti= c to > modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-ba= sed > solution, can we hear of at least one example of a real-life scenario whe= re > the LMA would receive such policies, and how such delivery would happen? = Also, > should there be a solution to have policies in the LMA, how does the LMA > actually decide to route flows on one access or the other? E.g., if some = flows > need to be routed on certain WLAN networks, but shall not be routed on ot= her > WLAN networks, how does the LMA know which specific WLAN network the host= is > connected to? Perhaps I missed the ability for the MAG to know e.g. the W= LAN > SSID and provide it to the LMA, in which case I would appreciate if someb= ody > could highlight to me where that is defined. >=20 > I think that, though not integral to the protocol specification, understa= nding > what framework the protocol would/needs to fit in is rather important. >=20 > Cheers, > Stefano >=20 >=20 > On Tue, Feb 1, 2011 at 3:47 PM, > > wrote: >=20 > Hello, >=20 > We have discussed the flow mobility solutions for Proxy MIP6 previously a= t > IETFs 78 and 79. > This is a consensus call for adopting this I-D: > draft-bernardos-netext-pmipv6-flowmob-02 > as the working group document. > I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt >=20 > The consensus call will expire on Feb 15th, 2011. Please indicate your > support or concerns in adopting this I-D as the WG baseline document on > the mailing list. >=20 > Please note that this I-D will serve as the baseline in the WG and will b= e > developed further based on input and feedback from WG members. >=20 > -Basavaraj >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > =20 > =20 > =20 >=20 --B_3379491987_51994305 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmi= pv6-flowmob as WG doc
Hi Gerardo,

  • my point is that someone/something is configuring th= e policy on the MN which needs to be in sync with the MN’s partner, i.= e., the network. If this is not the case, please let me know.
  • The last I heard, PMIP6 is applicable on the eHRPD (trus= ted non-3GPP network). Also, 33.402 does not specify whether a particular ty= pe of access network (such as WLAN) is considered trusted or untrusted (alth= ough a majority of the WLAN access could be considered untrusted today).

-Rajeev


On 2/2/11 11:16 AM, "Giaretta, Gerardo" <gerardog@qualcomm.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Hi Rajeev,
 
A couple of considerations on this:
 
-         This draft assumes there = is consistency in the rules. This is a new requirement for the system archit= ecture where this solution will be applied. There is no this requirement for= other solutions already adopted by IETF and 3GPP. In my view this seems a f= airly important issue.

-         The routing decisions bas= ed on WLAN SSID are different from trusted/untrusted. Note also that PMIPv6 = cannot be used in trusted networks so it is not clear at all what you are re= ferring to.

 
Gerardo
 

From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Raj= eev Koodli
Sent: Wednesday, February 02, 2011 11:28 AM
To: stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-n= etext-pmipv6-flowmob as WG doc

Stefano,

Regardless of how the policy is configured on the LMA, there is a consisten= cy of the rules which needs to be ensured regardless. Whatever the entity (O= MA-DM?!) is that configures the policy has to ensure such a consistency.

We can debate about how policy interaction works, but that’s another = topic. I would note that there are choices here (modulo respective pros and = cons).

I didn’t suggest that an operator should just trust the software on a= MN, although I suspect some device vendors might argue for their robustness= (surprise?).

I would frame the WLAN access problem as whether the access is considered t= rusted or not. Accordingly, you apply the policy.

-Rajeev


On 2/2/11 10:50 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:
Raj,
thanks for the reply.

If the LMA has statically configured policies, how do we ensure that the MN= has the same policies? That would mean implicitly assuming that the policie= s provisioned to the MN by the ANDSF "always" match what has been = set in the LMA, which I think it is unrealistic because the policies change = over time, and every time you need to update all the LMAs, which has a consi= derable operational cost. Instead, if we leave the MN to make the choice, th= ere are easy and well specified mechanisms that allow the provisioning of po= licies in the MN and for the MN to make such decision and communicate it to = the network, so that the network can

As for extensions to Gx, I am not stating that in theory one could extend G= x. However, at present such solution does not exists, and without it, I do n= ot see how the draft is applicable to 3GPP that is at present the only poten= tial customer identified (I guess I did not see any other identified?)  = ;

Even assuming that Gx could be modified, the issue of the per-access networ= k granularity remains. Even if the LMA has the right policies in place, the = LMA has no way of knowing exactly what access network of a specific access t= echnology (e.g. which SSID for WLAN0 the MN is connecting to.

I cannot agree with your assumption below that if the MN connects to an SSI= D it is because the operator is OK with routing traffic on that SSID, and th= at we should just "trust the software on the MN". There are two as= pects to consider:
1) whether it is OK for certain traffic to be routed at all over a certain = access access network of a specific access technology
2) how different traffic should be routed over different access networks of= different access technologies

Regarding these two points, the issue is whether the operator wants to allo= w traffic e.g. over a certain SSID or not. So, in that case, it is obvious a= s you say that if the MN has connected to an SSID configured by the operator= in the MN, then traffic could be allowed over that SSID. However, we need t= o consider that 3GPP allows the decision of which WLAN the MN can connect to= based on user preferences. This means that my MN can e.g. connect to my hom= e WLAN (which is not controlled necessarily by the operator and whose SSID t= he operator does not know) or to a coffee shop WLAN, even if the device does= not have those SSID configured. Those are typical examples of untrusted WLA= N access networks. Therefore, in such cases, just because the MN has connect= ed to a WLAN SSID, does not mean that the operator wants to route certain tr= affic over that SSID just because the policy says "route traffic X over= WLAN".

That brings us to a solution that, if applied to 3GPP, provides less functi= onality than what is available and has been specified today, so back to my p= oint above.

Unfortunately, there is no solution I am aware of that allows the WLAN netw= ork to indicate to the MAG/LMA the specific SSID (and as you say, there is n= o easy solution for that). Due to this and the points above about policy pro= visioning, it means that the applicability of this solution to a real case l= ike 3GPP depends on the feasibility of extending policy mechanisms in 3GPP, = and the ability to have a solution where the WLAN network provides the SSID = information to the MAG/LMA. Moreover, the provisioning of such SSID is not i= n the scope of IETF, but not even of 3GPP (since the interface between the W= LAN AP and the ePDG is not defined), thus I wonder how this could be defined= at all (I am afraid of asking what magic should happen here). So, now we ha= ve two big dependencies.

In general, I am also wondering if there is a customer that has asked us to= define this solution. I am not aware of any but I may have missed that.

Cheers,
Stefano

On Wed, Feb 2, 2011 at 10:44 AM, Rajeev Koodli <rkoodli@cisco.com> wrote:

Hi Stefano,

You make two interesting points: First, the defined solution should be usef= ul for 3GPP deployments. Second, if it’s not defined today in 3= GPP, it’s not useful.

I tend to agree with you on the first – 3GPP is a big potential custo= mer.
I cannot agree with your second point.

There are multiple ways I could envision policy on the LMA. Locally configu= red policy is one (which we use today in deployments) that does not need Gx = interaction. Gx extensions can be proposed in the future. I hope you are not= suggesting that these are not feasible choices.

For the MN (IETF term for UE) to even connect to the MAG via WLAN today, yo= u need an IPsec termination point (ePDG). If the operator pre-configures the= list of SSIDs or there is some out-of-band mechanism to inform the MN which= SSID is “white-listed”, then I expect the MN to decide when to = connect to the ePDG and hence the MAG. At this point, the MN is already on t= he WLAN the operator cares about I presume.
There is no easy way for the network (LMA, MAG) to know what SSID the MN is= connected to – the network has to either trust the software on the MN= or the WLAN infrastructure has to provide the SSID information to the netwo= rk.

-Rajeev



On 2/2/11 9:56 AM, "stefano faccin" <sfaccinstd@gmail.com <htt= p://sfaccinstd@gmail.com> > wrote:
Hello rajeev,
the use of PCRF is an interesting suggestion. However, unfortunately, PCRF = does not contain any policies or information that will tell the LMA what are= the policies to be used for decisions of IP flow mobility. This is not part= of current PCC functionality, and there is no work ongoing or planned to ex= tend PCC in such way. Therefore, the applicability of the solution in this d= raft would hinge on hypotetical future solutions and not on a current soluti= on for the open issues, which brings us back to my point that we are definin= g a solution with open issues for which there is not a single realistic solu= tion out there, thus making this draft not applicable to a real scenario.
I am not thinking of the UE connecting to more than one WLAN at the same ti= me, but the UE being able to connect to different WLANs (one at a time) beca= use the UE is e.g. provisioned with a list of SSIDs or the UE discovers a ho= tspot somewhere. I am talking about the scenario where the UE is capable to = connect to WLAN, but the operator has different policies wrt which WLAN the = UE should use or not.

If you have followed the work in 3GPP, it is clear that operators have inte= rest in applying policies not only at RAT level, but also at access network = level (please see how ANDSF was defined and why). I guess we can all agree t= hat an operator deploying PMIP-based mobility may be interested in having po= licies that allow traffic on the WLAN the operator owns or that belongs to a= roaming partner, while not allowing traffic on WLAN of other operators for = which it might need to pay an extra fee or where e.g. no QoS can be guarante= ed. That means that the entity deciding whether traffic needs to be routed o= n WLAN or not cannot just consider "WLAN is available", but "= WLAN SSIDx is available", so that the decision can be based on the oper= ator preferences as to which WLAN certain traffic needs to be routed on.
If the draft allows decisions to be made only at the RAT level, then we hav= e an issue because we are defining a solution that should be applicable to 3= GPP but does not meet the deployment scenarios of interest. In other words, = if we want to make this solution applicable e.g. to 3GPP, we need to be able= to provide the same functionality available today in 3GPP with other soluti= on in order to satisfy the use cases supported by 3GPP, and not step backwar= ds in terms of what can be supported.

Cheers,

Stefano

On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli <rkoodli@cisco.com <http://rkood= li@cisco.com> > wrote:

Hi Stefano,

Thanks for your input.

I expect the LMA interacting with PCRF for policy rules specific to the sub= scriber for different RAT types.
You are right that the LMA does not know the SSID the mobile is connected t= o. It’s not clear if the MAG can get that from the MN either without a= dditional signaling. However, the LMA knows that the MN is connected to WLAN= ; so it can apply the policy at the RAT type level. Are you thinking of the = MN connecting to more than one WLAN network (and each of those connections c= oming back to the LMA)? If so, please explain the scenario.

Regards,

-Rajeev




On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <htt= p://sfaccinstd@gmail.com>  <http://sfaccinstd@gmail.com> > wrote:
Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicate= to the network where the flows should be routed or for the LMA to receive s= omehow from somewhere some policies, the solution cannot really provide flow= mobility since there is no way to decide which flows are routed where. If w= e are thinking about a host-based solution, I have not yet seen a solution a= s to how the host can indicate to the MAG and ultimately to the MAG which fl= ows should be routed on each access. If we are relying on modifications of l= ayer 2 protocols, aren't we defining a solution that works only with some te= chnologies (since for other access technologies it is rather unrealistic to = modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-based= solution, can we hear of at least one example of a real-life scenario where= the LMA would receive such policies, and how such delivery would happen? Al= so, should there be a solution to have policies in the LMA, how does the LMA= actually decide to route flows on one access or the other? E.g., if some fl= ows need to be routed on certain WLAN networks, but shall not be routed on o= ther WLAN networks, how does the LMA know which specific WLAN network the ho= st is connected to? Perhaps I missed the ability for the MAG to know e.g. th= e WLAN SSID and provide it to the LMA, in which case I would appreciate if s= omebody could highlight to me where that is defined.

I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important. <= BR>
Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM,  <Basavaraj.Patil@nokia.com <http://Basavaraj.Patil@nokia.com>  <http://Basavaraj.Patil@nokia.com> > wrote:
Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= BR> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt<= /a>

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= BR> developed further based on input and feedback from WG members.

-Basavaraj

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

--B_3379491987_51994305-- From sfaccinstd@gmail.com Wed Feb 2 11:25:08 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 368C63A6DDD for ; Wed, 2 Feb 2011 11:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.338 X-Spam-Level: X-Spam-Status: No, score=-103.338 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcSdVwgllebc for ; Wed, 2 Feb 2011 11:25:04 -0800 (PST) Received: from mail-qw0-f66.google.com (mail-qw0-f66.google.com [209.85.216.66]) by core3.amsl.com (Postfix) with ESMTP id 3035D3A6CDC for ; Wed, 2 Feb 2011 11:25:03 -0800 (PST) Received: by qwk3 with SMTP id 3so24359qwk.1 for ; Wed, 02 Feb 2011 11:28:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0sULk3f6pz1hhUrmaZgkjw/6l1YMGJ07gr9N1dg1RcU=; b=ob0wTNB+SrX0i7EbnNrFrZUc0+fEYXWyVIMK+8ZAajzSe8EUkHrfz0FtT8imoeeHU8 u3t7K3TC87v4933uFEEmFoILjT6aVEsEht9JSG/7AsMdejurST4wlfGVF1UPWMB3SVpg 9eGZAT/hF3OkJSPTq5kvJhBFJpmI3+bwexH3o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=t+RH0jqCWSXltGgpZ4nOhDw0iNvYI8wbzjEuTq2+mh8XNbnC86BZrLqoZ8euKgGvCC fT/EoEOm1Bre5BZT46tz+09VbFTxghR0yhC7qlny0HQj/YCf59BTLRjJbj5qImdpjw9u 3uhq+oEWY+QIiLRFEu8Hc+lZMb2mFz+ZqqyZs= MIME-Version: 1.0 Received: by 10.229.91.194 with SMTP id o2mr8488354qcm.138.1296674902589; Wed, 02 Feb 2011 11:28:22 -0800 (PST) Received: by 10.229.20.70 with HTTP; Wed, 2 Feb 2011 11:28:22 -0800 (PST) In-Reply-To: References: Date: Wed, 2 Feb 2011 11:28:22 -0800 Message-ID: From: stefano faccin To: "Giaretta, Gerardo" Content-Type: multipart/alternative; boundary=0016364ee640f553cf049b51a6c7 Cc: "Basavaraj.Patil@nokia.com" , "netext@ietf.org" Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 19:25:08 -0000 --0016364ee640f553cf049b51a6c7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Rajeev, I am not sure what you refer to when you talk about consistency of the policies. In solutions currently adopted, the policies are managed by a network entity (ANDSF) that has no relationship with the LMA, and provided to the MN, thus the ANDSF can easily ensure that the MN has the correct policies. There is no need for further consistency since no other entity needs to know or use such policies. As Gerardo says, requiring such consistency is a considerable change to the system and a requirement that has not been discussed before. I would actually consider this an open issue with the current draft. I think robustness or trusting the software here has no relevance. What is relevant is the fact that just because a MN has selected a specific WLAN SSID, it does not mean that the LMA can safely assume that certain traffic can be carried above that specific WLAN just because (1) it is WLAN and (2) the operator has configured the preferred SSIDs in the MN. As I said, the user can select other SSIDs, as in current specified solutions. Whether WLAN is trusted or not is another matter orthogonal to this discussion. An operator may deploy WLAN APs that it owns but, due to e.g. the fact that the same operator does not control the interconnection betwee= n the AP and its own core network (as it will happen often), the operator decides to consider that access untrusted and therefore require the use of an ePDG. Therefore, just because the MN uses one of the SSIDs configured by the operator as preferred, does not mean that the access is considered trusted. Cheers, Stefano On Wed, Feb 2, 2011 at 11:16 AM, Giaretta, Gerardo w= rote: > Hi Rajeev, > > > > A couple of considerations on this: > > > > - This draft assumes there is consistency in the rules. This is = a > new requirement for the system architecture where this solution will be > applied. There is no this requirement for other solutions already adopted= by > IETF and 3GPP. In my view this seems a fairly important issue. > > - The routing decisions based on WLAN SSID are different from > trusted/untrusted. Note also that PMIPv6 cannot be used in trusted networ= ks > so it is not clear at all what you are referring to. > > > > Gerardo > > > > *From:* netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] *On > Behalf Of *Rajeev Koodli > *Sent:* Wednesday, February 02, 2011 11:28 AM > *To:* stefano faccin > *Cc:* netext@ietf.org; Basavaraj.Patil@nokia.com > *Subject:* Re: [netext] Consensus call to adopt I-D: > draft-bernardos-netext-pmipv6-flowmob as WG doc > > > > > Stefano, > > Regardless of how the policy is configured on the LMA, there is a > consistency of the rules which needs to be ensured regardless. Whatever t= he > entity (OMA-DM?!) is that configures the policy has to ensure such a > consistency. > > We can debate about how policy interaction works, but that=92s another to= pic. > I would note that there are choices here (modulo respective pros and cons= ). > > I didn=92t suggest that an operator should just trust the software on a M= N, > although I suspect some device vendors might argue for their robustness > (surprise?). > > I would frame the WLAN access problem as whether the access is considered > trusted or not. Accordingly, you apply the policy. > > -Rajeev > > > On 2/2/11 10:50 AM, "stefano faccin" wrote: > > Raj, > thanks for the reply. > > If the LMA has statically configured policies, how do we ensure that the = MN > has the same policies? That would mean implicitly assuming that the polic= ies > provisioned to the MN by the ANDSF "always" match what has been set in th= e > LMA, which I think it is unrealistic because the policies change over tim= e, > and every time you need to update all the LMAs, which has a considerable > operational cost. Instead, if we leave the MN to make the choice, there a= re > easy and well specified mechanisms that allow the provisioning of policie= s > in the MN and for the MN to make such decision and communicate it to the > network, so that the network can > > As for extensions to Gx, I am not stating that in theory one could extend > Gx. However, at present such solution does not exists, and without it, I = do > not see how the draft is applicable to 3GPP that is at present the only > potential customer identified (I guess I did not see any other identified= ?) > > > Even assuming that Gx could be modified, the issue of the per-access > network granularity remains. Even if the LMA has the right policies in > place, the LMA has no way of knowing exactly what access network of a > specific access technology (e.g. which SSID for WLAN0 the MN is connectin= g > to. > > I cannot agree with your assumption below that if the MN connects to an > SSID it is because the operator is OK with routing traffic on that SSID, = and > that we should just "trust the software on the MN". There are two aspects= to > consider: > 1) whether it is OK for certain traffic to be routed at all over a certai= n > access access network of a specific access technology > 2) how different traffic should be routed over different access networks = of > different access technologies > > Regarding these two points, the issue is whether the operator wants to > allow traffic e.g. over a certain SSID or not. So, in that case, it is > obvious as you say that if the MN has connected to an SSID configured by = the > operator in the MN, then traffic could be allowed over that SSID. However= , > we need to consider that 3GPP allows the decision of which WLAN the MN ca= n > connect to based on user preferences. This means that my MN can e.g. conn= ect > to my home WLAN (which is not controlled necessarily by the operator and > whose SSID the operator does not know) or to a coffee shop WLAN, even if = the > device does not have those SSID configured. Those are typical examples of > untrusted WLAN access networks. Therefore, in such cases, just because th= e > MN has connected to a WLAN SSID, does not mean that the operator wants to > route certain traffic over that SSID just because the policy says "route > traffic X over WLAN". > > That brings us to a solution that, if applied to 3GPP, provides less > functionality than what is available and has been specified today, so bac= k > to my point above. > > Unfortunately, there is no solution I am aware of that allows the WLAN > network to indicate to the MAG/LMA the specific SSID (and as you say, the= re > is no easy solution for that). Due to this and the points above about pol= icy > provisioning, it means that the applicability of this solution to a real > case like 3GPP depends on the feasibility of extending policy mechanisms = in > 3GPP, and the ability to have a solution where the WLAN network provides = the > SSID information to the MAG/LMA. Moreover, the provisioning of such SSID = is > not in the scope of IETF, but not even of 3GPP (since the interface betwe= en > the WLAN AP and the ePDG is not defined), thus I wonder how this could be > defined at all (I am afraid of asking what magic should happen here). So, > now we have two big dependencies. > > In general, I am also wondering if there is a customer that has asked us = to > define this solution. I am not aware of any but I may have missed that. > > Cheers, > Stefano > > On Wed, Feb 2, 2011 at 10:44 AM, Rajeev Koodli wrote: > > > Hi Stefano, > > You make two interesting points: First, the defined solution should be > useful for 3GPP deployments. Second, if it=92s not defined *today* in 3GP= P, > it=92s not useful. > > I tend to agree with you on the first =96 3GPP is a big potential custome= r. > I cannot agree with your second point. > > There are multiple ways I could envision policy on the LMA. Locally > configured policy is one (which we use today in deployments) that does no= t > need Gx interaction. Gx extensions can be proposed in the future. I hope = you > are not suggesting that these are not feasible choices. > > For the MN (IETF term for UE) to even connect to the MAG via WLAN today, > you need an IPsec termination point (ePDG). If the operator pre-configure= s > the list of SSIDs or there is some out-of-band mechanism to inform the MN > which SSID is =93white-listed=94, then I expect the MN to decide when to = connect > to the ePDG and hence the MAG. At this point, the MN is already on the WL= AN > the operator cares about I presume. > There is no easy way for the network (LMA, MAG) to know what SSID the MN = is > connected to =96 the network has to either trust the software on the MN o= r the > WLAN infrastructure has to provide the SSID information to the network. > > -Rajeev > > > > On 2/2/11 9:56 AM, "stefano faccin" http://sfaccinstd@gmail.com> > wrote: > > Hello rajeev, > the use of PCRF is an interesting suggestion. However, unfortunately, PCR= F > does not contain any policies or information that will tell the LMA what = are > the policies to be used for decisions of IP flow mobility. This is not pa= rt > of current PCC functionality, and there is no work ongoing or planned to > extend PCC in such way. Therefore, the applicability of the solution in t= his > draft would hinge on hypotetical future solutions and not on a current > solution for the open issues, which brings us back to my point that we ar= e > defining a solution with open issues for which there is not a single > realistic solution out there, thus making this draft not applicable to a > real scenario. > > I am not thinking of the UE connecting to more than one WLAN at the same > time, but the UE being able to connect to different WLANs (one at a time) > because the UE is e.g. provisioned with a list of SSIDs or the UE discove= rs > a hotspot somewhere. I am talking about the scenario where the UE is capa= ble > to connect to WLAN, but the operator has different policies wrt which WLA= N > the UE should use or not. > > If you have followed the work in 3GPP, it is clear that operators have > interest in applying policies not only at RAT level, but also at access > network level (please see how ANDSF was defined and why). I guess we can = all > agree that an operator deploying PMIP-based mobility may be interested in > having policies that allow traffic on the WLAN the operator owns or that > belongs to a roaming partner, while not allowing traffic on WLAN of other > operators for which it might need to pay an extra fee or where e.g. no Qo= S > can be guaranteed. That means that the entity deciding whether traffic ne= eds > to be routed on WLAN or not cannot just consider "WLAN is available", but > "WLAN SSIDx is available", so that the decision can be based on the opera= tor > preferences as to which WLAN certain traffic needs to be routed on. > > If the draft allows decisions to be made only at the RAT level, then we > have an issue because we are defining a solution that should be applicabl= e > to 3GPP but does not meet the deployment scenarios of interest. In other > words, if we want to make this solution applicable e.g. to 3GPP, we need = to > be able to provide the same functionality available today in 3GPP with ot= her > solution in order to satisfy the use cases supported by 3GPP, and not ste= p > backwards in terms of what can be supported. > > Cheers, > > Stefano > > On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli http://rkoodli@cisco.com> > wrote: > > > Hi Stefano, > > Thanks for your input. > > I expect the LMA interacting with PCRF for policy rules specific to the > subscriber for different RAT types. > You are right that the LMA does not know the SSID the mobile is connected > to. It=92s not clear if the MAG can get that from the MN either without > additional signaling. However, the LMA knows that the MN is connected to > WLAN; so it can apply the policy at the RAT type level. Are you thinking = of > the MN connecting to more than one WLAN network (and each of those > connections coming back to the LMA)? If so, please explain the scenario. > > Regards, > > -Rajeev > > > > > On 2/1/11 6:39 PM, "stefano faccin" http://sfaccinstd@gmail.com> > wrote: > > Raj, > thanks for the email. > > I need to apologize in advance if my questions have already been answered > before (though I cannot find a conclusive answer anywhere). > > I think that a protocol that is developed in NETEXT (or other groups) > should have at least a potential realistic scenario for applicability. > > In terms of applicability, though it is not part of the protocol definiti= on > per se, unless there are solutions in place for either the host to indica= te > to the network where the flows should be routed or for the LMA to receive > somehow from somewhere some policies, the solution cannot really provide > flow mobility since there is no way to decide which flows are routed wher= e. > If we are thinking about a host-based solution, I have not yet seen a > solution as to how the host can indicate to the MAG and ultimately to the > MAG which flows should be routed on each access. If we are relying on > modifications of layer 2 protocols, aren't we defining a solution that wo= rks > only with some technologies (since for other access technologies it is > rather unrealistic to modify L2 for IP flow mobility purposes)? If we are > thinking of an LMA-based solution, can we hear of at least one example of= a > real-life scenario where the LMA would receive such policies, and how suc= h > delivery would happen? Also, should there be a solution to have policies = in > the LMA, how does the LMA actually decide to route flows on one access or > the other? E.g., if some flows need to be routed on certain WLAN networks= , > but shall not be routed on other WLAN networks, how does the LMA know whi= ch > specific WLAN network the host is connected to? Perhaps I missed the abil= ity > for the MAG to know e.g. the WLAN SSID and provide it to the LMA, in whic= h > case I would appreciate if somebody could highlight to me where that is > defined. > > I think that, though not integral to the protocol specification, > understanding what framework the protocol would/needs to fit in is rather > important. > > Cheers, > Stefano > > > On Tue, Feb 1, 2011 at 3:47 PM, http://Basavaraj.Patil@nokia.com> > > wrote: > > > Hello, > > We have discussed the flow mobility solutions for Proxy MIP6 previously a= t > IETFs 78 and 79. > This is a consensus call for adopting this I-D: > draft-bernardos-netext-pmipv6-flowmob-02 > as the working group document. > I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt > > The consensus call will expire on Feb 15th, 2011. Please indicate your > support or concerns in adopting this I-D as the WG baseline document on > the mailing list. > > Please note that this I-D will serve as the baseline in the WG and will b= e > developed further based on input and feedback from WG members. > > -Basavaraj > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > > > > > > --=20 Stefano M. Faccin =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D May the Force be with you --0016364ee640f553cf049b51a6c7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Rajeev,

I am not sure what you refer to when you talk about consistency of the = policies. In solutions currently adopted, the policies are managed by a net= work entity (ANDSF) that has no relationship with the LMA, and provided to = the MN, thus the ANDSF can easily ensure that the MN has the correct polici= es. There is no need for further consistency since no other entity needs to= know or use such policies. As Gerardo says, requiring such consistency is = a considerable change to the system and a requirement that has not been dis= cussed before. I would actually consider this an open issue with the curren= t draft.

I think robustness or trusting the software here has no relevance. What= is relevant is the fact that just because a MN has selected a specific WLA= N SSID, it does not mean that the LMA can safely assume that certain traffi= c can be carried above that specific WLAN just because (1) it is WLAN and (= 2) the operator has configured the preferred SSIDs in the MN. As I said, th= e user can select other SSIDs, as in current specified solutions.

Whether WLAN is trusted or not is another matter orthogonal to this dis= cussion. An operator may deploy WLAN APs that it owns but, due to e.g. the = fact that the same operator does not control the interconnection between th= e AP and its own core network (as it will happen often), the operator decid= es to consider that access untrusted and therefore require the use of an eP= DG. Therefore, just because the MN uses one of the SSIDs configured by the = operator as preferred, does not mean that the access is considered trusted.=

Cheers,
Stefano

On Wed, Feb 2, 20= 11 at 11:16 AM, Giaretta, Gerardo <gerardog@qualcomm.com> wrote:

Hi Rajeev,

=A0

A couple of considerations on this:

=A0

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 This draft assumes there is consistency in the rules. This is a new req= uirement for the system architecture where this solution will be applied. There is no this requirement for other solutions already adopted by IETF a= nd 3GPP. In my view this seems a fairly important issue.

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 The routing decisions based on WLAN SSID are different from trusted/unt= rusted. Note also that PMIPv6 cannot be used in trusted networks so it is not clear at all what you are referring to.

=A0

Gerardo

=A0

From:= netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Rajeev Koodli
Sent: Wednesday, February 02, 2011 11:28 AM
To: stefano faccin
Cc: netext@ietf= .org; Ba= savaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-n= etext-pmipv6-flowmob as WG doc

=A0


Stefano,

Regardless of how the policy is configured on the LMA, there is a consisten= cy of the rules which needs to be ensured regardless. Whatever the entity (= OMA-DM?!) is that configures the policy has to ensure such a consistency.
We can debate about how policy interaction works, but that=92s another topi= c. I would note that there are choices here (modulo respective pros and con= s).

I didn=92t suggest that an operator should just trust the software on a MN,= although I suspect some device vendors might argue for their robustness (s= urprise?).

I would frame the WLAN access problem as whether the access is considered t= rusted or not. Accordingly, you apply the policy.

-Rajeev


On 2/2/11 10:50 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:

Raj,
thanks for the reply.

If the LMA has statically configured policies, how do we ensure that the MN= has the same policies? That would mean implicitly assuming that the polici= es provisioned to the MN by the ANDSF "always" match what has bee= n set in the LMA, which I think it is unrealistic because the policies change over time, and every time you need to update a= ll the LMAs, which has a considerable operational cost. Instead, if we leav= e the MN to make the choice, there are easy and well specified mechanisms t= hat allow the provisioning of policies in the MN and for the MN to make such decision and communicate it to the n= etwork, so that the network can

As for extensions to Gx, I am not stating that in theory one could extend G= x. However, at present such solution does not exists, and without it, I do = not see how the draft is applicable to 3GPP that is at present the only pot= ential customer identified (I guess I did not see any other identified?)=A0

Even assuming that Gx could be modified, the issue of the per-access networ= k granularity remains. Even if the LMA has the right policies in place, the= LMA has no way of knowing exactly what access network of a specific access= technology (e.g. which SSID for WLAN0 the MN is connecting to.

I cannot agree with your assumption below that if the MN connects to an SSI= D it is because the operator is OK with routing traffic on that SSID, and t= hat we should just "trust the software on the MN". There are two = aspects to consider:
1) whether it is OK for certain traffic to be routed at all over a certain = access access network of a specific access technology
2) how different traffic should be routed over different access networks of= different access technologies

Regarding these two points, the issue is whether the operator wants to allo= w traffic e.g. over a certain SSID or not. So, in that case, it is obvious = as you say that if the MN has connected to an SSID configured by the operat= or in the MN, then traffic could be allowed over that SSID. However, we need to consider that 3GPP allows t= he decision of which WLAN the MN can connect to based on user preferences. = This means that my MN can e.g. connect to my home WLAN (which is not contro= lled necessarily by the operator and whose SSID the operator does not know) or to a coffee shop WLAN, even = if the device does not have those SSID configured. Those are typical exampl= es of untrusted WLAN access networks. Therefore, in such cases, just becaus= e the MN has connected to a WLAN SSID, does not mean that the operator wants to route certain traffic over = that SSID just because the policy says "route traffic X over WLAN"= ;.=A0

That brings us to a solution that, if applied to 3GPP, provides less functi= onality than what is available and has been specified today, so back to my = point above.

Unfortunately, there is no solution I am aware of that allows the WLAN netw= ork to indicate to the MAG/LMA the specific SSID (and as you say, there is = no easy solution for that). Due to this and the points above about policy p= rovisioning, it means that the applicability of this solution to a real case like 3GPP depends on the feasibility of ex= tending policy mechanisms in 3GPP, and the ability to have a solution where= the WLAN network provides the SSID information to the MAG/LMA. Moreover, t= he provisioning of such SSID is not in the scope of IETF, but not even of 3GPP (since the interface betwee= n the WLAN AP and the ePDG is not defined), thus I wonder how this could be= defined at all (I am afraid of asking what magic should happen here). So, = now we have two big dependencies.

In general, I am also wondering if there is a customer that has asked us to= define this solution. I am not aware of any but I may have missed that.
Cheers,
Stefano

On Wed, Feb 2, 2011 at 10:44 AM, Rajeev Koodli <rkoodli@cisco.com> wrote:


Hi Stefano,

You make two interesting points: First, the defined solution should be usef= ul for 3GPP deployments. Second, if it=92s not defined today in 3GPP, it=92s not useful.

I tend to agree with you on the first =96 3GPP is a big potential customer.=
I cannot agree with your second point.

There are multiple ways I could envision policy on the LMA. Locally configu= red policy is one (which we use today in deployments) that does not need Gx= interaction. Gx extensions can be proposed in the future. I hope you are n= ot suggesting that these are not feasible choices.

For the MN (IETF term for UE) to even connect to the MAG via WLAN today, yo= u need an IPsec termination point (ePDG). If the operator pre-configures th= e list of SSIDs or there is some out-of-band mechanism to inform the MN whi= ch SSID is =93white-listed=94, then I expect the MN to decide when to connect to the ePDG and hence the MAG. A= t this point, the MN is already on the WLAN the operator cares about I pres= ume.
There is no easy way for the network (LMA, MAG) to know what SSID the MN is= connected to =96 the network has to either trust the software on the MN or= the WLAN infrastructure has to provide the SSID information to the network= .

-Rajeev



On 2/2/11 9:56 AM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com> > wrote:

Hello rajeev,
the use of PCRF is an interesting suggestion. However, unfortunately, PCRF = does not contain any policies or information that will tell the LMA what ar= e the policies to be used for decisions of IP flow mobility. This is not pa= rt of current PCC functionality, and there is no work ongoing or planned to extend PCC in such way. Therefo= re, the applicability of the solution in this draft would hinge on hypoteti= cal future solutions and not on a current solution for the open issues, whi= ch brings us back to my point that we are defining a solution with open issues for which there is not a singl= e realistic solution out there, thus making this draft not applicable to a = real scenario.

I am not thinking of the UE connecting to more than one WLAN at the same ti= me, but the UE being able to connect to different WLANs (one at a time) bec= ause the UE is e.g. provisioned with a list of SSIDs or the UE discovers a = hotspot somewhere. I am talking about the scenario where the UE is capable to connect to WLAN, but the ope= rator has different policies wrt which WLAN the UE should use or not.

If you have followed the work in 3GPP, it is clear that operators have inte= rest in applying policies not only at RAT level, but also at access network= level (please see how ANDSF was defined and why). I guess we can all agree= that an operator deploying PMIP-based mobility may be interested in having policies that allow traffic on the WL= AN the operator owns or that belongs to a roaming partner, while not allowi= ng traffic on WLAN of other operators for which it might need to pay an ext= ra fee or where e.g. no QoS can be guaranteed. That means that the entity deciding whether traffic needs t= o be routed on WLAN or not cannot just consider "WLAN is available&quo= t;, but "WLAN SSIDx is available", so that the decision can be ba= sed on the operator preferences as to which WLAN certain traffic needs to be routed on.

If the draft allows decisions to be made only at the RAT level, then we hav= e an issue because we are defining a solution that should be applicable to = 3GPP but does not meet the deployment scenarios of interest. In other words= , if we want to make this solution applicable e.g. to 3GPP, we need to be able to provide the same functional= ity available today in 3GPP with other solution in order to satisfy the use= cases supported by 3GPP, and not step backwards in terms of what can be su= pported.

Cheers,

Stefano

On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli <rkoodli@cisco.com <http://rkoodli@cisco.com> > w= rote:


Hi Stefano,

Thanks for your input.

I expect the LMA interacting with PCRF for policy rules specific to the sub= scriber for different RAT types.
You are right that the LMA does not know the SSID the mobile is connected t= o. It=92s not clear if the MAG can get that from the MN either without addi= tional signaling. However, the LMA knows that the MN is connected to WLAN; = so it can apply the policy at the RAT type level. Are you thinking of the MN connecting to more than one WLA= N network (and each of those connections coming back to the LMA)? If so, pl= ease explain the scenario.

Regards,

-Rajeev




On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com> =A0<http= ://sfaccinstd@gmail.com> > wrote:

Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicat= e to the network where the flows should be routed or for the LMA to receive= somehow from somewhere some policies, the solution cannot really provide flow mobility since there is no way to = decide which flows are routed where. If we are thinking about a host-based = solution, I have not yet seen a solution as to how the host can indicate to= the MAG and ultimately to the MAG which flows should be routed on each access. If we are relying on modifica= tions of layer 2 protocols, aren't we defining a solution that works on= ly with some technologies (since for other access technologies it is rather= unrealistic to modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-based solution, can we he= ar of at least one example of a real-life scenario where the LMA would rece= ive such policies, and how such delivery would happen? Also, should there b= e a solution to have policies in the LMA, how does the LMA actually decide to route flows on one access or = the other? E.g., if some flows need to be routed on certain WLAN networks, = but shall not be routed on other WLAN networks, how does the LMA know which= specific WLAN network the host is connected to? Perhaps I missed the ability for the MAG to know e.g. the= WLAN SSID and provide it to the LMA, in which case I would appreciate if s= omebody could highlight to me where that is defined.

I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important.

Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM, =A0<Basavaraj.Patil@nokia.com <http://Basavaraj.Patil@nok= ia.com> =A0<http://Basavaraj.Patil@nokia.com> > wrote:


Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= br> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= br> developed further based on input and feedback from WG members.

-Basavaraj

_______________________________________________
netext mailing list
netext@ietf.org &l= t;http://netext@ietf.o= rg> =A0<http= ://netext@ietf.org>
= https://www.ietf.org/mailman/listinfo/netext

=A0

=A0

=A0




--
Stefano M. Faccin
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
May the Force be = with you
--0016364ee640f553cf049b51a6c7-- From sfaccinstd@gmail.com Wed Feb 2 11:37:24 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2BF73A6C0B for ; Wed, 2 Feb 2011 11:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.381 X-Spam-Level: X-Spam-Status: No, score=-103.381 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufoJm47LycgE for ; Wed, 2 Feb 2011 11:37:21 -0800 (PST) Received: from mail-qw0-f66.google.com (mail-qw0-f66.google.com [209.85.216.66]) by core3.amsl.com (Postfix) with ESMTP id 9A4E23A6CDC for ; Wed, 2 Feb 2011 11:37:20 -0800 (PST) Received: by qwk3 with SMTP id 3so25182qwk.1 for ; Wed, 02 Feb 2011 11:40:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=3JCWnCCND5AMJzkni589C4qOLa5z3lArb7dyagJXwPw=; b=bvtRDAdqpgKiomMipj1Dc/C5ttiiips+hq+Edq91e1X+EwrEXwfgsdiac7Ha87iB5d zq+F5JZ3uqXnf4Wq+r9/yOtvw8vvf7MRdDmnWKpPsnFFdOR5jb03uSs7MTE5DcRQaShV E2J5+W3ErnPxpu0ODzwoQiouWuX2pan4u7W28= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=oZcoXUeXhCtAGz4ObDXP+Ve9L4Be8Ya7BAZaqGDGyPXpDzYDy3SrHstQw9zxnsGi4y hTqaJ/wp3HNXEjDoKN4BCWZ84fVVzLhuhaySzYLXqxA9YeEg6xJFWYBL9uNEEeXy0cLt 6Yt//OH+bSA5UOwqaU95B9IMOO1si/7hThk74= MIME-Version: 1.0 Received: by 10.229.89.84 with SMTP id d20mr6712764qcm.100.1296675640454; Wed, 02 Feb 2011 11:40:40 -0800 (PST) Received: by 10.229.20.70 with HTTP; Wed, 2 Feb 2011 11:40:40 -0800 (PST) In-Reply-To: References: Date: Wed, 2 Feb 2011 11:40:40 -0800 Message-ID: From: stefano faccin To: Rajeev Koodli , netext@ietf.org Content-Type: multipart/alternative; boundary=0016364ede48f039fb049b51d2f2 Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 19:37:24 -0000 --0016364ede48f039fb049b51d2f2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sorry, I forgot to reply to the whole list. Cheers, Stefano On Wed, Feb 2, 2011 at 11:29 AM, stefano faccin wrote= : > Hi Rajeev, > in current solution the policy is in sync, since it is the ANDSF (the > network counterpart of the MN for the policy) that configures it in the M= N. > That does not mean that the LMA has such policy. > > Cheers, > Stefano > > > On Wed, Feb 2, 2011 at 11:46 AM, Rajeev Koodli wrote: > >> >> Hi Gerardo, >> >> >> - my point is that someone/something is configuring the policy on the >> MN which needs to be in sync with the MN=92s partner, i.e., the netwo= rk. If >> this is not the case, please let me know. >> - The last I heard, PMIP6 is applicable on the eHRPD (trusted non-3GP= P >> network). Also, 33.402 does not specify whether a particular type of = access >> network (such as WLAN) is considered trusted or untrusted (although a >> majority of the WLAN access could be considered untrusted today). >> >> >> -Rajeev >> >> >> >> On 2/2/11 11:16 AM, "Giaretta, Gerardo" wrote: >> >> Hi Rajeev, >> >> A couple of considerations on this: >> >> - This draft assumes there is consistency in the rules. This is = a >> new requirement for the system architecture where this solution will be >> applied. There is no this requirement for other solutions already adopte= d by >> IETF and 3GPP. In my view this seems a fairly important issue. >> >> - The routing decisions based on WLAN SSID are different from >> trusted/untrusted. Note also that PMIPv6 cannot be used in trusted netwo= rks >> so it is not clear at all what you are referring to. >> >> >> Gerardo >> >> >> *From:* netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] >> *On Behalf Of *Rajeev Koodli >> *Sent:* Wednesday, February 02, 2011 11:28 AM >> *To:* stefano faccin >> *Cc:* netext@ietf.org; Basavaraj.Patil@nokia.com >> *Subject:* Re: [netext] Consensus call to adopt I-D: >> draft-bernardos-netext-pmipv6-flowmob as WG doc >> >> >> Stefano, >> >> Regardless of how the policy is configured on the LMA, there is a >> consistency of the rules which needs to be ensured regardless. Whatever = the >> entity (OMA-DM?!) is that configures the policy has to ensure such a >> consistency. >> >> We can debate about how policy interaction works, but that=92s another >> topic. I would note that there are choices here (modulo respective pros = and >> cons). >> >> I didn=92t suggest that an operator should just trust the software on a = MN, >> although I suspect some device vendors might argue for their robustness >> (surprise?). >> >> I would frame the WLAN access problem as whether the access is considere= d >> trusted or not. Accordingly, you apply the policy. >> >> -Rajeev >> >> >> On 2/2/11 10:50 AM, "stefano faccin" wrote: >> Raj, >> thanks for the reply. >> >> If the LMA has statically configured policies, how do we ensure that the >> MN has the same policies? That would mean implicitly assuming that the >> policies provisioned to the MN by the ANDSF "always" match what has been= set >> in the LMA, which I think it is unrealistic because the policies change = over >> time, and every time you need to update all the LMAs, which has a >> considerable operational cost. Instead, if we leave the MN to make the >> choice, there are easy and well specified mechanisms that allow the >> provisioning of policies in the MN and for the MN to make such decision = and >> communicate it to the network, so that the network can >> >> As for extensions to Gx, I am not stating that in theory one could exten= d >> Gx. However, at present such solution does not exists, and without it, I= do >> not see how the draft is applicable to 3GPP that is at present the only >> potential customer identified (I guess I did not see any other identifie= d?) >> >> >> Even assuming that Gx could be modified, the issue of the per-access >> network granularity remains. Even if the LMA has the right policies in >> place, the LMA has no way of knowing exactly what access network of a >> specific access technology (e.g. which SSID for WLAN0 the MN is connecti= ng >> to. >> >> I cannot agree with your assumption below that if the MN connects to an >> SSID it is because the operator is OK with routing traffic on that SSID,= and >> that we should just "trust the software on the MN". There are two aspect= s to >> consider: >> 1) whether it is OK for certain traffic to be routed at all over a certa= in >> access access network of a specific access technology >> 2) how different traffic should be routed over different access networks >> of different access technologies >> >> Regarding these two points, the issue is whether the operator wants to >> allow traffic e.g. over a certain SSID or not. So, in that case, it is >> obvious as you say that if the MN has connected to an SSID configured by= the >> operator in the MN, then traffic could be allowed over that SSID. Howeve= r, >> we need to consider that 3GPP allows the decision of which WLAN the MN c= an >> connect to based on user preferences. This means that my MN can e.g. con= nect >> to my home WLAN (which is not controlled necessarily by the operator and >> whose SSID the operator does not know) or to a coffee shop WLAN, even if= the >> device does not have those SSID configured. Those are typical examples o= f >> untrusted WLAN access networks. Therefore, in such cases, just because t= he >> MN has connected to a WLAN SSID, does not mean that the operator wants t= o >> route certain traffic over that SSID just because the policy says "route >> traffic X over WLAN". >> >> That brings us to a solution that, if applied to 3GPP, provides less >> functionality than what is available and has been specified today, so ba= ck >> to my point above. >> >> Unfortunately, there is no solution I am aware of that allows the WLAN >> network to indicate to the MAG/LMA the specific SSID (and as you say, th= ere >> is no easy solution for that). Due to this and the points above about po= licy >> provisioning, it means that the applicability of this solution to a real >> case like 3GPP depends on the feasibility of extending policy mechanisms= in >> 3GPP, and the ability to have a solution where the WLAN network provides= the >> SSID information to the MAG/LMA. Moreover, the provisioning of such SSID= is >> not in the scope of IETF, but not even of 3GPP (since the interface betw= een >> the WLAN AP and the ePDG is not defined), thus I wonder how this could b= e >> defined at all (I am afraid of asking what magic should happen here). So= , >> now we have two big dependencies. >> >> In general, I am also wondering if there is a customer that has asked us >> to define this solution. I am not aware of any but I may have missed tha= t. >> >> Cheers, >> Stefano >> >> On Wed, Feb 2, 2011 at 10:44 AM, Rajeev Koodli wrote= : >> >> Hi Stefano, >> >> You make two interesting points: First, the defined solution should be >> useful for 3GPP deployments. Second, if it=92s not defined *today* in 3G= PP, >> it=92s not useful. >> >> I tend to agree with you on the first =96 3GPP is a big potential custom= er. >> I cannot agree with your second point. >> >> There are multiple ways I could envision policy on the LMA. Locally >> configured policy is one (which we use today in deployments) that does n= ot >> need Gx interaction. Gx extensions can be proposed in the future. I hope= you >> are not suggesting that these are not feasible choices. >> >> For the MN (IETF term for UE) to even connect to the MAG via WLAN today, >> you need an IPsec termination point (ePDG). If the operator pre-configur= es >> the list of SSIDs or there is some out-of-band mechanism to inform the M= N >> which SSID is =93white-listed=94, then I expect the MN to decide when to= connect >> to the ePDG and hence the MAG. At this point, the MN is already on the W= LAN >> the operator cares about I presume. >> There is no easy way for the network (LMA, MAG) to know what SSID the MN >> is connected to =96 the network has to either trust the software on the = MN or >> the WLAN infrastructure has to provide the SSID information to the netwo= rk. >> >> -Rajeev >> >> >> >> On 2/2/11 9:56 AM, "stefano faccin" > http://sfaccinstd@gmail.com> > wrote: >> Hello rajeev, >> the use of PCRF is an interesting suggestion. However, unfortunately, PC= RF >> does not contain any policies or information that will tell the LMA what= are >> the policies to be used for decisions of IP flow mobility. This is not p= art >> of current PCC functionality, and there is no work ongoing or planned to >> extend PCC in such way. Therefore, the applicability of the solution in = this >> draft would hinge on hypotetical future solutions and not on a current >> solution for the open issues, which brings us back to my point that we a= re >> defining a solution with open issues for which there is not a single >> realistic solution out there, thus making this draft not applicable to a >> real scenario. >> >> I am not thinking of the UE connecting to more than one WLAN at the same >> time, but the UE being able to connect to different WLANs (one at a time= ) >> because the UE is e.g. provisioned with a list of SSIDs or the UE discov= ers >> a hotspot somewhere. I am talking about the scenario where the UE is cap= able >> to connect to WLAN, but the operator has different policies wrt which WL= AN >> the UE should use or not. >> >> If you have followed the work in 3GPP, it is clear that operators have >> interest in applying policies not only at RAT level, but also at access >> network level (please see how ANDSF was defined and why). I guess we can= all >> agree that an operator deploying PMIP-based mobility may be interested i= n >> having policies that allow traffic on the WLAN the operator owns or that >> belongs to a roaming partner, while not allowing traffic on WLAN of othe= r >> operators for which it might need to pay an extra fee or where e.g. no Q= oS >> can be guaranteed. That means that the entity deciding whether traffic n= eeds >> to be routed on WLAN or not cannot just consider "WLAN is available", bu= t >> "WLAN SSIDx is available", so that the decision can be based on the oper= ator >> preferences as to which WLAN certain traffic needs to be routed on. >> >> If the draft allows decisions to be made only at the RAT level, then we >> have an issue because we are defining a solution that should be applicab= le >> to 3GPP but does not meet the deployment scenarios of interest. In other >> words, if we want to make this solution applicable e.g. to 3GPP, we need= to >> be able to provide the same functionality available today in 3GPP with o= ther >> solution in order to satisfy the use cases supported by 3GPP, and not st= ep >> backwards in terms of what can be supported. >> >> Cheers, >> >> Stefano >> >> On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli > http://rkoodli@cisco.com> > wrote: >> >> Hi Stefano, >> >> Thanks for your input. >> >> I expect the LMA interacting with PCRF for policy rules specific to the >> subscriber for different RAT types. >> You are right that the LMA does not know the SSID the mobile is connecte= d >> to. It=92s not clear if the MAG can get that from the MN either without >> additional signaling. However, the LMA knows that the MN is connected to >> WLAN; so it can apply the policy at the RAT type level. Are you thinking= of >> the MN connecting to more than one WLAN network (and each of those >> connections coming back to the LMA)? If so, please explain the scenario. >> >> Regards, >> >> -Rajeev >> >> >> >> >> On 2/1/11 6:39 PM, "stefano faccin" > http://sfaccinstd@gmail.com> > wrote: >> Raj, >> thanks for the email. >> >> I need to apologize in advance if my questions have already been answere= d >> before (though I cannot find a conclusive answer anywhere). >> >> I think that a protocol that is developed in NETEXT (or other groups) >> should have at least a potential realistic scenario for applicability. >> >> In terms of applicability, though it is not part of the protocol >> definition per se, unless there are solutions in place for either the ho= st >> to indicate to the network where the flows should be routed or for the L= MA >> to receive somehow from somewhere some policies, the solution cannot rea= lly >> provide flow mobility since there is no way to decide which flows are ro= uted >> where. If we are thinking about a host-based solution, I have not yet se= en a >> solution as to how the host can indicate to the MAG and ultimately to th= e >> MAG which flows should be routed on each access. If we are relying on >> modifications of layer 2 protocols, aren't we defining a solution that w= orks >> only with some technologies (since for other access technologies it is >> rather unrealistic to modify L2 for IP flow mobility purposes)? If we ar= e >> thinking of an LMA-based solution, can we hear of at least one example o= f a >> real-life scenario where the LMA would receive such policies, and how su= ch >> delivery would happen? Also, should there be a solution to have policies= in >> the LMA, how does the LMA actually decide to route flows on one access o= r >> the other? E.g., if some flows need to be routed on certain WLAN network= s, >> but shall not be routed on other WLAN networks, how does the LMA know wh= ich >> specific WLAN network the host is connected to? Perhaps I missed the abi= lity >> for the MAG to know e.g. the WLAN SSID and provide it to the LMA, in whi= ch >> case I would appreciate if somebody could highlight to me where that is >> defined. >> >> I think that, though not integral to the protocol specification, >> understanding what framework the protocol would/needs to fit in is rathe= r >> important. >> >> Cheers, >> Stefano >> >> >> On Tue, Feb 1, 2011 at 3:47 PM, > http://Basavaraj.Patil@nokia.com> > >> wrote: >> >> Hello, >> >> We have discussed the flow mobility solutions for Proxy MIP6 previously = at >> IETFs 78 and 79. >> This is a consensus call for adopting this I-D: >> draft-bernardos-netext-pmipv6-flowmob-02 >> as the working group document. >> I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt >> >> The consensus call will expire on Feb 15th, 2011. Please indicate your >> support or concerns in adopting this I-D as the WG baseline document on >> the mailing list. >> >> Please note that this I-D will serve as the baseline in the WG and will = be >> developed further based on input and feedback from WG members. >> >> -Basavaraj >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> >> >> >> >> > > > -- > Stefano M. Faccin > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > May the Force be with you > --=20 Stefano M. Faccin =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D May the Force be with you --0016364ede48f039fb049b51d2f2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sorry, I forgot to reply to the whole list.
Cheers,
Stefano

<= div class=3D"gmail_quote">On Wed, Feb 2, 2011 at 11:29 AM, stefano faccin <= span dir=3D"ltr"><sfaccinstd@gma= il.com> wrote:
Hi Rajeev,
in = current solution the policy is in sync, since it is the ANDSF (the network = counterpart of the MN for the policy) that configures it in the MN. That do= es not mean that the LMA has such policy.

Cheers,
Stefano


On Wed, Feb 2, 2011 at 11:46 AM, Rajeev Koodli &l= t;rkoodli@cisco.com<= /a>> wrote:

Hi Gerardo,

  • my point is that someone/something is configu= ring the policy on the MN which needs to be in sync with the MN=92s partner= , i.e., the network. If this is not the case, please let me know.
  • The last I heard, PMIP6 is applicable on the= eHRPD (trusted non-3GPP network). Also, 33.402 does not specify whether a = particular type of access network (such as WLAN) is considered trusted or u= ntrusted (although a majority of the WLAN access could be considered untrus= ted today).
<= span style=3D"font-size: 11pt;">
-Rajeev
Hi Rajee= v,
=A0
A couple of considerations on this:
=A0
- =A0=A0=A0=A0=A0=A0=A0=A0This draft assumes there is consistency in the ru= les. This is a new requirement for the system architecture where this solut= ion will be applied. There is no this requirement for other solutions alrea= dy adopted by IETF and 3GPP. In my view this seems a fairly important issue= .

- =A0=A0=A0=A0=A0=A0=A0=A0The routing decisions based on WLAN SSID are diff= erent from trusted/untrusted. Note also that PMIPv6 cannot be used in trust= ed networks so it is not clear at all what you are referring to.

=A0
Gerardo
=A0

From: netext-bounces@ietf= .org [mail= to:netext-bounces@ietf.org] On Behalf Of Rajeev Koodli
Sent: Wednesday, February 02, 2011 11:28 AM
To: stefano faccin
Cc: netext@ietf= .org; Ba= savaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-n= etext-pmipv6-flowmob as WG doc

Stefano,

Regardless of how the policy is configured on the LMA, there is a consisten= cy of the rules which needs to be ensured regardless. Whatever the entity (= OMA-DM?!) is that configures the policy has to ensure such a consistency.
We can debate about how policy interaction works, but that=92s another topi= c. I would note that there are choices here (modulo respective pros and con= s).

I didn=92t suggest that an operator should just trust the software on a MN,= although I suspect some device vendors might argue for their robustness (s= urprise?).

I would frame the WLAN access problem as whether the access is considered t= rusted or not. Accordingly, you apply the policy.

-Rajeev


On 2/2/11 10:50 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:
Raj,
thanks for the reply.

If the LMA has statically configured policies, how do we ensure that the MN= has the same policies? That would mean implicitly assuming that the polici= es provisioned to the MN by the ANDSF "always" match what has bee= n set in the LMA, which I think it is unrealistic because the policies chan= ge over time, and every time you need to update all the LMAs, which has a c= onsiderable operational cost. Instead, if we leave the MN to make the choic= e, there are easy and well specified mechanisms that allow the provisioning= of policies in the MN and for the MN to make such decision and communicate= it to the network, so that the network can

As for extensions to Gx, I am not stating that in theory one could extend G= x. However, at present such solution does not exists, and without it, I do = not see how the draft is applicable to 3GPP that is at present the only pot= ential customer identified (I guess I did not see any other identified?) = =A0

Even assuming that Gx could be modified, the issue of the per-access networ= k granularity remains. Even if the LMA has the right policies in place, the= LMA has no way of knowing exactly what access network of a specific access= technology (e.g. which SSID for WLAN0 the MN is connecting to.

I cannot agree with your assumption below that if the MN connects to an SSI= D it is because the operator is OK with routing traffic on that SSID, and t= hat we should just "trust the software on the MN". There are two = aspects to consider:
1) whether it is OK for certain traffic to be routed at all over a certain = access access network of a specific access technology
2) how different traffic should be routed over different access networks of= different access technologies

Regarding these two points, the issue is whether the operator wants to allo= w traffic e.g. over a certain SSID or not. So, in that case, it is obvious = as you say that if the MN has connected to an SSID configured by the operat= or in the MN, then traffic could be allowed over that SSID. However, we nee= d to consider that 3GPP allows the decision of which WLAN the MN can connec= t to based on user preferences. This means that my MN can e.g. connect to m= y home WLAN (which is not controlled necessarily by the operator and whose = SSID the operator does not know) or to a coffee shop WLAN, even if the devi= ce does not have those SSID configured. Those are typical examples of untru= sted WLAN access networks. Therefore, in such cases, just because the MN ha= s connected to a WLAN SSID, does not mean that the operator wants to route = certain traffic over that SSID just because the policy says "route tra= ffic X over WLAN".

That brings us to a solution that, if applied to 3GPP, provides less functi= onality than what is available and has been specified today, so back to my = point above.

Unfortunately, there is no solution I am aware of that allows the WLAN netw= ork to indicate to the MAG/LMA the specific SSID (and as you say, there is = no easy solution for that). Due to this and the points above about policy p= rovisioning, it means that the applicability of this solution to a real cas= e like 3GPP depends on the feasibility of extending policy mechanisms in 3G= PP, and the ability to have a solution where the WLAN network provides the = SSID information to the MAG/LMA. Moreover, the provisioning of such SSID is= not in the scope of IETF, but not even of 3GPP (since the interface betwee= n the WLAN AP and the ePDG is not defined), thus I wonder how this could be= defined at all (I am afraid of asking what magic should happen here). So, = now we have two big dependencies.

In general, I am also wondering if there is a customer that has asked us to= define this solution. I am not aware of any but I may have missed that.
Cheers,
Stefano

On Wed, Feb 2, 2011 at 10:44 AM, Rajeev Koodli <rkoodli@cisco.com> wrote:

Hi Stefano,

You make two interesting points: First, the defined solution should be usef= ul for 3GPP deployments. Second, if it=92s not defined today in 3GPP= , it=92s not useful.

I tend to agree with you on the first =96 3GPP is a big potential customer.=
I cannot agree with your second point.

There are multiple ways I could envision policy on the LMA. Locally configu= red policy is one (which we use today in deployments) that does not need Gx= interaction. Gx extensions can be proposed in the future. I hope you are n= ot suggesting that these are not feasible choices.

For the MN (IETF term for UE) to even connect to the MAG via WLAN today, yo= u need an IPsec termination point (ePDG). If the operator pre-configures th= e list of SSIDs or there is some out-of-band mechanism to inform the MN whi= ch SSID is =93white-listed=94, then I expect the MN to decide when to conne= ct to the ePDG and hence the MAG. At this point, the MN is already on the W= LAN the operator cares about I presume.
There is no easy way for the network (LMA, MAG) to know what SSID the MN is= connected to =96 the network has to either trust the software on the MN or= the WLAN infrastructure has to provide the SSID information to the network= .

-Rajeev



On 2/2/11 9:56 AM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com> > wrote:
Hello rajeev,
the use of PCRF is an interesting suggestion. However, unfortunately, PCRF = does not contain any policies or information that will tell the LMA what ar= e the policies to be used for decisions of IP flow mobility. This is not pa= rt of current PCC functionality, and there is no work ongoing or planned to= extend PCC in such way. Therefore, the applicability of the solution in th= is draft would hinge on hypotetical future solutions and not on a current s= olution for the open issues, which brings us back to my point that we are d= efining a solution with open issues for which there is not a single realist= ic solution out there, thus making this draft not applicable to a real scen= ario.

I am not thinking of the UE connecting to more than one WLAN at the same ti= me, but the UE being able to connect to different WLANs (one at a time) bec= ause the UE is e.g. provisioned with a list of SSIDs or the UE discovers a = hotspot somewhere. I am talking about the scenario where the UE is capable = to connect to WLAN, but the operator has different policies wrt which WLAN = the UE should use or not.

If you have followed the work in 3GPP, it is clear that operators have inte= rest in applying policies not only at RAT level, but also at access network= level (please see how ANDSF was defined and why). I guess we can all agree= that an operator deploying PMIP-based mobility may be interested in having= policies that allow traffic on the WLAN the operator owns or that belongs = to a roaming partner, while not allowing traffic on WLAN of other operators= for which it might need to pay an extra fee or where e.g. no QoS can be gu= aranteed. That means that the entity deciding whether traffic needs to be r= outed on WLAN or not cannot just consider "WLAN is available", bu= t "WLAN SSIDx is available", so that the decision can be based on= the operator preferences as to which WLAN certain traffic needs to be rout= ed on.

If the draft allows decisions to be made only at the RAT level, then we hav= e an issue because we are defining a solution that should be applicable to = 3GPP but does not meet the deployment scenarios of interest. In other words= , if we want to make this solution applicable e.g. to 3GPP, we need to be a= ble to provide the same functionality available today in 3GPP with other so= lution in order to satisfy the use cases supported by 3GPP, and not step ba= ckwards in terms of what can be supported.

Cheers,

Stefano

On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli <rkoodli@cisco.com <http://rkoodli@cisco.com> > w= rote:

Hi Stefano,

Thanks for your input.

I expect the LMA interacting with PCRF for policy rules specific to the sub= scriber for different RAT types.
You are right that the LMA does not know the SSID the mobile is connected t= o. It=92s not clear if the MAG can get that from the MN either without addi= tional signaling. However, the LMA knows that the MN is connected to WLAN; = so it can apply the policy at the RAT type level. Are you thinking of the M= N connecting to more than one WLAN network (and each of those connections c= oming back to the LMA)? If so, please explain the scenario.

Regards,

-Rajeev




On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com> =A0<http= ://sfaccinstd@gmail.com> > wrote:
Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicat= e to the network where the flows should be routed or for the LMA to receive= somehow from somewhere some policies, the solution cannot really provide f= low mobility since there is no way to decide which flows are routed where. = If we are thinking about a host-based solution, I have not yet seen a solut= ion as to how the host can indicate to the MAG and ultimately to the MAG wh= ich flows should be routed on each access. If we are relying on modificatio= ns of layer 2 protocols, aren't we defining a solution that works only = with some technologies (since for other access technologies it is rather un= realistic to modify L2 for IP flow mobility purposes)? If we are thinking o= f an LMA-based solution, can we hear of at least one example of a real-life= scenario where the LMA would receive such policies, and how such delivery = would happen? Also, should there be a solution to have policies in the LMA,= how does the LMA actually decide to route flows on one access or the other= ? E.g., if some flows need to be routed on certain WLAN networks, but shall= not be routed on other WLAN networks, how does the LMA know which specific= WLAN network the host is connected to? Perhaps I missed the ability for th= e MAG to know e.g. the WLAN SSID and provide it to the LMA, in which case I= would appreciate if somebody could highlight to me where that is defined.<= br>
I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important. =

Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM, =A0<Basavaraj.Patil@nokia.com <http://Basavaraj.Patil@nok= ia.com> =A0<http://Basavaraj.Patil@nokia.com> > wrote:

Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= br> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-p= mipv6-flowmob-02.txt

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= br> developed further based on input and feedback from WG members.

-Basavaraj

_______________________________________________
netext mailing list
netext@ietf.org &l= t;http://netext@ietf.o= rg> =A0<http= ://netext@ietf.org>
= https://www.ietf.org/mailman/listinfo/netext
=A0
=A0




--
Stefano M. Faccin
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
May the Force be with you



--
Stefano M. = Faccin
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
May the= Force be with you
--0016364ede48f039fb049b51d2f2-- From rkoodli@cisco.com Wed Feb 2 11:41:27 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CA663A6C41 for ; Wed, 2 Feb 2011 11:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.523 X-Spam-Level: X-Spam-Status: No, score=-109.523 tagged_above=-999 required=5 tests=[AWL=-0.321, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IqdMQ-FuLyy for ; Wed, 2 Feb 2011 11:41:07 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 22D713A6C0B for ; Wed, 2 Feb 2011 11:41:07 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApUCAFdCSU2tJXG+/2dsb2JhbACCRZN2QIYHAYczZ3OgcJsnhVMEhHiGaYMwgwA Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rtp-iport-2.cisco.com with ESMTP; 02 Feb 2011 19:44:25 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p12JiP4k028125; Wed, 2 Feb 2011 19:44:25 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Feb 2011 13:44:25 -0600 Received: from 10.21.147.70 ([10.21.147.70]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Wed, 2 Feb 2011 19:44:25 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Wed, 02 Feb 2011 12:02:49 -0800 From: Rajeev Koodli To: stefano faccin , "Giaretta, Gerardo" Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvDFCqAzrwyfezAJUGTSY3WDkftqA== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3379492969_52112023" X-OriginalArrivalTime: 02 Feb 2011 19:44:25.0596 (UTC) FILETIME=[98D223C0:01CBC311] Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 19:41:27 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3379492969_52112023 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable We might be speaking of related but slightly different things here. I am referring to how the traffic is managed at the LMA, which needs to kno= w how to route traffic over which interface. I am calling this =B3policy=B2. If the LMA has no idea about this (because it i= s not specified yet in 3GPP), we need to specify it. I agree that selecting a particular SSID does not imply =B3safety=B2 - I mentioned the issue of reliably knowing which WLAN network the MN is attached to. What solutions do exist today? What you describe below about an operator deploying its own AP but not owning the interconnection defaults to one of the two cases again =AD its either considered trusted or not. I do agree that the distinction between the operator=B9s own (trusted) WLAN and the operator=B9s roaming partner (trusted) WLAN is useful; I just don=B9t know how you would determine this based on the (un)reliability of SSID. -Rajeev On 2/2/11 11:28 AM, "stefano faccin" wrote: > Rajeev, >=20 > I am not sure what you refer to when you talk about consistency of the > policies. In solutions currently adopted, the policies are managed by a > network entity (ANDSF) that has no relationship with the LMA, and provide= d to > the MN, thus the ANDSF can easily ensure that the MN has the correct poli= cies. > There is no need for further consistency since no other entity needs to k= now > or use such policies. As Gerardo says, requiring such consistency is a > considerable change to the system and a requirement that has not been > discussed before. I would actually consider this an open issue with the > current draft. >=20 > I think robustness or trusting the software here has no relevance. What i= s > relevant is the fact that just because a MN has selected a specific WLAN = SSID, > it does not mean that the LMA can safely assume that certain traffic can = be > carried above that specific WLAN just because (1) it is WLAN and (2) the > operator has configured the preferred SSIDs in the MN. As I said, the use= r can > select other SSIDs, as in current specified solutions. >=20 > Whether WLAN is trusted or not is another matter orthogonal to this > discussion. An operator may deploy WLAN APs that it owns but, due to e.g.= the > fact that the same operator does not control the interconnection between = the > AP and its own core network (as it will happen often), the operator decid= es to > consider that access untrusted and therefore require the use of an ePDG. > Therefore, just because the MN uses one of the SSIDs configured by the > operator as preferred, does not mean that the access is considered truste= d. >=20 > Cheers, > Stefano=20 >=20 > On Wed, Feb 2, 2011 at 11:16 AM, Giaretta, Gerardo > wrote: >> Hi Rajeev, >> =A0 >> A couple of considerations on this: >> =A0 >> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 This draft assumes there is consistency in the rules. This is= a >> new requirement for the system architecture where this solution will be >> applied. There is no this requirement for other solutions already adopte= d by >> IETF and 3GPP. In my view this seems a fairly important issue. >>=20 >> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 The routing decisions based on WLAN SSID are different from >> trusted/untrusted. Note also that PMIPv6 cannot be used in trusted netwo= rks >> so it is not clear at all what you are referring to. >>=20 >> =A0 >> Gerardo=20 >> =A0 >>=20 >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf= Of >> Rajeev Koodli >> Sent: Wednesday, February 02, 2011 11:28 AM >> To: stefano faccin >> Cc: netext@ietf.org; Basavaraj.Patil@nokia.com >> Subject: Re: [netext] Consensus call to adopt I-D: >> draft-bernardos-netext-pmipv6-flowmob as WG doc >>=20 >> =A0 >>=20 >> Stefano, >>=20 >> Regardless of how the policy is configured on the LMA, there is a consis= tency >> of the rules which needs to be ensured regardless. Whatever the entity >> (OMA-DM?!) is that configures the policy has to ensure such a consistenc= y. >>=20 >> We can debate about how policy interaction works, but that=B9s another top= ic. I >> would note that there are choices here (modulo respective pros and cons)= . >>=20 >> I didn=B9t suggest that an operator should just trust the software on a MN= , >> although I suspect some device vendors might argue for their robustness >> (surprise?).=20 >>=20 >> I would frame the WLAN access problem as whether the access is considere= d >> trusted or not. Accordingly, you apply the policy. >>=20 >> -Rajeev >>=20 >>=20 >> On 2/2/11 10:50 AM, "stefano faccin" > > wrote: >> Raj, >> thanks for the reply. >>=20 >> If the LMA has statically configured policies, how do we ensure that the= MN >> has the same policies? That would mean implicitly assuming that the poli= cies >> provisioned to the MN by the ANDSF "always" match what has been set in t= he >> LMA, which I think it is unrealistic because the policies change over ti= me, >> and every time you need to update all the LMAs, which has a considerable >> operational cost. Instead, if we leave the MN to make the choice, there = are >> easy and well specified mechanisms that allow the provisioning of polici= es in >> the MN and for the MN to make such decision and communicate it to the >> network, so that the network can >>=20 >> As for extensions to Gx, I am not stating that in theory one could exten= d Gx. >> However, at present such solution does not exists, and without it, I do = not >> see how the draft is applicable to 3GPP that is at present the only pote= ntial >> customer identified (I guess I did not see any other identified?)=A0 >>=20 >> Even assuming that Gx could be modified, the issue of the per-access net= work >> granularity remains. Even if the LMA has the right policies in place, th= e LMA >> has no way of knowing exactly what access network of a specific access >> technology (e.g. which SSID for WLAN0 the MN is connecting to. >>=20 >> I cannot agree with your assumption below that if the MN connects to an = SSID >> it is because the operator is OK with routing traffic on that SSID, and = that >> we should just "trust the software on the MN". There are two aspects to >> consider: >> 1) whether it is OK for certain traffic to be routed at all over a certa= in >> access access network of a specific access technology >> 2) how different traffic should be routed over different access networks= of >> different access technologies >>=20 >> Regarding these two points, the issue is whether the operator wants to a= llow >> traffic e.g. over a certain SSID or not. So, in that case, it is obvious= as >> you say that if the MN has connected to an SSID configured by the operat= or in >> the MN, then traffic could be allowed over that SSID. However, we need t= o >> consider that 3GPP allows the decision of which WLAN the MN can connect = to >> based on user preferences. This means that my MN can e.g. connect to my = home >> WLAN (which is not controlled necessarily by the operator and whose SSID= the >> operator does not know) or to a coffee shop WLAN, even if the device doe= s not >> have those SSID configured. Those are typical examples of untrusted WLAN >> access networks. Therefore, in such cases, just because the MN has conne= cted >> to a WLAN SSID, does not mean that the operator wants to route certain >> traffic over that SSID just because the policy says "route traffic X ove= r >> WLAN".=A0=20 >>=20 >> That brings us to a solution that, if applied to 3GPP, provides less >> functionality than what is available and has been specified today, so ba= ck to >> my point above. >>=20 >> Unfortunately, there is no solution I am aware of that allows the WLAN >> network to indicate to the MAG/LMA the specific SSID (and as you say, th= ere >> is no easy solution for that). Due to this and the points above about po= licy >> provisioning, it means that the applicability of this solution to a real= case >> like 3GPP depends on the feasibility of extending policy mechanisms in 3= GPP, >> and the ability to have a solution where the WLAN network provides the S= SID >> information to the MAG/LMA. Moreover, the provisioning of such SSID is n= ot in >> the scope of IETF, but not even of 3GPP (since the interface between the= WLAN >> AP and the ePDG is not defined), thus I wonder how this could be defined= at >> all (I am afraid of asking what magic should happen here). So, now we ha= ve >> two big dependencies. >>=20 >> In general, I am also wondering if there is a customer that has asked us= to >> define this solution. I am not aware of any but I may have missed that. >>=20 >> Cheers, >> Stefano >>=20 >> On Wed, Feb 2, 2011 at 10:44 AM, Rajeev Koodli > > wrote: >>=20 >> Hi Stefano, >>=20 >> You make two interesting points: First, the defined solution should be u= seful >> for 3GPP deployments. Second, if it=B9s not defined today in 3GPP, it=B9s no= t >> useful. >>=20 >> I tend to agree with you on the first =AD 3GPP is a big potential customer= . >> I cannot agree with your second point. >>=20 >> There are multiple ways I could envision policy on the LMA. Locally >> configured policy is one (which we use today in deployments) that does n= ot >> need Gx interaction. Gx extensions can be proposed in the future. I hope= you >> are not suggesting that these are not feasible choices. >>=20 >> For the MN (IETF term for UE) to even connect to the MAG via WLAN today,= you >> need an IPsec termination point (ePDG). If the operator pre-configures t= he >> list of SSIDs or there is some out-of-band mechanism to inform the MN wh= ich >> SSID is =B3white-listed=B2, then I expect the MN to decide when to connect t= o the >> ePDG and hence the MAG. At this point, the MN is already on the WLAN the >> operator cares about I presume. >> There is no easy way for the network (LMA, MAG) to know what SSID the MN= is >> connected to =AD the network has to either trust the software on the MN or= the >> WLAN infrastructure has to provide the SSID information to the network. >>=20 >> -Rajeev >>=20 >>=20 >>=20 >> On 2/2/11 9:56 AM, "stefano faccin" > > wrote: >> Hello rajeev, >> the use of PCRF is an interesting suggestion. However, unfortunately, PC= RF >> does not contain any policies or information that will tell the LMA what= are >> the policies to be used for decisions of IP flow mobility. This is not p= art >> of current PCC functionality, and there is no work ongoing or planned to >> extend PCC in such way. Therefore, the applicability of the solution in = this >> draft would hinge on hypotetical future solutions and not on a current >> solution for the open issues, which brings us back to my point that we a= re >> defining a solution with open issues for which there is not a single >> realistic solution out there, thus making this draft not applicable to a= real >> scenario. >>=20 >> I am not thinking of the UE connecting to more than one WLAN at the same >> time, but the UE being able to connect to different WLANs (one at a time= ) >> because the UE is e.g. provisioned with a list of SSIDs or the UE discov= ers a >> hotspot somewhere. I am talking about the scenario where the UE is capab= le to >> connect to WLAN, but the operator has different policies wrt which WLAN = the >> UE should use or not. >>=20 >> If you have followed the work in 3GPP, it is clear that operators have >> interest in applying policies not only at RAT level, but also at access >> network level (please see how ANDSF was defined and why). I guess we can= all >> agree that an operator deploying PMIP-based mobility may be interested i= n >> having policies that allow traffic on the WLAN the operator owns or that >> belongs to a roaming partner, while not allowing traffic on WLAN of othe= r >> operators for which it might need to pay an extra fee or where e.g. no Q= oS >> can be guaranteed. That means that the entity deciding whether traffic n= eeds >> to be routed on WLAN or not cannot just consider "WLAN is available", bu= t >> "WLAN SSIDx is available", so that the decision can be based on the oper= ator >> preferences as to which WLAN certain traffic needs to be routed on. >>=20 >> If the draft allows decisions to be made only at the RAT level, then we = have >> an issue because we are defining a solution that should be applicable to= 3GPP >> but does not meet the deployment scenarios of interest. In other words, = if we >> want to make this solution applicable e.g. to 3GPP, we need to be able t= o >> provide the same functionality available today in 3GPP with other soluti= on in >> order to satisfy the use cases supported by 3GPP, and not step backwards= in >> terms of what can be supported. >>=20 >> Cheers, >>=20 >> Stefano >>=20 >> On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli > > wrote: >>=20 >> Hi Stefano, >>=20 >> Thanks for your input. >>=20 >> I expect the LMA interacting with PCRF for policy rules specific to the >> subscriber for different RAT types. >> You are right that the LMA does not know the SSID the mobile is connecte= d to. >> It=B9s not clear if the MAG can get that from the MN either without additi= onal >> signaling. However, the LMA knows that the MN is connected to WLAN; so i= t can >> apply the policy at the RAT type level. Are you thinking of the MN conne= cting >> to more than one WLAN network (and each of those connections coming back= to >> the LMA)? If so, please explain the scenario. >>=20 >> Regards, >>=20 >> -Rajeev >>=20 >>=20 >>=20 >>=20 >> On 2/1/11 6:39 PM, "stefano faccin" > >> =A0 > wrote: >> Raj, >> thanks for the email. >>=20 >> I need to apologize in advance if my questions have already been answere= d >> before (though I cannot find a conclusive answer anywhere). >>=20 >> I think that a protocol that is developed in NETEXT (or other groups) sh= ould >> have at least a potential realistic scenario for applicability. >>=20 >> In terms of applicability, though it is not part of the protocol definit= ion >> per se, unless there are solutions in place for either the host to indic= ate >> to the network where the flows should be routed or for the LMA to receiv= e >> somehow from somewhere some policies, the solution cannot really provide= flow >> mobility since there is no way to decide which flows are routed where. I= f we >> are thinking about a host-based solution, I have not yet seen a solution= as >> to how the host can indicate to the MAG and ultimately to the MAG which = flows >> should be routed on each access. If we are relying on modifications of l= ayer >> 2 protocols, aren't we defining a solution that works only with some >> technologies (since for other access technologies it is rather unrealist= ic to >> modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-b= ased >> solution, can we hear of at least one example of a real-life scenario wh= ere >> the LMA would receive such policies, and how such delivery would happen? >> Also, should there be a solution to have policies in the LMA, how does t= he >> LMA actually decide to route flows on one access or the other? E.g., if = some >> flows need to be routed on certain WLAN networks, but shall not be route= d on >> other WLAN networks, how does the LMA know which specific WLAN network t= he >> host is connected to? Perhaps I missed the ability for the MAG to know e= .g. >> the WLAN SSID and provide it to the LMA, in which case I would appreciat= e if >> somebody could highlight to me where that is defined. >>=20 >> I think that, though not integral to the protocol specification, >> understanding what framework the protocol would/needs to fit in is rathe= r >> important.=20 >>=20 >> Cheers, >> Stefano >>=20 >>=20 >> On Tue, Feb 1, 2011 at 3:47 PM, =A0> >> =A0 > wrote: >>=20 >> Hello, >>=20 >> We have discussed the flow mobility solutions for Proxy MIP6 previously = at >> IETFs 78 and 79. >> This is a consensus call for adopting this I-D: >> draft-bernardos-netext-pmipv6-flowmob-02 >> as the working group document. >> I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt >>=20 >> The consensus call will expire on Feb 15th, 2011. Please indicate your >> support or concerns in adopting this I-D as the WG baseline document on >> the mailing list. >>=20 >> Please note that this I-D will serve as the baseline in the WG and will = be >> developed further based on input and feedback from WG members. >>=20 >> -Basavaraj >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> =A0 >> https://www.ietf.org/mailman/listinfo/netext >> =A0 >> =A0 >> =A0 >=20 >=20 --B_3379492969_52112023 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmi= pv6-flowmob as WG doc
We might be speaking of related but slightly different things here.
I am referring to how the traffic is managed at the LMA, which needs to kno= w how to route traffic over which interface.
I am calling this “policy”. If the LMA has no idea about this (= because it is not specified yet in 3GPP), we need to specify it.

I agree that selecting a particular SSID does not imply “safety”= ; - I mentioned the issue of reliably knowing which WLAN network the MN is a= ttached to. What solutions do exist today?

What you describe below about an operator deploying its own AP but not owni= ng the interconnection defaults to one of the two cases again – its ei= ther considered trusted or not. I do agree that the distinction between the = operator’s own (trusted) WLAN and the operator’s roaming partner= (trusted) WLAN is useful; I just don’t know how you would determine t= his based on the (un)reliability of SSID.  

-Rajeev


On 2/2/11 11:28 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Rajeev,

I am not sure what you refer to when you talk about consistency of the poli= cies. In solutions currently adopted, the policies are managed by a network = entity (ANDSF) that has no relationship with the LMA, and provided to the MN= , thus the ANDSF can easily ensure that the MN has the correct policies. The= re is no need for further consistency since no other entity needs to know or= use such policies. As Gerardo says, requiring such consistency is a conside= rable change to the system and a requirement that has not been discussed bef= ore. I would actually consider this an open issue with the current draft.
I think robustness or trusting the software here has no relevance. What is = relevant is the fact that just because a MN has selected a specific WLAN SSI= D, it does not mean that the LMA can safely assume that certain traffic can = be carried above that specific WLAN just because (1) it is WLAN and (2) the = operator has configured the preferred SSIDs in the MN. As I said, the user c= an select other SSIDs, as in current specified solutions.

Whether WLAN is trusted or not is another matter orthogonal to this discuss= ion. An operator may deploy WLAN APs that it owns but, due to e.g. the fact = that the same operator does not control the interconnection between the AP a= nd its own core network (as it will happen often), the operator decides to c= onsider that access untrusted and therefore require the use of an ePDG. Ther= efore, just because the MN uses one of the SSIDs configured by the operator = as preferred, does not mean that the access is considered trusted.

Cheers,
Stefano

On Wed, Feb 2, 2011 at 11:16 AM, Giaretta, Gerardo <gerardog@qualcomm.com> wrote:
<= SPAN STYLE=3D'font-size:11pt'>Hi Rajeev,
=A0
A couple of considerations on this:
=A0
-=A0=A0=A0=A0=A0=A0=A0=A0=A0 This draft assumes there is consistency in the rules. This is a = new requirement for the system architecture where this solution will be appl= ied. There is no this requirement for other solutions already adopted by IET= F and 3GPP. In my view this seems a fairly important issue.

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 The routing decisions based on WLAN SSID are different from trus= ted/untrusted. Note also that PMIPv6 cannot be used in trusted networks so i= t is not clear at all what you are referring to.

=A0
Gerardo
=A0

From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Raj= eev Koodli
Sent: Wednesday, February 02, 2011 11:28 AM
To: stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-n= etext-pmipv6-flowmob as WG doc

=A0

Stefano,

Regardless of how the policy is configured on the LMA, there is a consisten= cy of the rules which needs to be ensured regardless. Whatever the entity (O= MA-DM?!) is that configures the policy has to ensure such a consistency.

We can debate about how policy interaction works, but that’s another = topic. I would note that there are choices here (modulo respective pros and = cons).

I didn’t suggest that an operator should just trust the software on a= MN, although I suspect some device vendors might argue for their robustness= (surprise?).

I would frame the WLAN access problem as whether the access is considered t= rusted or not. Accordingly, you apply the policy.

-Rajeev


On 2/2/11 10:50 AM, "stefano faccin" <sfaccinstd@gmail.com <ht= tp://sfaccinstd@gmail.com> > wrote:
Raj,
thanks for the reply.

If the LMA has statically configured policies, how do we ensure that the MN= has the same policies? That would mean implicitly assuming that the policie= s provisioned to the MN by the ANDSF "always" match what has been = set in the LMA, which I think it is unrealistic because the policies change = over time, and every time you need to update all the LMAs, which has a consi= derable operational cost. Instead, if we leave the MN to make the choice, th= ere are easy and well specified mechanisms that allow the provisioning of po= licies in the MN and for the MN to make such decision and communicate it to = the network, so that the network can

As for extensions to Gx, I am not stating that in theory one could extend G= x. However, at present such solution does not exists, and without it, I do n= ot see how the draft is applicable to 3GPP that is at present the only poten= tial customer identified (I guess I did not see any other identified?)=A0

Even assuming that Gx could be modified, the issue of the per-access networ= k granularity remains. Even if the LMA has the right policies in place, the = LMA has no way of knowing exactly what access network of a specific access t= echnology (e.g. which SSID for WLAN0 the MN is connecting to.

I cannot agree with your assumption below that if the MN connects to an SSI= D it is because the operator is OK with routing traffic on that SSID, and th= at we should just "trust the software on the MN". There are two as= pects to consider:
1) whether it is OK for certain traffic to be routed at all over a certain = access access network of a specific access technology
2) how different traffic should be routed over different access networks of= different access technologies

Regarding these two points, the issue is whether the operator wants to allo= w traffic e.g. over a certain SSID or not. So, in that case, it is obvious a= s you say that if the MN has connected to an SSID configured by the operator= in the MN, then traffic could be allowed over that SSID. However, we need t= o consider that 3GPP allows the decision of which WLAN the MN can connect to= based on user preferences. This means that my MN can e.g. connect to my hom= e WLAN (which is not controlled necessarily by the operator and whose SSID t= he operator does not know) or to a coffee shop WLAN, even if the device does= not have those SSID configured. Those are typical examples of untrusted WLA= N access networks. Therefore, in such cases, just because the MN has connect= ed to a WLAN SSID, does not mean that the operator wants to route certain tr= affic over that SSID just because the policy says "route traffic X over= WLAN".=A0

That brings us to a solution that, if applied to 3GPP, provides less functi= onality than what is available and has been specified today, so back to my p= oint above.

Unfortunately, there is no solution I am aware of that allows the WLAN netw= ork to indicate to the MAG/LMA the specific SSID (and as you say, there is n= o easy solution for that). Due to this and the points above about policy pro= visioning, it means that the applicability of this solution to a real case l= ike 3GPP depends on the feasibility of extending policy mechanisms in 3GPP, = and the ability to have a solution where the WLAN network provides the SSID = information to the MAG/LMA. Moreover, the provisioning of such SSID is not i= n the scope of IETF, but not even of 3GPP (since the interface between the W= LAN AP and the ePDG is not defined), thus I wonder how this could be defined= at all (I am afraid of asking what magic should happen here). So, now we ha= ve two big dependencies.

In general, I am also wondering if there is a customer that has asked us to= define this solution. I am not aware of any but I may have missed that.

Cheers,
Stefano

On Wed, Feb 2, 2011 at 10:44 AM, Rajeev Koodli <rkoodli@cisco.com <http://rkoo= dli@cisco.com> > wrote:

Hi Stefano,

You make two interesting points: First, the defined solution should be usef= ul for 3GPP deployments. Second, if it’s not defined today in 3= GPP, it’s not useful.

I tend to agree with you on the first – 3GPP is a big potential custo= mer.
I cannot agree with your second point.

There are multiple ways I could envision policy on the LMA. Locally configu= red policy is one (which we use today in deployments) that does not need Gx = interaction. Gx extensions can be proposed in the future. I hope you are not= suggesting that these are not feasible choices.

For the MN (IETF term for UE) to even connect to the MAG via WLAN today, yo= u need an IPsec termination point (ePDG). If the operator pre-configures the= list of SSIDs or there is some out-of-band mechanism to inform the MN which= SSID is “white-listed”, then I expect the MN to decide when to = connect to the ePDG and hence the MAG. At this point, the MN is already on t= he WLAN the operator cares about I presume.
There is no easy way for the network (LMA, MAG) to know what SSID the MN is= connected to – the network has to either trust the software on the MN= or the WLAN infrastructure has to provide the SSID information to the netwo= rk.

-Rajeev



On 2/2/11 9:56 AM, "stefano faccin" <sfaccinstd@gmail.com <htt= p://sfaccinstd@gmail.com>  <http://sfaccinstd@gmail.com> > wrote:
Hello rajeev,
the use of PCRF is an interesting suggestion. However, unfortunately, PCRF = does not contain any policies or information that will tell the LMA what are= the policies to be used for decisions of IP flow mobility. This is not part= of current PCC functionality, and there is no work ongoing or planned to ex= tend PCC in such way. Therefore, the applicability of the solution in this d= raft would hinge on hypotetical future solutions and not on a current soluti= on for the open issues, which brings us back to my point that we are definin= g a solution with open issues for which there is not a single realistic solu= tion out there, thus making this draft not applicable to a real scenario.
I am not thinking of the UE connecting to more than one WLAN at the same ti= me, but the UE being able to connect to different WLANs (one at a time) beca= use the UE is e.g. provisioned with a list of SSIDs or the UE discovers a ho= tspot somewhere. I am talking about the scenario where the UE is capable to = connect to WLAN, but the operator has different policies wrt which WLAN the = UE should use or not.

If you have followed the work in 3GPP, it is clear that operators have inte= rest in applying policies not only at RAT level, but also at access network = level (please see how ANDSF was defined and why). I guess we can all agree t= hat an operator deploying PMIP-based mobility may be interested in having po= licies that allow traffic on the WLAN the operator owns or that belongs to a= roaming partner, while not allowing traffic on WLAN of other operators for = which it might need to pay an extra fee or where e.g. no QoS can be guarante= ed. That means that the entity deciding whether traffic needs to be routed o= n WLAN or not cannot just consider "WLAN is available", but "= WLAN SSIDx is available", so that the decision can be based on the oper= ator preferences as to which WLAN certain traffic needs to be routed on.
If the draft allows decisions to be made only at the RAT level, then we hav= e an issue because we are defining a solution that should be applicable to 3= GPP but does not meet the deployment scenarios of interest. In other words, = if we want to make this solution applicable e.g. to 3GPP, we need to be able= to provide the same functionality available today in 3GPP with other soluti= on in order to satisfy the use cases supported by 3GPP, and not step backwar= ds in terms of what can be supported.

Cheers,

Stefano

On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli <rkoodli@cisco.com <http://rkood= li@cisco.com>  <http://rko= odli@cisco.com> > wrote:

Hi Stefano,

Thanks for your input.

I expect the LMA interacting with PCRF for policy rules specific to the sub= scriber for different RAT types.
You are right that the LMA does not know the SSID the mobile is connected t= o. It’s not clear if the MAG can get that from the MN either without a= dditional signaling. However, the LMA knows that the MN is connected to WLAN= ; so it can apply the policy at the RAT type level. Are you thinking of the = MN connecting to more than one WLAN network (and each of those connections c= oming back to the LMA)? If so, please explain the scenario.

Regards,

-Rajeev




On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <htt= p://sfaccinstd@gmail.com>  <http://sfaccinstd@gmail.com> =A0<http://sfaccinstd@gmail.com> > wrote:
Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicate= to the network where the flows should be routed or for the LMA to receive s= omehow from somewhere some policies, the solution cannot really provide flow= mobility since there is no way to decide which flows are routed where. If w= e are thinking about a host-based solution, I have not yet seen a solution a= s to how the host can indicate to the MAG and ultimately to the MAG which fl= ows should be routed on each access. If we are relying on modifications of l= ayer 2 protocols, aren't we defining a solution that works only with some te= chnologies (since for other access technologies it is rather unrealistic to = modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-based= solution, can we hear of at least one example of a real-life scenario where= the LMA would receive such policies, and how such delivery would happen? Al= so, should there be a solution to have policies in the LMA, how does the LMA= actually decide to route flows on one access or the other? E.g., if some fl= ows need to be routed on certain WLAN networks, but shall not be routed on o= ther WLAN networks, how does the LMA know which specific WLAN network the ho= st is connected to? Perhaps I missed the ability for the MAG to know e.g. th= e WLAN SSID and provide it to the LMA, in which case I would appreciate if s= omebody could highlight to me where that is defined.

I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important. <= BR>
Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM, =A0<Ba= savaraj.Patil@nokia.com <h= ttp://Basavaraj.Patil@nokia.com>  <http://Basavaraj.Patil@nokia.com> =A0<http://Basavaraj.Patil@nokia.com> > = wrote:

Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= BR> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt<= /a>

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= BR> developed further based on input and feedback from WG members.

-Basavaraj

_______________________________________________
netext mailing list
netext@ietf.org <http://netext@ietf.org>  <http://netext@ietf.org> =A0<h= ttp://netext@ietf.org>
https://www.ietf.org= /mailman/listinfo/netext
=A0
=A0
=A0
=

--B_3379492969_52112023-- From JuanCarlos.Zuniga@InterDigital.com Wed Feb 2 11:54:04 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96DA03A6D9A for ; Wed, 2 Feb 2011 11:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArFlQggjeqsm for ; Wed, 2 Feb 2011 11:53:41 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 5DE593A6D41 for ; Wed, 2 Feb 2011 11:53:40 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Feb 2011 14:57:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBC313.59E8605E" Date: Wed, 2 Feb 2011 14:56:58 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvDERj5nCirM3vGQpiguigBNDVvJwAAUtXw References: From: "Zuniga, Juan Carlos" To: "stefano faccin" , "Rajeev Koodli" , X-OriginalArrivalTime: 02 Feb 2011 19:57:00.0398 (UTC) FILETIME=[5AB7C8E0:01CBC313] Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 19:54:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC313.59E8605E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stefano, =20 As much as I agree with most of your points about the problem from the 3GPP architecture point of view, I think that there is more than one solution. =20 We are assuming of course that what we have is a scenario where both networks are in the same PMIP domain and IP flow mobility is then possible. You point out that there are no means to convey policies to the LMA or MAG. However, there are means to convey these policies to the MN as it is already defined in 3GPP for the client-based IP flow mobility case (i.e. ANDSF). Hence, one different solution could be to let the MN apply the policy by moving the flow and make the MAG and LMA "react" to the IP flow change assuming that the flow change was made according to the policy being applied at the mobile. =20 I would see this scenario equivalent to the one specified in 3GPP from the point of view of node's responsibilities, don't you think? =20 Jc =20 =20 From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of stefano faccin Sent: February 2, 2011 2:41 PM To: Rajeev Koodli; netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc =20 Sorry, I forgot to reply to the whole list.=20 Cheers, Stefano On Wed, Feb 2, 2011 at 11:29 AM, stefano faccin wrote: Hi Rajeev, in current solution the policy is in sync, since it is the ANDSF (the network counterpart of the MN for the policy) that configures it in the MN. That does not mean that the LMA has such policy.=20 Cheers, Stefano =20 On Wed, Feb 2, 2011 at 11:46 AM, Rajeev Koodli wrote: Hi Gerardo, * my point is that someone/something is configuring the policy on the MN which needs to be in sync with the MN's partner, i.e., the network. If this is not the case, please let me know.=20 * The last I heard, PMIP6 is applicable on the eHRPD (trusted non-3GPP network). Also, 33.402 does not specify whether a particular type of access network (such as WLAN) is considered trusted or untrusted (although a majority of the WLAN access could be considered untrusted today).=20 -Rajeev On 2/2/11 11:16 AM, "Giaretta, Gerardo" wrote: Hi Rajeev, =20 A couple of considerations on this: =20 - This draft assumes there is consistency in the rules. This is a new requirement for the system architecture where this solution will be applied. There is no this requirement for other solutions already adopted by IETF and 3GPP. In my view this seems a fairly important issue. =09 - The routing decisions based on WLAN SSID are different from trusted/untrusted. Note also that PMIPv6 cannot be used in trusted networks so it is not clear at all what you are referring to. =09 =20 Gerardo=20 =20 =09 From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Rajeev Koodli Sent: Wednesday, February 02, 2011 11:28 AM To: stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc =09 =09 Stefano, =09 Regardless of how the policy is configured on the LMA, there is a consistency of the rules which needs to be ensured regardless. Whatever the entity (OMA-DM?!) is that configures the policy has to ensure such a consistency. =09 We can debate about how policy interaction works, but that's another topic. I would note that there are choices here (modulo respective pros and cons). =09 I didn't suggest that an operator should just trust the software on a MN, although I suspect some device vendors might argue for their robustness (surprise?).=20 =09 I would frame the WLAN access problem as whether the access is considered trusted or not. Accordingly, you apply the policy. =09 -Rajeev =09 =09 On 2/2/11 10:50 AM, "stefano faccin" wrote: Raj, thanks for the reply. =09 If the LMA has statically configured policies, how do we ensure that the MN has the same policies? That would mean implicitly assuming that the policies provisioned to the MN by the ANDSF "always" match what has been set in the LMA, which I think it is unrealistic because the policies change over time, and every time you need to update all the LMAs, which has a considerable operational cost. Instead, if we leave the MN to make the choice, there are easy and well specified mechanisms that allow the provisioning of policies in the MN and for the MN to make such decision and communicate it to the network, so that the network can =09 As for extensions to Gx, I am not stating that in theory one could extend Gx. However, at present such solution does not exists, and without it, I do not see how the draft is applicable to 3GPP that is at present the only potential customer identified (I guess I did not see any other identified?) =20 =09 Even assuming that Gx could be modified, the issue of the per-access network granularity remains. Even if the LMA has the right policies in place, the LMA has no way of knowing exactly what access network of a specific access technology (e.g. which SSID for WLAN0 the MN is connecting to.=20 =09 I cannot agree with your assumption below that if the MN connects to an SSID it is because the operator is OK with routing traffic on that SSID, and that we should just "trust the software on the MN". There are two aspects to consider: 1) whether it is OK for certain traffic to be routed at all over a certain access access network of a specific access technology 2) how different traffic should be routed over different access networks of different access technologies =09 Regarding these two points, the issue is whether the operator wants to allow traffic e.g. over a certain SSID or not. So, in that case, it is obvious as you say that if the MN has connected to an SSID configured by the operator in the MN, then traffic could be allowed over that SSID. However, we need to consider that 3GPP allows the decision of which WLAN the MN can connect to based on user preferences. This means that my MN can e.g. connect to my home WLAN (which is not controlled necessarily by the operator and whose SSID the operator does not know) or to a coffee shop WLAN, even if the device does not have those SSID configured. Those are typical examples of untrusted WLAN access networks. Therefore, in such cases, just because the MN has connected to a WLAN SSID, does not mean that the operator wants to route certain traffic over that SSID just because the policy says "route traffic X over WLAN".=20 =09 That brings us to a solution that, if applied to 3GPP, provides less functionality than what is available and has been specified today, so back to my point above. =09 Unfortunately, there is no solution I am aware of that allows the WLAN network to indicate to the MAG/LMA the specific SSID (and as you say, there is no easy solution for that). Due to this and the points above about policy provisioning, it means that the applicability of this solution to a real case like 3GPP depends on the feasibility of extending policy mechanisms in 3GPP, and the ability to have a solution where the WLAN network provides the SSID information to the MAG/LMA. Moreover, the provisioning of such SSID is not in the scope of IETF, but not even of 3GPP (since the interface between the WLAN AP and the ePDG is not defined), thus I wonder how this could be defined at all (I am afraid of asking what magic should happen here). So, now we have two big dependencies.=20 =09 In general, I am also wondering if there is a customer that has asked us to define this solution. I am not aware of any but I may have missed that. =09 Cheers, Stefano =09 On Wed, Feb 2, 2011 at 10:44 AM, Rajeev Koodli wrote: =09 Hi Stefano, =09 You make two interesting points: First, the defined solution should be useful for 3GPP deployments. Second, if it's not defined today in 3GPP, it's not useful. =09 I tend to agree with you on the first - 3GPP is a big potential customer.=20 I cannot agree with your second point. =09 There are multiple ways I could envision policy on the LMA. Locally configured policy is one (which we use today in deployments) that does not need Gx interaction. Gx extensions can be proposed in the future. I hope you are not suggesting that these are not feasible choices. =09 For the MN (IETF term for UE) to even connect to the MAG via WLAN today, you need an IPsec termination point (ePDG). If the operator pre-configures the list of SSIDs or there is some out-of-band mechanism to inform the MN which SSID is "white-listed", then I expect the MN to decide when to connect to the ePDG and hence the MAG. At this point, the MN is already on the WLAN the operator cares about I presume.=20 There is no easy way for the network (LMA, MAG) to know what SSID the MN is connected to - the network has to either trust the software on the MN or the WLAN infrastructure has to provide the SSID information to the network.=20 =09 -Rajeev =09 =09 =09 On 2/2/11 9:56 AM, "stefano faccin" > wrote: Hello rajeev, the use of PCRF is an interesting suggestion. However, unfortunately, PCRF does not contain any policies or information that will tell the LMA what are the policies to be used for decisions of IP flow mobility. This is not part of current PCC functionality, and there is no work ongoing or planned to extend PCC in such way. Therefore, the applicability of the solution in this draft would hinge on hypotetical future solutions and not on a current solution for the open issues, which brings us back to my point that we are defining a solution with open issues for which there is not a single realistic solution out there, thus making this draft not applicable to a real scenario. =09 I am not thinking of the UE connecting to more than one WLAN at the same time, but the UE being able to connect to different WLANs (one at a time) because the UE is e.g. provisioned with a list of SSIDs or the UE discovers a hotspot somewhere. I am talking about the scenario where the UE is capable to connect to WLAN, but the operator has different policies wrt which WLAN the UE should use or not. =09 If you have followed the work in 3GPP, it is clear that operators have interest in applying policies not only at RAT level, but also at access network level (please see how ANDSF was defined and why). I guess we can all agree that an operator deploying PMIP-based mobility may be interested in having policies that allow traffic on the WLAN the operator owns or that belongs to a roaming partner, while not allowing traffic on WLAN of other operators for which it might need to pay an extra fee or where e.g. no QoS can be guaranteed. That means that the entity deciding whether traffic needs to be routed on WLAN or not cannot just consider "WLAN is available", but "WLAN SSIDx is available", so that the decision can be based on the operator preferences as to which WLAN certain traffic needs to be routed on.=20 =09 If the draft allows decisions to be made only at the RAT level, then we have an issue because we are defining a solution that should be applicable to 3GPP but does not meet the deployment scenarios of interest. In other words, if we want to make this solution applicable e.g. to 3GPP, we need to be able to provide the same functionality available today in 3GPP with other solution in order to satisfy the use cases supported by 3GPP, and not step backwards in terms of what can be supported. =09 Cheers, =09 Stefano =09 On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli > wrote: =09 Hi Stefano, =09 Thanks for your input. =09 I expect the LMA interacting with PCRF for policy rules specific to the subscriber for different RAT types. You are right that the LMA does not know the SSID the mobile is connected to. It's not clear if the MAG can get that from the MN either without additional signaling. However, the LMA knows that the MN is connected to WLAN; so it can apply the policy at the RAT type level. Are you thinking of the MN connecting to more than one WLAN network (and each of those connections coming back to the LMA)? If so, please explain the scenario. =09 Regards, =09 -Rajeev =09 =09 =09 =09 On 2/1/11 6:39 PM, "stefano faccin" > wrote: Raj, thanks for the email. =09 I need to apologize in advance if my questions have already been answered before (though I cannot find a conclusive answer anywhere). =09 I think that a protocol that is developed in NETEXT (or other groups) should have at least a potential realistic scenario for applicability. =09 In terms of applicability, though it is not part of the protocol definition per se, unless there are solutions in place for either the host to indicate to the network where the flows should be routed or for the LMA to receive somehow from somewhere some policies, the solution cannot really provide flow mobility since there is no way to decide which flows are routed where. If we are thinking about a host-based solution, I have not yet seen a solution as to how the host can indicate to the MAG and ultimately to the MAG which flows should be routed on each access. If we are relying on modifications of layer 2 protocols, aren't we defining a solution that works only with some technologies (since for other access technologies it is rather unrealistic to modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-based solution, can we hear of at least one example of a real-life scenario where the LMA would receive such policies, and how such delivery would happen? Also, should there be a solution to have policies in the LMA, how does the LMA actually decide to route flows on one access or the other? E.g., if some flows need to be routed on certain WLAN networks, but shall not be routed on other WLAN networks, how does the LMA know which specific WLAN network the host is connected to? Perhaps I missed the ability for the MAG to know e.g. the WLAN SSID and provide it to the LMA, in which case I would appreciate if somebody could highlight to me where that is defined. =09 I think that, though not integral to the protocol specification, understanding what framework the protocol would/needs to fit in is rather important.=20 =09 Cheers, Stefano =09 =09 On Tue, Feb 1, 2011 at 3:47 PM, > wrote: =09 Hello, =09 We have discussed the flow mobility solutions for Proxy MIP6 previously at IETFs 78 and 79. This is a consensus call for adopting this I-D: draft-bernardos-netext-pmipv6-flowmob-02 as the working group document. I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt =09 The consensus call will expire on Feb 15th, 2011. Please indicate your support or concerns in adopting this I-D as the WG baseline document on the mailing list. =09 Please note that this I-D will serve as the baseline in the WG and will be developed further based on input and feedback from WG members. =09 -Basavaraj =09 _______________________________________________ netext mailing list netext@ietf.org =20 https://www.ietf.org/mailman/listinfo/netext =09 =20 =20 --=20 Stefano M. Faccin =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D May the Force be with you --=20 Stefano M. Faccin =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D May the Force be with you ------_=_NextPart_001_01CBC313.59E8605E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stefano,

 

As much as I agree with most of your points about the = problem from the 3GPP architecture point of view, I think that there is more = than one solution.

 

We are assuming of course that what we have is a scenario = where both networks are in the same PMIP domain and IP flow mobility is then = possible. You point out that there are no means to convey policies to the LMA or = MAG. However, there are means to convey these policies to the MN as it is already = defined in 3GPP for the client-based IP flow mobility case (i.e. ANDSF). Hence, one = different solution could be to let the MN apply the policy by moving the flow and = make the MAG and LMA “react” to the IP flow change assuming that the = flow change was made according to the policy being applied at the = mobile.

 

I would see this scenario equivalent to the one specified = in 3GPP from the point of view of node’s responsibilities, = don’t you think?

 

Jc

 

 

From:= netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of = stefano faccin
Sent: February 2, 2011 2:41 PM
To: Rajeev Koodli; netext@ietf.org
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

 

Sorry, I forgot to = reply to the whole list.
Cheers,
Stefano

On Wed, Feb 2, 2011 at 11:29 AM, stefano faccin = <sfaccinstd@gmail.com> = wrote:

Hi Rajeev,
in current solution the policy is in sync, since it is the ANDSF (the = network counterpart of the MN for the policy) that configures it in the MN. That = does not mean that the LMA has such policy.

Cheers,
Stefano

 

On Wed, Feb 2, 2011 at 11:46 AM, Rajeev Koodli = <rkoodli@cisco.com> wrote:


Hi Gerardo,

  • my point is that someone/something is configuring the policy on the MN = which needs to be in sync with the MN’s partner, i.e., the network. = If this is not the case, please let me know.
  • The last I heard, PMIP6 is applicable on the eHRPD (trusted non-3GPP = network). Also, 33.402 does not specify whether a particular type of access = network (such as WLAN) is considered trusted or untrusted (although a = majority of the WLAN access could be considered untrusted today). =


-Rajeev




On 2/2/11 11:16 AM, "Giaretta, Gerardo" <gerardog@qualcomm.com> wrote:

Hi Rajeev,
 
A couple of considerations on this:
 
-         This draft assumes = there is consistency in the rules. This is a new requirement for the system = architecture where this solution will be applied. There is no this requirement for = other solutions already adopted by IETF and 3GPP. In my view this seems a = fairly important issue.

-         The routing decisions = based on WLAN SSID are different from trusted/untrusted. Note also that PMIPv6 = cannot be used in trusted networks so it is not clear at all what you are = referring to.

 
Gerardo
 

From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Rajeev Koodli
Sent: Wednesday, February 02, 2011 11:28 AM
To: stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc


Stefano,

Regardless of how the policy is configured on the LMA, there is a = consistency of the rules which needs to be ensured regardless. Whatever the entity (OMA-DM?!) is that configures the policy has to ensure such a = consistency.

We can debate about how policy interaction works, but that’s = another topic. I would note that there are choices here (modulo respective pros = and cons).

I didn’t suggest that an operator should just trust the software = on a MN, although I suspect some device vendors might argue for their robustness (surprise?).

I would frame the WLAN access problem as whether the access is = considered trusted or not. Accordingly, you apply the policy.

-Rajeev


On 2/2/11 10:50 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:
Raj,
thanks for the reply.

If the LMA has statically configured policies, how do we ensure that the = MN has the same policies? That would mean implicitly assuming that the policies provisioned to the MN by the ANDSF "always" match what has = been set in the LMA, which I think it is unrealistic because the policies change = over time, and every time you need to update all the LMAs, which has a = considerable operational cost. Instead, if we leave the MN to make the choice, there = are easy and well specified mechanisms that allow the provisioning of = policies in the MN and for the MN to make such decision and communicate it to the = network, so that the network can

As for extensions to Gx, I am not stating that in theory one could = extend Gx. However, at present such solution does not exists, and without it, I do = not see how the draft is applicable to 3GPP that is at present the only = potential customer identified (I guess I did not see any other identified?) =  

Even assuming that Gx could be modified, the issue of the per-access = network granularity remains. Even if the LMA has the right policies in place, = the LMA has no way of knowing exactly what access network of a specific access technology (e.g. which SSID for WLAN0 the MN is connecting to.

I cannot agree with your assumption below that if the MN connects to an = SSID it is because the operator is OK with routing traffic on that SSID, and = that we should just "trust the software on the MN". There are two = aspects to consider:
1) whether it is OK for certain traffic to be routed at all over a = certain access access network of a specific access technology
2) how different traffic should be routed over different access networks = of different access technologies

Regarding these two points, the issue is whether the operator wants to = allow traffic e.g. over a certain SSID or not. So, in that case, it is obvious = as you say that if the MN has connected to an SSID configured by the operator = in the MN, then traffic could be allowed over that SSID. However, we need to = consider that 3GPP allows the decision of which WLAN the MN can connect to based = on user preferences. This means that my MN can e.g. connect to my home WLAN = (which is not controlled necessarily by the operator and whose SSID the operator = does not know) or to a coffee shop WLAN, even if the device does not have those = SSID configured. Those are typical examples of untrusted WLAN access = networks. Therefore, in such cases, just because the MN has connected to a WLAN = SSID, does not mean that the operator wants to route certain traffic over that = SSID just because the policy says "route traffic X over WLAN".

That brings us to a solution that, if applied to 3GPP, provides less functionality than what is available and has been specified today, so = back to my point above.

Unfortunately, there is no solution I am aware of that allows the WLAN = network to indicate to the MAG/LMA the specific SSID (and as you say, there is = no easy solution for that). Due to this and the points above about policy = provisioning, it means that the applicability of this solution to a real case like = 3GPP depends on the feasibility of extending policy mechanisms in 3GPP, and = the ability to have a solution where the WLAN network provides the SSID = information to the MAG/LMA. Moreover, the provisioning of such SSID is not in the = scope of IETF, but not even of 3GPP (since the interface between the WLAN AP and = the ePDG is not defined), thus I wonder how this could be defined at all (I = am afraid of asking what magic should happen here). So, now we have two big dependencies.

In general, I am also wondering if there is a customer that has asked us = to define this solution. I am not aware of any but I may have missed = that.

Cheers,
Stefano

On Wed, Feb 2, 2011 at 10:44 AM, Rajeev Koodli <rkoodli@cisco.com> wrote:

Hi Stefano,

You make two interesting points: First, the defined solution should be = useful for 3GPP deployments. Second, if it’s not defined today in = 3GPP, it’s not useful.

I tend to agree with you on the first – 3GPP is a big potential = customer.
I cannot agree with your second point.

There are multiple ways I could envision policy on the LMA. Locally = configured policy is one (which we use today in deployments) that does not need Gx interaction. Gx extensions can be proposed in the future. I hope you are = not suggesting that these are not feasible choices.

For the MN (IETF term for UE) to even connect to the MAG via WLAN today, = you need an IPsec termination point (ePDG). If the operator pre-configures = the list of SSIDs or there is some out-of-band mechanism to inform the MN which = SSID is “white-listed”, then I expect the MN to decide when to = connect to the ePDG and hence the MAG. At this point, the MN is already on the WLAN = the operator cares about I presume.
There is no easy way for the network (LMA, MAG) to know what SSID the MN = is connected to – the network has to either trust the software on the = MN or the WLAN infrastructure has to provide the SSID information to the = network.

-Rajeev



On 2/2/11 9:56 AM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com> > wrote:
Hello rajeev,
the use of PCRF is an interesting suggestion. However, unfortunately, = PCRF does not contain any policies or information that will tell the LMA what are = the policies to be used for decisions of IP flow mobility. This is not part = of current PCC functionality, and there is no work ongoing or planned to = extend PCC in such way. Therefore, the applicability of the solution in this = draft would hinge on hypotetical future solutions and not on a current = solution for the open issues, which brings us back to my point that we are defining a solution with open issues for which there is not a single realistic = solution out there, thus making this draft not applicable to a real scenario.

I am not thinking of the UE connecting to more than one WLAN at the same = time, but the UE being able to connect to different WLANs (one at a time) = because the UE is e.g. provisioned with a list of SSIDs or the UE discovers a = hotspot somewhere. I am talking about the scenario where the UE is capable to = connect to WLAN, but the operator has different policies wrt which WLAN the UE = should use or not.

If you have followed the work in 3GPP, it is clear that operators have = interest in applying policies not only at RAT level, but also at access network = level (please see how ANDSF was defined and why). I guess we can all agree = that an operator deploying PMIP-based mobility may be interested in having = policies that allow traffic on the WLAN the operator owns or that belongs to a = roaming partner, while not allowing traffic on WLAN of other operators for which = it might need to pay an extra fee or where e.g. no QoS can be guaranteed. = That means that the entity deciding whether traffic needs to be routed on WLAN or = not cannot just consider "WLAN is available", but "WLAN SSIDx = is available", so that the decision can be based on the operator = preferences as to which WLAN certain traffic needs to be routed on.

If the draft allows decisions to be made only at the RAT level, then we = have an issue because we are defining a solution that should be applicable to = 3GPP but does not meet the deployment scenarios of interest. In other words, if = we want to make this solution applicable e.g. to 3GPP, we need to be able to = provide the same functionality available today in 3GPP with other solution in = order to satisfy the use cases supported by 3GPP, and not step backwards in terms = of what can be supported.

Cheers,

Stefano

On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli <rkoodli@cisco.com <http://rkoodli@cisco.com> > wrote:

Hi Stefano,

Thanks for your input.

I expect the LMA interacting with PCRF for policy rules specific to the subscriber for different RAT types.
You are right that the LMA does not know the SSID the mobile is = connected to. It’s not clear if the MAG can get that from the MN either without additional signaling. However, the LMA knows that the MN is connected to = WLAN; so it can apply the policy at the RAT type level. Are you thinking of = the MN connecting to more than one WLAN network (and each of those connections = coming back to the LMA)? If so, please explain the scenario.

Regards,

-Rajeev




On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com>  <http://sfaccinstd@gmail.com> > wrote:
Raj,
thanks for the email.

I need to apologize in advance if my questions have already been = answered before (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) = should have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol = definition per se, unless there are solutions in place for either the host to indicate = to the network where the flows should be routed or for the LMA to receive = somehow from somewhere some policies, the solution cannot really provide flow = mobility since there is no way to decide which flows are routed where. If we are = thinking about a host-based solution, I have not yet seen a solution as to how = the host can indicate to the MAG and ultimately to the MAG which flows should be = routed on each access. If we are relying on modifications of layer 2 protocols, = aren't we defining a solution that works only with some technologies (since for = other access technologies it is rather unrealistic to modify L2 for IP flow = mobility purposes)? If we are thinking of an LMA-based solution, can we hear of = at least one example of a real-life scenario where the LMA would receive such = policies, and how such delivery would happen? Also, should there be a solution to = have policies in the LMA, how does the LMA actually decide to route flows on = one access or the other? E.g., if some flows need to be routed on certain = WLAN networks, but shall not be routed on other WLAN networks, how does the = LMA know which specific WLAN network the host is connected to? Perhaps I missed = the ability for the MAG to know e.g. the WLAN SSID and provide it to the = LMA, in which case I would appreciate if somebody could highlight to me where = that is defined.

I think that, though not integral to the protocol specification, = understanding what framework the protocol would/needs to fit in is rather important. =

Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM,  <Basavaraj.Patil@nokia.com <http://Basavaraj.Patil@nokia.com>  <http://Basavaraj.Patil@nokia.com> > wrote:

Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously = at
IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-fl= owmob-02.txt

The consensus call will expire on Feb 15th, 2011. Please indicate = your
support or concerns in adopting this I-D as the WG baseline document = on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will = be
developed further based on input and feedback from WG members.

-Basavaraj

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

 
 



--
Stefano M. Faccin
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
May the Force be with you




--
Stefano M. Faccin
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
May the Force be with you

------_=_NextPart_001_01CBC313.59E8605E-- From JuanCarlos.Zuniga@InterDigital.com Wed Feb 2 12:34:41 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 548243A6D07 for ; Wed, 2 Feb 2011 12:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dU5umO9foBwn for ; Wed, 2 Feb 2011 12:34:20 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 73FEA3A6D37 for ; Wed, 2 Feb 2011 12:34:19 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Feb 2011 15:37:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBC319.07E5D694" Date: Wed, 2 Feb 2011 15:37:35 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvDFVPVczX/KsxRTuCnkOspHpy6BwAASGJw References: From: "Zuniga, Juan Carlos" To: "stefano faccin" , X-OriginalArrivalTime: 02 Feb 2011 20:37:39.0364 (UTC) FILETIME=[08747640:01CBC319] Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 20:34:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC319.07E5D694 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stefano, =20 Thanks for the response (you forgot to copy the list again ;).=20 =20 What I had in mind was what they call Basic solution in the document, in which the same set of prefixes are assigned to different interfaces (or MAGs). In this case the MN can decide (based on policies) to change the flow and send packets over a new interface. The MAG would forward the packet with no problem and upon receiving this packet the LMA would implicitly know that the MN has performed a flow movement (again, based on policies). At this point the LMA would just need to change its routing table accordingly and start sending packets for this flow over the new interface (similar rule to the one already specified for the mobile). =20 I see this as a lightweight solution to the problem you pointed out that could easily be added to the document. =20 Jc =20 =20 =20 From: stefano faccin [mailto:sfaccinstd@gmail.com]=20 Sent: February 2, 2011 3:11 PM To: Zuniga, Juan Carlos Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc =20 Hi JC, As you say in 3GPP for the MN-based model this has been solved. However, if we want to apply a similar solution, we go back to the argument that it would require the MN to be able to communicate the decisions to the MAG/LMA but, as we discussed previously, we don't have a solution for that. This means that applying this protocol with a model similar to the one currently specified in IETF and 3GPP requires the definition of a solution that does not yet exist (at Layer 3 or at Layer 2). I am concerned about developing only some pieces of a solution. Alternatively, as you say the MAG reacts. However, it is not clear to me that the current draft describes how that happens. Cheers, Stefano On Wed, Feb 2, 2011 at 11:56 AM, Zuniga, Juan Carlos wrote: Stefano, =20 As much as I agree with most of your points about the problem from the 3GPP architecture point of view, I think that there is more than one solution. =20 We are assuming of course that what we have is a scenario where both networks are in the same PMIP domain and IP flow mobility is then possible. You point out that there are no means to convey policies to the LMA or MAG. However, there are means to convey these policies to the MN as it is already defined in 3GPP for the client-based IP flow mobility case (i.e. ANDSF). Hence, one different solution could be to let the MN apply the policy by moving the flow and make the MAG and LMA "react" to the IP flow change assuming that the flow change was made according to the policy being applied at the mobile. =20 I would see this scenario equivalent to the one specified in 3GPP from the point of view of node's responsibilities, don't you think? =20 Jc =20 =20 From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of stefano faccin Sent: February 2, 2011 2:41 PM To: Rajeev Koodli; netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc =20 Sorry, I forgot to reply to the whole list.=20 Cheers, Stefano On Wed, Feb 2, 2011 at 11:29 AM, stefano faccin wrote: Hi Rajeev, in current solution the policy is in sync, since it is the ANDSF (the network counterpart of the MN for the policy) that configures it in the MN. That does not mean that the LMA has such policy.=20 Cheers, Stefano =20 On Wed, Feb 2, 2011 at 11:46 AM, Rajeev Koodli wrote: Hi Gerardo, * my point is that someone/something is configuring the policy on the MN which needs to be in sync with the MN's partner, i.e., the network. If this is not the case, please let me know.=20 * The last I heard, PMIP6 is applicable on the eHRPD (trusted non-3GPP network). Also, 33.402 does not specify whether a particular type of access network (such as WLAN) is considered trusted or untrusted (although a majority of the WLAN access could be considered untrusted today).=20 -Rajeev On 2/2/11 11:16 AM, "Giaretta, Gerardo" wrote: Hi Rajeev, =20 A couple of considerations on this: =20 - This draft assumes there is consistency in the rules. This is a new requirement for the system architecture where this solution will be applied. There is no this requirement for other solutions already adopted by IETF and 3GPP. In my view this seems a fairly important issue. =09 - The routing decisions based on WLAN SSID are different from trusted/untrusted. Note also that PMIPv6 cannot be used in trusted networks so it is not clear at all what you are referring to. =09 =20 Gerardo=20 =20 =09 From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Rajeev Koodli Sent: Wednesday, February 02, 2011 11:28 AM To: stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc =09 =09 Stefano, =09 Regardless of how the policy is configured on the LMA, there is a consistency of the rules which needs to be ensured regardless. Whatever the entity (OMA-DM?!) is that configures the policy has to ensure such a consistency. =09 We can debate about how policy interaction works, but that's another topic. I would note that there are choices here (modulo respective pros and cons). =09 I didn't suggest that an operator should just trust the software on a MN, although I suspect some device vendors might argue for their robustness (surprise?).=20 =09 I would frame the WLAN access problem as whether the access is considered trusted or not. Accordingly, you apply the policy. =09 -Rajeev =09 =09 On 2/2/11 10:50 AM, "stefano faccin" wrote: Raj, thanks for the reply. =09 If the LMA has statically configured policies, how do we ensure that the MN has the same policies? That would mean implicitly assuming that the policies provisioned to the MN by the ANDSF "always" match what has been set in the LMA, which I think it is unrealistic because the policies change over time, and every time you need to update all the LMAs, which has a considerable operational cost. Instead, if we leave the MN to make the choice, there are easy and well specified mechanisms that allow the provisioning of policies in the MN and for the MN to make such decision and communicate it to the network, so that the network can =09 As for extensions to Gx, I am not stating that in theory one could extend Gx. However, at present such solution does not exists, and without it, I do not see how the draft is applicable to 3GPP that is at present the only potential customer identified (I guess I did not see any other identified?) =20 =09 Even assuming that Gx could be modified, the issue of the per-access network granularity remains. Even if the LMA has the right policies in place, the LMA has no way of knowing exactly what access network of a specific access technology (e.g. which SSID for WLAN0 the MN is connecting to.=20 =09 I cannot agree with your assumption below that if the MN connects to an SSID it is because the operator is OK with routing traffic on that SSID, and that we should just "trust the software on the MN". There are two aspects to consider: 1) whether it is OK for certain traffic to be routed at all over a certain access access network of a specific access technology 2) how different traffic should be routed over different access networks of different access technologies =09 Regarding these two points, the issue is whether the operator wants to allow traffic e.g. over a certain SSID or not. So, in that case, it is obvious as you say that if the MN has connected to an SSID configured by the operator in the MN, then traffic could be allowed over that SSID. However, we need to consider that 3GPP allows the decision of which WLAN the MN can connect to based on user preferences. This means that my MN can e.g. connect to my home WLAN (which is not controlled necessarily by the operator and whose SSID the operator does not know) or to a coffee shop WLAN, even if the device does not have those SSID configured. Those are typical examples of untrusted WLAN access networks. Therefore, in such cases, just because the MN has connected to a WLAN SSID, does not mean that the operator wants to route certain traffic over that SSID just because the policy says "route traffic X over WLAN".=20 =09 That brings us to a solution that, if applied to 3GPP, provides less functionality than what is available and has been specified today, so back to my point above. =09 Unfortunately, there is no solution I am aware of that allows the WLAN network to indicate to the MAG/LMA the specific SSID (and as you say, there is no easy solution for that). Due to this and the points above about policy provisioning, it means that the applicability of this solution to a real case like 3GPP depends on the feasibility of extending policy mechanisms in 3GPP, and the ability to have a solution where the WLAN network provides the SSID information to the MAG/LMA. Moreover, the provisioning of such SSID is not in the scope of IETF, but not even of 3GPP (since the interface between the WLAN AP and the ePDG is not defined), thus I wonder how this could be defined at all (I am afraid of asking what magic should happen here). So, now we have two big dependencies.=20 =09 In general, I am also wondering if there is a customer that has asked us to define this solution. I am not aware of any but I may have missed that. =09 Cheers, Stefano =09 On Wed, Feb 2, 2011 at 10:44 AM, Rajeev Koodli wrote: =09 Hi Stefano, =09 You make two interesting points: First, the defined solution should be useful for 3GPP deployments. Second, if it's not defined today in 3GPP, it's not useful. =09 I tend to agree with you on the first - 3GPP is a big potential customer.=20 I cannot agree with your second point. =09 There are multiple ways I could envision policy on the LMA. Locally configured policy is one (which we use today in deployments) that does not need Gx interaction. Gx extensions can be proposed in the future. I hope you are not suggesting that these are not feasible choices. =09 For the MN (IETF term for UE) to even connect to the MAG via WLAN today, you need an IPsec termination point (ePDG). If the operator pre-configures the list of SSIDs or there is some out-of-band mechanism to inform the MN which SSID is "white-listed", then I expect the MN to decide when to connect to the ePDG and hence the MAG. At this point, the MN is already on the WLAN the operator cares about I presume.=20 There is no easy way for the network (LMA, MAG) to know what SSID the MN is connected to - the network has to either trust the software on the MN or the WLAN infrastructure has to provide the SSID information to the network.=20 =09 -Rajeev =09 =09 =09 On 2/2/11 9:56 AM, "stefano faccin" > wrote: Hello rajeev, the use of PCRF is an interesting suggestion. However, unfortunately, PCRF does not contain any policies or information that will tell the LMA what are the policies to be used for decisions of IP flow mobility. This is not part of current PCC functionality, and there is no work ongoing or planned to extend PCC in such way. Therefore, the applicability of the solution in this draft would hinge on hypotetical future solutions and not on a current solution for the open issues, which brings us back to my point that we are defining a solution with open issues for which there is not a single realistic solution out there, thus making this draft not applicable to a real scenario. =09 I am not thinking of the UE connecting to more than one WLAN at the same time, but the UE being able to connect to different WLANs (one at a time) because the UE is e.g. provisioned with a list of SSIDs or the UE discovers a hotspot somewhere. I am talking about the scenario where the UE is capable to connect to WLAN, but the operator has different policies wrt which WLAN the UE should use or not. =09 If you have followed the work in 3GPP, it is clear that operators have interest in applying policies not only at RAT level, but also at access network level (please see how ANDSF was defined and why). I guess we can all agree that an operator deploying PMIP-based mobility may be interested in having policies that allow traffic on the WLAN the operator owns or that belongs to a roaming partner, while not allowing traffic on WLAN of other operators for which it might need to pay an extra fee or where e.g. no QoS can be guaranteed. That means that the entity deciding whether traffic needs to be routed on WLAN or not cannot just consider "WLAN is available", but "WLAN SSIDx is available", so that the decision can be based on the operator preferences as to which WLAN certain traffic needs to be routed on.=20 =09 If the draft allows decisions to be made only at the RAT level, then we have an issue because we are defining a solution that should be applicable to 3GPP but does not meet the deployment scenarios of interest. In other words, if we want to make this solution applicable e.g. to 3GPP, we need to be able to provide the same functionality available today in 3GPP with other solution in order to satisfy the use cases supported by 3GPP, and not step backwards in terms of what can be supported. =09 Cheers, =09 Stefano =09 On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli > wrote: =09 Hi Stefano, =09 Thanks for your input. =09 I expect the LMA interacting with PCRF for policy rules specific to the subscriber for different RAT types. You are right that the LMA does not know the SSID the mobile is connected to. It's not clear if the MAG can get that from the MN either without additional signaling. However, the LMA knows that the MN is connected to WLAN; so it can apply the policy at the RAT type level. Are you thinking of the MN connecting to more than one WLAN network (and each of those connections coming back to the LMA)? If so, please explain the scenario. =09 Regards, =09 -Rajeev =09 =09 =09 =09 On 2/1/11 6:39 PM, "stefano faccin" > wrote: Raj, thanks for the email. =09 I need to apologize in advance if my questions have already been answered before (though I cannot find a conclusive answer anywhere). =09 I think that a protocol that is developed in NETEXT (or other groups) should have at least a potential realistic scenario for applicability. =09 In terms of applicability, though it is not part of the protocol definition per se, unless there are solutions in place for either the host to indicate to the network where the flows should be routed or for the LMA to receive somehow from somewhere some policies, the solution cannot really provide flow mobility since there is no way to decide which flows are routed where. If we are thinking about a host-based solution, I have not yet seen a solution as to how the host can indicate to the MAG and ultimately to the MAG which flows should be routed on each access. If we are relying on modifications of layer 2 protocols, aren't we defining a solution that works only with some technologies (since for other access technologies it is rather unrealistic to modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-based solution, can we hear of at least one example of a real-life scenario where the LMA would receive such policies, and how such delivery would happen? Also, should there be a solution to have policies in the LMA, how does the LMA actually decide to route flows on one access or the other? E.g., if some flows need to be routed on certain WLAN networks, but shall not be routed on other WLAN networks, how does the LMA know which specific WLAN network the host is connected to? Perhaps I missed the ability for the MAG to know e.g. the WLAN SSID and provide it to the LMA, in which case I would appreciate if somebody could highlight to me where that is defined. =09 I think that, though not integral to the protocol specification, understanding what framework the protocol would/needs to fit in is rather important.=20 =09 Cheers, Stefano =09 =09 On Tue, Feb 1, 2011 at 3:47 PM, > wrote: =09 Hello, =09 We have discussed the flow mobility solutions for Proxy MIP6 previously at IETFs 78 and 79. This is a consensus call for adopting this I-D: draft-bernardos-netext-pmipv6-flowmob-02 as the working group document. I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt =09 The consensus call will expire on Feb 15th, 2011. Please indicate your support or concerns in adopting this I-D as the WG baseline document on the mailing list. =09 Please note that this I-D will serve as the baseline in the WG and will be developed further based on input and feedback from WG members. =09 -Basavaraj =09 _______________________________________________ netext mailing list netext@ietf.org =20 https://www.ietf.org/mailman/listinfo/netext =09 =20 =20 --=20 Stefano M. Faccin =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D May the Force be with you --=20 Stefano M. Faccin =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D May the Force be with you --=20 Stefano M. Faccin =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D May the Force be with you ------_=_NextPart_001_01CBC319.07E5D694 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Stefano,

 

Thanks for the response (you forgot to copy the list = again ;).

 

What I had in mind was what they call Basic solution in = the document, in which the same set of prefixes are assigned to different interfaces (or MAGs). In this case the MN can decide (based on policies) = to change the flow and send packets over a new interface. The MAG would forward = the packet with no problem and upon receiving this packet the LMA would = implicitly know that the MN has performed a flow movement (again, based on policies). At = this point the LMA would just need to change its routing table accordingly = and start sending packets for this flow over the new interface (similar rule to = the one already specified for the mobile).

 

I see this as a lightweight solution to the problem you = pointed out that could easily be added to the document.

 

Jc

 

 

 

From:= stefano = faccin [mailto:sfaccinstd@gmail.com]
Sent: February 2, 2011 3:11 PM
To: Zuniga, Juan Carlos
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

 

Hi JC,

As you say in 3GPP for the MN-based model this has been solved. However, = if we want to apply a similar solution, we go back to the argument that it = would require the MN to be able to communicate the decisions to the MAG/LMA = but, as we discussed previously, we don't have a solution for that. This means = that applying this protocol with a model similar to the one currently = specified in IETF and 3GPP requires the definition of a solution that does not yet = exist (at Layer 3 or at Layer 2). I am concerned about developing only some pieces = of a solution.

Alternatively, as you say the MAG reacts. However, it is not clear to me = that the current draft describes how that happens.

Cheers,
Stefano

On Wed, Feb 2, 2011 at 11:56 AM, Zuniga, Juan = Carlos <JuanCarlos.Zuniga@inte= rdigital.com> wrote:

Stefano,

 

As much as I agree with most of = your points about the problem from the 3GPP architecture point of view, I = think that there is more than one solution.

 

We are assuming of course that = what we have is a scenario where both networks are in the same PMIP domain and = IP flow mobility is then possible. You point out that there are no means to = convey policies to the LMA or MAG. However, there are means to convey these = policies to the MN as it is already defined in 3GPP for the client-based IP flow mobility case (i.e. ANDSF). Hence, one different solution could be to = let the MN apply the policy by moving the flow and make the MAG and LMA = “react” to the IP flow change assuming that the flow change was made according to the = policy being applied at the mobile.

 

I would see this scenario = equivalent to the one specified in 3GPP from the point of view of node’s = responsibilities, don’t you think?

 

Jc

 

 

From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of stefano faccin
Sent: February 2, 2011 2:41 PM
To: Rajeev Koodli; netext@ietf.org


Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

 <= /o:p>

Sorry, I forgot to reply to the whole list.
Cheers,
Stefano

On Wed, Feb 2, 2011 at 11:29 AM, stefano faccin <sfaccinstd@gmail.com> wrote:

Hi Rajeev,
in current solution the policy is in sync, since it is the ANDSF (the = network counterpart of the MN for the policy) that configures it in the MN. That = does not mean that the LMA has such policy.

Cheers,
Stefano

 <= /p>

On Wed, Feb 2, 2011 at 11:46 AM, Rajeev Koodli <rkoodli@cisco.com> wrote:


Hi Gerardo,

  • my point = is that someone/something is configuring the policy on the MN which needs = to be in sync with the MN’s partner, i.e., the network. If this is not = the case, please let me know.
  • The last = I heard, PMIP6 is applicable on the eHRPD (trusted non-3GPP network). Also, = 33.402 does not specify whether a particular type of access network (such = as WLAN) is considered trusted or untrusted (although a majority of = the WLAN access could be considered untrusted today). =


-Rajeev




On 2/2/11 11:16 AM, "Giaretta, Gerardo" <gerardog@qualcomm.com> wrote:

Hi Rajeev,
 
A couple of considerations on this:
 
-         This draft assumes = there is consistency in the rules. This is a new requirement for the system = architecture where this solution will be applied. There is no this requirement for = other solutions already adopted by IETF and 3GPP. In my view this seems a = fairly important issue.

-         The routing decisions = based on WLAN SSID are different from trusted/untrusted. Note also that PMIPv6 = cannot be used in trusted networks so it is not clear at all what you are = referring to.

 
Gerardo
 

From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Rajeev Koodli
Sent: Wednesday, February 02, 2011 11:28 AM
To: stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc


Stefano,

Regardless of how the policy is configured on the LMA, there is a = consistency of the rules which needs to be ensured regardless. Whatever the entity (OMA-DM?!) is that configures the policy has to ensure such a = consistency.

We can debate about how policy interaction works, but that’s = another topic. I would note that there are choices here (modulo respective pros and = cons).

I didn’t suggest that an operator should just trust the software = on a MN, although I suspect some device vendors might argue for their robustness (surprise?).

I would frame the WLAN access problem as whether the access is = considered trusted or not. Accordingly, you apply the policy.

-Rajeev


On 2/2/11 10:50 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:
Raj,
thanks for the reply.

If the LMA has statically configured policies, how do we ensure that the = MN has the same policies? That would mean implicitly assuming that the policies provisioned to the MN by the ANDSF "always" match what has = been set in the LMA, which I think it is unrealistic because the policies change = over time, and every time you need to update all the LMAs, which has a considerable operational cost. Instead, if we leave the MN to make the choice, there = are easy and well specified mechanisms that allow the provisioning of = policies in the MN and for the MN to make such decision and communicate it to the = network, so that the network can

As for extensions to Gx, I am not stating that in theory one could = extend Gx. However, at present such solution does not exists, and without it, I do = not see how the draft is applicable to 3GPP that is at present the only = potential customer identified (I guess I did not see any other identified?) =  

Even assuming that Gx could be modified, the issue of the per-access = network granularity remains. Even if the LMA has the right policies in place, = the LMA has no way of knowing exactly what access network of a specific access technology (e.g. which SSID for WLAN0 the MN is connecting to.

I cannot agree with your assumption below that if the MN connects to an = SSID it is because the operator is OK with routing traffic on that SSID, and = that we should just "trust the software on the MN". There are two = aspects to consider:
1) whether it is OK for certain traffic to be routed at all over a = certain access access network of a specific access technology
2) how different traffic should be routed over different access networks = of different access technologies

Regarding these two points, the issue is whether the operator wants to = allow traffic e.g. over a certain SSID or not. So, in that case, it is obvious = as you say that if the MN has connected to an SSID configured by the operator = in the MN, then traffic could be allowed over that SSID. However, we need to = consider that 3GPP allows the decision of which WLAN the MN can connect to based = on user preferences. This means that my MN can e.g. connect to my home WLAN = (which is not controlled necessarily by the operator and whose SSID the operator = does not know) or to a coffee shop WLAN, even if the device does not have those = SSID configured. Those are typical examples of untrusted WLAN access = networks. Therefore, in such cases, just because the MN has connected to a WLAN = SSID, does not mean that the operator wants to route certain traffic over that = SSID just because the policy says "route traffic X over WLAN".

That brings us to a solution that, if applied to 3GPP, provides less functionality than what is available and has been specified today, so = back to my point above.

Unfortunately, there is no solution I am aware of that allows the WLAN = network to indicate to the MAG/LMA the specific SSID (and as you say, there is = no easy solution for that). Due to this and the points above about policy = provisioning, it means that the applicability of this solution to a real case like = 3GPP depends on the feasibility of extending policy mechanisms in 3GPP, and = the ability to have a solution where the WLAN network provides the SSID = information to the MAG/LMA. Moreover, the provisioning of such SSID is not in the = scope of IETF, but not even of 3GPP (since the interface between the WLAN AP and = the ePDG is not defined), thus I wonder how this could be defined at all (I = am afraid of asking what magic should happen here). So, now we have two big dependencies.

In general, I am also wondering if there is a customer that has asked us = to define this solution. I am not aware of any but I may have missed = that.

Cheers,
Stefano

On Wed, Feb 2, 2011 at 10:44 AM, Rajeev Koodli <rkoodli@cisco.com> wrote:

Hi Stefano,

You make two interesting points: First, the defined solution should be = useful for 3GPP deployments. Second, if it’s not defined today in = 3GPP, it’s not useful.

I tend to agree with you on the first – 3GPP is a big potential = customer.
I cannot agree with your second point.

There are multiple ways I could envision policy on the LMA. Locally = configured policy is one (which we use today in deployments) that does not need Gx interaction. Gx extensions can be proposed in the future. I hope you are = not suggesting that these are not feasible choices.

For the MN (IETF term for UE) to even connect to the MAG via WLAN today, = you need an IPsec termination point (ePDG). If the operator pre-configures = the list of SSIDs or there is some out-of-band mechanism to inform the MN which = SSID is “white-listed”, then I expect the MN to decide when to = connect to the ePDG and hence the MAG. At this point, the MN is already on the WLAN the operator = cares about I presume.
There is no easy way for the network (LMA, MAG) to know what SSID the MN = is connected to – the network has to either trust the software on the = MN or the WLAN infrastructure has to provide the SSID information to the network. =

-Rajeev



On 2/2/11 9:56 AM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com> > wrote:
Hello rajeev,
the use of PCRF is an interesting suggestion. However, unfortunately, = PCRF does not contain any policies or information that will tell the LMA what are = the policies to be used for decisions of IP flow mobility. This is not part = of current PCC functionality, and there is no work ongoing or planned to = extend PCC in such way. Therefore, the applicability of the solution in this = draft would hinge on hypotetical future solutions and not on a current = solution for the open issues, which brings us back to my point that we are defining a solution with open issues for which there is not a single realistic = solution out there, thus making this draft not applicable to a real scenario.

I am not thinking of the UE connecting to more than one WLAN at the same = time, but the UE being able to connect to different WLANs (one at a time) = because the UE is e.g. provisioned with a list of SSIDs or the UE discovers a = hotspot somewhere. I am talking about the scenario where the UE is capable to = connect to WLAN, but the operator has different policies wrt which WLAN the UE = should use or not.

If you have followed the work in 3GPP, it is clear that operators have = interest in applying policies not only at RAT level, but also at access network = level (please see how ANDSF was defined and why). I guess we can all agree = that an operator deploying PMIP-based mobility may be interested in having = policies that allow traffic on the WLAN the operator owns or that belongs to a roaming partner, while not allowing traffic on WLAN of other operators for which = it might need to pay an extra fee or where e.g. no QoS can be guaranteed. = That means that the entity deciding whether traffic needs to be routed on = WLAN or not cannot just consider "WLAN is available", but "WLAN = SSIDx is available", so that the decision can be based on the operator = preferences as to which WLAN certain traffic needs to be routed on.

If the draft allows decisions to be made only at the RAT level, then we = have an issue because we are defining a solution that should be applicable to = 3GPP but does not meet the deployment scenarios of interest. In other words, if = we want to make this solution applicable e.g. to 3GPP, we need to be able to = provide the same functionality available today in 3GPP with other solution in = order to satisfy the use cases supported by 3GPP, and not step backwards in terms = of what can be supported.

Cheers,

Stefano

On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli <rkoodli@cisco.com <http://rkoodli@cisco.com> > wrote:

Hi Stefano,

Thanks for your input.

I expect the LMA interacting with PCRF for policy rules specific to the subscriber for different RAT types.
You are right that the LMA does not know the SSID the mobile is = connected to. It’s not clear if the MAG can get that from the MN either without = additional signaling. However, the LMA knows that the MN is connected to WLAN; so = it can apply the policy at the RAT type level. Are you thinking of the MN = connecting to more than one WLAN network (and each of those connections coming back = to the LMA)? If so, please explain the scenario.

Regards,

-Rajeev




On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com>  <http://sfaccinstd@gmail.com> > wrote:
Raj,
thanks for the email.

I need to apologize in advance if my questions have already been = answered before (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) = should have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol = definition per se, unless there are solutions in place for either the host to indicate = to the network where the flows should be routed or for the LMA to receive = somehow from somewhere some policies, the solution cannot really provide flow = mobility since there is no way to decide which flows are routed where. If we are = thinking about a host-based solution, I have not yet seen a solution as to how = the host can indicate to the MAG and ultimately to the MAG which flows should be = routed on each access. If we are relying on modifications of layer 2 protocols, = aren't we defining a solution that works only with some technologies (since for = other access technologies it is rather unrealistic to modify L2 for IP flow = mobility purposes)? If we are thinking of an LMA-based solution, can we hear of = at least one example of a real-life scenario where the LMA would receive such = policies, and how such delivery would happen? Also, should there be a solution to = have policies in the LMA, how does the LMA actually decide to route flows on = one access or the other? E.g., if some flows need to be routed on certain = WLAN networks, but shall not be routed on other WLAN networks, how does the = LMA know which specific WLAN network the host is connected to? Perhaps I missed = the ability for the MAG to know e.g. the WLAN SSID and provide it to the = LMA, in which case I would appreciate if somebody could highlight to me where = that is defined.

I think that, though not integral to the protocol specification, = understanding what framework the protocol would/needs to fit in is rather important. =

Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM,  <Basavaraj.Patil@nokia.com <http://Basavaraj.Patil@nokia.com>  <http://Basavaraj.Patil@nokia.com> > wrote:

Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously = at
IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-fl= owmob-02.txt

The consensus call will expire on Feb 15th, 2011. Please indicate = your
support or concerns in adopting this I-D as the WG baseline document = on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will = be
developed further based on input and feedback from WG members.

-Basavaraj

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

 
 



--
Stefano M. Faccin
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
May the Force be with you




--
Stefano M. Faccin
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
May the Force be with you




--
Stefano M. Faccin
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
May the Force be with you

------_=_NextPart_001_01CBC319.07E5D694-- From sfaccinstd@gmail.com Wed Feb 2 14:23:15 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 469023A6DDD for ; Wed, 2 Feb 2011 14:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.412 X-Spam-Level: X-Spam-Status: No, score=-103.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tjye+Rbr788S for ; Wed, 2 Feb 2011 14:23:10 -0800 (PST) Received: from mail-qw0-f66.google.com (mail-qw0-f66.google.com [209.85.216.66]) by core3.amsl.com (Postfix) with ESMTP id D81C13A6C62 for ; Wed, 2 Feb 2011 14:23:09 -0800 (PST) Received: by qwk3 with SMTP id 3so37384qwk.1 for ; Wed, 02 Feb 2011 14:26:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cBg8vT4HjjtdW4EPIA8CdhLeCS2msiA786mgbDGSsuI=; b=AXL0ySsx6TLjz8iNDGkCV/rDZ/oXi0emD3mtsT9wP0QYPRKPxPzitr2NLZneSaucM8 rYOL7x2QMNi9HWpK2xQwaNhriZxFZ5t+Dm9kYkZvnT5Rfloz4svbKtU8gGFb7ZH0Z6/9 8wozpaHqN63YbFi5w8Kx0Pt3deIXFbfE+K+q4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=auHkgnBYIul8ZpINPBMjVWQtIF2aAiFJW9vx16wa5EO9YE5Ni/rOHVBwrje25PoYUG CAVAlxFFnyuZHbH7Zm8ESw7dzReYm+q7sUrh3K/efc0+JjzPNlj0jDioG6oZFf60qAuN dRQLW0Mo9G6tYX1CVjyU0+gnFOzObokGimQFk= MIME-Version: 1.0 Received: by 10.229.221.208 with SMTP id id16mr6080663qcb.62.1296685588721; Wed, 02 Feb 2011 14:26:28 -0800 (PST) Received: by 10.229.20.70 with HTTP; Wed, 2 Feb 2011 14:26:28 -0800 (PST) In-Reply-To: References: Date: Wed, 2 Feb 2011 14:26:28 -0800 Message-ID: From: stefano faccin To: "Zuniga, Juan Carlos" Content-Type: multipart/alternative; boundary=0016363b7d26e6b026049b5423de Cc: netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 22:23:15 -0000 --0016363b7d26e6b026049b5423de Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello JC, thanks for acknowledging that there is indeed an issue with the current draft. For my clarification, how would the "MAG forward the packet with no problem"? I am not sure I am understanding what the sequence of steps would be. Also, I guess that as you say the solution is not included in the current draft, which means modifying the protocol that we have in the current draft= . Cheers, Stefano On Wed, Feb 2, 2011 at 12:37 PM, Zuniga, Juan Carlos < JuanCarlos.Zuniga@interdigital.com> wrote: > Hi Stefano, > > > > Thanks for the response (you forgot to copy the list again ;). > > > > What I had in mind was what they call Basic solution in the document, in > which the same set of prefixes are assigned to different interfaces (or > MAGs). In this case the MN can decide (based on policies) to change the f= low > and send packets over a new interface. The MAG would forward the packet w= ith > no problem and upon receiving this packet the LMA would implicitly know t= hat > the MN has performed a flow movement (again, based on policies). At this > point the LMA would just need to change its routing table accordingly and > start sending packets for this flow over the new interface (similar rule = to > the one already specified for the mobile). > > > > I see this as a lightweight solution to the problem you pointed out that > could easily be added to the document. > > > > Jc > > > > > > > > *From:* stefano faccin [mailto:sfaccinstd@gmail.com] > *Sent:* February 2, 2011 3:11 PM > *To:* Zuniga, Juan Carlos > > *Subject:* Re: [netext] Consensus call to adopt I-D: > draft-bernardos-netext-pmipv6-flowmob as WG doc > > > > Hi JC, > > As you say in 3GPP for the MN-based model this has been solved. However, = if > we want to apply a similar solution, we go back to the argument that it > would require the MN to be able to communicate the decisions to the MAG/L= MA > but, as we discussed previously, we don't have a solution for that. This > means that applying this protocol with a model similar to the one current= ly > specified in IETF and 3GPP requires the definition of a solution that doe= s > not yet exist (at Layer 3 or at Layer 2). I am concerned about developing > only some pieces of a solution. > > Alternatively, as you say the MAG reacts. However, it is not clear to me > that the current draft describes how that happens. > > Cheers, > Stefano > > On Wed, Feb 2, 2011 at 11:56 AM, Zuniga, Juan Carlos < > JuanCarlos.Zuniga@interdigital.com> wrote: > > Stefano, > > > > As much as I agree with most of your points about the problem from the 3G= PP > architecture point of view, I think that there is more than one solution. > > > > We are assuming of course that what we have is a scenario where both > networks are in the same PMIP domain and IP flow mobility is then possibl= e. > You point out that there are no means to convey policies to the LMA or MA= G. > However, there are means to convey these policies to the MN as it is alre= ady > defined in 3GPP for the client-based IP flow mobility case (i.e. ANDSF). > Hence, one different solution could be to let the MN apply the policy by > moving the flow and make the MAG and LMA =93react=94 to the IP flow chang= e > assuming that the flow change was made according to the policy being appl= ied > at the mobile. > > > > I would see this scenario equivalent to the one specified in 3GPP from th= e > point of view of node=92s responsibilities, don=92t you think? > > > > Jc > > > > > > *From:* netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] *On > Behalf Of *stefano faccin > *Sent:* February 2, 2011 2:41 PM > *To:* Rajeev Koodli; netext@ietf.org > > > *Subject:* Re: [netext] Consensus call to adopt I-D: > draft-bernardos-netext-pmipv6-flowmob as WG doc > > > > Sorry, I forgot to reply to the whole list. > Cheers, > Stefano > > On Wed, Feb 2, 2011 at 11:29 AM, stefano faccin > wrote: > > Hi Rajeev, > in current solution the policy is in sync, since it is the ANDSF (the > network counterpart of the MN for the policy) that configures it in the M= N. > That does not mean that the LMA has such policy. > > Cheers, > Stefano > > > > On Wed, Feb 2, 2011 at 11:46 AM, Rajeev Koodli wrote: > > > Hi Gerardo, > > - my point is that someone/something is configuring the policy on the > MN which needs to be in sync with the MN=92s partner, i.e., the networ= k. If > this is not the case, please let me know. > - The last I heard, PMIP6 is applicable on the eHRPD (trusted non-3GPP > network). Also, 33.402 does not specify whether a particular type of a= ccess > network (such as WLAN) is considered trusted or untrusted (although a > majority of the WLAN access could be considered untrusted today). > > > -Rajeev > > > > > On 2/2/11 11:16 AM, "Giaretta, Gerardo" wrote: > > Hi Rajeev, > > A couple of considerations on this: > > - This draft assumes there is consistency in the rules. This is a > new requirement for the system architecture where this solution will be > applied. There is no this requirement for other solutions already adopted= by > IETF and 3GPP. In my view this seems a fairly important issue. > > - The routing decisions based on WLAN SSID are different from > trusted/untrusted. Note also that PMIPv6 cannot be used in trusted networ= ks > so it is not clear at all what you are referring to. > > > Gerardo > > > *From:* netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] > *On Behalf Of *Rajeev Koodli > *Sent:* Wednesday, February 02, 2011 11:28 AM > *To:* stefano faccin > *Cc:* netext@ietf.org; Basavaraj.Patil@nokia.com > *Subject:* Re: [netext] Consensus call to adopt I-D: > draft-bernardos-netext-pmipv6-flowmob as WG doc > > > Stefano, > > Regardless of how the policy is configured on the LMA, there is a > consistency of the rules which needs to be ensured regardless. Whatever t= he > entity (OMA-DM?!) is that configures the policy has to ensure such a > consistency. > > We can debate about how policy interaction works, but that=92s another to= pic. > I would note that there are choices here (modulo respective pros and cons= ). > > I didn=92t suggest that an operator should just trust the software on a M= N, > although I suspect some device vendors might argue for their robustness > (surprise?). > > I would frame the WLAN access problem as whether the access is considered > trusted or not. Accordingly, you apply the policy. > > -Rajeev > > > On 2/2/11 10:50 AM, "stefano faccin" wrote: > Raj, > thanks for the reply. > > If the LMA has statically configured policies, how do we ensure that the = MN > has the same policies? That would mean implicitly assuming that the polic= ies > provisioned to the MN by the ANDSF "always" match what has been set in th= e > LMA, which I think it is unrealistic because the policies change over tim= e, > and every time you need to update all the LMAs, which has a considerable > operational cost. Instead, if we leave the MN to make the choice, there a= re > easy and well specified mechanisms that allow the provisioning of policie= s > in the MN and for the MN to make such decision and communicate it to the > network, so that the network can > > As for extensions to Gx, I am not stating that in theory one could extend > Gx. However, at present such solution does not exists, and without it, I = do > not see how the draft is applicable to 3GPP that is at present the only > potential customer identified (I guess I did not see any other identified= ?) > > > Even assuming that Gx could be modified, the issue of the per-access > network granularity remains. Even if the LMA has the right policies in > place, the LMA has no way of knowing exactly what access network of a > specific access technology (e.g. which SSID for WLAN0 the MN is connectin= g > to. > > I cannot agree with your assumption below that if the MN connects to an > SSID it is because the operator is OK with routing traffic on that SSID, = and > that we should just "trust the software on the MN". There are two aspects= to > consider: > 1) whether it is OK for certain traffic to be routed at all over a certai= n > access access network of a specific access technology > 2) how different traffic should be routed over different access networks = of > different access technologies > > Regarding these two points, the issue is whether the operator wants to > allow traffic e.g. over a certain SSID or not. So, in that case, it is > obvious as you say that if the MN has connected to an SSID configured by = the > operator in the MN, then traffic could be allowed over that SSID. However= , > we need to consider that 3GPP allows the decision of which WLAN the MN ca= n > connect to based on user preferences. This means that my MN can e.g. conn= ect > to my home WLAN (which is not controlled necessarily by the operator and > whose SSID the operator does not know) or to a coffee shop WLAN, even if = the > device does not have those SSID configured. Those are typical examples of > untrusted WLAN access networks. Therefore, in such cases, just because th= e > MN has connected to a WLAN SSID, does not mean that the operator wants to > route certain traffic over that SSID just because the policy says "route > traffic X over WLAN". > > That brings us to a solution that, if applied to 3GPP, provides less > functionality than what is available and has been specified today, so bac= k > to my point above. > > Unfortunately, there is no solution I am aware of that allows the WLAN > network to indicate to the MAG/LMA the specific SSID (and as you say, the= re > is no easy solution for that). Due to this and the points above about pol= icy > provisioning, it means that the applicability of this solution to a real > case like 3GPP depends on the feasibility of extending policy mechanisms = in > 3GPP, and the ability to have a solution where the WLAN network provides = the > SSID information to the MAG/LMA. Moreover, the provisioning of such SSID = is > not in the scope of IETF, but not even of 3GPP (since the interface betwe= en > the WLAN AP and the ePDG is not defined), thus I wonder how this could be > defined at all (I am afraid of asking what magic should happen here). So, > now we have two big dependencies. > > In general, I am also wondering if there is a customer that has asked us = to > define this solution. I am not aware of any but I may have missed that. > > Cheers, > Stefano > > On Wed, Feb 2, 2011 at 10:44 AM, Rajeev Koodli wrote: > > Hi Stefano, > > You make two interesting points: First, the defined solution should be > useful for 3GPP deployments. Second, if it=92s not defined *today* in 3GP= P, > it=92s not useful. > > I tend to agree with you on the first =96 3GPP is a big potential custome= r. > I cannot agree with your second point. > > There are multiple ways I could envision policy on the LMA. Locally > configured policy is one (which we use today in deployments) that does no= t > need Gx interaction. Gx extensions can be proposed in the future. I hope = you > are not suggesting that these are not feasible choices. > > For the MN (IETF term for UE) to even connect to the MAG via WLAN today, > you need an IPsec termination point (ePDG). If the operator pre-configure= s > the list of SSIDs or there is some out-of-band mechanism to inform the MN > which SSID is =93white-listed=94, then I expect the MN to decide when to = connect > to the ePDG and hence the MAG. At this point, the MN is already on the WL= AN > the operator cares about I presume. > There is no easy way for the network (LMA, MAG) to know what SSID the MN = is > connected to =96 the network has to either trust the software on the MN o= r the > WLAN infrastructure has to provide the SSID information to the network. > > -Rajeev > > > > On 2/2/11 9:56 AM, "stefano faccin" http://sfaccinstd@gmail.com> > wrote: > Hello rajeev, > the use of PCRF is an interesting suggestion. However, unfortunately, PCR= F > does not contain any policies or information that will tell the LMA what = are > the policies to be used for decisions of IP flow mobility. This is not pa= rt > of current PCC functionality, and there is no work ongoing or planned to > extend PCC in such way. Therefore, the applicability of the solution in t= his > draft would hinge on hypotetical future solutions and not on a current > solution for the open issues, which brings us back to my point that we ar= e > defining a solution with open issues for which there is not a single > realistic solution out there, thus making this draft not applicable to a > real scenario. > > I am not thinking of the UE connecting to more than one WLAN at the same > time, but the UE being able to connect to different WLANs (one at a time) > because the UE is e.g. provisioned with a list of SSIDs or the UE discove= rs > a hotspot somewhere. I am talking about the scenario where the UE is capa= ble > to connect to WLAN, but the operator has different policies wrt which WLA= N > the UE should use or not. > > If you have followed the work in 3GPP, it is clear that operators have > interest in applying policies not only at RAT level, but also at access > network level (please see how ANDSF was defined and why). I guess we can = all > agree that an operator deploying PMIP-based mobility may be interested in > having policies that allow traffic on the WLAN the operator owns or that > belongs to a roaming partner, while not allowing traffic on WLAN of other > operators for which it might need to pay an extra fee or where e.g. no Qo= S > can be guaranteed. That means that the entity deciding whether traffic ne= eds > to be routed on WLAN or not cannot just consider "WLAN is available", but > "WLAN SSIDx is available", so that the decision can be based on the opera= tor > preferences as to which WLAN certain traffic needs to be routed on. > > If the draft allows decisions to be made only at the RAT level, then we > have an issue because we are defining a solution that should be applicabl= e > to 3GPP but does not meet the deployment scenarios of interest. In other > words, if we want to make this solution applicable e.g. to 3GPP, we need = to > be able to provide the same functionality available today in 3GPP with ot= her > solution in order to satisfy the use cases supported by 3GPP, and not ste= p > backwards in terms of what can be supported. > > Cheers, > > Stefano > > On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli http://rkoodli@cisco.com> > wrote: > > Hi Stefano, > > Thanks for your input. > > I expect the LMA interacting with PCRF for policy rules specific to the > subscriber for different RAT types. > You are right that the LMA does not know the SSID the mobile is connected > to. It=92s not clear if the MAG can get that from the MN either without > additional signaling. However, the LMA knows that the MN is connected to > WLAN; so it can apply the policy at the RAT type level. Are you thinking = of > the MN connecting to more than one WLAN network (and each of those > connections coming back to the LMA)? If so, please explain the scenario. > > Regards, > > -Rajeev > > > > > On 2/1/11 6:39 PM, "stefano faccin" http://sfaccinstd@gmail.com> > wrote: > Raj, > thanks for the email. > > I need to apologize in advance if my questions have already been answered > before (though I cannot find a conclusive answer anywhere). > > I think that a protocol that is developed in NETEXT (or other groups) > should have at least a potential realistic scenario for applicability. > > In terms of applicability, though it is not part of the protocol definiti= on > per se, unless there are solutions in place for either the host to indica= te > to the network where the flows should be routed or for the LMA to receive > somehow from somewhere some policies, the solution cannot really provide > flow mobility since there is no way to decide which flows are routed wher= e. > If we are thinking about a host-based solution, I have not yet seen a > solution as to how the host can indicate to the MAG and ultimately to the > MAG which flows should be routed on each access. If we are relying on > modifications of layer 2 protocols, aren't we defining a solution that wo= rks > only with some technologies (since for other access technologies it is > rather unrealistic to modify L2 for IP flow mobility purposes)? If we are > thinking of an LMA-based solution, can we hear of at least one example of= a > real-life scenario where the LMA would receive such policies, and how suc= h > delivery would happen? Also, should there be a solution to have policies = in > the LMA, how does the LMA actually decide to route flows on one access or > the other? E.g., if some flows need to be routed on certain WLAN networks= , > but shall not be routed on other WLAN networks, how does the LMA know whi= ch > specific WLAN network the host is connected to? Perhaps I missed the abil= ity > for the MAG to know e.g. the WLAN SSID and provide it to the LMA, in whic= h > case I would appreciate if somebody could highlight to me where that is > defined. > > I think that, though not integral to the protocol specification, > understanding what framework the protocol would/needs to fit in is rather > important. > > Cheers, > Stefano > > > On Tue, Feb 1, 2011 at 3:47 PM, http://Basavaraj.Patil@nokia.com> > > wrote: > > Hello, > > We have discussed the flow mobility solutions for Proxy MIP6 previously a= t > IETFs 78 and 79. > This is a consensus call for adopting this I-D: > draft-bernardos-netext-pmipv6-flowmob-02 > as the working group document. > I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt > > The consensus call will expire on Feb 15th, 2011. Please indicate your > support or concerns in adopting this I-D as the WG baseline document on > the mailing list. > > Please note that this I-D will serve as the baseline in the WG and will b= e > developed further based on input and feedback from WG members. > > -Basavaraj > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > > > > > > -- > Stefano M. Faccin > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > May the Force be with you > > > > > -- > Stefano M. Faccin > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > May the Force be with you > > > > > -- > Stefano M. Faccin > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > May the Force be with you > --=20 Stefano M. Faccin =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D May the Force be with you --0016363b7d26e6b026049b5423de Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello JC,
thanks for acknowledging that there is indeed an issue with th= e current draft.

For my clarification, how would the "MAG forw= ard the packet with no problem"? I am not sure I am understanding what= the sequence of steps would be.

Also, I guess that as you say the solution is not included in the curre= nt draft, which means modifying the protocol that we have in the current dr= aft.

Cheers,
Stefano

On Wed, Fe= b 2, 2011 at 12:37 PM, Zuniga, Juan Carlos <JuanCarlos.Zuniga@interdigital.= com> wrote:

Hi Stefano,

=A0

Thanks for the response (you forgot to copy the list again ;).

=A0

What I had in mind was what they call Basic solution in the document, in which the same set of prefixes are assigned to different interfaces (or MAGs). In this case the MN can decide (based on policies) to= change the flow and send packets over a new interface. The MAG would forward the packet with no problem and upon receiving this packet the LMA would implici= tly know that the MN has performed a flow movement (again, based on policies). At th= is point the LMA would just need to change its routing table accordingly and s= tart sending packets for this flow over the new interface (similar rule to the o= ne already specified for the mobile).

=A0

I see this as a lightweight solution to the problem you pointed out that could easily be added to the document.

=A0

Jc

=A0

=A0

=A0

From:= stefano faccin [mailto:sfaccinst= d@gmail.com]
Sent: February 2, 2011 3:11 PM
To: Zuniga, Juan Carlos


Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

=A0

Hi JC,

As you say in 3GPP for the MN-based model this has been solved. However, if= we want to apply a similar solution, we go back to the argument that it would require the MN to be able to communicate the decisions to the MAG/LMA but, = as we discussed previously, we don't have a solution for that. This means = that applying this protocol with a model similar to the one currently specified = in IETF and 3GPP requires the definition of a solution that does not yet exist= (at Layer 3 or at Layer 2). I am concerned about developing only some pieces of= a solution.

Alternatively, as you say the MAG reacts. However, it is not clear to me th= at the current draft describes how that happens.

Cheers,
Stefano

On Wed, Feb 2, 2011 at 11:56 AM, Zuniga, Juan Carlos= <JuanCarlos.Zuniga@interdigital.com> wrote:

Stefano,

=A0

As much as I agree with most of your points about the problem from the 3GPP architecture point of view, I think = that there is more than one solution.

=A0

We are assuming of course that what we have is a scenario where both networks are in the same PMIP domain and IP f= low mobility is then possible. You point out that there are no means to convey policies to the LMA or MAG. However, there are means to convey these polici= es to the MN as it is already defined in 3GPP for the client-based IP flow mobility case (i.e. ANDSF). Hence, one different solution could be to let t= he MN apply the policy by moving the flow and make the MAG and LMA =93react=94= to the IP flow change assuming that the flow change was made according to the poli= cy being applied at the mobile.

=A0

I would see this scenario equivalent to the one specified in 3GPP from the point of view of node=92s responsibiliti= es, don=92t you think?

=A0

Jc

=A0

=A0

From:= netext-bounces@ietf.org [mailto:netext= -bounces@ietf.org] On Behalf Of stefano faccin
Sent: February 2, 2011 2:41 PM
To: Rajeev Koodli; netext@ietf.org


Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

=A0

Sorry, I forgot to reply to the whole list.
Cheers,
Stefano

On Wed, Feb 2, 2011 at 11:29 AM, stefano faccin <sfaccinstd@gmail.com> wrote:

Hi Rajeev,
in current solution the policy is in sync, since it is the ANDSF (the netwo= rk counterpart of the MN for the policy) that configures it in the MN. That do= es not mean that the LMA has such policy.

Cheers,
Stefano

=A0

On Wed, Feb 2, 2011 at 11:46 AM, Rajeev Koodli <rkoodli@cisco.com> wrote:


Hi Gerardo,

  • my point is that someone/something is configuring the policy on the MN which needs to b= e in sync with the MN=92s partner, i.e., the network. If this is not the ca= se, please let me know.
  • The last I heard, PMIP6 is applicable on the eHRPD (trusted non-3GPP network). Also, 33.= 402 does not specify whether a particular type of access network (such as WLAN) is considered trusted or untrusted (although a majority of the W= LAN access could be considered untrusted today).


-Rajeev




On 2/2/11 11:16 AM, "Giaretta, Gerardo" <gerardog@qualcomm.com> wrote:

Hi Rajeev,
=A0
A couple of considerations on this:
=A0
- =A0=A0=A0=A0=A0=A0=A0=A0This draft assumes there is consistency in the rules. This is a new requirement for the system architec= ture where this solution will be applied. There is no this requirement for other solutions already adopted by IETF and 3GPP. In my view this seems a fairly important issue.

- =A0=A0=A0=A0=A0=A0=A0=A0The routing decisions based on WLAN SSID are different from trusted/untrusted. Note also that PMIPv6 ca= nnot be used in trusted networks so it is not clear at all what you are referrin= g to.

=A0
Gerardo
=A0

From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Rajeev Koodli
Sent: Wednesday, February 02, 2011 11:28 AM
To: stefano faccin
Cc: netext@ietf= .org; Basavaraj.Pa= til@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc


Stefano,

Regardless of how the policy is configured on the LMA, there is a consisten= cy of the rules which needs to be ensured regardless. Whatever the entity (OMA-DM?!) is that configures the policy has to ensure such a consistency.<= br>
We can debate about how policy interaction works, but that=92s another topi= c. I would note that there are choices here (modulo respective pros and cons).
I didn=92t suggest that an operator should just trust the software on a MN, although I suspect some device vendors might argue for their robustness (surprise?).

I would frame the WLAN access problem as whether the access is considered trusted or not. Accordingly, you apply the policy.

-Rajeev


On 2/2/11 10:50 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:
Raj,
thanks for the reply.

If the LMA has statically configured policies, how do we ensure that the MN= has the same policies? That would mean implicitly assuming that the policies provisioned to the MN by the ANDSF "always" match what has been s= et in the LMA, which I think it is unrealistic because the policies change ove= r time, and every time you need to update all the LMAs, which has a considerable operational cost. Instead, if we leave the MN to make the choice, there are easy and well specified mechanisms that allow the provisioning of policies = in the MN and for the MN to make such decision and communicate it to the netwo= rk, so that the network can

As for extensions to Gx, I am not stating that in theory one could extend G= x. However, at present such solution does not exists, and without it, I do not= see how the draft is applicable to 3GPP that is at present the only potential customer identified (I guess I did not see any other identified?) =A0

Even assuming that Gx could be modified, the issue of the per-access networ= k granularity remains. Even if the LMA has the right policies in place, the L= MA has no way of knowing exactly what access network of a specific access technology (e.g. which SSID for WLAN0 the MN is connecting to.

I cannot agree with your assumption below that if the MN connects to an SSI= D it is because the operator is OK with routing traffic on that SSID, and that w= e should just "trust the software on the MN". There are two aspects= to consider:
1) whether it is OK for certain traffic to be routed at all over a certain access access network of a specific access technology
2) how different traffic should be routed over different access networks of different access technologies

Regarding these two points, the issue is whether the operator wants to allo= w traffic e.g. over a certain SSID or not. So, in that case, it is obvious as= you say that if the MN has connected to an SSID configured by the operator in t= he MN, then traffic could be allowed over that SSID. However, we need to consi= der that 3GPP allows the decision of which WLAN the MN can connect to based on = user preferences. This means that my MN can e.g. connect to my home WLAN (which = is not controlled necessarily by the operator and whose SSID the operator does= not know) or to a coffee shop WLAN, even if the device does not have those SSID configured. Those are typical examples of untrusted WLAN access networks. Therefore, in such cases, just because the MN has connected to a WLAN SSID, does not mean that the operator wants to route certain traffic over that SS= ID just because the policy says "route traffic X over WLAN".

That brings us to a solution that, if applied to 3GPP, provides less functionality than what is available and has been specified today, so back = to my point above.

Unfortunately, there is no solution I am aware of that allows the WLAN netw= ork to indicate to the MAG/LMA the specific SSID (and as you say, there is no e= asy solution for that). Due to this and the points above about policy provision= ing, it means that the applicability of this solution to a real case like 3GPP depends on the feasibility of extending policy mechanisms in 3GPP, and the ability to have a solution where the WLAN network provides the SSID informa= tion to the MAG/LMA. Moreover, the provisioning of such SSID is not in the scope= of IETF, but not even of 3GPP (since the interface between the WLAN AP and the ePDG is not defined), thus I wonder how this could be defined at all (I am afraid of asking what magic should happen here). So, now we have two big dependencies.

In general, I am also wondering if there is a customer that has asked us to define this solution. I am not aware of any but I may have missed that.

Cheers,
Stefano

On Wed, Feb 2, 2011 at 10:44 AM, Rajeev Koodli <rkoodli@cisco.com> wrote:

Hi Stefano,

You make two interesting points: First, the defined solution should be usef= ul for 3GPP deployments. Second, if it=92s not defined today in 3GPP, i= t=92s not useful.

I tend to agree with you on the first =96 3GPP is a big potential customer.=
I cannot agree with your second point.

There are multiple ways I could envision policy on the LMA. Locally configu= red policy is one (which we use today in deployments) that does not need Gx interaction. Gx extensions can be proposed in the future. I hope you are no= t suggesting that these are not feasible choices.

For the MN (IETF term for UE) to even connect to the MAG via WLAN today, yo= u need an IPsec termination point (ePDG). If the operator pre-configures the = list of SSIDs or there is some out-of-band mechanism to inform the MN which SSID= is =93white-listed=94, then I expect the MN to decide when to connect to the e= PDG and hence the MAG. At this point, the MN is already on the WLAN the operator ca= res about I presume.
There is no easy way for the network (LMA, MAG) to know what SSID the MN is connected to =96 the network has to either trust the software on the MN or = the WLAN infrastructure has to provide the SSID information to the network.
-Rajeev



On 2/2/11 9:56 AM, "stefano faccin" <sfaccinstd@gmail.com <http://sfacci= nstd@gmail.com> > wrote:
Hello rajeev,
the use of PCRF is an interesting suggestion. However, unfortunately, PCRF = does not contain any policies or information that will tell the LMA what are the policies to be used for decisions of IP flow mobility. This is not part of current PCC functionality, and there is no work ongoing or planned to exten= d PCC in such way. Therefore, the applicability of the solution in this draft would hinge on hypotetical future solutions and not on a current solution f= or the open issues, which brings us back to my point that we are defining a solution with open issues for which there is not a single realistic solutio= n out there, thus making this draft not applicable to a real scenario.

I am not thinking of the UE connecting to more than one WLAN at the same ti= me, but the UE being able to connect to different WLANs (one at a time) because= the UE is e.g. provisioned with a list of SSIDs or the UE discovers a hotspot somewhere. I am talking about the scenario where the UE is capable to conne= ct to WLAN, but the operator has different policies wrt which WLAN the UE shou= ld use or not.

If you have followed the work in 3GPP, it is clear that operators have inte= rest in applying policies not only at RAT level, but also at access network leve= l (please see how ANDSF was defined and why). I guess we can all agree that a= n operator deploying PMIP-based mobility may be interested in having policies= that allow traffic on the WLAN the operator owns or that belongs to a roaming partner, while not allowing traffic on WLAN of other operators for which it might need to pay an extra fee or where e.g. no QoS can be guaranteed. That means that the entity deciding whether traffic needs to be routed on WLAN o= r not cannot just consider "WLAN is available", but "WLAN SSID= x is available", so that the decision can be based on the operator preferen= ces as to which WLAN certain traffic needs to be routed on.

If the draft allows decisions to be made only at the RAT level, then we hav= e an issue because we are defining a solution that should be applicable to 3GPP = but does not meet the deployment scenarios of interest. In other words, if we w= ant to make this solution applicable e.g. to 3GPP, we need to be able to provid= e the same functionality available today in 3GPP with other solution in order= to satisfy the use cases supported by 3GPP, and not step backwards in terms of what can be supported.

Cheers,

Stefano

On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli <rkoodli@cisco.com <http://rkoodli@cisco.com> > wrote:

Hi Stefano,

Thanks for your input.

I expect the LMA interacting with PCRF for policy rules specific to the subscriber for different RAT types.
You are right that the LMA does not know the SSID the mobile is connected t= o. It=92s not clear if the MAG can get that from the MN either without additio= nal signaling. However, the LMA knows that the MN is connected to WLAN; so it c= an apply the policy at the RAT type level. Are you thinking of the MN connecti= ng to more than one WLAN network (and each of those connections coming back to= the LMA)? If so, please explain the scenario.

Regards,

-Rajeev




On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <http://sfacci= nstd@gmail.com> =A0<http://sfa= ccinstd@gmail.com> > wrote:
Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered before (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicate to = the network where the flows should be routed or for the LMA to receive somehow = from somewhere some policies, the solution cannot really provide flow mobility s= ince there is no way to decide which flows are routed where. If we are thinking about a host-based solution, I have not yet seen a solution as to how the h= ost can indicate to the MAG and ultimately to the MAG which flows should be rou= ted on each access. If we are relying on modifications of layer 2 protocols, ar= en't we defining a solution that works only with some technologies (since for ot= her access technologies it is rather unrealistic to modify L2 for IP flow mobil= ity purposes)? If we are thinking of an LMA-based solution, can we hear of at l= east one example of a real-life scenario where the LMA would receive such polici= es, and how such delivery would happen? Also, should there be a solution to hav= e policies in the LMA, how does the LMA actually decide to route flows on one access or the other? E.g., if some flows need to be routed on certain WLAN networks, but shall not be routed on other WLAN networks, how does the LMA = know which specific WLAN network the host is connected to? Perhaps I missed the ability for the MAG to know e.g. the WLAN SSID and provide it to the LMA, i= n which case I would appreciate if somebody could highlight to me where that = is defined.

I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important.

Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM, =A0<Basavaraj.Patil@nokia.com <http://B= asavaraj.Patil@nokia.com> =A0<http:= //Basavaraj.Patil@nokia.com> > wrote:

Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= br> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-p= mipv6-flowmob-02.txt

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= br> developed further based on input and feedback from WG members.

-Basavaraj

_______________________________________________
netext mailing list
netext@ietf.org &l= t;http://netext@ietf.o= rg> =A0<http://netext@i= etf.org>
= https://www.ietf.org/mailman/listinfo/netext

=A0
=A0



--
Stefano M. Faccin
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
May the Force be with you




--
Stefano M. Faccin
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
May the Force be with you




--
Stefano M. Faccin
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
May the Force be with you




--
Stefano M. Faccin
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
May the Force be = with you
--0016363b7d26e6b026049b5423de-- From cjbc@it.uc3m.es Wed Feb 2 14:48:21 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D63B03A6C80 for ; Wed, 2 Feb 2011 14:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.056 X-Spam-Level: X-Spam-Status: No, score=-4.056 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLqR7GtDYSnp for ; Wed, 2 Feb 2011 14:48:19 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 7CB5E3A6864 for ; Wed, 2 Feb 2011 14:48:18 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.3] (213.37.82.169.static.user.ono.com [213.37.82.169]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 098F1759125; Wed, 2 Feb 2011 23:51:37 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: stefano faccin In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-pJeNOCHRbRF06Tm+zp9L" Organization: Universidad Carlos III de Madrid Date: Wed, 02 Feb 2011 23:52:34 +0100 Message-ID: <1296687154.3593.15.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17932.002 Cc: netext@ietf.org, "Zuniga, Juan Carlos" Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 22:48:21 -0000 --=-pJeNOCHRbRF06Tm+zp9L Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Stefano, Thanks for the comments on the draft. Two comments from my side: - Regarding the comment about the potential realistic scenario for applicability, this is not an issue of this solution (or any other), if it is an issue at all. We are chartered to work on protocol extensions for flow mobility without introducing any changes to the IP stack of the MN. IMHO all your comments on this regard relates to the charter itself, not this draft. - Regarding the comments about the "lack of support from 3GPP", I acknowledge that 3GPP is an important potential customer, but as far as I know, we are not chartered to come up with a 3GPP-only solution, and I think it's fair to design a solution that works under certain assumptions, as long as those assumptions cannot realistically be met in a particular network deployment. I think it's fair to expect that 3GPP may need to add also extensions to make this solution work in their architecture. Thanks, Carlos On Wed, 2011-02-02 at 14:26 -0800, stefano faccin wrote: > Hello JC, > thanks for acknowledging that there is indeed an issue with the current > draft. >=20 > For my clarification, how would the "MAG forward the packet with no > problem"? I am not sure I am understanding what the sequence of steps wou= ld > be. >=20 > Also, I guess that as you say the solution is not included in the current > draft, which means modifying the protocol that we have in the current dra= ft. >=20 > Cheers, > Stefano >=20 > On Wed, Feb 2, 2011 at 12:37 PM, Zuniga, Juan Carlos < > JuanCarlos.Zuniga@interdigital.com> wrote: >=20 > > Hi Stefano, > > > > > > > > Thanks for the response (you forgot to copy the list again ;). > > > > > > > > What I had in mind was what they call Basic solution in the document, i= n > > which the same set of prefixes are assigned to different interfaces (or > > MAGs). In this case the MN can decide (based on policies) to change the= flow > > and send packets over a new interface. The MAG would forward the packet= with > > no problem and upon receiving this packet the LMA would implicitly know= that > > the MN has performed a flow movement (again, based on policies). At thi= s > > point the LMA would just need to change its routing table accordingly a= nd > > start sending packets for this flow over the new interface (similar rul= e to > > the one already specified for the mobile). > > > > > > > > I see this as a lightweight solution to the problem you pointed out tha= t > > could easily be added to the document. > > > > > > > > Jc > > > > > > > > > > > > > > > > *From:* stefano faccin [mailto:sfaccinstd@gmail.com] > > *Sent:* February 2, 2011 3:11 PM > > *To:* Zuniga, Juan Carlos > > > > *Subject:* Re: [netext] Consensus call to adopt I-D: > > draft-bernardos-netext-pmipv6-flowmob as WG doc > > > > > > > > Hi JC, > > > > As you say in 3GPP for the MN-based model this has been solved. However= , if > > we want to apply a similar solution, we go back to the argument that it > > would require the MN to be able to communicate the decisions to the MAG= /LMA > > but, as we discussed previously, we don't have a solution for that. Thi= s > > means that applying this protocol with a model similar to the one curre= ntly > > specified in IETF and 3GPP requires the definition of a solution that d= oes > > not yet exist (at Layer 3 or at Layer 2). I am concerned about developi= ng > > only some pieces of a solution. > > > > Alternatively, as you say the MAG reacts. However, it is not clear to m= e > > that the current draft describes how that happens. > > > > Cheers, > > Stefano > > > > On Wed, Feb 2, 2011 at 11:56 AM, Zuniga, Juan Carlos < > > JuanCarlos.Zuniga@interdigital.com> wrote: > > > > Stefano, > > > > > > > > As much as I agree with most of your points about the problem from the = 3GPP > > architecture point of view, I think that there is more than one solutio= n. > > > > > > > > We are assuming of course that what we have is a scenario where both > > networks are in the same PMIP domain and IP flow mobility is then possi= ble. > > You point out that there are no means to convey policies to the LMA or = MAG. > > However, there are means to convey these policies to the MN as it is al= ready > > defined in 3GPP for the client-based IP flow mobility case (i.e. ANDSF)= . > > Hence, one different solution could be to let the MN apply the policy b= y > > moving the flow and make the MAG and LMA =E2=80=9Creact=E2=80=9D to the= IP flow change > > assuming that the flow change was made according to the policy being ap= plied > > at the mobile. > > > > > > > > I would see this scenario equivalent to the one specified in 3GPP from = the > > point of view of node=E2=80=99s responsibilities, don=E2=80=99t you thi= nk? > > > > > > > > Jc > > > > > > > > > > > > *From:* netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] *On > > Behalf Of *stefano faccin > > *Sent:* February 2, 2011 2:41 PM > > *To:* Rajeev Koodli; netext@ietf.org > > > > > > *Subject:* Re: [netext] Consensus call to adopt I-D: > > draft-bernardos-netext-pmipv6-flowmob as WG doc > > > > > > > > Sorry, I forgot to reply to the whole list. > > Cheers, > > Stefano > > > > On Wed, Feb 2, 2011 at 11:29 AM, stefano faccin > > wrote: > > > > Hi Rajeev, > > in current solution the policy is in sync, since it is the ANDSF (the > > network counterpart of the MN for the policy) that configures it in the= MN. > > That does not mean that the LMA has such policy. > > > > Cheers, > > Stefano > > > > > > > > On Wed, Feb 2, 2011 at 11:46 AM, Rajeev Koodli wrot= e: > > > > > > Hi Gerardo, > > > > - my point is that someone/something is configuring the policy on th= e > > MN which needs to be in sync with the MN=E2=80=99s partner, i.e., th= e network. If > > this is not the case, please let me know. > > - The last I heard, PMIP6 is applicable on the eHRPD (trusted non-3G= PP > > network). Also, 33.402 does not specify whether a particular type of= access > > network (such as WLAN) is considered trusted or untrusted (although = a > > majority of the WLAN access could be considered untrusted today). > > > > > > -Rajeev > > > > > > > > > > On 2/2/11 11:16 AM, "Giaretta, Gerardo" wrote: > > > > Hi Rajeev, > > > > A couple of considerations on this: > > > > - This draft assumes there is consistency in the rules. This is= a > > new requirement for the system architecture where this solution will be > > applied. There is no this requirement for other solutions already adopt= ed by > > IETF and 3GPP. In my view this seems a fairly important issue. > > > > - The routing decisions based on WLAN SSID are different from > > trusted/untrusted. Note also that PMIPv6 cannot be used in trusted netw= orks > > so it is not clear at all what you are referring to. > > > > > > Gerardo > > > > > > *From:* netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] > > *On Behalf Of *Rajeev Koodli > > *Sent:* Wednesday, February 02, 2011 11:28 AM > > *To:* stefano faccin > > *Cc:* netext@ietf.org; Basavaraj.Patil@nokia.com > > *Subject:* Re: [netext] Consensus call to adopt I-D: > > draft-bernardos-netext-pmipv6-flowmob as WG doc > > > > > > Stefano, > > > > Regardless of how the policy is configured on the LMA, there is a > > consistency of the rules which needs to be ensured regardless. Whatever= the > > entity (OMA-DM?!) is that configures the policy has to ensure such a > > consistency. > > > > We can debate about how policy interaction works, but that=E2=80=99s an= other topic. > > I would note that there are choices here (modulo respective pros and co= ns). > > > > I didn=E2=80=99t suggest that an operator should just trust the softwar= e on a MN, > > although I suspect some device vendors might argue for their robustness > > (surprise?). > > > > I would frame the WLAN access problem as whether the access is consider= ed > > trusted or not. Accordingly, you apply the policy. > > > > -Rajeev > > > > > > On 2/2/11 10:50 AM, "stefano faccin" wrote: > > Raj, > > thanks for the reply. > > > > If the LMA has statically configured policies, how do we ensure that th= e MN > > has the same policies? That would mean implicitly assuming that the pol= icies > > provisioned to the MN by the ANDSF "always" match what has been set in = the > > LMA, which I think it is unrealistic because the policies change over t= ime, > > and every time you need to update all the LMAs, which has a considerabl= e > > operational cost. Instead, if we leave the MN to make the choice, there= are > > easy and well specified mechanisms that allow the provisioning of polic= ies > > in the MN and for the MN to make such decision and communicate it to th= e > > network, so that the network can > > > > As for extensions to Gx, I am not stating that in theory one could exte= nd > > Gx. However, at present such solution does not exists, and without it, = I do > > not see how the draft is applicable to 3GPP that is at present the only > > potential customer identified (I guess I did not see any other identifi= ed?) > > > > > > Even assuming that Gx could be modified, the issue of the per-access > > network granularity remains. Even if the LMA has the right policies in > > place, the LMA has no way of knowing exactly what access network of a > > specific access technology (e.g. which SSID for WLAN0 the MN is connect= ing > > to. > > > > I cannot agree with your assumption below that if the MN connects to an > > SSID it is because the operator is OK with routing traffic on that SSID= , and > > that we should just "trust the software on the MN". There are two aspec= ts to > > consider: > > 1) whether it is OK for certain traffic to be routed at all over a cert= ain > > access access network of a specific access technology > > 2) how different traffic should be routed over different access network= s of > > different access technologies > > > > Regarding these two points, the issue is whether the operator wants to > > allow traffic e.g. over a certain SSID or not. So, in that case, it is > > obvious as you say that if the MN has connected to an SSID configured b= y the > > operator in the MN, then traffic could be allowed over that SSID. Howev= er, > > we need to consider that 3GPP allows the decision of which WLAN the MN = can > > connect to based on user preferences. This means that my MN can e.g. co= nnect > > to my home WLAN (which is not controlled necessarily by the operator an= d > > whose SSID the operator does not know) or to a coffee shop WLAN, even i= f the > > device does not have those SSID configured. Those are typical examples = of > > untrusted WLAN access networks. Therefore, in such cases, just because = the > > MN has connected to a WLAN SSID, does not mean that the operator wants = to > > route certain traffic over that SSID just because the policy says "rout= e > > traffic X over WLAN". > > > > That brings us to a solution that, if applied to 3GPP, provides less > > functionality than what is available and has been specified today, so b= ack > > to my point above. > > > > Unfortunately, there is no solution I am aware of that allows the WLAN > > network to indicate to the MAG/LMA the specific SSID (and as you say, t= here > > is no easy solution for that). Due to this and the points above about p= olicy > > provisioning, it means that the applicability of this solution to a rea= l > > case like 3GPP depends on the feasibility of extending policy mechanism= s in > > 3GPP, and the ability to have a solution where the WLAN network provide= s the > > SSID information to the MAG/LMA. Moreover, the provisioning of such SSI= D is > > not in the scope of IETF, but not even of 3GPP (since the interface bet= ween > > the WLAN AP and the ePDG is not defined), thus I wonder how this could = be > > defined at all (I am afraid of asking what magic should happen here). S= o, > > now we have two big dependencies. > > > > In general, I am also wondering if there is a customer that has asked u= s to > > define this solution. I am not aware of any but I may have missed that. > > > > Cheers, > > Stefano > > > > On Wed, Feb 2, 2011 at 10:44 AM, Rajeev Koodli wrot= e: > > > > Hi Stefano, > > > > You make two interesting points: First, the defined solution should be > > useful for 3GPP deployments. Second, if it=E2=80=99s not defined *today= * in 3GPP, > > it=E2=80=99s not useful. > > > > I tend to agree with you on the first =E2=80=93 3GPP is a big potential= customer. > > I cannot agree with your second point. > > > > There are multiple ways I could envision policy on the LMA. Locally > > configured policy is one (which we use today in deployments) that does = not > > need Gx interaction. Gx extensions can be proposed in the future. I hop= e you > > are not suggesting that these are not feasible choices. > > > > For the MN (IETF term for UE) to even connect to the MAG via WLAN today= , > > you need an IPsec termination point (ePDG). If the operator pre-configu= res > > the list of SSIDs or there is some out-of-band mechanism to inform the = MN > > which SSID is =E2=80=9Cwhite-listed=E2=80=9D, then I expect the MN to d= ecide when to connect > > to the ePDG and hence the MAG. At this point, the MN is already on the = WLAN > > the operator cares about I presume. > > There is no easy way for the network (LMA, MAG) to know what SSID the M= N is > > connected to =E2=80=93 the network has to either trust the software on = the MN or the > > WLAN infrastructure has to provide the SSID information to the network. > > > > -Rajeev > > > > > > > > On 2/2/11 9:56 AM, "stefano faccin" > http://sfaccinstd@gmail.com> > wrote: > > Hello rajeev, > > the use of PCRF is an interesting suggestion. However, unfortunately, P= CRF > > does not contain any policies or information that will tell the LMA wha= t are > > the policies to be used for decisions of IP flow mobility. This is not = part > > of current PCC functionality, and there is no work ongoing or planned t= o > > extend PCC in such way. Therefore, the applicability of the solution in= this > > draft would hinge on hypotetical future solutions and not on a current > > solution for the open issues, which brings us back to my point that we = are > > defining a solution with open issues for which there is not a single > > realistic solution out there, thus making this draft not applicable to = a > > real scenario. > > > > I am not thinking of the UE connecting to more than one WLAN at the sam= e > > time, but the UE being able to connect to different WLANs (one at a tim= e) > > because the UE is e.g. provisioned with a list of SSIDs or the UE disco= vers > > a hotspot somewhere. I am talking about the scenario where the UE is ca= pable > > to connect to WLAN, but the operator has different policies wrt which W= LAN > > the UE should use or not. > > > > If you have followed the work in 3GPP, it is clear that operators have > > interest in applying policies not only at RAT level, but also at access > > network level (please see how ANDSF was defined and why). I guess we ca= n all > > agree that an operator deploying PMIP-based mobility may be interested = in > > having policies that allow traffic on the WLAN the operator owns or tha= t > > belongs to a roaming partner, while not allowing traffic on WLAN of oth= er > > operators for which it might need to pay an extra fee or where e.g. no = QoS > > can be guaranteed. That means that the entity deciding whether traffic = needs > > to be routed on WLAN or not cannot just consider "WLAN is available", b= ut > > "WLAN SSIDx is available", so that the decision can be based on the ope= rator > > preferences as to which WLAN certain traffic needs to be routed on. > > > > If the draft allows decisions to be made only at the RAT level, then we > > have an issue because we are defining a solution that should be applica= ble > > to 3GPP but does not meet the deployment scenarios of interest. In othe= r > > words, if we want to make this solution applicable e.g. to 3GPP, we nee= d to > > be able to provide the same functionality available today in 3GPP with = other > > solution in order to satisfy the use cases supported by 3GPP, and not s= tep > > backwards in terms of what can be supported. > > > > Cheers, > > > > Stefano > > > > On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli > http://rkoodli@cisco.com> > wrote: > > > > Hi Stefano, > > > > Thanks for your input. > > > > I expect the LMA interacting with PCRF for policy rules specific to the > > subscriber for different RAT types. > > You are right that the LMA does not know the SSID the mobile is connect= ed > > to. It=E2=80=99s not clear if the MAG can get that from the MN either w= ithout > > additional signaling. However, the LMA knows that the MN is connected t= o > > WLAN; so it can apply the policy at the RAT type level. Are you thinkin= g of > > the MN connecting to more than one WLAN network (and each of those > > connections coming back to the LMA)? If so, please explain the scenario= . > > > > Regards, > > > > -Rajeev > > > > > > > > > > On 2/1/11 6:39 PM, "stefano faccin" > http://sfaccinstd@gmail.com> > wrote: > > Raj, > > thanks for the email. > > > > I need to apologize in advance if my questions have already been answer= ed > > before (though I cannot find a conclusive answer anywhere). > > > > I think that a protocol that is developed in NETEXT (or other groups) > > should have at least a potential realistic scenario for applicability. > > > > In terms of applicability, though it is not part of the protocol defini= tion > > per se, unless there are solutions in place for either the host to indi= cate > > to the network where the flows should be routed or for the LMA to recei= ve > > somehow from somewhere some policies, the solution cannot really provid= e > > flow mobility since there is no way to decide which flows are routed wh= ere. > > If we are thinking about a host-based solution, I have not yet seen a > > solution as to how the host can indicate to the MAG and ultimately to t= he > > MAG which flows should be routed on each access. If we are relying on > > modifications of layer 2 protocols, aren't we defining a solution that = works > > only with some technologies (since for other access technologies it is > > rather unrealistic to modify L2 for IP flow mobility purposes)? If we a= re > > thinking of an LMA-based solution, can we hear of at least one example = of a > > real-life scenario where the LMA would receive such policies, and how s= uch > > delivery would happen? Also, should there be a solution to have policie= s in > > the LMA, how does the LMA actually decide to route flows on one access = or > > the other? E.g., if some flows need to be routed on certain WLAN networ= ks, > > but shall not be routed on other WLAN networks, how does the LMA know w= hich > > specific WLAN network the host is connected to? Perhaps I missed the ab= ility > > for the MAG to know e.g. the WLAN SSID and provide it to the LMA, in wh= ich > > case I would appreciate if somebody could highlight to me where that is > > defined. > > > > I think that, though not integral to the protocol specification, > > understanding what framework the protocol would/needs to fit in is rath= er > > important. > > > > Cheers, > > Stefano > > > > > > On Tue, Feb 1, 2011 at 3:47 PM, > http://Basavaraj.Patil@nokia.com> > > > wrote: > > > > Hello, > > > > We have discussed the flow mobility solutions for Proxy MIP6 previously= at > > IETFs 78 and 79. > > This is a consensus call for adopting this I-D: > > draft-bernardos-netext-pmipv6-flowmob-02 > > as the working group document. > > I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.tx= t > > > > The consensus call will expire on Feb 15th, 2011. Please indicate your > > support or concerns in adopting this I-D as the WG baseline document on > > the mailing list. > > > > Please note that this I-D will serve as the baseline in the WG and will= be > > developed further based on input and feedback from WG members. > > > > -Basavaraj > > > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > > > > > > > > > > > > > > -- > > Stefano M. Faccin > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > May the Force be with you > > > > > > > > > > -- > > Stefano M. Faccin > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > May the Force be with you > > > > > > > > > > -- > > Stefano M. Faccin > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > May the Force be with you > > >=20 >=20 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --=20 Carlos Jes=C3=BAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-pJeNOCHRbRF06Tm+zp9L Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1J4DIACgkQNdy6TdFwT2eZFQCfbN8RYxyLjT4jsqDXB/LtgC55 A/YAn2jBkexF0QyJclecLS+Y860rqpzQ =dZgg -----END PGP SIGNATURE----- --=-pJeNOCHRbRF06Tm+zp9L-- From behcetsarikaya@yahoo.com Wed Feb 2 14:51:04 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30D583A6C88 for ; Wed, 2 Feb 2011 14:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTM4ejel2GtO for ; Wed, 2 Feb 2011 14:51:00 -0800 (PST) Received: from nm15.bullet.mail.sp2.yahoo.com (nm15.bullet.mail.sp2.yahoo.com [98.139.91.85]) by core3.amsl.com (Postfix) with SMTP id 4AB633A6C72 for ; Wed, 2 Feb 2011 14:51:00 -0800 (PST) Received: from [98.139.91.66] by nm15.bullet.mail.sp2.yahoo.com with NNFMP; 02 Feb 2011 22:54:18 -0000 Received: from [98.139.91.47] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 02 Feb 2011 22:54:18 -0000 Received: from [127.0.0.1] by omp1047.mail.sp2.yahoo.com with NNFMP; 02 Feb 2011 22:54:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 851666.8127.bm@omp1047.mail.sp2.yahoo.com Received: (qmail 19206 invoked by uid 60001); 2 Feb 2011 22:54:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1296687258; bh=khmkvPf0FIQsGmkPawRvfol2M9jSKZM6Q1YB37Pibdo=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=3viM6n1SIgSp76mzpXGnTLFVBPm+89QjtYDSZFworiVfAWOsOmRPlxEaJKp03mORyCc/J6p/3NQw8fLHAyQtylEI2TJNp4+UFrOXzOhYhu6CTsAIK3r8DhWm8j98gjlIqVdF2Axpre+o3evsehdqK+YvvfaK/OOEb65Bg258WcM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=pfY+SjgBIY213DRtDhbfRVaepQ2D8zSjfqdNT4LERXPtFSgw5ZtzyK6FCC7V143Diie7FAScliPpn+arrkS7W86IGX8gh9b9xrKdQpC2UwOODYI6a9gsJtXfE40r7CyjCPuE+/a6Z9gzx/QhxFCRzRgXHQcvIv+H5USgP/HMYzk=; Message-ID: <314265.17931.qm@web111409.mail.gq1.yahoo.com> X-YMail-OSG: tBGin8QVM1kpcV3GHAQhcUajzd1IRxOW__79gQWt82EBNKp ETjt_J7fWHO4LM5nZYXbHnVV3GOAv0UZTDroBXlSkiOOsctVvaE4xs_htVkJ hH3vEO8.t2pYjKZVyWXwYZoKJZzHxZ2mM1ghQGz1_h4n3MLXrlVnRuRkEgrI kbxUH2JrXCWmQriltCOniQwUL5A79Q7zrjKaJrLu9VynzJl.fiXV5W2gpFRm mfJch9NI8BglWyWKXsLbUOD7W8YsdGEsZokvCOXi8HVWasTeK57258h4q.zs hH9GgU3wOnmfO2xtm4q1BeyokceRSVyeG5yEFdbxPp.74S9pJujgsa9hiBbs jfGJrfh0odJMLluGwsgZCEuF50yKqu61eA2i_FVV6t43ycmdY5aQ8gGWnTNc Y4xAoNxbideL19UR0PPxClw-- Received: from [71.170.141.239] by web111409.mail.gq1.yahoo.com via HTTP; Wed, 02 Feb 2011 14:54:18 PST X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.108.291010 References: Date: Wed, 2 Feb 2011 14:54:18 -0800 (PST) From: Behcet Sarikaya To: stefano faccin In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 22:51:04 -0000 Hi Stefano,=0A This draft addresses: =0AIP Flow Mobility and Seamless= Offload (IFOM) on S2a and S2b interfaces.=0AAs we already have a solution = (in RFC 6088 and 6089) for s2c, this document aims =0A=0Ato address the mis= sing part.=0A=0AThe issues you raised are out of scope for the document.=0A= =0ARegards,=0A=0ABehcet=0A=0A=0A=0A>Hello JC,=0A>thanks for acknowledging t= hat there is indeed an issue with the current draft. =0A>=0A>For my clarifi= cation, how would the "MAG forward the packet with no problem"? I =0A=0A>am= not sure I am understanding what the sequence of steps would be. =0A>=0A>= =0A>Also, I guess that as you say the solution is not included in the curre= nt draft, =0A>=0A>which means modifying the protocol that we have in the cu= rrent draft.=0A>=0A>Cheers,=0A>Stefano=0A>=0A>=0A>On Wed, Feb 2, 2011 at 12= :37 PM, Zuniga, Juan Carlos =0A> wrote:= =0A>=0A>Hi Stefano,=0A>> =0A>>Thanks for the response (you forgot to copy t= he list again ;). =0A>> =0A>>What I had in mind was what they call Basic so= lution in the document, in which =0A=0A>>the same set of prefixes are assig= ned to different interfaces (or MAGs). In this =0A>>=0A>>case the MN can de= cide (based on policies) to change the flow and send packets =0A=0A>>over a= new interface. The MAG would forward the packet with no problem and upon = =0A>=0A>>receiving this packet the LMA would implicitly know that the MN ha= s performed a =0A>=0A>>flow movement (again, based on policies). At this po= int the LMA would just need =0A>=0A>>to change its routing table accordingl= y and start sending packets for this flow =0A>=0A>>over the new interface (= similar rule to the one already specified for the =0A>>mobile).=0A>> =0A>>I= see this as a lightweight solution to the problem you pointed out that cou= ld =0A=0A>>easily be added to the document.=0A>> =0A>>Jc=0A>> =0A>> =0A>> = =0A>>From:stefano faccin [mailto:sfaccinstd@gmail.com] =0A>>Sent: February = 2, 2011 3:11 PM=0A>>To: Zuniga, Juan Carlos=0A>>=0A>>Subject: Re: [netext] = Consensus call to adopt I-D: =0A>>draft-bernardos-netext-pmipv6-flowmob as = WG doc =0A>>=0A>> =0A>>Hi JC,=0A>>=0A>>As you say in 3GPP for the MN-based = model this has been solved. However, if we =0A=0A>>want to apply a similar = solution, we go back to the argument that it would =0A>>require the MN to b= e able to communicate the decisions to the MAG/LMA but, as we =0A>>=0A>>dis= cussed previously, we don't have a solution for that. This means that =0A>>= applying this protocol with a model similar to the one currently specified = in =0A>>IETF and 3GPP requires the definition of a solution that does not y= et exist (at =0A>=0A>>Layer 3 or at Layer 2). I am concerned about developi= ng only some pieces of a =0A>>solution.=0A>>=0A>>Alternatively, as you say = the MAG reacts. However, it is not clear to me that =0A>>the current draft = describes how that happens.=0A>>=0A>>Cheers,=0A>>Stefano=0A>>On Wed, Feb 2,= 2011 at 11:56 AM, Zuniga, Juan Carlos =0A>> wrote:=0A>>Stefano,=0A>> =0A>>As much as I agree with most of your po= ints about the problem from the 3GPP =0A>>architecture point of view, I thi= nk that there is more than one solution.=0A>> =0A>>We are assuming of cours= e that what we have is a scenario where both networks =0A>>are in the same = PMIP domain and IP flow mobility is then possible. You point out =0A>>=0A>>= that there are no means to convey policies to the LMA or MAG. However, ther= e are =0A>>=0A>>means to convey these policies to the MN as it is already d= efined in 3GPP for =0A>>the client-based IP flow mobility case (i.e. ANDSF)= . Hence, one different =0A>>solution could be to let the MN apply the polic= y by moving the flow and make the =0A>>=0A>>MAG and LMA =E2=80=9Creact=E2= =80=9D to the IP flow change assuming that the flow change was made =0A>>= =0A>>according to the policy being applied at the mobile.=0A>> =0A>>I would= see this scenario equivalent to the one specified in 3GPP from the point = =0A>>=0A>>of view of node=E2=80=99s responsibilities, don=E2=80=99t you thi= nk?=0A>> =0A>>Jc=0A>> =0A>> =0A>>From:netext-bounces@ietf.org [mailto:netex= t-bounces@ietf.org] On Behalf Of =0A>>stefano faccin=0A>>Sent: February 2, = 2011 2:41 PM=0A>>To: Rajeev Koodli; netext@ietf.org=0A>>=0A>>Subject: Re: [= netext] Consensus call to adopt I-D: =0A>>draft-bernardos-netext-pmipv6-flo= wmob as WG doc=0A>> =0A>>Sorry, I forgot to reply to the whole list. =0A>>C= heers,=0A>>Stefano=0A>>On Wed, Feb 2, 2011 at 11:29 AM, stefano faccin wrote:=0A>>Hi Rajeev,=0A>>in current solution the policy= is in sync, since it is the ANDSF (the network =0A>>counterpart of the MN = for the policy) that configures it in the MN. That does =0A>>not mean that = the LMA has such policy. =0A>>=0A>>=0A>>Cheers,=0A>>Stefano=0A>> =0A>>On We= d, Feb 2, 2011 at 11:46 AM, Rajeev Koodli wrote:=0A>>= =0A>>Hi Gerardo,=0A>> * my point is that someone/something is confi= guring the policy on the =0A>>MN =0A>>=0A>>which needs to be in sync w= ith the MN=E2=80=99s partner, i.e., the network. If this =0A>>=0A>>is not t= he case, please let me know. =0A>>=0A>> * The last I heard, PM= IP6 is applicable on the eHRPD (trusted non-3GPP =0A>=0A>>network). Also, 3= 3.402 does not specify whether a particular type of access =0A>>=0A>>n= etwork (such as WLAN) is considered trusted or untrusted (although a = =0A>>majority of the WLAN access could be considered untrusted today).= =0A>>=0A>>=0A>>-Rajeev=0A>>=0A>>=0A>>=0A>>On 2/2/11 11:16 AM, "Giaretta, G= erardo" wrote:=0A>>Hi Rajeev,=0A>>> =0A>>>A couple = of considerations on this:=0A>>> =0A>>>- This draft assumes there i= s consistency in the rules. This is a new =0A=0A>>>requirement for the syst= em architecture where this solution will be applied. =0A>>>There is no this= requirement for other solutions already adopted by IETF and =0A>>>3GPP. In= my view this seems a fairly important issue.=0A>>>=0A>>>- The rout= ing decisions based on WLAN SSID are different from =0A>>>trusted/untrusted= . Note also that PMIPv6 cannot be used in trusted networks so =0A>=0A>>>it = is not clear at all what you are referring to.=0A>>>=0A>>> =0A>>>Gerardo = =0A>>> =0A>>>=0A>>>From:netext-bounces@ietf.org [mailto:netext-bounces@ietf= .org] On Behalf Of =0A>>>Rajeev Koodli=0A>>>Sent: Wednesday, February 02, 2= 011 11:28 AM=0A>>>To: stefano faccin=0A>>>Cc: netext@ietf.org; Basavaraj.Pa= til@nokia.com=0A>>>Subject: Re: [netext] Consensus call to adopt I-D: =0A>>= >draft-bernardos-netext-pmipv6-flowmob as WG doc=0A>>>=0A>>>=0A>>>Stefano,= =0A>>>=0A>>>Regardless of how the policy is configured on the LMA, there is= a consistency of =0A>>>=0A>>>the rules which needs to be ensured regardles= s. Whatever the entity (OMA-DM?!) =0A>=0A>>>is that configures the policy h= as to ensure such a consistency.=0A>>>=0A>>>We can debate about how policy = interaction works, but that=E2=80=99s another topic. I =0A=0A>>>would note = that there are choices here (modulo respective pros and cons).=0A>>>=0A>>>I= didn=E2=80=99t suggest that an operator should just trust the software on = a MN, =0A>>>although I suspect some device vendors might argue for their ro= bustness =0A>>>(surprise?). =0A>>>=0A>>>=0A>>>I would frame the WLAN access= problem as whether the access is considered =0A>>>trusted or not. Accordin= gly, you apply the policy.=0A>>>=0A>>>-Rajeev=0A>>>=0A>>>=0A>>>On 2/2/11 10= :50 AM, "stefano faccin" wrote:=0A>>>Raj,=0A>>>thank= s for the reply.=0A>>>=0A>>>If the LMA has statically configured policies, = how do we ensure that the MN has =0A>>=0A>>>the same policies? That would m= ean implicitly assuming that the policies =0A>>>provisioned to the MN by th= e ANDSF "always" match what has been set in the LMA, =0A>>=0A>>>which I thi= nk it is unrealistic because the policies change over time, and every =0A>>= >=0A>>>time you need to update all the LMAs, which has a considerable opera= tional cost. =0A>>>=0A>>>Instead, if we leave the MN to make the choice, th= ere are easy and well =0A>>>specified mechanisms that allow the provisionin= g of policies in the MN and for =0A>=0A>>>the MN to make such decision and = communicate it to the network, so that the =0A>>>network can =0A>>>=0A>>>= =0A>>>As for extensions to Gx, I am not stating that in theory one could ex= tend Gx. =0A=0A>>>However, at present such solution does not exists, and wi= thout it, I do not see =0A>>=0A>>>how the draft is applicable to 3GPP that = is at present the only potential =0A>>>customer identified (I guess I did n= ot see any other identified?) =0A>>>=0A>>>Even assuming that Gx could be m= odified, the issue of the per-access network =0A>>>granularity remains. Eve= n if the LMA has the right policies in place, the LMA =0A=0A>>>has no way o= f knowing exactly what access network of a specific access =0A>>>technology= (e.g. which SSID for WLAN0 the MN is connecting to. =0A>>>=0A>>>=0A>>>I ca= nnot agree with your assumption below that if the MN connects to an SSID it= =0A>>=0A>>>is because the operator is OK with routing traffic on that SSID= , and that we =0A>>>should just "trust the software on the MN". There are t= wo aspects to =0Aconsider:=0A>>>1) whether it is OK for certain traffic to = be routed at all over a certain =0A>>>access access network of a specific a= ccess technology=0A>>>2) how different traffic should be routed over differ= ent access networks of =0A>>>different access technologies=0A>>>=0A>>>Regar= ding these two points, the issue is whether the operator wants to allow =0A= >>>traffic e.g. over a certain SSID or not. So, in that case, it is obvious= as you =0A>>=0A>>>say that if the MN has connected to an SSID configured b= y the operator in the =0A=0A>>>MN, then traffic could be allowed over that = SSID. However, we need to consider =0A>=0A>>>that 3GPP allows the decision = of which WLAN the MN can connect to based on user =0A>>=0A>>>preferences. T= his means that my MN can e.g. connect to my home WLAN (which is =0A=0A>>>no= t controlled necessarily by the operator and whose SSID the operator does n= ot =0A>>=0A>>>know) or to a coffee shop WLAN, even if the device does not h= ave those SSID =0A>>>configured. Those are typical examples of untrusted WL= AN access networks. =0A>>>Therefore, in such cases, just because the MN has= connected to a WLAN SSID, does =0A>>>=0A>>>not mean that the operator want= s to route certain traffic over that SSID just =0A=0A>>>because the policy = says "route traffic X over WLAN". =0A>>>=0A>>>=0A>>>That brings us to a sol= ution that, if applied to 3GPP, provides less =0A>>>functionality than what= is available and has been specified today, so back to my =0A>>>=0A>>>point= above.=0A>>>=0A>>>Unfortunately, there is no solution I am aware of that a= llows the WLAN network =0A>=0A>>>to indicate to the MAG/LMA the specific SS= ID (and as you say, there is no easy =0A>=0A>>>solution for that). Due to t= his and the points above about policy provisioning, =0A>>=0A>>>it means tha= t the applicability of this solution to a real case like 3GPP =0A>>>depends= on the feasibility of extending policy mechanisms in 3GPP, and the =0A>>>a= bility to have a solution where the WLAN network provides the SSID informat= ion =0A>>=0A>>>to the MAG/LMA. Moreover, the provisioning of such SSID is n= ot in the scope of =0A>=0A>>>IETF, but not even of 3GPP (since the interfac= e between the WLAN AP and the ePDG =0A>>>=0A>>>is not defined), thus I wond= er how this could be defined at all (I am afraid of =0A>>=0A>>>asking what = magic should happen here). So, now we have two big dependencies. =0A>>>=0A>= >>=0A>>>In general, I am also wondering if there is a customer that has ask= ed us to =0A>>>define this solution. I am not aware of any but I may have m= issed that.=0A>>>=0A>>>Cheers,=0A>>>Stefano=0A>>>=0A>>>On Wed, Feb 2, 2011 = at 10:44 AM, Rajeev Koodli wrote:=0A>>>=0A>>>Hi Stefano= ,=0A>>>=0A>>>You make two interesting points: First, the defined solution s= hould be useful =0A=0A>>>for 3GPP deployments. Second, if it=E2=80=99s not = defined today in 3GPP, it=E2=80=99s not =0A>>>useful.=0A>>>=0A>>>I tend to = agree with you on the first =E2=80=93 3GPP is a big potential customer. =0A= >>>I cannot agree with your second point.=0A>>>=0A>>>There are multiple way= s I could envision policy on the LMA. Locally configured =0A>=0A>>>policy i= s one (which we use today in deployments) that does not need Gx =0A>>>inter= action. Gx extensions can be proposed in the future. I hope you are not =0A= >>>suggesting that these are not feasible choices.=0A>>>=0A>>>For the MN (I= ETF term for UE) to even connect to the MAG via WLAN today, you =0A>>>need = an IPsec termination point (ePDG). If the operator pre-configures the list = =0A>>=0A>>>of SSIDs or there is some out-of-band mechanism to inform the MN= which SSID is =0A>=0A>>>=E2=80=9Cwhite-listed=E2=80=9D, then I expect the = MN to decide when to connect to the ePDG and =0A>=0A>>>hence the MAG. At th= is point, the MN is already on the WLAN the operator cares =0A>=0A>>>about = I presume. =0A>>>=0A>>>There is no easy way for the network (LMA, MAG) to k= now what SSID the MN is =0A>>>connected to =E2=80=93 the network has to eit= her trust the software on the MN or the =0A>>>WLAN infrastructure has to pr= ovide the SSID information to the network. =0A>>>=0A>>>=0A>>>-Rajeev=0A>>>= =0A>>>=0A>>>=0A>>>On 2/2/11 9:56 AM, "stefano faccin" >> > wrote:=0A>>>Hello rajeev,=0A>>>the u= se of PCRF is an interesting suggestion. However, unfortunately, PCRF does = =0A>>=0A>>>not contain any policies or information that will tell the LMA w= hat are the =0A>>>policies to be used for decisions of IP flow mobility. Th= is is not part of =0A>>>current PCC functionality, and there is no work ong= oing or planned to extend PCC =0A>>>=0A>>>in such way. Therefore, the appli= cability of the solution in this draft would =0A=0A>>>hinge on hypotetical = future solutions and not on a current solution for the open =0A>>>=0A>>>iss= ues, which brings us back to my point that we are defining a solution with = =0A=0A>>>open issues for which there is not a single realistic solution out= there, thus =0A>=0A>>>making this draft not applicable to a real scenario.= =0A>>>=0A>>>I am not thinking of the UE connecting to more than one WLAN at= the same time, =0A>=0A>>>but the UE being able to connect to different WLA= Ns (one at a time) because the =0A>>=0A>>>UE is e.g. provisioned with a lis= t of SSIDs or the UE discovers a hotspot =0A>>>somewhere. I am talking abou= t the scenario where the UE is capable to connect to =0A>>>=0A>>>WLAN, but = the operator has different policies wrt which WLAN the UE should use =0A>= =0A>>>or not.=0A>>>=0A>>>If you have followed the work in 3GPP, it is clear= that operators have interest =0A>>=0A>>>in applying policies not only at R= AT level, but also at access network level =0A>>>(please see how ANDSF was = defined and why). I guess we can all agree that an =0A>>>operator deploying= PMIP-based mobility may be interested in having policies that =0A>>>=0A>>>= allow traffic on the WLAN the operator owns or that belongs to a roaming = =0A>>>partner, while not allowing traffic on WLAN of other operators for wh= ich it =0A>>>might need to pay an extra fee or where e.g. no QoS can be gua= ranteed. That =0A>>>means that the entity deciding whether traffic needs to= be routed on WLAN or not =0A>>>=0A>>>cannot just consider "WLAN is availab= le", but "WLAN SSIDx is available", so that =0A>>>=0A>>>the decision can be= based on the operator preferences as to which WLAN certain =0A>=0A>>>traff= ic needs to be routed on. =0A>>>=0A>>>=0A>>>If the draft allows decisions t= o be made only at the RAT level, then we have an =0A>>=0A>>>issue because w= e are defining a solution that should be applicable to 3GPP but =0A>=0A>>>d= oes not meet the deployment scenarios of interest. In other words, if we wa= nt =0A>=0A>>>to make this solution applicable e.g. to 3GPP, we need to be a= ble to provide the =0A>>>=0A>>>same functionality available today in 3GPP w= ith other solution in order to =0A>>>satisfy the use cases supported by 3GP= P, and not step backwards in terms of what =0A>>>=0A>>>can be supported.=0A= >>>=0A>>>Cheers,=0A>>>=0A>>>Stefano=0A>>>=0A>>>On Wed, Feb 2, 2011 at 9:55 = AM, Rajeev Koodli >> > wro= te:=0A>>>=0A>>>Hi Stefano,=0A>>>=0A>>>Thanks for your input.=0A>>>=0A>>>I e= xpect the LMA interacting with PCRF for policy rules specific to the =0A>>>= subscriber for different RAT types.=0A>>>You are right that the LMA does no= t know the SSID the mobile is connected to. =0A=0A>>>It=E2=80=99s not clear= if the MAG can get that from the MN either without additional =0A>>>signal= ing. However, the LMA knows that the MN is connected to WLAN; so it can =0A= =0A>>>apply the policy at the RAT type level. Are you thinking of the MN co= nnecting to =0A>>>=0A>>>more than one WLAN network (and each of those conne= ctions coming back to the =0A>>>LMA)? If so, please explain the scenario.= =0A>>>=0A>>>Regards,=0A>>>=0A>>>-Rajeev=0A>>>=0A>>>=0A>>>=0A>>>=0A>>>On 2/1= /11 6:39 PM, "stefano faccin" >> > wrote:=0A>>>Raj,=0A>>>thanks = for the email.=0A>>>=0A>>>I need to apologize in advance if my questions ha= ve already been answered before =0A>>>=0A>>>(though I cannot find a conclus= ive answer anywhere).=0A>>>=0A>>>I think that a protocol that is developed = in NETEXT (or other groups) should =0A>>>have at least a potential realisti= c scenario for applicability.=0A>>>=0A>>>In terms of applicability, though = it is not part of the protocol definition per =0A>>=0A>>>se, unless there a= re solutions in place for either the host to indicate to the =0A>=0A>>>netw= ork where the flows should be routed or for the LMA to receive somehow from= =0A>>=0A>>>somewhere some policies, the solution cannot really provide flo= w mobility since =0A>>=0A>>>there is no way to decide which flows are route= d where. If we are thinking about =0A>>>=0A>>>a host-based solution, I have= not yet seen a solution as to how the host can =0A>>>indicate to the MAG a= nd ultimately to the MAG which flows should be routed on =0A=0A>>>each acce= ss. If we are relying on modifications of layer 2 protocols, aren't we =0A>= >=0A>>>defining a solution that works only with some technologies (since fo= r other =0A>>>access technologies it is rather unrealistic to modify L2 for= IP flow mobility =0A>=0A>>>purposes)? If we are thinking of an LMA-based s= olution, can we hear of at least =0A>>=0A>>>one example of a real-life scen= ario where the LMA would receive such policies, =0A>=0A>>>and how such deli= very would happen? Also, should there be a solution to have =0A>>>policies = in the LMA, how does the LMA actually decide to route flows on one =0A>>>ac= cess or the other? E.g., if some flows need to be routed on certain WLAN = =0A>>>networks, but shall not be routed on other WLAN networks, how does th= e LMA know =0A>>=0A>>>which specific WLAN network the host is connected to?= Perhaps I missed the =0A>>>ability for the MAG to know e.g. the WLAN SSID = and provide it to the LMA, in =0A>>>which case I would appreciate if somebo= dy could highlight to me where that is =0A=0A>>>defined.=0A>>>=0A>>>I think= that, though not integral to the protocol specification, understanding =0A= >=0A>>>what framework the protocol would/needs to fit in is rather importan= t. =0A>>>=0A>>>=0A>>>Cheers,=0A>>>Stefano=0A>>>=0A>>>=0A>>>On Tue, Feb 1, 2= 011 at 3:47 PM, >> > =0A>wrote:=0A>>>=0A>>>Hello= ,=0A>>>=0A>>>We have discussed the flow mobility solutions for Proxy MIP6 p= reviously at=0A>>>IETFs 78 and 79.=0A>>>This is a consensus call for adopti= ng this I-D:=0A>>>draft-bernardos-netext-pmipv6-flowmob-02=0A>>>as the work= ing group document.=0A>>>I-D: http://www.ietf.org/id/draft-bernardos-netext= -pmipv6-flowmob-02.txt=0A>>>=0A>>>The consensus call will expire on Feb 15t= h, 2011. Please indicate your=0A>>>support or concerns in adopting this I-D= as the WG baseline document on=0A>>>the mailing list.=0A>>>=0A>>>Please no= te that this I-D will serve as the baseline in the WG and will be=0A>>>deve= loped further based on input and feedback from WG members.=0A>>>=0A>>>-Basa= varaj=0A>>>=0A>>>_______________________________________________=0A>>>netex= t mailing list=0A>>>netext@ietf.org =0A>>>https://www.ietf.org/mailman/listinfo/netext=0A>>>=0A>>> = =0A>>> =0A>>=0A>>=0A>>=0A>>-- =0A>>Stefano M. Faccin=0A>>=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A>>May the Force be with you=0A>>=0A>= >=0A>>=0A>>-- =0A>>Stefano M. Faccin=0A>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=0A>>May the Force be with you=0A>>=0A>>=0A>>=0A>>-- = =0A>>Stefano M. Faccin=0A>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=0A>>May the Force be with you=0A>=0A>=0A>-- =0A>Stefano M. Faccin=0A= >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A>May the Force be= with you=0A>=0A=0A=0A From julien.ietf@gmail.com Wed Feb 2 15:03:16 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE7A23A6C7A for ; Wed, 2 Feb 2011 15:03:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqwmfUTmKpxN for ; Wed, 2 Feb 2011 15:03:15 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 8386B3A6864 for ; Wed, 2 Feb 2011 15:03:15 -0800 (PST) Received: by fxm9 with SMTP id 9so558372fxm.31 for ; Wed, 02 Feb 2011 15:06:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=msS7MagUSZlQGkju9owFf5/krQT3LL0vDcVzDFaNxYY=; b=xXMLwkFzJ/vHjFmjrqlE4mBbcS/EcXBFzh/vu0nlFDvWIFR95Y6vLabcb+YX0Nehmi qC3YNJqTZJ3lbmF3YAPmRibX9R8R7E0kmW9qn9rTjgCtQbp4Tk+RP/29UoPswGH1gc41 Z+YQ6sFSRb3dc9L4NJaoQXPCh7meYPygZGaFg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VvawIchAt2Iz48wPMy2LYbRcGsCBMhwlUrvuSEvgnjCWtWyTD8+oBPzo5hGde+ePAc quk5BZPdL4FMTFSrEQdDCfCzVgpFHUsZusjDoa6mcEctVg5jkh546HBGTD3eZF9+YxF5 KuNfeuPIPqe82+14SeogPZeUX4Qq1zlnNqIFE= MIME-Version: 1.0 Received: by 10.103.243.16 with SMTP id v16mr5194774mur.57.1296687994351; Wed, 02 Feb 2011 15:06:34 -0800 (PST) Received: by 10.103.221.9 with HTTP; Wed, 2 Feb 2011 15:06:34 -0800 (PST) In-Reply-To: References: Date: Wed, 2 Feb 2011 15:06:34 -0800 Message-ID: From: Julien Laganier To: Basavaraj.Patil@nokia.com Content-Type: multipart/alternative; boundary=0016367ed4fb49b15d049b54b362 Cc: netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 23:03:16 -0000 --0016367ed4fb49b15d049b54b362 Content-Type: text/plain; charset=ISO-8859-1 Raj, As with the other draft (logical interface), I have raised a number of issues with this draft that in my humble opinion have not been addressed adequately, and thus at this stage I believe that asking for adoption is premature. In other words, I'd like the issues that I've raised to be addressed by the authors before I feel comfortable having an opinion on whether or not this draft is a good basis to progress the flow mobility extensions. Thank you for your consideration, --julien On Tue, Feb 1, 2011 at 3:47 PM, wrote: > > Hello, > > We have discussed the flow mobility solutions for Proxy MIP6 previously at > IETFs 78 and 79. > This is a consensus call for adopting this I-D: > draft-bernardos-netext-pmipv6-flowmob-02 > as the working group document. > I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt > > The consensus call will expire on Feb 15th, 2011. Please indicate your > support or concerns in adopting this I-D as the WG baseline document on > the mailing list. > > Please note that this I-D will serve as the baseline in the WG and will be > developed further based on input and feedback from WG members. > > -Basavaraj > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > --0016367ed4fb49b15d049b54b362 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Raj,

As with the other draft (logical interface), I have= raised a number of issues with this draft that in my humble opinion have n= ot been addressed adequately, and thus at this stage I believe that asking = for adoption is premature. In other words, I'd like the issues that I&#= 39;ve raised to be addressed by the authors before I feel comfortable havin= g an opinion on whether or not this draft is a good basis to progress the f= low mobility extensions.

Thank you for your consideration,

<= div>--julien=A0

On Tue, Feb 1, 2011 at 3:= 47 PM, <= Basavaraj.Patil@nokia.com> wrote:

Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= br> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-p= mipv6-flowmob-02.txt

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= br> developed further based on input and feedback from WG members.

-Basavaraj

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

--0016367ed4fb49b15d049b54b362-- From sfaccinstd@gmail.com Wed Feb 2 15:15:17 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E15CA3A6C85 for ; Wed, 2 Feb 2011 15:15:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.136 X-Spam-Level: X-Spam-Status: No, score=-103.136 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dIN1W09c4XN for ; Wed, 2 Feb 2011 15:15:13 -0800 (PST) Received: from mail-qy0-f194.google.com (mail-qy0-f194.google.com [209.85.216.194]) by core3.amsl.com (Postfix) with ESMTP id 7A2493A6BC2 for ; Wed, 2 Feb 2011 15:15:13 -0800 (PST) Received: by qyk4 with SMTP id 4so41195qyk.1 for ; Wed, 02 Feb 2011 15:18:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qkte3M36Rfx2dv5KwrO1lU1xVs/tcIz1EmSYyoxb4Ls=; b=N61ic7QDBm2Ly/REkeTqFIuGVUqGW5iXlqgFZjZSDgMAE23pfo17Z/GHN6wj7ENLMh 5w1wo3alEaNsET4JOQpRZeITCiwj3nTuStxTN7YbhmAgHnm0UjUXWXgPe0GLJ1FsUsJx YeTYGujiF9bHIR6nfxMiBLXY941W6GAmgBlns= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qZgLnlFKLyCIH7fqa7xToPpvxUFl32Qp3Xe0BivuJb4CE1iP9ZfKuZQycnZc28rPK9 CJznuzAtAixOJk3FieP/DJX1xbXcmNh2ZVeqGwAOEZ/B3zBmXwNYc6jUWIWF/pYicikH GsOCxKPbiJBiJm8Grm7uoSl/DSMRvGhanDF3A= MIME-Version: 1.0 Received: by 10.229.233.19 with SMTP id jw19mr6926198qcb.24.1296688713881; Wed, 02 Feb 2011 15:18:33 -0800 (PST) Received: by 10.229.20.70 with HTTP; Wed, 2 Feb 2011 15:18:33 -0800 (PST) In-Reply-To: <1296687154.3593.15.camel@acorde.it.uc3m.es> References: <1296687154.3593.15.camel@acorde.it.uc3m.es> Date: Wed, 2 Feb 2011 15:18:33 -0800 Message-ID: From: stefano faccin To: cjbc@it.uc3m.es Content-Type: multipart/alternative; boundary=0016363b8b702cdfab049b54de55 Cc: netext@ietf.org, "Zuniga, Juan Carlos" Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 23:15:18 -0000 --0016363b8b702cdfab049b54de55 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello Carlos, unfortunately I beg to disagree. Indeed we are chartered to do this work, but at the same time developing a protocol that due to technical limitation= s cannot be adopted in realistic scenarios seems a fruitless effort. I would also beg to disagree that 3GPP will have to modify their architecture to allow this solution to work. I believe that, if 3GPP is to be a customer, the protocol must be developed to fit the need of the customer, not the other way around. Cheers, Stefano 2011/2/2 Carlos Jes=FAs Bernardos Cano > Hi Stefano, > > Thanks for the comments on the draft. Two comments from my side: > > - Regarding the comment about the potential realistic scenario for > applicability, this is not an issue of this solution (or any other), if > it is an issue at all. We are chartered to work on protocol extensions > for flow mobility without introducing any changes to the IP stack of the > MN. IMHO all your comments on this regard relates to the charter itself, > not this draft. > > - Regarding the comments about the "lack of support from 3GPP", I > acknowledge that 3GPP is an important potential customer, but as far as > I know, we are not chartered to come up with a 3GPP-only solution, and I > think it's fair to design a solution that works under certain > assumptions, as long as those assumptions cannot realistically be met in > a particular network deployment. I think it's fair to expect that 3GPP > may need to add also extensions to make this solution work in their > architecture. > > Thanks, > > Carlos > > On Wed, 2011-02-02 at 14:26 -0800, stefano faccin wrote: > > Hello JC, > > thanks for acknowledging that there is indeed an issue with the current > > draft. > > > > For my clarification, how would the "MAG forward the packet with no > > problem"? I am not sure I am understanding what the sequence of steps > would > > be. > > > > Also, I guess that as you say the solution is not included in the curre= nt > > draft, which means modifying the protocol that we have in the current > draft. > > > > Cheers, > > Stefano > > > > On Wed, Feb 2, 2011 at 12:37 PM, Zuniga, Juan Carlos < > > JuanCarlos.Zuniga@interdigital.com> wrote: > > > > > Hi Stefano, > > > > > > > > > > > > Thanks for the response (you forgot to copy the list again ;). > > > > > > > > > > > > What I had in mind was what they call Basic solution in the document, > in > > > which the same set of prefixes are assigned to different interfaces (= or > > > MAGs). In this case the MN can decide (based on policies) to change t= he > flow > > > and send packets over a new interface. The MAG would forward the pack= et > with > > > no problem and upon receiving this packet the LMA would implicitly kn= ow > that > > > the MN has performed a flow movement (again, based on policies). At > this > > > point the LMA would just need to change its routing table accordingly > and > > > start sending packets for this flow over the new interface (similar > rule to > > > the one already specified for the mobile). > > > > > > > > > > > > I see this as a lightweight solution to the problem you pointed out > that > > > could easily be added to the document. > > > > > > > > > > > > Jc > > > > > > > > > > > > > > > > > > > > > > > > *From:* stefano faccin [mailto:sfaccinstd@gmail.com] > > > *Sent:* February 2, 2011 3:11 PM > > > *To:* Zuniga, Juan Carlos > > > > > > *Subject:* Re: [netext] Consensus call to adopt I-D: > > > draft-bernardos-netext-pmipv6-flowmob as WG doc > > > > > > > > > > > > Hi JC, > > > > > > As you say in 3GPP for the MN-based model this has been solved. > However, if > > > we want to apply a similar solution, we go back to the argument that = it > > > would require the MN to be able to communicate the decisions to the > MAG/LMA > > > but, as we discussed previously, we don't have a solution for that. > This > > > means that applying this protocol with a model similar to the one > currently > > > specified in IETF and 3GPP requires the definition of a solution that > does > > > not yet exist (at Layer 3 or at Layer 2). I am concerned about > developing > > > only some pieces of a solution. > > > > > > Alternatively, as you say the MAG reacts. However, it is not clear to > me > > > that the current draft describes how that happens. > > > > > > Cheers, > > > Stefano > > > > > > On Wed, Feb 2, 2011 at 11:56 AM, Zuniga, Juan Carlos < > > > JuanCarlos.Zuniga@interdigital.com> wrote: > > > > > > Stefano, > > > > > > > > > > > > As much as I agree with most of your points about the problem from th= e > 3GPP > > > architecture point of view, I think that there is more than one > solution. > > > > > > > > > > > > We are assuming of course that what we have is a scenario where both > > > networks are in the same PMIP domain and IP flow mobility is then > possible. > > > You point out that there are no means to convey policies to the LMA o= r > MAG. > > > However, there are means to convey these policies to the MN as it is > already > > > defined in 3GPP for the client-based IP flow mobility case (i.e. > ANDSF). > > > Hence, one different solution could be to let the MN apply the policy > by > > > moving the flow and make the MAG and LMA =93react=94 to the IP flow c= hange > > > assuming that the flow change was made according to the policy being > applied > > > at the mobile. > > > > > > > > > > > > I would see this scenario equivalent to the one specified in 3GPP fro= m > the > > > point of view of node=92s responsibilities, don=92t you think? > > > > > > > > > > > > Jc > > > > > > > > > > > > > > > > > > *From:* netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] *On > > > Behalf Of *stefano faccin > > > *Sent:* February 2, 2011 2:41 PM > > > *To:* Rajeev Koodli; netext@ietf.org > > > > > > > > > *Subject:* Re: [netext] Consensus call to adopt I-D: > > > draft-bernardos-netext-pmipv6-flowmob as WG doc > > > > > > > > > > > > Sorry, I forgot to reply to the whole list. > > > Cheers, > > > Stefano > > > > > > On Wed, Feb 2, 2011 at 11:29 AM, stefano faccin > > > wrote: > > > > > > Hi Rajeev, > > > in current solution the policy is in sync, since it is the ANDSF (the > > > network counterpart of the MN for the policy) that configures it in t= he > MN. > > > That does not mean that the LMA has such policy. > > > > > > Cheers, > > > Stefano > > > > > > > > > > > > On Wed, Feb 2, 2011 at 11:46 AM, Rajeev Koodli > wrote: > > > > > > > > > Hi Gerardo, > > > > > > - my point is that someone/something is configuring the policy on > the > > > MN which needs to be in sync with the MN=92s partner, i.e., the > network. If > > > this is not the case, please let me know. > > > - The last I heard, PMIP6 is applicable on the eHRPD (trusted > non-3GPP > > > network). Also, 33.402 does not specify whether a particular type = of > access > > > network (such as WLAN) is considered trusted or untrusted (althoug= h > a > > > majority of the WLAN access could be considered untrusted today). > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > On 2/2/11 11:16 AM, "Giaretta, Gerardo" wrote= : > > > > > > Hi Rajeev, > > > > > > A couple of considerations on this: > > > > > > - This draft assumes there is consistency in the rules. This = is > a > > > new requirement for the system architecture where this solution will = be > > > applied. There is no this requirement for other solutions already > adopted by > > > IETF and 3GPP. In my view this seems a fairly important issue. > > > > > > - The routing decisions based on WLAN SSID are different from > > > trusted/untrusted. Note also that PMIPv6 cannot be used in trusted > networks > > > so it is not clear at all what you are referring to. > > > > > > > > > Gerardo > > > > > > > > > *From:* netext-bounces@ietf.org [mailto:netext-bounces@ietf.org< > netext-bounces@ietf.org>] > > > *On Behalf Of *Rajeev Koodli > > > *Sent:* Wednesday, February 02, 2011 11:28 AM > > > *To:* stefano faccin > > > *Cc:* netext@ietf.org; Basavaraj.Patil@nokia.com > > > *Subject:* Re: [netext] Consensus call to adopt I-D: > > > draft-bernardos-netext-pmipv6-flowmob as WG doc > > > > > > > > > Stefano, > > > > > > Regardless of how the policy is configured on the LMA, there is a > > > consistency of the rules which needs to be ensured regardless. Whatev= er > the > > > entity (OMA-DM?!) is that configures the policy has to ensure such a > > > consistency. > > > > > > We can debate about how policy interaction works, but that=92s anothe= r > topic. > > > I would note that there are choices here (modulo respective pros and > cons). > > > > > > I didn=92t suggest that an operator should just trust the software on= a > MN, > > > although I suspect some device vendors might argue for their robustne= ss > > > (surprise?). > > > > > > I would frame the WLAN access problem as whether the access is > considered > > > trusted or not. Accordingly, you apply the policy. > > > > > > -Rajeev > > > > > > > > > On 2/2/11 10:50 AM, "stefano faccin" wrote: > > > Raj, > > > thanks for the reply. > > > > > > If the LMA has statically configured policies, how do we ensure that > the MN > > > has the same policies? That would mean implicitly assuming that the > policies > > > provisioned to the MN by the ANDSF "always" match what has been set i= n > the > > > LMA, which I think it is unrealistic because the policies change over > time, > > > and every time you need to update all the LMAs, which has a > considerable > > > operational cost. Instead, if we leave the MN to make the choice, the= re > are > > > easy and well specified mechanisms that allow the provisioning of > policies > > > in the MN and for the MN to make such decision and communicate it to > the > > > network, so that the network can > > > > > > As for extensions to Gx, I am not stating that in theory one could > extend > > > Gx. However, at present such solution does not exists, and without it= , > I do > > > not see how the draft is applicable to 3GPP that is at present the on= ly > > > potential customer identified (I guess I did not see any other > identified?) > > > > > > > > > Even assuming that Gx could be modified, the issue of the per-access > > > network granularity remains. Even if the LMA has the right policies i= n > > > place, the LMA has no way of knowing exactly what access network of a > > > specific access technology (e.g. which SSID for WLAN0 the MN is > connecting > > > to. > > > > > > I cannot agree with your assumption below that if the MN connects to = an > > > SSID it is because the operator is OK with routing traffic on that > SSID, and > > > that we should just "trust the software on the MN". There are two > aspects to > > > consider: > > > 1) whether it is OK for certain traffic to be routed at all over a > certain > > > access access network of a specific access technology > > > 2) how different traffic should be routed over different access > networks of > > > different access technologies > > > > > > Regarding these two points, the issue is whether the operator wants t= o > > > allow traffic e.g. over a certain SSID or not. So, in that case, it i= s > > > obvious as you say that if the MN has connected to an SSID configured > by the > > > operator in the MN, then traffic could be allowed over that SSID. > However, > > > we need to consider that 3GPP allows the decision of which WLAN the M= N > can > > > connect to based on user preferences. This means that my MN can e.g. > connect > > > to my home WLAN (which is not controlled necessarily by the operator > and > > > whose SSID the operator does not know) or to a coffee shop WLAN, even > if the > > > device does not have those SSID configured. Those are typical example= s > of > > > untrusted WLAN access networks. Therefore, in such cases, just becaus= e > the > > > MN has connected to a WLAN SSID, does not mean that the operator want= s > to > > > route certain traffic over that SSID just because the policy says > "route > > > traffic X over WLAN". > > > > > > That brings us to a solution that, if applied to 3GPP, provides less > > > functionality than what is available and has been specified today, so > back > > > to my point above. > > > > > > Unfortunately, there is no solution I am aware of that allows the WLA= N > > > network to indicate to the MAG/LMA the specific SSID (and as you say, > there > > > is no easy solution for that). Due to this and the points above about > policy > > > provisioning, it means that the applicability of this solution to a > real > > > case like 3GPP depends on the feasibility of extending policy > mechanisms in > > > 3GPP, and the ability to have a solution where the WLAN network > provides the > > > SSID information to the MAG/LMA. Moreover, the provisioning of such > SSID is > > > not in the scope of IETF, but not even of 3GPP (since the interface > between > > > the WLAN AP and the ePDG is not defined), thus I wonder how this coul= d > be > > > defined at all (I am afraid of asking what magic should happen here). > So, > > > now we have two big dependencies. > > > > > > In general, I am also wondering if there is a customer that has asked > us to > > > define this solution. I am not aware of any but I may have missed tha= t. > > > > > > Cheers, > > > Stefano > > > > > > On Wed, Feb 2, 2011 at 10:44 AM, Rajeev Koodli > wrote: > > > > > > Hi Stefano, > > > > > > You make two interesting points: First, the defined solution should b= e > > > useful for 3GPP deployments. Second, if it=92s not defined *today* in > 3GPP, > > > it=92s not useful. > > > > > > I tend to agree with you on the first =96 3GPP is a big potential > customer. > > > I cannot agree with your second point. > > > > > > There are multiple ways I could envision policy on the LMA. Locally > > > configured policy is one (which we use today in deployments) that doe= s > not > > > need Gx interaction. Gx extensions can be proposed in the future. I > hope you > > > are not suggesting that these are not feasible choices. > > > > > > For the MN (IETF term for UE) to even connect to the MAG via WLAN > today, > > > you need an IPsec termination point (ePDG). If the operator > pre-configures > > > the list of SSIDs or there is some out-of-band mechanism to inform th= e > MN > > > which SSID is =93white-listed=94, then I expect the MN to decide when= to > connect > > > to the ePDG and hence the MAG. At this point, the MN is already on th= e > WLAN > > > the operator cares about I presume. > > > There is no easy way for the network (LMA, MAG) to know what SSID the > MN is > > > connected to =96 the network has to either trust the software on the = MN > or the > > > WLAN infrastructure has to provide the SSID information to the networ= k. > > > > > > -Rajeev > > > > > > > > > > > > On 2/2/11 9:56 AM, "stefano faccin" > > http://sfaccinstd@gmail.com> > wrote: > > > Hello rajeev, > > > the use of PCRF is an interesting suggestion. However, unfortunately, > PCRF > > > does not contain any policies or information that will tell the LMA > what are > > > the policies to be used for decisions of IP flow mobility. This is no= t > part > > > of current PCC functionality, and there is no work ongoing or planned > to > > > extend PCC in such way. Therefore, the applicability of the solution = in > this > > > draft would hinge on hypotetical future solutions and not on a curren= t > > > solution for the open issues, which brings us back to my point that w= e > are > > > defining a solution with open issues for which there is not a single > > > realistic solution out there, thus making this draft not applicable t= o > a > > > real scenario. > > > > > > I am not thinking of the UE connecting to more than one WLAN at the > same > > > time, but the UE being able to connect to different WLANs (one at a > time) > > > because the UE is e.g. provisioned with a list of SSIDs or the UE > discovers > > > a hotspot somewhere. I am talking about the scenario where the UE is > capable > > > to connect to WLAN, but the operator has different policies wrt which > WLAN > > > the UE should use or not. > > > > > > If you have followed the work in 3GPP, it is clear that operators hav= e > > > interest in applying policies not only at RAT level, but also at acce= ss > > > network level (please see how ANDSF was defined and why). I guess we > can all > > > agree that an operator deploying PMIP-based mobility may be intereste= d > in > > > having policies that allow traffic on the WLAN the operator owns or > that > > > belongs to a roaming partner, while not allowing traffic on WLAN of > other > > > operators for which it might need to pay an extra fee or where e.g. n= o > QoS > > > can be guaranteed. That means that the entity deciding whether traffi= c > needs > > > to be routed on WLAN or not cannot just consider "WLAN is available", > but > > > "WLAN SSIDx is available", so that the decision can be based on the > operator > > > preferences as to which WLAN certain traffic needs to be routed on. > > > > > > If the draft allows decisions to be made only at the RAT level, then = we > > > have an issue because we are defining a solution that should be > applicable > > > to 3GPP but does not meet the deployment scenarios of interest. In > other > > > words, if we want to make this solution applicable e.g. to 3GPP, we > need to > > > be able to provide the same functionality available today in 3GPP wit= h > other > > > solution in order to satisfy the use cases supported by 3GPP, and not > step > > > backwards in terms of what can be supported. > > > > > > Cheers, > > > > > > Stefano > > > > > > On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli > > http://rkoodli@cisco.com> > wrote: > > > > > > Hi Stefano, > > > > > > Thanks for your input. > > > > > > I expect the LMA interacting with PCRF for policy rules specific to t= he > > > subscriber for different RAT types. > > > You are right that the LMA does not know the SSID the mobile is > connected > > > to. It=92s not clear if the MAG can get that from the MN either witho= ut > > > additional signaling. However, the LMA knows that the MN is connected > to > > > WLAN; so it can apply the policy at the RAT type level. Are you > thinking of > > > the MN connecting to more than one WLAN network (and each of those > > > connections coming back to the LMA)? If so, please explain the > scenario. > > > > > > Regards, > > > > > > -Rajeev > > > > > > > > > > > > > > > On 2/1/11 6:39 PM, "stefano faccin" > > http://sfaccinstd@gmail.com> > wrote: > > > Raj, > > > thanks for the email. > > > > > > I need to apologize in advance if my questions have already been > answered > > > before (though I cannot find a conclusive answer anywhere). > > > > > > I think that a protocol that is developed in NETEXT (or other groups) > > > should have at least a potential realistic scenario for applicability= . > > > > > > In terms of applicability, though it is not part of the protocol > definition > > > per se, unless there are solutions in place for either the host to > indicate > > > to the network where the flows should be routed or for the LMA to > receive > > > somehow from somewhere some policies, the solution cannot really > provide > > > flow mobility since there is no way to decide which flows are routed > where. > > > If we are thinking about a host-based solution, I have not yet seen a > > > solution as to how the host can indicate to the MAG and ultimately to > the > > > MAG which flows should be routed on each access. If we are relying on > > > modifications of layer 2 protocols, aren't we defining a solution tha= t > works > > > only with some technologies (since for other access technologies it i= s > > > rather unrealistic to modify L2 for IP flow mobility purposes)? If we > are > > > thinking of an LMA-based solution, can we hear of at least one exampl= e > of a > > > real-life scenario where the LMA would receive such policies, and how > such > > > delivery would happen? Also, should there be a solution to have > policies in > > > the LMA, how does the LMA actually decide to route flows on one acces= s > or > > > the other? E.g., if some flows need to be routed on certain WLAN > networks, > > > but shall not be routed on other WLAN networks, how does the LMA know > which > > > specific WLAN network the host is connected to? Perhaps I missed the > ability > > > for the MAG to know e.g. the WLAN SSID and provide it to the LMA, in > which > > > case I would appreciate if somebody could highlight to me where that = is > > > defined. > > > > > > I think that, though not integral to the protocol specification, > > > understanding what framework the protocol would/needs to fit in is > rather > > > important. > > > > > > Cheers, > > > Stefano > > > > > > > > > On Tue, Feb 1, 2011 at 3:47 PM, > > http://Basavaraj.Patil@nokia.com> > > > > > wrote: > > > > > > Hello, > > > > > > We have discussed the flow mobility solutions for Proxy MIP6 previous= ly > at > > > IETFs 78 and 79. > > > This is a consensus call for adopting this I-D: > > > draft-bernardos-netext-pmipv6-flowmob-02 > > > as the working group document. > > > I-D: > http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt > > > > > > The consensus call will expire on Feb 15th, 2011. Please indicate you= r > > > support or concerns in adopting this I-D as the WG baseline document = on > > > the mailing list. > > > > > > Please note that this I-D will serve as the baseline in the WG and wi= ll > be > > > developed further based on input and feedback from WG members. > > > > > > -Basavaraj > > > > > > _______________________________________________ > > > netext mailing list > > > netext@ietf.org > > > https://www.ietf.org/mailman/listinfo/netext > > > > > > > > > > > > > > > > > > > > > -- > > > Stefano M. Faccin > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > May the Force be with you > > > > > > > > > > > > > > > -- > > > Stefano M. Faccin > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > May the Force be with you > > > > > > > > > > > > > > > -- > > > Stefano M. Faccin > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > May the Force be with you > > > > > > > > > > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > > -- > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > --=20 Stefano M. Faccin =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D May the Force be with you --0016363b8b702cdfab049b54de55 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello Carlos,
unfortunately I beg to disagree. Indeed we are chartered t= o do this work, but at the same time developing a protocol that due to tech= nical limitations cannot be adopted in realistic scenarios seems a fruitles= s effort.

I would also beg to disagree that 3GPP will have to modify their archit= ecture to allow this solution to work. I believe that, if 3GPP is to be a c= ustomer, the protocol must be developed to fit the need of the customer, no= t the other way around.

Cheers,
Stefano

2011/2/2 Carlos Je= s=FAs Bernardos Cano <cjbc@it.uc3m.es>
Hi Stefano,

Thanks for the comments on the draft. Two comments from my side:

- Regarding the comment about the potential realistic scenario for
applicability, this is not an issue of this solution (or any other), if
it is an issue at all. We are chartered to work on protocol extensions
for flow mobility without introducing any changes to the IP stack of the MN. IMHO all your comments on this regard relates to the charter itself, not this draft.

- Regarding the comments about the "lack of support from 3GPP", I=
acknowledge that 3GPP is an important potential customer, but as far as
I know, we are not chartered to come up with a 3GPP-only solution, and I think it's fair to design a solution that works under certain
assumptions, as long as those assumptions cannot realistically be met in a particular network deployment. I think it's fair to expect that 3GPP<= br> may need to add also extensions to make this solution work in their
architecture.

Thanks,

Carlos

On Wed, 2011-02-02 at 14:26 -0800, stefano faccin wrote:
> Hello JC,
> thanks for acknowledging that there is indeed an issue with the curren= t
> draft.
>
> For my clarification, how would the "MAG forward the packet with = no
> problem"? I am not sure I am understanding what the sequence of s= teps would
> be.
>
> Also, I guess that as you say the solution is not included in the curr= ent
> draft, which means modifying the protocol that we have in the current = draft.
>
> Cheers,
> Stefano
>
> On Wed, Feb 2, 2011 at 12:37 PM, Zuniga, Juan Carlos <
> JuanCarlos.Zunig= a@interdigital.com> wrote:
>
> > =A0Hi Stefano,
> >
> >
> >
> > Thanks for the response (you forgot to copy the list again ;). > >
> >
> >
> > What I had in mind was what they call Basic solution in the docum= ent, in
> > which the same set of prefixes are assigned to different interfac= es (or
> > MAGs). In this case the MN can decide (based on policies) to chan= ge the flow
> > and send packets over a new interface. The MAG would forward the = packet with
> > no problem and upon receiving this packet the LMA would implicitl= y know that
> > the MN has performed a flow movement (again, based on policies). = At this
> > point the LMA would just need to change its routing table accordi= ngly and
> > start sending packets for this flow over the new interface (simil= ar rule to
> > the one already specified for the mobile).
> >
> >
> >
> > I see this as a lightweight solution to the problem you pointed o= ut that
> > could easily be added to the document.
> >
> >
> >
> > Jc
> >
> >
> >
> >
> >
> >
> >
> > *From:* stefano faccin [mailto:sfaccinstd@gmail.com]
> > *Sent:* February 2, 2011 3:11 PM
> > *To:* Zuniga, Juan Carlos
> >
> > *Subject:* Re: [netext] Consensus call to adopt I-D:
> > draft-bernardos-netext-pmipv6-flowmob as WG doc
> >
> >
> >
> > Hi JC,
> >
> > As you say in 3GPP for the MN-based model this has been solved. H= owever, if
> > we want to apply a similar solution, we go back to the argument t= hat it
> > would require the MN to be able to communicate the decisions to t= he MAG/LMA
> > but, as we discussed previously, we don't have a solution for= that. This
> > means that applying this protocol with a model similar to the one= currently
> > specified in IETF and 3GPP requires the definition of a solution = that does
> > not yet exist (at Layer 3 or at Layer 2). I am concerned about de= veloping
> > only some pieces of a solution.
> >
> > Alternatively, as you say the MAG reacts. However, it is not clea= r to me
> > that the current draft describes how that happens.
> >
> > Cheers,
> > Stefano
> >
> > On Wed, Feb 2, 2011 at 11:56 AM, Zuniga, Juan Carlos <
> > JuanCarlos.= Zuniga@interdigital.com> wrote:
> >
> > Stefano,
> >
> >
> >
> > As much as I agree with most of your points about the problem fro= m the 3GPP
> > architecture point of view, I think that there is more than one s= olution.
> >
> >
> >
> > We are assuming of course that what we have is a scenario where b= oth
> > networks are in the same PMIP domain and IP flow mobility is then= possible.
> > You point out that there are no means to convey policies to the L= MA or MAG.
> > However, there are means to convey these policies to the MN as it= is already
> > defined in 3GPP for the client-based IP flow mobility case (i.e. = ANDSF).
> > Hence, one different solution could be to let the MN apply the po= licy by
> > moving the flow and make the MAG and LMA =93react=94 to the IP fl= ow change
> > assuming that the flow change was made according to the policy be= ing applied
> > at the mobile.
> >
> >
> >
> > I would see this scenario equivalent to the one specified in 3GPP= from the
> > point of view of node=92s responsibilities, don=92t you think? > >
> >
> >
> > Jc
> >
> >
> >
> >
> >
> > *From:* netext-bounces= @ietf.org [mailto:netext-bou= nces@ietf.org] *On
> > Behalf Of *stefano faccin
> > *Sent:* February 2, 2011 2:41 PM
> > *To:* Rajeev Koodli; netext@ie= tf.org
> >
> >
> > *Subject:* Re: [netext] Consensus call to adopt I-D:
> > draft-bernardos-netext-pmipv6-flowmob as WG doc
> >
> >
> >
> > Sorry, I forgot to reply to the whole list.
> > Cheers,
> > Stefano
> >
> > On Wed, Feb 2, 2011 at 11:29 AM, stefano faccin <sfaccinstd@gmail.com>
> > wrote:
> >
> > Hi Rajeev,
> > in current solution the policy is in sync, since it is the ANDSF = (the
> > network counterpart of the MN for the policy) that configures it = in the MN.
> > That does not mean that the LMA has such policy.
> >
> > Cheers,
> > Stefano
> >
> >
> >
> > On Wed, Feb 2, 2011 at 11:46 AM, Rajeev Koodli <rkoodli@cisco.com> wrote:
> >
> >
> > Hi Gerardo,
> >
> > =A0 =A0- my point is that someone/something is configuring the po= licy on the
> > =A0 =A0MN which needs to be in sync with the MN=92s partner, i.e.= , the network. If
> > =A0 =A0this is not the case, please let me know.
> > =A0 =A0- The last I heard, PMIP6 is applicable on the eHRPD (trus= ted non-3GPP
> > =A0 =A0network). Also, 33.402 does not specify whether a particul= ar type of access
> > =A0 =A0network (such as WLAN) is considered trusted or untrusted = (although a
> > =A0 =A0majority of the WLAN access could be considered untrusted = today).
> >
> >
> > -Rajeev
> >
> >
> >
> >
> > On 2/2/11 11:16 AM, "Giaretta, Gerardo" <gerardog@qualcomm.com> wrote:
> >
> > Hi Rajeev,
> >
> > A couple of considerations on this:
> >
> > - =A0 =A0 =A0 =A0 This draft assumes there is consistency in the = rules. This is a
> > new requirement for the system architecture where this solution w= ill be
> > applied. There is no this requirement for other solutions already= adopted by
> > IETF and 3GPP. In my view this seems a fairly important issue. > >
> > - =A0 =A0 =A0 =A0 The routing decisions based on WLAN SSID are di= fferent from
> > trusted/untrusted. Note also that PMIPv6 cannot be used in truste= d networks
> > so it is not clear at all what you are referring to.
> >
> >
> > Gerardo
> >
> >
> > *From:* ne= text-bounces@ietf.org [mailto:netext-bounces@ietf.org<netext-bounces@ietf.org>]
> > *On Behalf Of *Rajeev Koodli > > *Sent:* Wednesday, February 02, 2011 11:28 AM
> > *To:* stefano faccin
> > *Cc:* netext@ietf.org; Basavaraj.Patil@nokia.com
> > *Subject:* Re: [netext] Consensus call to adopt I-D:
> > draft-bernardos-netext-pmipv6-flowmob as WG doc
> >
> >
> > Stefano,
> >
> > Regardless of how the policy is configured on the LMA, there is a=
> > consistency of the rules which needs to be ensured regardless. Wh= atever the
> > entity (OMA-DM?!) is that configures the policy has to ensure suc= h a
> > consistency.
> >
> > We can debate about how policy interaction works, but that=92s an= other topic.
> > I would note that there are choices here (modulo respective pros = and cons).
> >
> > I didn=92t suggest that an operator should just trust the softwar= e on a MN,
> > although I suspect some device vendors might argue for their robu= stness
> > (surprise?).
> >
> > I would frame the WLAN access problem as whether the access is co= nsidered
> > trusted or not. Accordingly, you apply the policy.
> >
> > -Rajeev
> >
> >
> > On 2/2/11 10:50 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:
> > Raj,
> > thanks for the reply.
> >
> > If the LMA has statically configured policies, how do we ensure t= hat the MN
> > has the same policies? That would mean implicitly assuming that t= he policies
> > provisioned to the MN by the ANDSF "always" match what = has been set in the
> > LMA, which I think it is unrealistic because the policies change = over time,
> > and every time you need to update all the LMAs, which has a consi= derable
> > operational cost. Instead, if we leave the MN to make the choice,= there are
> > easy and well specified mechanisms that allow the provisioning of= policies
> > in the MN and for the MN to make such decision and communicate it= to the
> > network, so that the network can
> >
> > As for extensions to Gx, I am not stating that in theory one coul= d extend
> > Gx. However, at present such solution does not exists, and withou= t it, I do
> > not see how the draft is applicable to 3GPP that is at present th= e only
> > potential customer identified (I guess I did not see any other id= entified?)
> >
> >
> > Even assuming that Gx could be modified, the issue of the per-acc= ess
> > network granularity remains. Even if the LMA has the right polici= es in
> > place, the LMA has no way of knowing exactly what access network = of a
> > specific access technology (e.g. which SSID for WLAN0 the MN is c= onnecting
> > to.
> >
> > I cannot agree with your assumption below that if the MN connects= to an
> > SSID it is because the operator is OK with routing traffic on tha= t SSID, and
> > that we should just "trust the software on the MN". The= re are two aspects to
> > consider:
> > 1) whether it is OK for certain traffic to be routed at all over = a certain
> > access access network of a specific access technology
> > 2) how different traffic should be routed over different access n= etworks of
> > different access technologies
> >
> > Regarding these two points, the issue is whether the operator wan= ts to
> > allow traffic e.g. over a certain SSID or not. So, in that case, = it is
> > obvious as you say that if the MN has connected to an SSID config= ured by the
> > operator in the MN, then traffic could be allowed over that SSID.= However,
> > we need to consider that 3GPP allows the decision of which WLAN t= he MN can
> > connect to based on user preferences. This means that my MN can e= .g. connect
> > to my home WLAN (which is not controlled necessarily by the opera= tor and
> > whose SSID the operator does not know) or to a coffee shop WLAN, = even if the
> > device does not have those SSID configured. Those are typical exa= mples of
> > untrusted WLAN access networks. Therefore, in such cases, just be= cause the
> > MN has connected to a WLAN SSID, does not mean that the operator = wants to
> > route certain traffic over that SSID just because the policy says= "route
> > traffic X over WLAN".
> >
> > That brings us to a solution that, if applied to 3GPP, provides l= ess
> > functionality than what is available and has been specified today= , so back
> > to my point above.
> >
> > Unfortunately, there is no solution I am aware of that allows the= WLAN
> > network to indicate to the MAG/LMA the specific SSID (and as you = say, there
> > is no easy solution for that). Due to this and the points above a= bout policy
> > provisioning, it means that the applicability of this solution to= a real
> > case like 3GPP depends on the feasibility of extending policy mec= hanisms in
> > 3GPP, and the ability to have a solution where the WLAN network p= rovides the
> > SSID information to the MAG/LMA. Moreover, the provisioning of su= ch SSID is
> > not in the scope of IETF, but not even of 3GPP (since the interfa= ce between
> > the WLAN AP and the ePDG is not defined), thus I wonder how this = could be
> > defined at all (I am afraid of asking what magic should happen he= re). So,
> > now we have two big dependencies.
> >
> > In general, I am also wondering if there is a customer that has a= sked us to
> > define this solution. I am not aware of any but I may have missed= that.
> >
> > Cheers,
> > Stefano
> >
> > On Wed, Feb 2, 2011 at 10:44 AM, Rajeev Koodli <rkoodli@cisco.com> wrote:
> >
> > Hi Stefano,
> >
> > You make two interesting points: First, the defined solution shou= ld be
> > useful for 3GPP deployments. Second, if it=92s not defined *today= * in 3GPP,
> > it=92s not useful.
> >
> > I tend to agree with you on the first =96 3GPP is a big potential= customer.
> > I cannot agree with your second point.
> >
> > There are multiple ways I could envision policy on the LMA. Local= ly
> > configured policy is one (which we use today in deployments) that= does not
> > need Gx interaction. Gx extensions can be proposed in the future.= I hope you
> > are not suggesting that these are not feasible choices.
> >
> > For the MN (IETF term for UE) to even connect to the MAG via WLAN= today,
> > you need an IPsec termination point (ePDG). If the operator pre-c= onfigures
> > the list of SSIDs or there is some out-of-band mechanism to infor= m the MN
> > which SSID is =93white-listed=94, then I expect the MN to decide = when to connect
> > to the ePDG and hence the MAG. At this point, the MN is already o= n the WLAN
> > the operator cares about I presume.
> > There is no easy way for the network (LMA, MAG) to know what SSID= the MN is
> > connected to =96 the network has to either trust the software on = the MN or the
> > WLAN infrastructure has to provide the SSID information to the ne= twork.
> >
> > -Rajeev
> >
> >
> >
> > On 2/2/11 9:56 AM, "stefano faccin" <sfaccinstd@gmail.com <
> > http://sfaccinstd= @gmail.com> > = wrote:
> > Hello rajeev,
> > the use of PCRF is an interesting suggestion. However, unfortunat= ely, PCRF
> > does not contain any policies or information that will tell the L= MA what are
> > the policies to be used for decisions of IP flow mobility. This i= s not part
> > of current PCC functionality, and there is no work ongoing or pla= nned to
> > extend PCC in such way. Therefore, the applicability of the solut= ion in this
> > draft would hinge on hypotetical future solutions and not on a cu= rrent
> > solution for the open issues, which brings us back to my point th= at we are
> > defining a solution with open issues for which there is not a sin= gle
> > realistic solution out there, thus making this draft not applicab= le to a
> > real scenario.
> >
> > I am not thinking of the UE connecting to more than one WLAN at t= he same
> > time, but the UE being able to connect to different WLANs (one at= a time)
> > because the UE is e.g. provisioned with a list of SSIDs or the UE= discovers
> > a hotspot somewhere. I am talking about the scenario where the UE= is capable
> > to connect to WLAN, but the operator has different policies wrt w= hich WLAN
> > the UE should use or not.
> >
> > If you have followed the work in 3GPP, it is clear that operators= have
> > interest in applying policies not only at RAT level, but also at = access
> > network level (please see how ANDSF was defined and why). I guess= we can all
> > agree that an operator deploying PMIP-based mobility may be inter= ested in
> > having policies that allow traffic on the WLAN the operator owns = or that
> > belongs to a roaming partner, while not allowing traffic on WLAN = of other
> > operators for which it might need to pay an extra fee or where e.= g. no QoS
> > can be guaranteed. That means that the entity deciding whether tr= affic needs
> > to be routed on WLAN or not cannot just consider "WLAN is av= ailable", but
> > "WLAN SSIDx is available", so that the decision can be = based on the operator
> > preferences as to which WLAN certain traffic needs to be routed o= n.
> >
> > If the draft allows decisions to be made only at the RAT level, t= hen we
> > have an issue because we are defining a solution that should be a= pplicable
> > to 3GPP but does not meet the deployment scenarios of interest. I= n other
> > words, if we want to make this solution applicable e.g. to 3GPP, = we need to
> > be able to provide the same functionality available today in 3GPP= with other
> > solution in order to satisfy the use cases supported by 3GPP, and= not step
> > backwards in terms of what can be supported.
> >
> > Cheers,
> >
> > Stefano
> >
> > On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli <rkoodli@cisco.com <
> > http://rkoodli@<= a href=3D"http://cisco.com" target=3D"_blank">cisco.com> > wrote:=
> >
> > Hi Stefano,
> >
> > Thanks for your input.
> >
> > I expect the LMA interacting with PCRF for policy rules specific = to the
> > subscriber for different RAT types.
> > You are right that the LMA does not know the SSID the mobile is c= onnected
> > to. It=92s not clear if the MAG can get that from the MN either w= ithout
> > additional signaling. However, the LMA knows that the MN is conne= cted to
> > WLAN; so it can apply the policy at the RAT type level. Are you t= hinking of
> > the MN connecting to more than one WLAN network (and each of thos= e
> > connections coming back to the LMA)? If so, please explain the sc= enario.
> >
> > Regards,
> >
> > -Rajeev
> >
> >
> >
> >
> > On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <
> > http://sfaccinstd= @gmail.com> =A0&l= t;http://sfaccinstd@gmail.com> > wrote: > > Raj,
> > thanks for the email.
> >
> > I need to apologize in advance if my questions have already been = answered
> > before (though I cannot find a conclusive answer anywhere).
> >
> > I think that a protocol that is developed in NETEXT (or other gro= ups)
> > should have at least a potential realistic scenario for applicabi= lity.
> >
> > In terms of applicability, though it is not part of the protocol = definition
> > per se, unless there are solutions in place for either the host t= o indicate
> > to the network where the flows should be routed or for the LMA to= receive
> > somehow from somewhere some policies, the solution cannot really = provide
> > flow mobility since there is no way to decide which flows are rou= ted where.
> > If we are thinking about a host-based solution, I have not yet se= en a
> > solution as to how the host can indicate to the MAG and ultimatel= y to the
> > MAG which flows should be routed on each access. If we are relyin= g on
> > modifications of layer 2 protocols, aren't we defining a solu= tion that works
> > only with some technologies (since for other access technologies = it is
> > rather unrealistic to modify L2 for IP flow mobility purposes)? I= f we are
> > thinking of an LMA-based solution, can we hear of at least one ex= ample of a
> > real-life scenario where the LMA would receive such policies, and= how such
> > delivery would happen? Also, should there be a solution to have p= olicies in
> > the LMA, how does the LMA actually decide to route flows on one a= ccess or
> > the other? E.g., if some flows need to be routed on certain WLAN = networks,
> > but shall not be routed on other WLAN networks, how does the LMA = know which
> > specific WLAN network the host is connected to? Perhaps I missed = the ability
> > for the MAG to know e.g. the WLAN SSID and provide it to the LMA,= in which
> > case I would appreciate if somebody could highlight to me where t= hat is
> > defined.
> >
> > I think that, though not integral to the protocol specification,<= br> > > understanding what framework the protocol would/needs to fit in i= s rather
> > important.
> >
> > Cheers,
> > Stefano
> >
> >
> > On Tue, Feb 1, 2011 at 3:47 PM, =A0<Basavaraj.Patil@nokia.com <
> > http://Basav= araj.Patil@nokia.com= > =A0<http://Bas= avaraj.Patil@nokia.com> >
> > wrote:
> >
> > Hello,
> >
> > We have discussed the flow mobility solutions for Proxy MIP6 prev= iously at
> > IETFs 78 and 79.
> > This is a consensus call for adopting this I-D:
> > draft-bernardos-netext-pmipv6-flowmob-02
> > as the working group document.
> > I-D: http://www.ietf.org/id/draft-bernardo= s-netext-pmipv6-flowmob-02.txt
> >
> > The consensus call will expire on Feb 15th, 2011. Please indicate= your
> > support or concerns in adopting this I-D as the WG baseline docum= ent on
> > the mailing list.
> >
> > Please note that this I-D will serve as the baseline in the WG an= d will be
> > developed further based on input and feedback from WG members. > >
> > -Basavaraj
> >
> > _______________________________________________
> > netext mailing list
> > netext@ietf.org <http://netext@ietf.org> =A0<http://netext@ietf.org>
> > https://www.ietf.org/mailman/listinfo/netext
> >
> >
> >
> >
> >
> >
> > =A0 =A0--
> > Stefano M. Faccin
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > May the Force be with you
> >
> >
> >
> >
> > --
> > Stefano M. Faccin
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > May the Force be with you
> >
> >
> >
> >
> > --
> > Stefano M. Faccin
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > May the Force be with you
> >
>
>
>
> _______________________________________________
> netext mailing list
> netext@ietf.org
> https://www.ietf.org/mailman/listinfo/netext

--
Carlos Jes=FAs Bernardos Cano= =A0 =A0 http://www.ne= tcoms.net
GPG FP: D29B 0A6A 639A A561 93CA =A04D55 35DC BA4D D170 4F67



--
Stefano M. = Faccin
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
May the= Force be with you
--0016363b8b702cdfab049b54de55-- From sfaccinstd@gmail.com Wed Feb 2 15:18:42 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01A4E3A6AF9 for ; Wed, 2 Feb 2011 15:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.42 X-Spam-Level: X-Spam-Status: No, score=-103.42 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zyIQwM-2NV6 for ; Wed, 2 Feb 2011 15:18:38 -0800 (PST) Received: from mail-qy0-f194.google.com (mail-qy0-f194.google.com [209.85.216.194]) by core3.amsl.com (Postfix) with ESMTP id BBC283A6864 for ; Wed, 2 Feb 2011 15:18:37 -0800 (PST) Received: by qyk4 with SMTP id 4so41378qyk.1 for ; Wed, 02 Feb 2011 15:21:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=g1KFQEDa47UN8KM7RiQG1MLxY/T3vMzCX9iOu7exs7g=; b=SsErl2rVeG5WxlvRlBafEWb2ZzYX3C5SXKrnDZb054r4UjY84+HckmVcyEJeDyX+up 8M+GuxrID/3G89iNpbJpkB/N8AN3mP9qMtc8BhIe2Il85g5YllSxGoBT7ZDbz+e9icqs +yQ+wiTNizFZ8jtYP1bsZ0NdEGQjGdl8+NNLk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bgAWbnkOO6LmjvPE0m0kFY64mPhHO7fbJ3svDZNuK/HIK3lgcfHU37+F7twx0NdIbL Y0E81CjgFo9/Zvn/5lVc8a9/HZfOzzvRvEAJrkDCKCw+XB8Pa4F0c/Jr17F8h5PM05QG IBluevk6DC4QDm/DNGwdF/SXlJxPBN2e0Tk7s= MIME-Version: 1.0 Received: by 10.229.233.19 with SMTP id jw19mr6928387qcb.24.1296688917579; Wed, 02 Feb 2011 15:21:57 -0800 (PST) Received: by 10.229.20.70 with HTTP; Wed, 2 Feb 2011 15:21:57 -0800 (PST) In-Reply-To: <314265.17931.qm@web111409.mail.gq1.yahoo.com> References: <314265.17931.qm@web111409.mail.gq1.yahoo.com> Date: Wed, 2 Feb 2011 15:21:57 -0800 Message-ID: From: stefano faccin To: Behcet Sarikaya Content-Type: multipart/alternative; boundary=0016363b8b70510d66049b54ea06 Cc: netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 23:18:42 -0000 --0016363b8b70510d66049b54ea06 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Behcet, thanks for the reminder that we are indeed targeting 3GPP and specific interfaces as our customer. Indeed if a working solution that fits the framework of S2a and S2b is designed, it could be used at the discretion of 3GPP. However, if "a missing part" needs to be provided, I believe the technical issues I raise are indeed in the scope and need to be addressed i= n order to make the protocol applicable to the customer. Expecting to define = a solution that does not fit the customer and throwing the protocol over the fence to them to fix their part to make the protocol work does not sound like a good design approach to me. Cheers, Stefano On Wed, Feb 2, 2011 at 2:54 PM, Behcet Sarikaya w= rote: > Hi Stefano, > This draft addresses: > IP Flow Mobility and Seamless Offload (IFOM) on S2a and S2b interfaces. > As we already have a solution (in RFC 6088 and 6089) for s2c, this docume= nt > aims > > to address the missing part. > > The issues you raised are out of scope for the document. > > Regards, > > Behcet > > > > >Hello JC, > >thanks for acknowledging that there is indeed an issue with the current > draft. > > > >For my clarification, how would the "MAG forward the packet with no > problem"? I > > >am not sure I am understanding what the sequence of steps would be. > > > > > >Also, I guess that as you say the solution is not included in the curren= t > draft, > > > >which means modifying the protocol that we have in the current draft. > > > >Cheers, > >Stefano > > > > > >On Wed, Feb 2, 2011 at 12:37 PM, Zuniga, Juan Carlos > > wrote: > > > >Hi Stefano, > >> > >>Thanks for the response (you forgot to copy the list again ;). > >> > >>What I had in mind was what they call Basic solution in the document, i= n > which > > >>the same set of prefixes are assigned to different interfaces (or MAGs)= . > In this > >> > >>case the MN can decide (based on policies) to change the flow and send > packets > > >>over a new interface. The MAG would forward the packet with no problem > and upon > > > >>receiving this packet the LMA would implicitly know that the MN has > performed a > > > >>flow movement (again, based on policies). At this point the LMA would > just need > > > >>to change its routing table accordingly and start sending packets for > this flow > > > >>over the new interface (similar rule to the one already specified for t= he > >>mobile). > >> > >>I see this as a lightweight solution to the problem you pointed out tha= t > could > > >>easily be added to the document. > >> > >>Jc > >> > >> > >> > >>From:stefano faccin [mailto:sfaccinstd@gmail.com] > >>Sent: February 2, 2011 3:11 PM > >>To: Zuniga, Juan Carlos > >> > >>Subject: Re: [netext] Consensus call to adopt I-D: > >>draft-bernardos-netext-pmipv6-flowmob as WG doc > >> > >> > >>Hi JC, > >> > >>As you say in 3GPP for the MN-based model this has been solved. However= , > if we > > >>want to apply a similar solution, we go back to the argument that it > would > >>require the MN to be able to communicate the decisions to the MAG/LMA > but, as we > >> > >>discussed previously, we don't have a solution for that. This means tha= t > >>applying this protocol with a model similar to the one currently > specified in > >>IETF and 3GPP requires the definition of a solution that does not yet > exist (at > > > >>Layer 3 or at Layer 2). I am concerned about developing only some piece= s > of a > >>solution. > >> > >>Alternatively, as you say the MAG reacts. However, it is not clear to m= e > that > >>the current draft describes how that happens. > >> > >>Cheers, > >>Stefano > >>On Wed, Feb 2, 2011 at 11:56 AM, Zuniga, Juan Carlos > >> wrote: > >>Stefano, > >> > >>As much as I agree with most of your points about the problem from the > 3GPP > >>architecture point of view, I think that there is more than one solutio= n. > >> > >>We are assuming of course that what we have is a scenario where both > networks > >>are in the same PMIP domain and IP flow mobility is then possible. You > point out > >> > >>that there are no means to convey policies to the LMA or MAG. However, > there are > >> > >>means to convey these policies to the MN as it is already defined in 3G= PP > for > >>the client-based IP flow mobility case (i.e. ANDSF). Hence, one differe= nt > >>solution could be to let the MN apply the policy by moving the flow and > make the > >> > >>MAG and LMA =93react=94 to the IP flow change assuming that the flow ch= ange > was made > >> > >>according to the policy being applied at the mobile. > >> > >>I would see this scenario equivalent to the one specified in 3GPP from > the point > >> > >>of view of node=92s responsibilities, don=92t you think? > >> > >>Jc > >> > >> > >>From:netext-bounces@ietf.org [mailto: > netext-bounces@ietf.org] On Behalf Of > >>stefano faccin > >>Sent: February 2, 2011 2:41 PM > >>To: Rajeev Koodli; netext@ietf.org > >> > >>Subject: Re: [netext] Consensus call to adopt I-D: > >>draft-bernardos-netext-pmipv6-flowmob as WG doc > >> > >>Sorry, I forgot to reply to the whole list. > >>Cheers, > >>Stefano > >>On Wed, Feb 2, 2011 at 11:29 AM, stefano faccin > wrote: > >>Hi Rajeev, > >>in current solution the policy is in sync, since it is the ANDSF (the > network > >>counterpart of the MN for the policy) that configures it in the MN. Tha= t > does > >>not mean that the LMA has such policy. > >> > >> > >>Cheers, > >>Stefano > >> > >>On Wed, Feb 2, 2011 at 11:46 AM, Rajeev Koodli > wrote: > >> > >>Hi Gerardo, > >> * my point is that someone/something is configuring the policy > on the > >>MN > >> > >>which needs to be in sync with the MN=92s partner, i.e., the netwo= rk. > If this > >> > >>is not the case, please let me know. > >> > >> * The last I heard, PMIP6 is applicable on the eHRPD (trusted > non-3GPP > > > >>network). Also, 33.402 does not specify whether a particular type = of > access > >> > >>network (such as WLAN) is considered trusted or untrusted (althoug= h > a > >>majority of the WLAN access could be considered untrusted today). > >> > >> > >>-Rajeev > >> > >> > >> > >>On 2/2/11 11:16 AM, "Giaretta, Gerardo" wrote: > >>Hi Rajeev, > >>> > >>>A couple of considerations on this: > >>> > >>>- This draft assumes there is consistency in the rules. This i= s > a new > > >>>requirement for the system architecture where this solution will be > applied. > >>>There is no this requirement for other solutions already adopted by IE= TF > and > >>>3GPP. In my view this seems a fairly important issue. > >>> > >>>- The routing decisions based on WLAN SSID are different from > >>>trusted/untrusted. Note also that PMIPv6 cannot be used in trusted > networks so > > > >>>it is not clear at all what you are referring to. > >>> > >>> > >>>Gerardo > >>> > >>> > >>>From:netext-bounces@ietf.org [mailto: > netext-bounces@ietf.org] On Behalf Of > >>>Rajeev Koodli > >>>Sent: Wednesday, February 02, 2011 11:28 AM > >>>To: stefano faccin > >>>Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > >>>Subject: Re: [netext] Consensus call to adopt I-D: > >>>draft-bernardos-netext-pmipv6-flowmob as WG doc > >>> > >>> > >>>Stefano, > >>> > >>>Regardless of how the policy is configured on the LMA, there is a > consistency of > >>> > >>>the rules which needs to be ensured regardless. Whatever the entity > (OMA-DM?!) > > > >>>is that configures the policy has to ensure such a consistency. > >>> > >>>We can debate about how policy interaction works, but that=92s another > topic. I > > >>>would note that there are choices here (modulo respective pros and > cons). > >>> > >>>I didn=92t suggest that an operator should just trust the software on = a > MN, > >>>although I suspect some device vendors might argue for their robustnes= s > >>>(surprise?). > >>> > >>> > >>>I would frame the WLAN access problem as whether the access is > considered > >>>trusted or not. Accordingly, you apply the policy. > >>> > >>>-Rajeev > >>> > >>> > >>>On 2/2/11 10:50 AM, "stefano faccin" wrote: > >>>Raj, > >>>thanks for the reply. > >>> > >>>If the LMA has statically configured policies, how do we ensure that t= he > MN has > >> > >>>the same policies? That would mean implicitly assuming that the polici= es > >>>provisioned to the MN by the ANDSF "always" match what has been set in > the LMA, > >> > >>>which I think it is unrealistic because the policies change over time, > and every > >>> > >>>time you need to update all the LMAs, which has a considerable > operational cost. > >>> > >>>Instead, if we leave the MN to make the choice, there are easy and wel= l > >>>specified mechanisms that allow the provisioning of policies in the MN > and for > > > >>>the MN to make such decision and communicate it to the network, so tha= t > the > >>>network can > >>> > >>> > >>>As for extensions to Gx, I am not stating that in theory one could > extend Gx. > > >>>However, at present such solution does not exists, and without it, I d= o > not see > >> > >>>how the draft is applicable to 3GPP that is at present the only > potential > >>>customer identified (I guess I did not see any other identified?) > >>> > >>>Even assuming that Gx could be modified, the issue of the per-access > network > >>>granularity remains. Even if the LMA has the right policies in place, > the LMA > > >>>has no way of knowing exactly what access network of a specific access > >>>technology (e.g. which SSID for WLAN0 the MN is connecting to. > >>> > >>> > >>>I cannot agree with your assumption below that if the MN connects to a= n > SSID it > >> > >>>is because the operator is OK with routing traffic on that SSID, and > that we > >>>should just "trust the software on the MN". There are two aspects to > consider: > >>>1) whether it is OK for certain traffic to be routed at all over a > certain > >>>access access network of a specific access technology > >>>2) how different traffic should be routed over different access networ= ks > of > >>>different access technologies > >>> > >>>Regarding these two points, the issue is whether the operator wants to > allow > >>>traffic e.g. over a certain SSID or not. So, in that case, it is obvio= us > as you > >> > >>>say that if the MN has connected to an SSID configured by the operator > in the > > >>>MN, then traffic could be allowed over that SSID. However, we need to > consider > > > >>>that 3GPP allows the decision of which WLAN the MN can connect to base= d > on user > >> > >>>preferences. This means that my MN can e.g. connect to my home WLAN > (which is > > >>>not controlled necessarily by the operator and whose SSID the operator > does not > >> > >>>know) or to a coffee shop WLAN, even if the device does not have those > SSID > >>>configured. Those are typical examples of untrusted WLAN access > networks. > >>>Therefore, in such cases, just because the MN has connected to a WLAN > SSID, does > >>> > >>>not mean that the operator wants to route certain traffic over that SS= ID > just > > >>>because the policy says "route traffic X over WLAN". > >>> > >>> > >>>That brings us to a solution that, if applied to 3GPP, provides less > >>>functionality than what is available and has been specified today, so > back to my > >>> > >>>point above. > >>> > >>>Unfortunately, there is no solution I am aware of that allows the WLAN > network > > > >>>to indicate to the MAG/LMA the specific SSID (and as you say, there is > no easy > > > >>>solution for that). Due to this and the points above about policy > provisioning, > >> > >>>it means that the applicability of this solution to a real case like > 3GPP > >>>depends on the feasibility of extending policy mechanisms in 3GPP, and > the > >>>ability to have a solution where the WLAN network provides the SSID > information > >> > >>>to the MAG/LMA. Moreover, the provisioning of such SSID is not in the > scope of > > > >>>IETF, but not even of 3GPP (since the interface between the WLAN AP an= d > the ePDG > >>> > >>>is not defined), thus I wonder how this could be defined at all (I am > afraid of > >> > >>>asking what magic should happen here). So, now we have two big > dependencies. > >>> > >>> > >>>In general, I am also wondering if there is a customer that has asked = us > to > >>>define this solution. I am not aware of any but I may have missed that= . > >>> > >>>Cheers, > >>>Stefano > >>> > >>>On Wed, Feb 2, 2011 at 10:44 AM, Rajeev Koodli > wrote: > >>> > >>>Hi Stefano, > >>> > >>>You make two interesting points: First, the defined solution should be > useful > > >>>for 3GPP deployments. Second, if it=92s not defined today in 3GPP, it= =92s > not > >>>useful. > >>> > >>>I tend to agree with you on the first =96 3GPP is a big potential > customer. > >>>I cannot agree with your second point. > >>> > >>>There are multiple ways I could envision policy on the LMA. Locally > configured > > > >>>policy is one (which we use today in deployments) that does not need G= x > >>>interaction. Gx extensions can be proposed in the future. I hope you a= re > not > >>>suggesting that these are not feasible choices. > >>> > >>>For the MN (IETF term for UE) to even connect to the MAG via WLAN toda= y, > you > >>>need an IPsec termination point (ePDG). If the operator pre-configures > the list > >> > >>>of SSIDs or there is some out-of-band mechanism to inform the MN which > SSID is > > > >>>=93white-listed=94, then I expect the MN to decide when to connect to = the > ePDG and > > > >>>hence the MAG. At this point, the MN is already on the WLAN the operat= or > cares > > > >>>about I presume. > >>> > >>>There is no easy way for the network (LMA, MAG) to know what SSID the = MN > is > >>>connected to =96 the network has to either trust the software on the M= N or > the > >>>WLAN infrastructure has to provide the SSID information to the network= . > >>> > >>> > >>>-Rajeev > >>> > >>> > >>> > >>>On 2/2/11 9:56 AM, "stefano faccin" >>> > wrote: > >>>Hello rajeev, > >>>the use of PCRF is an interesting suggestion. However, unfortunately, > PCRF does > >> > >>>not contain any policies or information that will tell the LMA what ar= e > the > >>>policies to be used for decisions of IP flow mobility. This is not par= t > of > >>>current PCC functionality, and there is no work ongoing or planned to > extend PCC > >>> > >>>in such way. Therefore, the applicability of the solution in this draf= t > would > > >>>hinge on hypotetical future solutions and not on a current solution fo= r > the open > >>> > >>>issues, which brings us back to my point that we are defining a soluti= on > with > > >>>open issues for which there is not a single realistic solution out > there, thus > > > >>>making this draft not applicable to a real scenario. > >>> > >>>I am not thinking of the UE connecting to more than one WLAN at the sa= me > time, > > > >>>but the UE being able to connect to different WLANs (one at a time) > because the > >> > >>>UE is e.g. provisioned with a list of SSIDs or the UE discovers a > hotspot > >>>somewhere. I am talking about the scenario where the UE is capable to > connect to > >>> > >>>WLAN, but the operator has different policies wrt which WLAN the UE > should use > > > >>>or not. > >>> > >>>If you have followed the work in 3GPP, it is clear that operators have > interest > >> > >>>in applying policies not only at RAT level, but also at access network > level > >>>(please see how ANDSF was defined and why). I guess we can all agree > that an > >>>operator deploying PMIP-based mobility may be interested in having > policies that > >>> > >>>allow traffic on the WLAN the operator owns or that belongs to a roami= ng > >>>partner, while not allowing traffic on WLAN of other operators for whi= ch > it > >>>might need to pay an extra fee or where e.g. no QoS can be guaranteed. > That > >>>means that the entity deciding whether traffic needs to be routed on > WLAN or not > >>> > >>>cannot just consider "WLAN is available", but "WLAN SSIDx is available= ", > so that > >>> > >>>the decision can be based on the operator preferences as to which WLAN > certain > > > >>>traffic needs to be routed on. > >>> > >>> > >>>If the draft allows decisions to be made only at the RAT level, then w= e > have an > >> > >>>issue because we are defining a solution that should be applicable to > 3GPP but > > > >>>does not meet the deployment scenarios of interest. In other words, if > we want > > > >>>to make this solution applicable e.g. to 3GPP, we need to be able to > provide the > >>> > >>>same functionality available today in 3GPP with other solution in orde= r > to > >>>satisfy the use cases supported by 3GPP, and not step backwards in ter= ms > of what > >>> > >>>can be supported. > >>> > >>>Cheers, > >>> > >>>Stefano > >>> > >>>On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli >>> > wrote: > >>> > >>>Hi Stefano, > >>> > >>>Thanks for your input. > >>> > >>>I expect the LMA interacting with PCRF for policy rules specific to th= e > >>>subscriber for different RAT types. > >>>You are right that the LMA does not know the SSID the mobile is > connected to. > > >>>It=92s not clear if the MAG can get that from the MN either without > additional > >>>signaling. However, the LMA knows that the MN is connected to WLAN; so > it can > > >>>apply the policy at the RAT type level. Are you thinking of the MN > connecting to > >>> > >>>more than one WLAN network (and each of those connections coming back = to > the > >>>LMA)? If so, please explain the scenario. > >>> > >>>Regards, > >>> > >>>-Rajeev > >>> > >>> > >>> > >>> > >>>On 2/1/11 6:39 PM, "stefano faccin" >>> > wrote: > >>>Raj, > >>>thanks for the email. > >>> > >>>I need to apologize in advance if my questions have already been > answered before > >>> > >>>(though I cannot find a conclusive answer anywhere). > >>> > >>>I think that a protocol that is developed in NETEXT (or other groups) > should > >>>have at least a potential realistic scenario for applicability. > >>> > >>>In terms of applicability, though it is not part of the protocol > definition per > >> > >>>se, unless there are solutions in place for either the host to indicat= e > to the > > > >>>network where the flows should be routed or for the LMA to receive > somehow from > >> > >>>somewhere some policies, the solution cannot really provide flow > mobility since > >> > >>>there is no way to decide which flows are routed where. If we are > thinking about > >>> > >>>a host-based solution, I have not yet seen a solution as to how the ho= st > can > >>>indicate to the MAG and ultimately to the MAG which flows should be > routed on > > >>>each access. If we are relying on modifications of layer 2 protocols, > aren't we > >> > >>>defining a solution that works only with some technologies (since for > other > >>>access technologies it is rather unrealistic to modify L2 for IP flow > mobility > > > >>>purposes)? If we are thinking of an LMA-based solution, can we hear of > at least > >> > >>>one example of a real-life scenario where the LMA would receive such > policies, > > > >>>and how such delivery would happen? Also, should there be a solution t= o > have > >>>policies in the LMA, how does the LMA actually decide to route flows o= n > one > >>>access or the other? E.g., if some flows need to be routed on certain > WLAN > >>>networks, but shall not be routed on other WLAN networks, how does the > LMA know > >> > >>>which specific WLAN network the host is connected to? Perhaps I missed > the > >>>ability for the MAG to know e.g. the WLAN SSID and provide it to the > LMA, in > >>>which case I would appreciate if somebody could highlight to me where > that is > > >>>defined. > >>> > >>>I think that, though not integral to the protocol specification, > understanding > > > >>>what framework the protocol would/needs to fit in is rather important. > >>> > >>> > >>>Cheers, > >>>Stefano > >>> > >>> > >>>On Tue, Feb 1, 2011 at 3:47 PM, >>> > > > >wrote: > >>> > >>>Hello, > >>> > >>>We have discussed the flow mobility solutions for Proxy MIP6 previousl= y > at > >>>IETFs 78 and 79. > >>>This is a consensus call for adopting this I-D: > >>>draft-bernardos-netext-pmipv6-flowmob-02 > >>>as the working group document. > >>>I-D: > http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt > >>> > >>>The consensus call will expire on Feb 15th, 2011. Please indicate your > >>>support or concerns in adopting this I-D as the WG baseline document o= n > >>>the mailing list. > >>> > >>>Please note that this I-D will serve as the baseline in the WG and wil= l > be > >>>developed further based on input and feedback from WG members. > >>> > >>>-Basavaraj > >>> > >>>_______________________________________________ > >>>netext mailing list > >>>netext@ietf.org > >>>https://www.ietf.org/mailman/listinfo/netext > >>> > >>> > >>> > >> > >> > >> > >>-- > >>Stefano M. Faccin > >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>May the Force be with you > >> > >> > >> > >>-- > >>Stefano M. Faccin > >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>May the Force be with you > >> > >> > >> > >>-- > >>Stefano M. Faccin > >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>May the Force be with you > > > > > >-- > >Stefano M. Faccin > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >May the Force be with you > > > > > > --=20 Stefano M. Faccin =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D May the Force be with you --0016363b8b70510d66049b54ea06 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Behcet,
thanks for the reminder that we are indeed targeting 3GPP and sp= ecific interfaces as our customer. Indeed if a working solution that fits t= he framework of S2a and S2b is designed, it could be used at the discretion= of 3GPP. However, if "a missing part" needs to be provided, I be= lieve the technical issues I raise are indeed in the scope and need to be a= ddressed in order to make the protocol applicable to the customer. Expectin= g to define a solution that does not fit the customer and throwing the prot= ocol over the fence to them to fix their part to make the protocol work doe= s not sound like a good design approach to me.

Cheers,
Stefano

On Wed, Feb 2, 201= 1 at 2:54 PM, Behcet Sarikaya <behcetsarikaya@yahoo.com> wrote:
Hi Stefano,
=A0This draft addresses:
IP Flow Mobility and Seamless Offload (IFOM) on S2a and S2b interfaces.
As we already have a solution (in RFC 6088 and 6089) for s2c, this document= aims

to address the missing part.

The issues you raised are out of scope for the document.

Regards,

Behcet



>Hello JC,
>thanks for acknowledging that there is indeed an issue with the current= draft.
>
>For my clarification, how would the "MAG forward the packet with n= o problem"? I

>am not sure I am understanding what the sequence of steps would be.
>
>
>Also, I guess that as you say the solution is not included in the curre= nt draft,
>
>which means modifying the protocol that we have in the current draft. >
>Cheers,
>Stefano
>
>
>On Wed, Feb 2, 2011 at 12:37 PM, Zuniga, Juan Carlos
><JuanCarlos.Zu= niga@interdigital.com> wrote:
>
>Hi Stefano,
>>
>>Thanks for the response (you forgot to copy the list again ;).
>>
>>What I had in mind was what they call Basic solution in the documen= t, in which

>>the same set of prefixes are assigned to different interfaces (or M= AGs). In this
>>
>>case the MN can decide (based on policies) to change the flow and s= end packets

>>over a new interface. The MAG would forward the packet with no prob= lem and upon
>
>>receiving this packet the LMA would implicitly know that the MN has= performed a
>
>>flow movement (again, based on policies). At this point the LMA wou= ld just need
>
>>to change its routing table accordingly and start sending packets f= or this flow
>
>>over the new interface (similar rule to the one already specified f= or the
>>mobile).
>>
>>I see this as a lightweight solution to the problem you pointed out= that could

>>easily be added to the document.
>>
>>Jc
>>
>>
>>
>>From:stefano faccin [mailto:sfaccinstd@gmail.com]
>>Sent: February 2, 2011 3:11 PM
>>To: Zuniga, Juan Carlos
>>
>>Subject: Re: [netext] Consensus call to adopt I-D:
>>draft-bernardos-netext-pmipv6-flowmob as WG doc
>>
>>
>>Hi JC,
>>
>>As you say in 3GPP for the MN-based model this has been solved. How= ever, if we

>>want to apply a similar solution, we go back to the argument that i= t would
>>require the MN to be able to communicate the decisions to the MAG/L= MA but, as we
>>
>>discussed previously, we don't have a solution for that. This m= eans that
>>applying this protocol with a model similar to the one currently sp= ecified in
>>IETF and 3GPP requires the definition of a solution that does not y= et exist (at
>
>>Layer 3 or at Layer 2). I am concerned about developing only some p= ieces of a
>>solution.
>>
>>Alternatively, as you say the MAG reacts. However, it is not clear = to me that
>>the current draft describes how that happens.
>>
>>Cheers,
>>Stefano
>>On Wed, Feb 2, 2011 at 11:56 AM, Zuniga, Juan Carlos
>><JuanCarlo= s.Zuniga@interdigital.com> wrote:
>>Stefano,
>>
>>As much as I agree with most of your points about the problem from = the 3GPP
>>architecture point of view, I think that there is more than one sol= ution.
>>
>>We are assuming of course that what we have is a scenario where bot= h networks
>>are in the same PMIP domain and IP flow mobility is then possible. = You point out
>>
>>that there are no means to convey policies to the LMA or MAG. Howev= er, there are
>>
>>means to convey these policies to the MN as it is already defined i= n 3GPP for
>>the client-based IP flow mobility case (i.e. ANDSF). Hence, one dif= ferent
>>solution could be to let the MN apply the policy by moving the flow= and make the
>>
>>MAG and LMA =93react=94 to the IP flow change assuming that the flo= w change was made
>>
>>according to the policy being applied at the mobile.
>>
>>I would see this scenario equivalent to the one specified in 3GPP f= rom the point
>>
>>of view of node=92s responsibilities, don=92t you think?
>>
>>Jc
>>
>>
>>From:netext-bounc= es@ietf.org [mailto:netext-b= ounces@ietf.org] On Behalf Of
>>stefano faccin
>>Sent: February 2, 2011 2:41 PM
>>To: Rajeev Koodli; netext@ietf.o= rg
>>
>>Subject: Re: [netext] Consensus call to adopt I-D:
>>draft-bernardos-netext-pmipv6-flowmob as WG doc
>>
>>Sorry, I forgot to reply to the whole list.
>>Cheers,
>>Stefano
>>On Wed, Feb 2, 2011 at 11:29 AM, stefano faccin <sfaccinstd@gmail.com> wrote:
>>Hi Rajeev,
>>in current solution the policy is in sync, since it is the ANDSF (t= he network
>>counterpart of the MN for the policy) that configures it in the MN.= That does
>>not mean that the LMA has such policy.
>>
>>
>>Cheers,
>>Stefano
>>
>>On Wed, Feb 2, 2011 at 11:46 AM, Rajeev Koodli <rkoodli@cisco.com> wrote:
>>
>>Hi Gerardo,
>> =A0 =A0* my point is that =A0 =A0 =A0someone/something is configur= ing the policy on the
>>MN
>>
>>which needs to be in =A0 =A0 =A0sync with the MN=92s partner, i.e.,= the network. If this
>>
>>is not the case, =A0 =A0 =A0please let me know.
>>
>> =A0 =A0* The last I heard, =A0 =A0 =A0PMIP6 is applicable on the e= HRPD (trusted non-3GPP
>
>>network). Also, 33.402 =A0 =A0 =A0does not specify whether a partic= ular type of access
>>
>>network (such as =A0 =A0 =A0WLAN) is considered trusted or untruste= d (although a
>>majority of the WLAN =A0 =A0 =A0access could be considered untruste= d today).
>>
>>
>>-Rajeev
>>
>>
>>
>>On 2/2/11 11:16 AM, "Giaretta, Gerardo" <gerardog@qualcomm.com> wrote:
>>Hi Rajeev,
>>>
>>>A couple of considerations on this:
>>>
>>>- =A0 =A0 =A0 =A0 This draft assumes there is consistency in th= e rules. This is a new

>>>requirement for the system architecture where this solution wil= l be applied.
>>>There is no this requirement for other solutions already adopte= d by IETF and
>>>3GPP. In my view this seems a fairly important issue.
>>>
>>>- =A0 =A0 =A0 =A0 The routing decisions based on WLAN SSID are = different from
>>>trusted/untrusted. Note also that PMIPv6 cannot be used in trus= ted networks so
>
>>>it is not clear at all what you are referring to.
>>>
>>>
>>>Gerardo
>>>
>>>
>>>From:netext-b= ounces@ietf.org [mailto:nete= xt-bounces@ietf.org] On Behalf Of
>>>Rajeev Koodli
>>>Sent: Wednesday, February 02, 2011 11:28 AM
>>>To: stefano faccin
>>>Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
>>>Subject: Re: [netext] Consensus call to adopt I-D:
>>>draft-bernardos-netext-pmipv6-flowmob as WG doc
>>>
>>>
>>>Stefano,
>>>
>>>Regardless of how the policy is configured on the LMA, there is= a consistency of
>>>
>>>the rules which needs to be ensured regardless. Whatever the en= tity (OMA-DM?!)
>
>>>is that configures the policy has to ensure such a consistency.=
>>>
>>>We can debate about how policy interaction works, but that=92s = another topic. I

>>>would note that there are choices here (modulo respective pros = and cons).
>>>
>>>I didn=92t suggest that an operator should just trust the softw= are on a MN,
>>>although I suspect some device vendors might argue for their ro= bustness
>>>(surprise?).
>>>
>>>
>>>I would frame the WLAN access problem as whether the access is = considered
>>>trusted or not. Accordingly, you apply the policy.
>>>
>>>-Rajeev
>>>
>>>
>>>On 2/2/11 10:50 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:
>>>Raj,
>>>thanks for the reply.
>>>
>>>If the LMA has statically configured policies, how do we ensure= that the MN has
>>
>>>the same policies? That would mean implicitly assuming that the= policies
>>>provisioned to the MN by the ANDSF "always" match wha= t has been set in the LMA,
>>
>>>which I think it is unrealistic because the policies change ove= r time, and every
>>>
>>>time you need to update all the LMAs, which has a considerable = operational cost.
>>>
>>>Instead, if we leave the MN to make the choice, there are easy = and well
>>>specified mechanisms that allow the provisioning of policies in= the MN and for
>
>>>the MN to make such decision and communicate it to the network,= so that the
>>>network can
>>>
>>>
>>>As for extensions to Gx, I am not stating that in theory one co= uld extend Gx.

>>>However, at present such solution does not exists, and without = it, I do not see
>>
>>>how the draft is applicable to 3GPP that is at present the only= potential
>>>customer identified (I guess I did not see any other identified= ?)
>>>
>>>Even assuming that Gx could be modified, the issue of the per-a= ccess network
>>>granularity remains. Even if the LMA has the right policies in = place, the LMA

>>>has no way of knowing exactly what access network of a specific= access
>>>technology (e.g. which SSID for WLAN0 the MN is connecting to.<= br> >>>
>>>
>>>I cannot agree with your assumption below that if the MN connec= ts to an SSID it
>>
>>>is because the operator is OK with routing traffic on that SSID= , and that we
>>>should just "trust the software on the MN". There are= two aspects to
consider:
>>>1) whether it is OK for certain traffic to be routed at all ove= r a certain
>>>access access network of a specific access technology
>>>2) how different traffic should be routed over different access= networks of
>>>different access technologies
>>>
>>>Regarding these two points, the issue is whether the operator w= ants to allow
>>>traffic e.g. over a certain SSID or not. So, in that case, it i= s obvious as you
>>
>>>say that if the MN has connected to an SSID configured by the o= perator in the

>>>MN, then traffic could be allowed over that SSID. However, we n= eed to consider
>
>>>that 3GPP allows the decision of which WLAN the MN can connect = to based on user
>>
>>>preferences. This means that my MN can e.g. connect to my home = WLAN (which is

>>>not controlled necessarily by the operator and whose SSID the o= perator does not
>>
>>>know) or to a coffee shop WLAN, even if the device does not hav= e those SSID
>>>configured. Those are typical examples of untrusted WLAN access= networks.
>>>Therefore, in such cases, just because the MN has connected to = a WLAN SSID, does
>>>
>>>not mean that the operator wants to route certain traffic over = that SSID just

>>>because the policy says "route traffic X over WLAN".<= br> >>>
>>>
>>>That brings us to a solution that, if applied to 3GPP, provides= less
>>>functionality than what is available and has been specified tod= ay, so back to my
>>>
>>>point above.
>>>
>>>Unfortunately, there is no solution I am aware of that allows t= he WLAN network
>
>>>to indicate to the MAG/LMA the specific SSID (and as you say, t= here is no easy
>
>>>solution for that). Due to this and the points above about poli= cy provisioning,
>>
>>>it means that the applicability of this solution to a real case= like 3GPP
>>>depends on the feasibility of extending policy mechanisms in 3G= PP, and the
>>>ability to have a solution where the WLAN network provides the = SSID information
>>
>>>to the MAG/LMA. Moreover, the provisioning of such SSID is not = in the scope of
>
>>>IETF, but not even of 3GPP (since the interface between the WLA= N AP and the ePDG
>>>
>>>is not defined), thus I wonder how this could be defined at all= (I am afraid of
>>
>>>asking what magic should happen here). So, now we have two big = dependencies.
>>>
>>>
>>>In general, I am also wondering if there is a customer that has= asked us to
>>>define this solution. I am not aware of any but I may have miss= ed that.
>>>
>>>Cheers,
>>>Stefano
>>>
>>>On Wed, Feb 2, 2011 at 10:44 AM, Rajeev Koodli <rkoodli@cisco.com> wrote:
>>>
>>>Hi Stefano,
>>>
>>>You make two interesting points: First, the defined solution sh= ould be useful

>>>for 3GPP deployments. Second, if it=92s not defined today in 3G= PP, it=92s not
>>>useful.
>>>
>>>I tend to agree with you on the first =96 3GPP is a big potenti= al customer.
>>>I cannot agree with your second point.
>>>
>>>There are multiple ways I could envision policy on the LMA. Loc= ally configured
>
>>>policy is one (which we use today in deployments) that does not= need Gx
>>>interaction. Gx extensions can be proposed in the future. I hop= e you are not
>>>suggesting that these are not feasible choices.
>>>
>>>For the MN (IETF term for UE) to even connect to the MAG via WL= AN today, you
>>>need an IPsec termination point (ePDG). If the operator pre-con= figures the list
>>
>>>of SSIDs or there is some out-of-band mechanism to inform the M= N which SSID is
>
>>>=93white-listed=94, then I expect the MN to decide when to conn= ect to the ePDG and
>
>>>hence the MAG. At this point, the MN is already on the WLAN the= operator cares
>
>>>about I presume.
>>>
>>>There is no easy way for the network (LMA, MAG) to know what SS= ID the MN is
>>>connected to =96 the network has to either trust the software o= n the MN or the
>>>WLAN infrastructure has to provide the SSID information to the = network.
>>>
>>>
>>>-Rajeev
>>>
>>>
>>>
>>>On 2/2/11 9:56 AM, "stefano faccin" <sfaccinstd@gmail.com
>>><http://sfac= cinstd@gmail.com>= > wrote:
>>>Hello rajeev,
>>>the use of PCRF is an interesting suggestion. However, unfortun= ately, PCRF does
>>
>>>not contain any policies or information that will tell the LMA = what are the
>>>policies to be used for decisions of IP flow mobility. This is = not part of
>>>current PCC functionality, and there is no work ongoing or plan= ned to extend PCC
>>>
>>>in such way. Therefore, the applicability of the solution in th= is draft would

>>>hinge on hypotetical future solutions and not on a current solu= tion for the open
>>>
>>>issues, which brings us back to my point that we are defining a= solution with

>>>open issues for which there is not a single realistic solution = out there, thus
>
>>>making this draft not applicable to a real scenario.
>>>
>>>I am not thinking of the UE connecting to more than one WLAN at= the same time,
>
>>>but the UE being able to connect to different WLANs (one at a t= ime) because the
>>
>>>UE is e.g. provisioned with a list of SSIDs or the UE discovers= a hotspot
>>>somewhere. I am talking about the scenario where the UE is capa= ble to connect to
>>>
>>>WLAN, but the operator has different policies wrt which WLAN th= e UE should use
>
>>>or not.
>>>
>>>If you have followed the work in 3GPP, it is clear that operato= rs have interest
>>
>>>in applying policies not only at RAT level, but also at access = network level
>>>(please see how ANDSF was defined and why). I guess we can all = agree that an
>>>operator deploying PMIP-based mobility may be interested in hav= ing policies that
>>>
>>>allow traffic on the WLAN the operator owns or that belongs to = a roaming
>>>partner, while not allowing traffic on WLAN of other operators = for which it
>>>might need to pay an extra fee or where e.g. no QoS can be guar= anteed. That
>>>means that the entity deciding whether traffic needs to be rout= ed on WLAN or not
>>>
>>>cannot just consider "WLAN is available", but "W= LAN SSIDx is available", so that
>>>
>>>the decision can be based on the operator preferences as to whi= ch WLAN certain
>
>>>traffic needs to be routed on.
>>>
>>>
>>>If the draft allows decisions to be made only at the RAT level,= then we have an
>>
>>>issue because we are defining a solution that should be applica= ble to 3GPP but
>
>>>does not meet the deployment scenarios of interest. In other wo= rds, if we want
>
>>>to make this solution applicable e.g. to 3GPP, we need to be ab= le to provide the
>>>
>>>same functionality available today in 3GPP with other solution = in order to
>>>satisfy the use cases supported by 3GPP, and not step backwards= in terms of what
>>>
>>>can be supported.
>>>
>>>Cheers,
>>>
>>>Stefano
>>>
>>>On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli <rkoodli@cisco.com
>>><http://rkoodli= @cisco.com> > = wrote:
>>>
>>>Hi Stefano,
>>>
>>>Thanks for your input.
>>>
>>>I expect the LMA interacting with PCRF for policy rules specifi= c to the
>>>subscriber for different RAT types.
>>>You are right that the LMA does not know the SSID the mobile is= connected to.

>>>It=92s not clear if the MAG can get that from the MN either wit= hout additional
>>>signaling. However, the LMA knows that the MN is connected to W= LAN; so it can

>>>apply the policy at the RAT type level. Are you thinking of the= MN connecting to
>>>
>>>more than one WLAN network (and each of those connections comin= g back to the
>>>LMA)? If so, please explain the scenario.
>>>
>>>Regards,
>>>
>>>-Rajeev
>>>
>>>
>>>
>>>
>>>On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com
>>><http://sfac= cinstd@gmail.com>= =A0<http://sfaccinstd@gmail.com> > wr= ote:
>>>Raj,
>>>thanks for the email.
>>>
>>>I need to apologize in advance if my questions have already bee= n answered before
>>>
>>>(though I cannot find a conclusive answer anywhere).
>>>
>>>I think that a protocol that is developed in NETEXT (or other g= roups) should
>>>have at least a potential realistic scenario for applicability.=
>>>
>>>In terms of applicability, though it is not part of the protoco= l definition per
>>
>>>se, unless there are solutions in place for either the host to = indicate to the
>
>>>network where the flows should be routed or for the LMA to rece= ive somehow from
>>
>>>somewhere some policies, the solution cannot really provide flo= w mobility since
>>
>>>there is no way to decide which flows are routed where. If we a= re thinking about
>>>
>>>a host-based solution, I have not yet seen a solution as to how= the host can
>>>indicate to the MAG and ultimately to the MAG which flows shoul= d be routed on

>>>each access. If we are relying on modifications of layer 2 prot= ocols, aren't we
>>
>>>defining a solution that works only with some technologies (sin= ce for other
>>>access technologies it is rather unrealistic to modify L2 for I= P flow mobility
>
>>>purposes)? If we are thinking of an LMA-based solution, can we = hear of at least
>>
>>>one example of a real-life scenario where the LMA would receive= such policies,
>
>>>and how such delivery would happen? Also, should there be a sol= ution to have
>>>policies in the LMA, how does the LMA actually decide to route = flows on one
>>>access or the other? E.g., if some flows need to be routed on c= ertain WLAN
>>>networks, but shall not be routed on other WLAN networks, how d= oes the LMA know
>>
>>>which specific WLAN network the host is connected to? Perhaps I= missed the
>>>ability for the MAG to know e.g. the WLAN SSID and provide it t= o the LMA, in
>>>which case I would appreciate if somebody could highlight to me= where that is

>>>defined.
>>>
>>>I think that, though not integral to the protocol specification= , understanding
>
>>>what framework the protocol would/needs to fit in is rather imp= ortant.
>>>
>>>
>>>Cheers,
>>>Stefano
>>>
>>>
>>>On Tue, Feb 1, 2011 at 3:47 PM, =A0<Basavaraj.Patil@nokia.com
>>><http:/= /Basavaraj.Patil@nokia.c= om> =A0<http= ://Basavaraj.Patil@nokia= .com> >
>wrote:
>>>
>>>Hello,
>>>
>>>We have discussed the flow mobility solutions for Proxy MIP6 pr= eviously at
>>>IETFs 78 and 79.
>>>This is a consensus call for adopting this I-D:
>>>draft-bernardos-netext-pmipv6-flowmob-02
>>>as the working group document.
>>>I-D: http://www.ietf.org/id/draft-bernar= dos-netext-pmipv6-flowmob-02.txt
>>>
>>>The consensus call will expire on Feb 15th, 2011. Please indica= te your
>>>support or concerns in adopting this I-D as the WG baseline doc= ument on
>>>the mailing list.
>>>
>>>Please note that this I-D will serve as the baseline in the WG = and will be
>>>developed further based on input and feedback from WG members.<= br> >>>
>>>-Basavaraj
>>>
>>>_______________________________________________
>>>netext mailing list
>>>netext@ietf.org <http://netext@ietf.org> =A0<http://netext@ietf.org>
>>>https://www.ietf.org/mailman/listinfo/netext
>>>
>>>
>>>
>>
>>
>>
>>--
>>Stefano M. Faccin
>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>May the Force be with you
>>
>>
>>
>>--
>>Stefano M. Faccin
>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>May the Force be with you
>>
>>
>>
>>--
>>Stefano M. Faccin
>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>May the Force be with you
>
>
>--
>Stefano M. Faccin
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>May the Force be with you
>






--
Stefano M. = Faccin
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
May the= Force be with you
--0016363b8b70510d66049b54ea06-- From cjbc@it.uc3m.es Wed Feb 2 15:19:42 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71CCF3A6C7A for ; Wed, 2 Feb 2011 15:19:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.056 X-Spam-Level: X-Spam-Status: No, score=-4.056 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88Zzkn3wDfGy for ; Wed, 2 Feb 2011 15:19:41 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id C3B753A6BC2 for ; Wed, 2 Feb 2011 15:19:40 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.3] (213.37.82.169.static.user.ono.com [213.37.82.169]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id E4C0270D88B; Thu, 3 Feb 2011 00:23:00 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Julien Laganier In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-xrhTlHsqNplcdk4EDIQP" Organization: Universidad Carlos III de Madrid Date: Thu, 03 Feb 2011 00:23:57 +0100 Message-ID: <1296689037.3593.20.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17932.002 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 23:19:42 -0000 --=-xrhTlHsqNplcdk4EDIQP Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Julien, Can you please summarize the issues you raised? As far as I recall, your main concern was about the scenario in which the prefix(es) is not shared between all the physical interfaces of the MN, correct me if I'm wrong. In regards to this, as I think we answered, there are a number of scenarios that people expressed interest about that requires to support it. Current draft support this and the shared-prefix scenario. If the WG reaches a consensus in removing the non-shared prefix scenario, we are happy to do it, but my understanding was that not all the WG had that opinion (at that time, at least). Thanks, Carlos On Wed, 2011-02-02 at 15:06 -0800, Julien Laganier wrote: > Raj, >=20 > As with the other draft (logical interface), I have raised a number of > issues with this draft that in my humble opinion have not been addressed > adequately, and thus at this stage I believe that asking for adoption is > premature. In other words, I'd like the issues that I've raised to be > addressed by the authors before I feel comfortable having an opinion on > whether or not this draft is a good basis to progress the flow mobility > extensions. >=20 > Thank you for your consideration, >=20 > --julien >=20 > On Tue, Feb 1, 2011 at 3:47 PM, wrote: >=20 > > > > Hello, > > > > We have discussed the flow mobility solutions for Proxy MIP6 previously= at > > IETFs 78 and 79. > > This is a consensus call for adopting this I-D: > > draft-bernardos-netext-pmipv6-flowmob-02 > > as the working group document. > > I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.tx= t > > > > The consensus call will expire on Feb 15th, 2011. Please indicate your > > support or concerns in adopting this I-D as the WG baseline document on > > the mailing list. > > > > Please note that this I-D will serve as the baseline in the WG and will= be > > developed further based on input and feedback from WG members. > > > > -Basavaraj > > > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-xrhTlHsqNplcdk4EDIQP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1J540ACgkQNdy6TdFwT2dgLwCgptgH6LWGnpox+1vWeHVyIwSn wXsAoLhOzMY0Fx3vf5jQrqNIYH9/iB1C =ZZcz -----END PGP SIGNATURE----- --=-xrhTlHsqNplcdk4EDIQP-- From cjbc@it.uc3m.es Wed Feb 2 15:22:14 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA28D3A6C7A for ; Wed, 2 Feb 2011 15:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.056 X-Spam-Level: X-Spam-Status: No, score=-4.056 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrNisKR6fIEk for ; Wed, 2 Feb 2011 15:22:12 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id CBADD3A6BC2 for ; Wed, 2 Feb 2011 15:22:10 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.3] (213.37.82.169.static.user.ono.com [213.37.82.169]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 699AB74EF51; Thu, 3 Feb 2011 00:25:29 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: stefano faccin In-Reply-To: References: <1296687154.3593.15.camel@acorde.it.uc3m.es> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-WbMgvTQOS7gHsPo8sdUb" Organization: Universidad Carlos III de Madrid Date: Thu, 03 Feb 2011 00:26:31 +0100 Message-ID: <1296689191.3593.23.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17932.002 Cc: netext@ietf.org, "Zuniga, Juan Carlos" Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 23:22:15 -0000 --=-WbMgvTQOS7gHsPo8sdUb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2011-02-02 at 15:18 -0800, stefano faccin wrote: > Hello Carlos, > unfortunately I beg to disagree. Indeed we are chartered to do this work, > but at the same time developing a protocol that due to technical limitati= ons > cannot be adopted in realistic scenarios seems a fruitless effort. >=20 > I would also beg to disagree that 3GPP will have to modify their > architecture to allow this solution to work. I believe that, if 3GPP is t= o > be a customer, the protocol must be developed to fit the need of the > customer, not the other way around. True, if the requirements are such that allow a solution to be developed. Having IP-unmodified MNs and not being able to assume that the network and the MN have a mean to keep their policies in sync (which is not based on IP signaling from the MN) is a blocking situation, IMHO. Carlos >=20 > Cheers, > Stefano >=20 > 2011/2/2 Carlos Jes=C3=BAs Bernardos Cano >=20 > > Hi Stefano, > > > > Thanks for the comments on the draft. Two comments from my side: > > > > - Regarding the comment about the potential realistic scenario for > > applicability, this is not an issue of this solution (or any other), if > > it is an issue at all. We are chartered to work on protocol extensions > > for flow mobility without introducing any changes to the IP stack of th= e > > MN. IMHO all your comments on this regard relates to the charter itself= , > > not this draft. > > > > - Regarding the comments about the "lack of support from 3GPP", I > > acknowledge that 3GPP is an important potential customer, but as far as > > I know, we are not chartered to come up with a 3GPP-only solution, and = I > > think it's fair to design a solution that works under certain > > assumptions, as long as those assumptions cannot realistically be met i= n > > a particular network deployment. I think it's fair to expect that 3GPP > > may need to add also extensions to make this solution work in their > > architecture. > > > > Thanks, > > > > Carlos > > > > On Wed, 2011-02-02 at 14:26 -0800, stefano faccin wrote: > > > Hello JC, > > > thanks for acknowledging that there is indeed an issue with the curre= nt > > > draft. > > > > > > For my clarification, how would the "MAG forward the packet with no > > > problem"? I am not sure I am understanding what the sequence of steps > > would > > > be. > > > > > > Also, I guess that as you say the solution is not included in the cur= rent > > > draft, which means modifying the protocol that we have in the current > > draft. > > > > > > Cheers, > > > Stefano > > > > > > On Wed, Feb 2, 2011 at 12:37 PM, Zuniga, Juan Carlos < > > > JuanCarlos.Zuniga@interdigital.com> wrote: > > > > > > > Hi Stefano, > > > > > > > > > > > > > > > > Thanks for the response (you forgot to copy the list again ;). > > > > > > > > > > > > > > > > What I had in mind was what they call Basic solution in the documen= t, > > in > > > > which the same set of prefixes are assigned to different interfaces= (or > > > > MAGs). In this case the MN can decide (based on policies) to change= the > > flow > > > > and send packets over a new interface. The MAG would forward the pa= cket > > with > > > > no problem and upon receiving this packet the LMA would implicitly = know > > that > > > > the MN has performed a flow movement (again, based on policies). At > > this > > > > point the LMA would just need to change its routing table according= ly > > and > > > > start sending packets for this flow over the new interface (similar > > rule to > > > > the one already specified for the mobile). > > > > > > > > > > > > > > > > I see this as a lightweight solution to the problem you pointed out > > that > > > > could easily be added to the document. > > > > > > > > > > > > > > > > Jc > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *From:* stefano faccin [mailto:sfaccinstd@gmail.com] > > > > *Sent:* February 2, 2011 3:11 PM > > > > *To:* Zuniga, Juan Carlos > > > > > > > > *Subject:* Re: [netext] Consensus call to adopt I-D: > > > > draft-bernardos-netext-pmipv6-flowmob as WG doc > > > > > > > > > > > > > > > > Hi JC, > > > > > > > > As you say in 3GPP for the MN-based model this has been solved. > > However, if > > > > we want to apply a similar solution, we go back to the argument tha= t it > > > > would require the MN to be able to communicate the decisions to the > > MAG/LMA > > > > but, as we discussed previously, we don't have a solution for that. > > This > > > > means that applying this protocol with a model similar to the one > > currently > > > > specified in IETF and 3GPP requires the definition of a solution th= at > > does > > > > not yet exist (at Layer 3 or at Layer 2). I am concerned about > > developing > > > > only some pieces of a solution. > > > > > > > > Alternatively, as you say the MAG reacts. However, it is not clear = to > > me > > > > that the current draft describes how that happens. > > > > > > > > Cheers, > > > > Stefano > > > > > > > > On Wed, Feb 2, 2011 at 11:56 AM, Zuniga, Juan Carlos < > > > > JuanCarlos.Zuniga@interdigital.com> wrote: > > > > > > > > Stefano, > > > > > > > > > > > > > > > > As much as I agree with most of your points about the problem from = the > > 3GPP > > > > architecture point of view, I think that there is more than one > > solution. > > > > > > > > > > > > > > > > We are assuming of course that what we have is a scenario where bot= h > > > > networks are in the same PMIP domain and IP flow mobility is then > > possible. > > > > You point out that there are no means to convey policies to the LMA= or > > MAG. > > > > However, there are means to convey these policies to the MN as it i= s > > already > > > > defined in 3GPP for the client-based IP flow mobility case (i.e. > > ANDSF). > > > > Hence, one different solution could be to let the MN apply the poli= cy > > by > > > > moving the flow and make the MAG and LMA =E2=80=9Creact=E2=80=9D to= the IP flow change > > > > assuming that the flow change was made according to the policy bein= g > > applied > > > > at the mobile. > > > > > > > > > > > > > > > > I would see this scenario equivalent to the one specified in 3GPP f= rom > > the > > > > point of view of node=E2=80=99s responsibilities, don=E2=80=99t you= think? > > > > > > > > > > > > > > > > Jc > > > > > > > > > > > > > > > > > > > > > > > > *From:* netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] *O= n > > > > Behalf Of *stefano faccin > > > > *Sent:* February 2, 2011 2:41 PM > > > > *To:* Rajeev Koodli; netext@ietf.org > > > > > > > > > > > > *Subject:* Re: [netext] Consensus call to adopt I-D: > > > > draft-bernardos-netext-pmipv6-flowmob as WG doc > > > > > > > > > > > > > > > > Sorry, I forgot to reply to the whole list. > > > > Cheers, > > > > Stefano > > > > > > > > On Wed, Feb 2, 2011 at 11:29 AM, stefano faccin > > > > wrote: > > > > > > > > Hi Rajeev, > > > > in current solution the policy is in sync, since it is the ANDSF (t= he > > > > network counterpart of the MN for the policy) that configures it in= the > > MN. > > > > That does not mean that the LMA has such policy. > > > > > > > > Cheers, > > > > Stefano > > > > > > > > > > > > > > > > On Wed, Feb 2, 2011 at 11:46 AM, Rajeev Koodli > > wrote: > > > > > > > > > > > > Hi Gerardo, > > > > > > > > - my point is that someone/something is configuring the policy o= n > > the > > > > MN which needs to be in sync with the MN=E2=80=99s partner, i.e.= , the > > network. If > > > > this is not the case, please let me know. > > > > - The last I heard, PMIP6 is applicable on the eHRPD (trusted > > non-3GPP > > > > network). Also, 33.402 does not specify whether a particular typ= e of > > access > > > > network (such as WLAN) is considered trusted or untrusted (altho= ugh > > a > > > > majority of the WLAN access could be considered untrusted today)= . > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > On 2/2/11 11:16 AM, "Giaretta, Gerardo" wro= te: > > > > > > > > Hi Rajeev, > > > > > > > > A couple of considerations on this: > > > > > > > > - This draft assumes there is consistency in the rules. Thi= s is > > a > > > > new requirement for the system architecture where this solution wil= l be > > > > applied. There is no this requirement for other solutions already > > adopted by > > > > IETF and 3GPP. In my view this seems a fairly important issue. > > > > > > > > - The routing decisions based on WLAN SSID are different fr= om > > > > trusted/untrusted. Note also that PMIPv6 cannot be used in trusted > > networks > > > > so it is not clear at all what you are referring to. > > > > > > > > > > > > Gerardo > > > > > > > > > > > > *From:* netext-bounces@ietf.org [mailto:netext-bounces@ietf.org< > > netext-bounces@ietf.org>] > > > > *On Behalf Of *Rajeev Koodli > > > > *Sent:* Wednesday, February 02, 2011 11:28 AM > > > > *To:* stefano faccin > > > > *Cc:* netext@ietf.org; Basavaraj.Patil@nokia.com > > > > *Subject:* Re: [netext] Consensus call to adopt I-D: > > > > draft-bernardos-netext-pmipv6-flowmob as WG doc > > > > > > > > > > > > Stefano, > > > > > > > > Regardless of how the policy is configured on the LMA, there is a > > > > consistency of the rules which needs to be ensured regardless. What= ever > > the > > > > entity (OMA-DM?!) is that configures the policy has to ensure such = a > > > > consistency. > > > > > > > > We can debate about how policy interaction works, but that=E2=80=99= s another > > topic. > > > > I would note that there are choices here (modulo respective pros an= d > > cons). > > > > > > > > I didn=E2=80=99t suggest that an operator should just trust the sof= tware on a > > MN, > > > > although I suspect some device vendors might argue for their robust= ness > > > > (surprise?). > > > > > > > > I would frame the WLAN access problem as whether the access is > > considered > > > > trusted or not. Accordingly, you apply the policy. > > > > > > > > -Rajeev > > > > > > > > > > > > On 2/2/11 10:50 AM, "stefano faccin" wrote: > > > > Raj, > > > > thanks for the reply. > > > > > > > > If the LMA has statically configured policies, how do we ensure tha= t > > the MN > > > > has the same policies? That would mean implicitly assuming that the > > policies > > > > provisioned to the MN by the ANDSF "always" match what has been set= in > > the > > > > LMA, which I think it is unrealistic because the policies change ov= er > > time, > > > > and every time you need to update all the LMAs, which has a > > considerable > > > > operational cost. Instead, if we leave the MN to make the choice, t= here > > are > > > > easy and well specified mechanisms that allow the provisioning of > > policies > > > > in the MN and for the MN to make such decision and communicate it t= o > > the > > > > network, so that the network can > > > > > > > > As for extensions to Gx, I am not stating that in theory one could > > extend > > > > Gx. However, at present such solution does not exists, and without = it, > > I do > > > > not see how the draft is applicable to 3GPP that is at present the = only > > > > potential customer identified (I guess I did not see any other > > identified?) > > > > > > > > > > > > Even assuming that Gx could be modified, the issue of the per-acces= s > > > > network granularity remains. Even if the LMA has the right policies= in > > > > place, the LMA has no way of knowing exactly what access network of= a > > > > specific access technology (e.g. which SSID for WLAN0 the MN is > > connecting > > > > to. > > > > > > > > I cannot agree with your assumption below that if the MN connects t= o an > > > > SSID it is because the operator is OK with routing traffic on that > > SSID, and > > > > that we should just "trust the software on the MN". There are two > > aspects to > > > > consider: > > > > 1) whether it is OK for certain traffic to be routed at all over a > > certain > > > > access access network of a specific access technology > > > > 2) how different traffic should be routed over different access > > networks of > > > > different access technologies > > > > > > > > Regarding these two points, the issue is whether the operator wants= to > > > > allow traffic e.g. over a certain SSID or not. So, in that case, it= is > > > > obvious as you say that if the MN has connected to an SSID configur= ed > > by the > > > > operator in the MN, then traffic could be allowed over that SSID. > > However, > > > > we need to consider that 3GPP allows the decision of which WLAN the= MN > > can > > > > connect to based on user preferences. This means that my MN can e.g= . > > connect > > > > to my home WLAN (which is not controlled necessarily by the operato= r > > and > > > > whose SSID the operator does not know) or to a coffee shop WLAN, ev= en > > if the > > > > device does not have those SSID configured. Those are typical examp= les > > of > > > > untrusted WLAN access networks. Therefore, in such cases, just beca= use > > the > > > > MN has connected to a WLAN SSID, does not mean that the operator wa= nts > > to > > > > route certain traffic over that SSID just because the policy says > > "route > > > > traffic X over WLAN". > > > > > > > > That brings us to a solution that, if applied to 3GPP, provides les= s > > > > functionality than what is available and has been specified today, = so > > back > > > > to my point above. > > > > > > > > Unfortunately, there is no solution I am aware of that allows the W= LAN > > > > network to indicate to the MAG/LMA the specific SSID (and as you sa= y, > > there > > > > is no easy solution for that). Due to this and the points above abo= ut > > policy > > > > provisioning, it means that the applicability of this solution to a > > real > > > > case like 3GPP depends on the feasibility of extending policy > > mechanisms in > > > > 3GPP, and the ability to have a solution where the WLAN network > > provides the > > > > SSID information to the MAG/LMA. Moreover, the provisioning of such > > SSID is > > > > not in the scope of IETF, but not even of 3GPP (since the interface > > between > > > > the WLAN AP and the ePDG is not defined), thus I wonder how this co= uld > > be > > > > defined at all (I am afraid of asking what magic should happen here= ). > > So, > > > > now we have two big dependencies. > > > > > > > > In general, I am also wondering if there is a customer that has ask= ed > > us to > > > > define this solution. I am not aware of any but I may have missed t= hat. > > > > > > > > Cheers, > > > > Stefano > > > > > > > > On Wed, Feb 2, 2011 at 10:44 AM, Rajeev Koodli > > wrote: > > > > > > > > Hi Stefano, > > > > > > > > You make two interesting points: First, the defined solution should= be > > > > useful for 3GPP deployments. Second, if it=E2=80=99s not defined *t= oday* in > > 3GPP, > > > > it=E2=80=99s not useful. > > > > > > > > I tend to agree with you on the first =E2=80=93 3GPP is a big poten= tial > > customer. > > > > I cannot agree with your second point. > > > > > > > > There are multiple ways I could envision policy on the LMA. Locally > > > > configured policy is one (which we use today in deployments) that d= oes > > not > > > > need Gx interaction. Gx extensions can be proposed in the future. I > > hope you > > > > are not suggesting that these are not feasible choices. > > > > > > > > For the MN (IETF term for UE) to even connect to the MAG via WLAN > > today, > > > > you need an IPsec termination point (ePDG). If the operator > > pre-configures > > > > the list of SSIDs or there is some out-of-band mechanism to inform = the > > MN > > > > which SSID is =E2=80=9Cwhite-listed=E2=80=9D, then I expect the MN = to decide when to > > connect > > > > to the ePDG and hence the MAG. At this point, the MN is already on = the > > WLAN > > > > the operator cares about I presume. > > > > There is no easy way for the network (LMA, MAG) to know what SSID t= he > > MN is > > > > connected to =E2=80=93 the network has to either trust the software= on the MN > > or the > > > > WLAN infrastructure has to provide the SSID information to the netw= ork. > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > On 2/2/11 9:56 AM, "stefano faccin" > > > http://sfaccinstd@gmail.com> > wrote: > > > > Hello rajeev, > > > > the use of PCRF is an interesting suggestion. However, unfortunatel= y, > > PCRF > > > > does not contain any policies or information that will tell the LMA > > what are > > > > the policies to be used for decisions of IP flow mobility. This is = not > > part > > > > of current PCC functionality, and there is no work ongoing or plann= ed > > to > > > > extend PCC in such way. Therefore, the applicability of the solutio= n in > > this > > > > draft would hinge on hypotetical future solutions and not on a curr= ent > > > > solution for the open issues, which brings us back to my point that= we > > are > > > > defining a solution with open issues for which there is not a singl= e > > > > realistic solution out there, thus making this draft not applicable= to > > a > > > > real scenario. > > > > > > > > I am not thinking of the UE connecting to more than one WLAN at the > > same > > > > time, but the UE being able to connect to different WLANs (one at a > > time) > > > > because the UE is e.g. provisioned with a list of SSIDs or the UE > > discovers > > > > a hotspot somewhere. I am talking about the scenario where the UE i= s > > capable > > > > to connect to WLAN, but the operator has different policies wrt whi= ch > > WLAN > > > > the UE should use or not. > > > > > > > > If you have followed the work in 3GPP, it is clear that operators h= ave > > > > interest in applying policies not only at RAT level, but also at ac= cess > > > > network level (please see how ANDSF was defined and why). I guess w= e > > can all > > > > agree that an operator deploying PMIP-based mobility may be interes= ted > > in > > > > having policies that allow traffic on the WLAN the operator owns or > > that > > > > belongs to a roaming partner, while not allowing traffic on WLAN of > > other > > > > operators for which it might need to pay an extra fee or where e.g.= no > > QoS > > > > can be guaranteed. That means that the entity deciding whether traf= fic > > needs > > > > to be routed on WLAN or not cannot just consider "WLAN is available= ", > > but > > > > "WLAN SSIDx is available", so that the decision can be based on the > > operator > > > > preferences as to which WLAN certain traffic needs to be routed on. > > > > > > > > If the draft allows decisions to be made only at the RAT level, the= n we > > > > have an issue because we are defining a solution that should be > > applicable > > > > to 3GPP but does not meet the deployment scenarios of interest. In > > other > > > > words, if we want to make this solution applicable e.g. to 3GPP, we > > need to > > > > be able to provide the same functionality available today in 3GPP w= ith > > other > > > > solution in order to satisfy the use cases supported by 3GPP, and n= ot > > step > > > > backwards in terms of what can be supported. > > > > > > > > Cheers, > > > > > > > > Stefano > > > > > > > > On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli > > > http://rkoodli@cisco.com> > wrote: > > > > > > > > Hi Stefano, > > > > > > > > Thanks for your input. > > > > > > > > I expect the LMA interacting with PCRF for policy rules specific to= the > > > > subscriber for different RAT types. > > > > You are right that the LMA does not know the SSID the mobile is > > connected > > > > to. It=E2=80=99s not clear if the MAG can get that from the MN eith= er without > > > > additional signaling. However, the LMA knows that the MN is connect= ed > > to > > > > WLAN; so it can apply the policy at the RAT type level. Are you > > thinking of > > > > the MN connecting to more than one WLAN network (and each of those > > > > connections coming back to the LMA)? If so, please explain the > > scenario. > > > > > > > > Regards, > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > On 2/1/11 6:39 PM, "stefano faccin" > > > http://sfaccinstd@gmail.com> > wrote= : > > > > Raj, > > > > thanks for the email. > > > > > > > > I need to apologize in advance if my questions have already been > > answered > > > > before (though I cannot find a conclusive answer anywhere). > > > > > > > > I think that a protocol that is developed in NETEXT (or other group= s) > > > > should have at least a potential realistic scenario for applicabili= ty. > > > > > > > > In terms of applicability, though it is not part of the protocol > > definition > > > > per se, unless there are solutions in place for either the host to > > indicate > > > > to the network where the flows should be routed or for the LMA to > > receive > > > > somehow from somewhere some policies, the solution cannot really > > provide > > > > flow mobility since there is no way to decide which flows are route= d > > where. > > > > If we are thinking about a host-based solution, I have not yet seen= a > > > > solution as to how the host can indicate to the MAG and ultimately = to > > the > > > > MAG which flows should be routed on each access. If we are relying = on > > > > modifications of layer 2 protocols, aren't we defining a solution t= hat > > works > > > > only with some technologies (since for other access technologies it= is > > > > rather unrealistic to modify L2 for IP flow mobility purposes)? If = we > > are > > > > thinking of an LMA-based solution, can we hear of at least one exam= ple > > of a > > > > real-life scenario where the LMA would receive such policies, and h= ow > > such > > > > delivery would happen? Also, should there be a solution to have > > policies in > > > > the LMA, how does the LMA actually decide to route flows on one acc= ess > > or > > > > the other? E.g., if some flows need to be routed on certain WLAN > > networks, > > > > but shall not be routed on other WLAN networks, how does the LMA kn= ow > > which > > > > specific WLAN network the host is connected to? Perhaps I missed th= e > > ability > > > > for the MAG to know e.g. the WLAN SSID and provide it to the LMA, i= n > > which > > > > case I would appreciate if somebody could highlight to me where tha= t is > > > > defined. > > > > > > > > I think that, though not integral to the protocol specification, > > > > understanding what framework the protocol would/needs to fit in is > > rather > > > > important. > > > > > > > > Cheers, > > > > Stefano > > > > > > > > > > > > On Tue, Feb 1, 2011 at 3:47 PM, > > > http://Basavaraj.Patil@nokia.com> > > > > > > > wrote: > > > > > > > > Hello, > > > > > > > > We have discussed the flow mobility solutions for Proxy MIP6 previo= usly > > at > > > > IETFs 78 and 79. > > > > This is a consensus call for adopting this I-D: > > > > draft-bernardos-netext-pmipv6-flowmob-02 > > > > as the working group document. > > > > I-D: > > http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt > > > > > > > > The consensus call will expire on Feb 15th, 2011. Please indicate y= our > > > > support or concerns in adopting this I-D as the WG baseline documen= t on > > > > the mailing list. > > > > > > > > Please note that this I-D will serve as the baseline in the WG and = will > > be > > > > developed further based on input and feedback from WG members. > > > > > > > > -Basavaraj > > > > > > > > _______________________________________________ > > > > netext mailing list > > > > netext@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netext > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Stefano M. Faccin > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > May the Force be with you > > > > > > > > > > > > > > > > > > > > -- > > > > Stefano M. Faccin > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > May the Force be with you > > > > > > > > > > > > > > > > > > > > -- > > > > Stefano M. Faccin > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > May the Force be with you > > > > > > > > > > > > > > > > _______________________________________________ > > > netext mailing list > > > netext@ietf.org > > > https://www.ietf.org/mailman/listinfo/netext > > > > -- > > Carlos Jes=C3=BAs Bernardos Cano http://www.netcoms.net > > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > > >=20 >=20 >=20 --=20 Carlos Jes=C3=BAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-WbMgvTQOS7gHsPo8sdUb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1J6CcACgkQNdy6TdFwT2fNPACgziEI8Xl7x0q56Y/R4ixsz1Dc /pUAnR+tSdFS/KZ9iwaII9A06LoJw2aY =2hYo -----END PGP SIGNATURE----- --=-WbMgvTQOS7gHsPo8sdUb-- From julien.ietf@gmail.com Wed Feb 2 15:41:47 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E18083A6D70 for ; Wed, 2 Feb 2011 15:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GXxiUSYdMoD for ; Wed, 2 Feb 2011 15:41:46 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 08F2A3A6BC2 for ; Wed, 2 Feb 2011 15:41:45 -0800 (PST) Received: by fxm9 with SMTP id 9so593821fxm.31 for ; Wed, 02 Feb 2011 15:45:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PXZmUlinhu7O4Yay9CJNwxiIy6uYgKv3Bdo5lGxnb4I=; b=Zy1hvcnbqdxP1IpTJWDJ4gJvbTUOpI+Iwik9d8XlMShy67Tgzdx/NrCUgOgrPn8+2t d0Bkkihfat++m5iMddv6vvmLsZymUcBuuWLDmtHScVlRRvKtBcSdg9+KMYDNyz1huQj2 6n4mTVftiTaurjFHaLvkWgnd1/SnQNerg4dXE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=id8aNzrDDUI8rtNI9lRgwxq3Xyzm8PR3qLfQ8RSQzZfo86DJPUq/9mHtfnfVmyFSv8 BpNQIoTq1KanssITOkv0icAjZcOA7xsHjMxkYDmUtAnN3iz5wrIz0PUXllyy8aWTCWd8 Bpi+dMHUjLgRdXMtAx3JhNL8oUxD03suYIlPI= MIME-Version: 1.0 Received: by 10.103.199.18 with SMTP id b18mr5212935muq.21.1296690304991; Wed, 02 Feb 2011 15:45:04 -0800 (PST) Received: by 10.103.221.9 with HTTP; Wed, 2 Feb 2011 15:45:04 -0800 (PST) In-Reply-To: <1296689037.3593.20.camel@acorde.it.uc3m.es> References: <1296689037.3593.20.camel@acorde.it.uc3m.es> Date: Wed, 2 Feb 2011 15:45:04 -0800 Message-ID: From: Julien Laganier To: cjbc@it.uc3m.es Content-Type: multipart/alternative; boundary=0016364c440b03408b049b553dec Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 23:41:48 -0000 --0016364c440b03408b049b553dec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Carlos, Thank you for your answer.The two issues I've raised earlier were: 1. there is no need to support multiple addressing models. All scenarios ca= n be supported by a single addressing model in which each PMIPv6 session maps to a set of prefixes that are equally accessible through the set of physica= l interfaces attached to that PMIPv6 session. This allows all scenarios, including one in which two prefix sets are available through different physical interfaces set. I understand that the WG has been divided on that question but that does not constitute a mandate to include everyone's wish list in a standard specification. Thus unless someone can come up with a rebuttal of my argument on why single addressing model (prefix-set per interface-set) satisfies all scenarios, e.g., by pointing out a scenario in which it does not, that should be the only addressing model supported in that spec. 2. there is no need to convey traffic selectors between the MAG and the LMA= . The LMA forwards downlink packets as per the network-based policy, and the uplink packets to the Internet. The MAG forwards downlink packets to the MN= , and uplink packets to the LMA. End of the story. As above, unless someone comes up with a rebuttal of why that is not sufficient to address the scenario we're concerned with (network-based flow mobility), the traffic selectors shall be removed from the specification. Best, --julien 2011/2/2 Carlos Jes=FAs Bernardos Cano > Hi Julien, > > Can you please summarize the issues you raised? As far as I recall, your > main concern was about the scenario in which the prefix(es) is not > shared between all the physical interfaces of the MN, correct me if I'm > wrong. In regards to this, as I think we answered, there are a number of > scenarios that people expressed interest about that requires to support > it. Current draft support this and the shared-prefix scenario. If the WG > reaches a consensus in removing the non-shared prefix scenario, we are > happy to do it, but my understanding was that not all the WG had that > opinion (at that time, at least). > > Thanks, > > Carlos > > On Wed, 2011-02-02 at 15:06 -0800, Julien Laganier wrote: > > Raj, > > > > As with the other draft (logical interface), I have raised a number of > > issues with this draft that in my humble opinion have not been addresse= d > > adequately, and thus at this stage I believe that asking for adoption i= s > > premature. In other words, I'd like the issues that I've raised to be > > addressed by the authors before I feel comfortable having an opinion on > > whether or not this draft is a good basis to progress the flow mobility > > extensions. > > > > Thank you for your consideration, > > > > --julien > > > > On Tue, Feb 1, 2011 at 3:47 PM, wrote: > > > > > > > > Hello, > > > > > > We have discussed the flow mobility solutions for Proxy MIP6 previous= ly > at > > > IETFs 78 and 79. > > > This is a consensus call for adopting this I-D: > > > draft-bernardos-netext-pmipv6-flowmob-02 > > > as the working group document. > > > I-D: > http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt > > > > > > The consensus call will expire on Feb 15th, 2011. Please indicate you= r > > > support or concerns in adopting this I-D as the WG baseline document = on > > > the mailing list. > > > > > > Please note that this I-D will serve as the baseline in the WG and wi= ll > be > > > developed further based on input and feedback from WG members. > > > > > > -Basavaraj > > > > > > _______________________________________________ > > > 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 > > -- > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > --0016364c440b03408b049b553dec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Carlos,

Thank you for your answer.The two issues I= 9;ve raised earlier were:

1. there is no need to s= upport multiple addressing models. All scenarios can be supported by a sing= le addressing model in which each PMIPv6 session maps to a set of prefixes = that are equally accessible through the set of physical interfaces attached= to that PMIPv6 session. This allows all scenarios, including one in which = two prefix sets are available through different physical interfaces set. I = understand that the WG has been divided on that question but that does not = constitute a mandate to include everyone's wish list =A0in a standard s= pecification. Thus unless someone can come up with a=A0rebuttal=A0of my arg= ument on why single addressing model (prefix-set per interface-set) satisfi= es all scenarios, e.g., by pointing out a scenario in which it does not, th= at should be the only addressing model supported in that spec.

2. there is no need to convey traffic selectors between= the MAG and the LMA. The LMA forwards downlink packets as per the network-= based policy, and the uplink packets to the Internet. The MAG forwards down= link packets to the MN, and uplink packets to the LMA. End of the story. As= above, unless someone comes up with a rebuttal of why that is not=A0suffic= ient=A0to address the scenario we're concerned with (network-based flow= mobility), the traffic selectors shall be removed from the specification.<= /div>

Best,

--julien=A0

2011/2/2 Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es>
Hi Julien,

Can you please summarize the issues you raised? As far as I recall, your main concern was about the scenario in which the prefix(es) is not
shared between all the physical interfaces of the MN, correct me if I'm=
wrong. In regards to this, as I think we answered, there are a number of scenarios that people expressed interest about that requires to support
it. Current draft support this and the shared-prefix scenario. If the WG reaches a consensus in removing the non-shared prefix scenario, we are
happy to do it, but my understanding was that not all the WG had that
opinion (at that time, at least).

Thanks,

Carlos

On Wed, 2011-02-02 at 15:06 -0800, Julien Laganier wrote:
> Raj,
>
> As with the other draft (logical interface), I have raised a number of=
> issues with this draft that in my humble opinion have not been address= ed
> adequately, and thus at this stage I believe that asking for adoption = is
> premature. In other words, I'd like the issues that I've raise= d to be
> addressed by the authors before I feel comfortable having an opinion o= n
> whether or not this draft is a good basis to progress the flow mobilit= y
> extensions.
>
> Thank you for your consideration,
>
> --julien
>
> On Tue, Feb 1, 2011 at 3:47 PM, <Basavaraj.Patil@nokia.com> wrote:
>
> >
> > Hello,
> >
> > We have discussed the flow mobility solutions for Proxy MIP6 prev= iously at
> > IETFs 78 and 79.
> > This is a consensus call for adopting this I-D:
> > draft-bernardos-netext-pmipv6-flowmob-02
> > as the working group document.
> > I-D: http://www.ietf.org/id/draft-bernardo= s-netext-pmipv6-flowmob-02.txt
> >
> > The consensus call will expire on Feb 15th, 2011. Please indicate= your
> > support or concerns in adopting this I-D as the WG baseline docum= ent on
> > the mailing list.
> >
> > Please note that this I-D will serve as the baseline in the WG an= d will be
> > developed further based on input and feedback from WG members. > >
> > -Basavaraj
> >
> > _______________________________________________
> > 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

--

--0016364c440b03408b049b553dec-- From julien.ietf@gmail.com Wed Feb 2 15:49:54 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F6C23A6C41 for ; Wed, 2 Feb 2011 15:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJvSecZzBj9i for ; Wed, 2 Feb 2011 15:49:46 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 36F7D3A6C66 for ; Wed, 2 Feb 2011 15:49:45 -0800 (PST) Received: by fxm9 with SMTP id 9so602064fxm.31 for ; Wed, 02 Feb 2011 15:53:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yOgglCwYEqSoc7xItKBgOKHQQYtrC+FR96U2DK5i6/g=; b=UgrsEMmSfoRSiy61p5sSzlTWKorVqoGZ1SZS+i4B141O9lWFrA0Lc3XVtRB/O3Fkdi wJY+W08VykvjlP1H0LoDyMS5mq/zdsVn4sgs2AGZ1qbMNjtPlfcLpqXu3Q6TQVPwdj0c Es504LBp0QxOx8DtH2aUkhGe4w8YqcYNIoMjk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WqX+VrwTRdEeGAqafIrLFnVKsaYHu5bg2EMIXHJ2z1SoWfFGaNe2OeC5XHmiQYKr83 HzBRGum0LQiSzVx+MYUqtS+QIVOkOhBUJu7xlmjsltHPg5ZKZ89ifx/n1Dk3CsnATdj+ CV7iZEp/QLUzIzLCMymDbntgsEGSm/N9kmnzM= MIME-Version: 1.0 Received: by 10.103.233.4 with SMTP id k4mr5263083mur.129.1296690785413; Wed, 02 Feb 2011 15:53:05 -0800 (PST) Received: by 10.103.221.9 with HTTP; Wed, 2 Feb 2011 15:53:05 -0800 (PST) In-Reply-To: References: Date: Wed, 2 Feb 2011 15:53:05 -0800 Message-ID: From: Julien Laganier To: Rajeev Koodli Content-Type: multipart/alternative; boundary=001636b4310fa5ec37049b5559dd Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 23:49:54 -0000 --001636b4310fa5ec37049b5559dd Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Rajeev, I understand that the MN takes a decision as per the policy and the context= . It seems to me that consistency of policy rules between the MN and LMA does not ensure that the LMA knows what decision the MN took because the LMA doe= s not necessarily knows the context in which the MN is. If so, isn't there a potential disconnect between routing decision at the LMA and the MN? Best, --julien On Wed, Feb 2, 2011 at 11:28 AM, Rajeev Koodli wrote: > > Stefano, > > Regardless of how the policy is configured on the LMA, there is a > consistency of the rules which needs to be ensured regardless. Whatever t= he > entity (OMA-DM?!) is that configures the policy has to ensure such a > consistency. > > We can debate about how policy interaction works, but that=92s another to= pic. > I would note that there are choices here (modulo respective pros and cons= ). > > I didn=92t suggest that an operator should just trust the software on a M= N, > although I suspect some device vendors might argue for their robustness > (surprise?). > > I would frame the WLAN access problem as whether the access is considered > trusted or not. Accordingly, you apply the policy. > > -Rajeev > > > > On 2/2/11 10:50 AM, "stefano faccin" wrote: > > Raj, > thanks for the reply. > > If the LMA has statically configured policies, how do we ensure that the = MN > has the same policies? That would mean implicitly assuming that the polic= ies > provisioned to the MN by the ANDSF "always" match what has been set in th= e > LMA, which I think it is unrealistic because the policies change over tim= e, > and every time you need to update all the LMAs, which has a considerable > operational cost. Instead, if we leave the MN to make the choice, there a= re > easy and well specified mechanisms that allow the provisioning of policie= s > in the MN and for the MN to make such decision and communicate it to the > network, so that the network can > > As for extensions to Gx, I am not stating that in theory one could extend > Gx. However, at present such solution does not exists, and without it, I = do > not see how the draft is applicable to 3GPP that is at present the only > potential customer identified (I guess I did not see any other identified= ?) > > > Even assuming that Gx could be modified, the issue of the per-access > network granularity remains. Even if the LMA has the right policies in > place, the LMA has no way of knowing exactly what access network of a > specific access technology (e.g. which SSID for WLAN0 the MN is connectin= g > to. > > I cannot agree with your assumption below that if the MN connects to an > SSID it is because the operator is OK with routing traffic on that SSID, = and > that we should just "trust the software on the MN". There are two aspects= to > consider: > 1) whether it is OK for certain traffic to be routed at all over a certai= n > access access network of a specific access technology > 2) how different traffic should be routed over different access networks = of > different access technologies > > Regarding these two points, the issue is whether the operator wants to > allow traffic e.g. over a certain SSID or not. So, in that case, it is > obvious as you say that if the MN has connected to an SSID configured by = the > operator in the MN, then traffic could be allowed over that SSID. However= , > we need to consider that 3GPP allows the decision of which WLAN the MN ca= n > connect to based on user preferences. This means that my MN can e.g. conn= ect > to my home WLAN (which is not controlled necessarily by the operator and > whose SSID the operator does not know) or to a coffee shop WLAN, even if = the > device does not have those SSID configured. Those are typical examples of > untrusted WLAN access networks. Therefore, in such cases, just because th= e > MN has connected to a WLAN SSID, does not mean that the operator wants to > route certain traffic over that SSID just because the policy says "route > traffic X over WLAN". > > That brings us to a solution that, if applied to 3GPP, provides less > functionality than what is available and has been specified today, so bac= k > to my point above. > > Unfortunately, there is no solution I am aware of that allows the WLAN > network to indicate to the MAG/LMA the specific SSID (and as you say, the= re > is no easy solution for that). Due to this and the points above about pol= icy > provisioning, it means that the applicability of this solution to a real > case like 3GPP depends on the feasibility of extending policy mechanisms = in > 3GPP, and the ability to have a solution where the WLAN network provides = the > SSID information to the MAG/LMA. Moreover, the provisioning of such SSID = is > not in the scope of IETF, but not even of 3GPP (since the interface betwe= en > the WLAN AP and the ePDG is not defined), thus I wonder how this could be > defined at all (I am afraid of asking what magic should happen here). So, > now we have two big dependencies. > > In general, I am also wondering if there is a customer that has asked us = to > define this solution. I am not aware of any but I may have missed that. > > Cheers, > Stefano > > On Wed, Feb 2, 2011 at 10:44 AM, Rajeev Koodli wrote: > > > Hi Stefano, > > You make two interesting points: First, the defined solution should be > useful for 3GPP deployments. Second, if it=92s not defined *today* in 3GP= P, > it=92s not useful. > > I tend to agree with you on the first =96 3GPP is a big potential custome= r. > I cannot agree with your second point. > > There are multiple ways I could envision policy on the LMA. Locally > configured policy is one (which we use today in deployments) that does no= t > need Gx interaction. Gx extensions can be proposed in the future. I hope = you > are not suggesting that these are not feasible choices. > > For the MN (IETF term for UE) to even connect to the MAG via WLAN today, > you need an IPsec termination point (ePDG). If the operator pre-configure= s > the list of SSIDs or there is some out-of-band mechanism to inform the MN > which SSID is =93white-listed=94, then I expect the MN to decide when to = connect > to the ePDG and hence the MAG. At this point, the MN is already on the WL= AN > the operator cares about I presume. > There is no easy way for the network (LMA, MAG) to know what SSID the MN = is > connected to =96 the network has to either trust the software on the MN o= r the > WLAN infrastructure has to provide the SSID information to the network. > > -Rajeev > > > > On 2/2/11 9:56 AM, "stefano faccin" http://sfaccinstd@gmail.com> > wrote: > > Hello rajeev, > the use of PCRF is an interesting suggestion. However, unfortunately, PCR= F > does not contain any policies or information that will tell the LMA what = are > the policies to be used for decisions of IP flow mobility. This is not pa= rt > of current PCC functionality, and there is no work ongoing or planned to > extend PCC in such way. Therefore, the applicability of the solution in t= his > draft would hinge on hypotetical future solutions and not on a current > solution for the open issues, which brings us back to my point that we ar= e > defining a solution with open issues for which there is not a single > realistic solution out there, thus making this draft not applicable to a > real scenario. > > I am not thinking of the UE connecting to more than one WLAN at the same > time, but the UE being able to connect to different WLANs (one at a time) > because the UE is e.g. provisioned with a list of SSIDs or the UE discove= rs > a hotspot somewhere. I am talking about the scenario where the UE is capa= ble > to connect to WLAN, but the operator has different policies wrt which WLA= N > the UE should use or not. > > If you have followed the work in 3GPP, it is clear that operators have > interest in applying policies not only at RAT level, but also at access > network level (please see how ANDSF was defined and why). I guess we can = all > agree that an operator deploying PMIP-based mobility may be interested in > having policies that allow traffic on the WLAN the operator owns or that > belongs to a roaming partner, while not allowing traffic on WLAN of other > operators for which it might need to pay an extra fee or where e.g. no Qo= S > can be guaranteed. That means that the entity deciding whether traffic ne= eds > to be routed on WLAN or not cannot just consider "WLAN is available", but > "WLAN SSIDx is available", so that the decision can be based on the opera= tor > preferences as to which WLAN certain traffic needs to be routed on. > > If the draft allows decisions to be made only at the RAT level, then we > have an issue because we are defining a solution that should be applicabl= e > to 3GPP but does not meet the deployment scenarios of interest. In other > words, if we want to make this solution applicable e.g. to 3GPP, we need = to > be able to provide the same functionality available today in 3GPP with ot= her > solution in order to satisfy the use cases supported by 3GPP, and not ste= p > backwards in terms of what can be supported. > > Cheers, > > Stefano > > On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli http://rkoodli@cisco.com> > wrote: > > > Hi Stefano, > > Thanks for your input. > > I expect the LMA interacting with PCRF for policy rules specific to the > subscriber for different RAT types. > You are right that the LMA does not know the SSID the mobile is connected > to. It=92s not clear if the MAG can get that from the MN either without > additional signaling. However, the LMA knows that the MN is connected to > WLAN; so it can apply the policy at the RAT type level. Are you thinking = of > the MN connecting to more than one WLAN network (and each of those > connections coming back to the LMA)? If so, please explain the scenario. > > Regards, > > -Rajeev > > > > > On 2/1/11 6:39 PM, "stefano faccin" http://sfaccinstd@gmail.com> > wrote: > > Raj, > thanks for the email. > > I need to apologize in advance if my questions have already been answered > before (though I cannot find a conclusive answer anywhere). > > I think that a protocol that is developed in NETEXT (or other groups) > should have at least a potential realistic scenario for applicability. > > In terms of applicability, though it is not part of the protocol definiti= on > per se, unless there are solutions in place for either the host to indica= te > to the network where the flows should be routed or for the LMA to receive > somehow from somewhere some policies, the solution cannot really provide > flow mobility since there is no way to decide which flows are routed wher= e. > If we are thinking about a host-based solution, I have not yet seen a > solution as to how the host can indicate to the MAG and ultimately to the > MAG which flows should be routed on each access. If we are relying on > modifications of layer 2 protocols, aren't we defining a solution that wo= rks > only with some technologies (since for other access technologies it is > rather unrealistic to modify L2 for IP flow mobility purposes)? If we are > thinking of an LMA-based solution, can we hear of at least one example of= a > real-life scenario where the LMA would receive such policies, and how suc= h > delivery would happen? Also, should there be a solution to have policies = in > the LMA, how does the LMA actually decide to route flows on one access or > the other? E.g., if some flows need to be routed on certain WLAN networks= , > but shall not be routed on other WLAN networks, how does the LMA know whi= ch > specific WLAN network the host is connected to? Perhaps I missed the abil= ity > for the MAG to know e.g. the WLAN SSID and provide it to the LMA, in whic= h > case I would appreciate if somebody could highlight to me where that is > defined. > > I think that, though not integral to the protocol specification, > understanding what framework the protocol would/needs to fit in is rather > important. > > Cheers, > Stefano > > > On Tue, Feb 1, 2011 at 3:47 PM, http://Basavaraj.Patil@nokia.com> > > wrote: > > > Hello, > > We have discussed the flow mobility solutions for Proxy MIP6 previously a= t > IETFs 78 and 79. > This is a consensus call for adopting this I-D: > draft-bernardos-netext-pmipv6-flowmob-02 > as the working group document. > I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt > > The consensus call will expire on Feb 15th, 2011. Please indicate your > support or concerns in adopting this I-D as the WG baseline document on > the mailing list. > > Please note that this I-D will serve as the baseline in the WG and will b= e > developed further based on input and feedback from WG members. > > -Basavaraj > > _______________________________________________ > 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 > > --001636b4310fa5ec37049b5559dd Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Rajeev,

I understand that the MN takes a decision as = per the policy and the context. It seems to me that consistency of policy r= ules between the MN and LMA does not ensure=A0that the LMA knows what decis= ion the MN took because the LMA does not necessarily knows the context in w= hich the MN is. If so, isn't there a potential disconnect between routi= ng decision at the LMA and the MN?

Best,

--julien

<= div class=3D"gmail_quote">On Wed, Feb 2, 2011 at 11:28 AM, Rajeev Koodli <rkoodli@cisco.com<= /a>> wrote:

Stefano,

Regardless of how the policy is configured on the LMA, there is a consisten= cy of the rules which needs to be ensured regardless. Whatever the entity (= OMA-DM?!) is that configures the policy has to ensure such a consistency.
We can debate about how policy interaction works, but that=92s another topi= c. I would note that there are choices here (modulo respective pros and con= s).

I didn=92t suggest that an operator should just trust the software on a MN,= although I suspect some device vendors might argue for their robustness (s= urprise?).

I would frame the WLAN access problem as whether the access is considered t= rusted or not. Accordingly, you apply the policy.

-Rajeev



On 2/2/11 10:50 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:

Raj,
thanks for the reply.

If the LMA has statically configured policies, how do we ensure that the MN= has the same policies? That would mean implicitly assuming that the polici= es provisioned to the MN by the ANDSF "always" match what has bee= n set in the LMA, which I think it is unrealistic because the policies chan= ge over time, and every time you need to update all the LMAs, which has a c= onsiderable operational cost. Instead, if we leave the MN to make the choic= e, there are easy and well specified mechanisms that allow the provisioning= of policies in the MN and for the MN to make such decision and communicate= it to the network, so that the network can

As for extensions to Gx, I am not stating that in theory one could extend G= x. However, at present such solution does not exists, and without it, I do = not see how the draft is applicable to 3GPP that is at present the only pot= ential customer identified (I guess I did not see any other identified?)=A0=

Even assuming that Gx could be modified, the issue of the per-access networ= k granularity remains. Even if the LMA has the right policies in place, the= LMA has no way of knowing exactly what access network of a specific access= technology (e.g. which SSID for WLAN0 the MN is connecting to.

I cannot agree with your assumption below that if the MN connects to an SSI= D it is because the operator is OK with routing traffic on that SSID, and t= hat we should just "trust the software on the MN". There are two = aspects to consider:
1) whether it is OK for certain traffic to be routed at all over a certain = access access network of a specific access technology
2) how different traffic should be routed over different access networks of= different access technologies

Regarding these two points, the issue is whether the operator wants to allo= w traffic e.g. over a certain SSID or not. So, in that case, it is obvious = as you say that if the MN has connected to an SSID configured by the operat= or in the MN, then traffic could be allowed over that SSID. However, we nee= d to consider that 3GPP allows the decision of which WLAN the MN can connec= t to based on user preferences. This means that my MN can e.g. connect to m= y home WLAN (which is not controlled necessarily by the operator and whose = SSID the operator does not know) or to a coffee shop WLAN, even if the devi= ce does not have those SSID configured. Those are typical examples of untru= sted WLAN access networks. Therefore, in such cases, just because the MN ha= s connected to a WLAN SSID, does not mean that the operator wants to route = certain traffic over that SSID just because the policy says "route tra= ffic X over WLAN".=A0

That brings us to a solution that, if applied to 3GPP, provides less functi= onality than what is available and has been specified today, so back to my = point above.

Unfortunately, there is no solution I am aware of that allows the WLAN netw= ork to indicate to the MAG/LMA the specific SSID (and as you say, there is = no easy solution for that). Due to this and the points above about policy p= rovisioning, it means that the applicability of this solution to a real cas= e like 3GPP depends on the feasibility of extending policy mechanisms in 3G= PP, and the ability to have a solution where the WLAN network provides the = SSID information to the MAG/LMA. Moreover, the provisioning of such SSID is= not in the scope of IETF, but not even of 3GPP (since the interface betwee= n the WLAN AP and the ePDG is not defined), thus I wonder how this could be= defined at all (I am afraid of asking what magic should happen here). So, = now we have two big dependencies.

In general, I am also wondering if there is a customer that has asked us to= define this solution. I am not aware of any but I may have missed that.
Cheers,
Stefano

On Wed, Feb 2, 2011 at 10:44 AM, Rajeev Koodli <rkoodli@cisco.com> wrote:

Hi Stefano,

You make two interesting points: First, the defined solution should be usef= ul for 3GPP deployments. Second, if it=92s not defined today in 3GPP= , it=92s not useful.

I tend to agree with you on the first =96 3GPP is a big potential customer.=
I cannot agree with your second point.

There are multiple ways I could envision policy on the LMA. Locally configu= red policy is one (which we use today in deployments) that does not need Gx= interaction. Gx extensions can be proposed in the future. I hope you are n= ot suggesting that these are not feasible choices.

For the MN (IETF term for UE) to even connect to the MAG via WLAN today, yo= u need an IPsec termination point (ePDG). If the operator pre-configures th= e list of SSIDs or there is some out-of-band mechanism to inform the MN whi= ch SSID is =93white-listed=94, then I expect the MN to decide when to conne= ct to the ePDG and hence the MAG. At this point, the MN is already on the W= LAN the operator cares about I presume.
There is no easy way for the network (LMA, MAG) to know what SSID the MN is= connected to =96 the network has to either trust the software on the MN or= the WLAN infrastructure has to provide the SSID information to the network= .

-Rajeev



On 2/2/11 9:56 AM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com> > wrote:

Hello rajeev,
the use of PCRF is an interesting suggestion. However, unfortunately, PCRF = does not contain any policies or information that will tell the LMA what ar= e the policies to be used for decisions of IP flow mobility. This is not pa= rt of current PCC functionality, and there is no work ongoing or planned to= extend PCC in such way. Therefore, the applicability of the solution in th= is draft would hinge on hypotetical future solutions and not on a current s= olution for the open issues, which brings us back to my point that we are d= efining a solution with open issues for which there is not a single realist= ic solution out there, thus making this draft not applicable to a real scen= ario.

I am not thinking of the UE connecting to more than one WLAN at the same ti= me, but the UE being able to connect to different WLANs (one at a time) bec= ause the UE is e.g. provisioned with a list of SSIDs or the UE discovers a = hotspot somewhere. I am talking about the scenario where the UE is capable = to connect to WLAN, but the operator has different policies wrt which WLAN = the UE should use or not.

If you have followed the work in 3GPP, it is clear that operators have inte= rest in applying policies not only at RAT level, but also at access network= level (please see how ANDSF was defined and why). I guess we can all agree= that an operator deploying PMIP-based mobility may be interested in having= policies that allow traffic on the WLAN the operator owns or that belongs = to a roaming partner, while not allowing traffic on WLAN of other operators= for which it might need to pay an extra fee or where e.g. no QoS can be gu= aranteed. That means that the entity deciding whether traffic needs to be r= outed on WLAN or not cannot just consider "WLAN is available", bu= t "WLAN SSIDx is available", so that the decision can be based on= the operator preferences as to which WLAN certain traffic needs to be rout= ed on.

If the draft allows decisions to be made only at the RAT level, then we hav= e an issue because we are defining a solution that should be applicable to = 3GPP but does not meet the deployment scenarios of interest. In other words= , if we want to make this solution applicable e.g. to 3GPP, we need to be a= ble to provide the same functionality available today in 3GPP with other so= lution in order to satisfy the use cases supported by 3GPP, and not step ba= ckwards in terms of what can be supported.

Cheers,

Stefano

On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli <rkoodli@cisco.com <http://rkoodli@cisco.com> > w= rote:

Hi Stefano,

Thanks for your input.

I expect the LMA interacting with PCRF for policy rules specific to the sub= scriber for different RAT types.
You are right that the LMA does not know the SSID the mobile is connected t= o. It=92s not clear if the MAG can get that from the MN either without addi= tional signaling. However, the LMA knows that the MN is connected to WLAN; = so it can apply the policy at the RAT type level. Are you thinking of the M= N connecting to more than one WLAN network (and each of those connections c= oming back to the LMA)? If so, please explain the scenario.

Regards,

-Rajeev




On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com> =A0<http= ://sfaccinstd@gmail.com> > wrote:

Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicat= e to the network where the flows should be routed or for the LMA to receive= somehow from somewhere some policies, the solution cannot really provide f= low mobility since there is no way to decide which flows are routed where. = If we are thinking about a host-based solution, I have not yet seen a solut= ion as to how the host can indicate to the MAG and ultimately to the MAG wh= ich flows should be routed on each access. If we are relying on modificatio= ns of layer 2 protocols, aren't we defining a solution that works only = with some technologies (since for other access technologies it is rather un= realistic to modify L2 for IP flow mobility purposes)? If we are thinking o= f an LMA-based solution, can we hear of at least one example of a real-life= scenario where the LMA would receive such policies, and how such delivery = would happen? Also, should there be a solution to have policies in the LMA,= how does the LMA actually decide to route flows on one access or the other= ? E.g., if some flows need to be routed on certain WLAN networks, but shall= not be routed on other WLAN networks, how does the LMA know which specific= WLAN network the host is connected to? Perhaps I missed the ability for th= e MAG to know e.g. the WLAN SSID and provide it to the LMA, in which case I= would appreciate if somebody could highlight to me where that is defined.<= br>
I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important. =

Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM, =A0<Basavaraj.Patil@nokia.com <http://Basavaraj.Patil@nok= ia.com> =A0<http://Basavaraj.Patil@nokia.com> > wrote:

Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= br> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-p= mipv6-flowmob-02.txt

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= br> developed further based on input and feedback from WG members.

-Basavaraj

_______________________________________________
netext mailing list
netext@ietf.org<= /a> <http://netext@= ietf.org> =A0<http://netext@ietf.org>
= https://www.ietf.org/mailman/listinfo/netext







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


--001636b4310fa5ec37049b5559dd-- From sgundave@cisco.com Wed Feb 2 16:10:12 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 396A23A63CA for ; Wed, 2 Feb 2011 16:10:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.7 X-Spam-Level: X-Spam-Status: No, score=-9.7 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOD0fTS1h4dJ for ; Wed, 2 Feb 2011 16:10:03 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 01EB93A63C9 for ; Wed, 2 Feb 2011 16:10:02 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgCAKmBSU2rRN+K/2dsb2JhbACCRZQBjmJzoEmbJIVTBIR4iho Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 03 Feb 2011 00:13:23 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p130DNW4021981; Thu, 3 Feb 2011 00:13:23 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Feb 2011 16:13:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBC337.2B9A0309" Date: Wed, 2 Feb 2011 16:13:20 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvDM0AHyD43qnn3QvSC6GDbt86rIwAAh/7Q References: <1296689037.3593.20.camel@acorde.it.uc3m.es> From: "Sri Gundavelli (sgundave)" To: "Julien Laganier" , X-OriginalArrivalTime: 03 Feb 2011 00:13:23.0621 (UTC) FILETIME=[2BD55550:01CBC337] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 03 Feb 2011 00:10:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC337.2B9A0309 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Julien, =20 Inline .. =20 =20 From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of Julien Laganier Sent: Wednesday, February 02, 2011 3:45 PM To: cjbc@it.uc3m.es Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: = draft-bernardos-netext-pmipv6-flowmob as WG doc =20 Hi Carlos, =20 Thank you for your answer.The two issues I've raised earlier were: =20 1. there is no need to support multiple addressing models. All scenarios = can be supported by a single addressing model in which each PMIPv6 = session maps to a set of prefixes that are equally accessible through = the set of physical interfaces attached to that PMIPv6 session. This = allows all scenarios, including one in which two prefix sets are = available through different physical interfaces set. I understand that = the WG has been divided on that question but that does not constitute a = mandate to include everyone's wish list in a standard specification. = Thus unless someone can come up with a rebuttal of my argument on why = single addressing model (prefix-set per interface-set) satisfies all = scenarios, e.g., by pointing out a scenario in which it does not, that = should be the only addressing model supported in that spec. =20 [Sri] I guess, this goes back to our last discussion in this list. We = allow the hosting of multiple prefixes on an IPv6 link and the base = RFC-5213 allows the same. You agreed and your comments on to take the = approach of session management, as supposed to addressing models. Now, = we allow the ability to move a full/partial set of prefixes to a = different interface, and optionally allow the sharing of prefixes across = links. This is one issue to discuss the shared link approach and see how = to capture the final text. The text can be updated once we decide the = scenarios that we support. This also probably ties to the policy = interface to MN. Lets take this as an open issue. =20 =20 2. there is no need to convey traffic selectors between the MAG and the = LMA. The LMA forwards downlink packets as per the network-based policy, = and the uplink packets to the Internet. The MAG forwards downlink = packets to the MN, and uplink packets to the LMA. End of the story. As = above, unless someone comes up with a rebuttal of why that is not = sufficient to address the scenario we're concerned with (network-based = flow mobility), the traffic selectors shall be removed from the = specification. =20 =20 [Sri] I tend to agree. The MAG does not have ability to convey flow = level info over ND interface. At the end of the day, the MAG is hosting = a set of prefixes on a link and that's all. So, the traffic selectors = are not needed from the mobility perspective, but if we look at this as = exchange of policy, we can allow them optionally. But, I'm fine to get = rid of this entirely, but allowing this exchange is not undesirable = either. =20 Regards Sri =20 =20 Best, =20 --julien=20 2011/2/2 Carlos Jes=FAs Bernardos Cano Hi Julien, Can you please summarize the issues you raised? As far as I recall, your main concern was about the scenario in which the prefix(es) is not shared between all the physical interfaces of the MN, correct me if I'm wrong. In regards to this, as I think we answered, there are a number of scenarios that people expressed interest about that requires to support it. Current draft support this and the shared-prefix scenario. If the WG reaches a consensus in removing the non-shared prefix scenario, we are happy to do it, but my understanding was that not all the WG had that opinion (at that time, at least). Thanks, Carlos On Wed, 2011-02-02 at 15:06 -0800, Julien Laganier wrote: > Raj, > > As with the other draft (logical interface), I have raised a number of > issues with this draft that in my humble opinion have not been = addressed > adequately, and thus at this stage I believe that asking for adoption = is > premature. In other words, I'd like the issues that I've raised to be > addressed by the authors before I feel comfortable having an opinion = on > whether or not this draft is a good basis to progress the flow = mobility > extensions. > > Thank you for your consideration, > > --julien > > On Tue, Feb 1, 2011 at 3:47 PM, wrote: > > > > > Hello, > > > > We have discussed the flow mobility solutions for Proxy MIP6 = previously at > > IETFs 78 and 79. > > This is a consensus call for adopting this I-D: > > draft-bernardos-netext-pmipv6-flowmob-02 > > as the working group document. > > I-D: = http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt > > > > The consensus call will expire on Feb 15th, 2011. Please indicate = your > > support or concerns in adopting this I-D as the WG baseline document = on > > the mailing list. > > > > Please note that this I-D will serve as the baseline in the WG and = will be > > developed further based on input and feedback from WG members. > > > > -Basavaraj > > > > _______________________________________________ > > 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 -- Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 =20 ------_=_NextPart_001_01CBC337.2B9A0309 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Julien,

 

Inline ..

 

 

From:= netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of = Julien Laganier
Sent: Wednesday, February 02, 2011 3:45 PM
To: cjbc@it.uc3m.es
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

 

Hi Carlos,

 

Thank you for your answer.The two issues I've = raised earlier were:

 

1. there is no need to support multiple addressing = models. All scenarios can be supported by a single addressing model in which = each PMIPv6 session maps to a set of prefixes that are equally accessible = through the set of physical interfaces attached to that PMIPv6 session. This = allows all scenarios, including one in which two prefix sets are available through = different physical interfaces set. I understand that the WG has been divided on = that question but that does not constitute a mandate to include everyone's = wish list  in a standard specification. Thus unless someone can come up with a rebuttal of my argument on why single addressing model = (prefix-set per interface-set) satisfies all scenarios, e.g., by pointing out a = scenario in which it does not, that should be the only addressing model supported in = that spec.

 

[Sri] I guess, this goes back to our last discussion in = this list. We allow the hosting of multiple prefixes on an IPv6 link and the = base RFC-5213 allows the same. You agreed and your comments on to take the = approach of session management, as supposed to addressing models. Now, we allow = the ability to move a full/partial set of prefixes to a different interface, = and optionally allow the sharing of prefixes across links. This is one issue to discuss = the shared link approach and see how to capture the final text. The text can = be updated once we decide the scenarios that we support. This also probably = ties to the policy interface to MN. Lets take this as an open = issue.

 

 

2. there is no need to convey traffic selectors = between the MAG and the LMA. The LMA forwards downlink packets as per the = network-based policy, and the uplink packets to the Internet. The MAG forwards = downlink packets to the MN, and uplink packets to the LMA. End of the story. As = above, unless someone comes up with a rebuttal of why that is not sufficient to address the scenario we're concerned with (network-based flow mobility), the traffic selectors shall be removed = from the specification.

 

 

[Sri] I tend to agree. The MAG does not have ability to = convey flow level info over ND interface. At the end of the day, the MAG is hosting = a set of prefixes on a link and that’s all. So, the traffic selectors = are not needed from the mobility perspective, but if we look at this as exchange = of policy, we can allow them optionally. But, =A0I’m fine to get rid = of this entirely, but allowing this exchange is not undesirable = either.

 

Regards

Sri

 

 

Best,

 

--julien 

2011/2/2 Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es>

Hi Julien,

Can you please summarize the issues you raised? As far as I recall, = your
main concern was about the scenario in which the prefix(es) is not
shared between all the physical interfaces of the MN, correct me if = I'm
wrong. In regards to this, as I think we answered, there are a number = of
scenarios that people expressed interest about that requires to = support
it. Current draft support this and the shared-prefix scenario. If the = WG
reaches a consensus in removing the non-shared prefix scenario, we = are
happy to do it, but my understanding was that not all the WG had = that
opinion (at that time, at least).

Thanks,

Carlos


On Wed, 2011-02-02 at 15:06 -0800, Julien Laganier wrote:
> Raj,
>
> As with the other draft (logical interface), I have raised a number = of
> issues with this draft that in my humble opinion have not been = addressed
> adequately, and thus at this stage I believe that asking for = adoption is
> premature. In other words, I'd like the issues that I've raised to = be
> addressed by the authors before I feel comfortable having an = opinion on
> whether or not this draft is a good basis to progress the flow = mobility
> extensions.
>
> Thank you for your consideration,
>
> --julien
>
> On Tue, Feb 1, 2011 at 3:47 PM, <Basavaraj.Patil@nokia.com&g= t; wrote:
>
> >
> > Hello,
> >
> > We have discussed the flow mobility solutions for Proxy MIP6 previously at
> > IETFs 78 and 79.
> > This is a consensus call for adopting this I-D:
> > draft-bernardos-netext-pmipv6-flowmob-02
> > as the working group document.
> > I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-fl= owmob-02.txt
> >
> > The consensus call will expire on Feb 15th, 2011. Please = indicate your
> > support or concerns in adopting this I-D as the WG baseline = document on
> > the mailing list.
> >
> > Please note that this I-D will serve as the baseline in the WG = and will be
> > developed further based on input and feedback from WG = members.
> >
> > -Basavaraj
> >
> > _______________________________________________
> > 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

--

Carlos Jes=FAs Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 = 4F67

 

------_=_NextPart_001_01CBC337.2B9A0309-- From behcetsarikaya@yahoo.com Wed Feb 2 18:20:07 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48F2F3A67B3 for ; Wed, 2 Feb 2011 18:20:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJUuiafOX7CK for ; Wed, 2 Feb 2011 18:20:06 -0800 (PST) Received: from nm23-vm0.bullet.mail.sp2.yahoo.com (nm23-vm0.bullet.mail.sp2.yahoo.com [98.139.91.224]) by core3.amsl.com (Postfix) with SMTP id 6C6FC3A67A6 for ; Wed, 2 Feb 2011 18:20:06 -0800 (PST) Received: from [98.139.91.65] by nm23.bullet.mail.sp2.yahoo.com with NNFMP; 03 Feb 2011 02:23:24 -0000 Received: from [98.139.91.59] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 03 Feb 2011 02:23:24 -0000 Received: from [127.0.0.1] by omp1059.mail.sp2.yahoo.com with NNFMP; 03 Feb 2011 02:23:24 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 901511.50704.bm@omp1059.mail.sp2.yahoo.com Received: (qmail 86483 invoked by uid 60001); 3 Feb 2011 02:23:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1296699804; bh=W5pFMFgQ/ZrnZxCpJ5EtPtDTbOC4uM8E1A/z8CRcvjg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=zW+EjDnL+VHhln8VmMt7a0oeBxeIDg0Aasgmya75UEePpDaJd8w5HaW7IJeh6R7N/BkEoGOio4wRO6dz+zAu0DkQuu6kDJZ0prWZMfG/iPJ3b6N+CNf82Nqx7ldBjsjz0yahUc/LuWDqneLXRodE4tX+jFPWfAWp0kjfjaG84Fk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=j8xcpRVXJYofkzLUf+k72bv+W0FJxuByWWEoXIi09bZUg/LSyfRuOEk+N3hZnoOlIbtuFqTjWRpJHKqI3S949b99pz5/KfYKqvC8hHQGqRqKxf2HQbDWau7MSuqSiw8KvBu1Bnayw8+Tzofi/by8H4w9uUuTwo630z8NxiM4BBQ=; Message-ID: <509304.85599.qm@web111415.mail.gq1.yahoo.com> X-YMail-OSG: CPmt.3wVM1lsJsGsuuCOau.3.y6qUt82OjSXIc815nVvuTV AuljuAiJyctIFV.b3UeN02rpJaHl5OPwpGd0xxuIEf8ri4wSNDRFUMTssabR ITKzx.2wden9yvDMpqq3N50zl4KEYyh5q4CcRRo0PDTkcB7HjcJPMw1ri9Io BFAV3Rt9EfqQIUmPT6YUMhVL7XfjmCKRTIKf_l2FcO3NLZ4bEHBOc4zBtgxK b30woufD.XETnuVKLj_cZygKbhBMyJOxy6TfwwSVix8.QxOG8v6GznQBrYiL YC31lTy_YWj4Bw0eQ1Aakxlqe.BLkoMGnkCZWq_orzAhBWatY.wCNwYXzo7R KxsAxyFydakXZI6Eq6OhuBfzyI8fDDdjb7VXQvDs9gvkGb7vV8jXAQw4ROD6 3ErniUf9pgsDa Received: from [71.170.141.239] by web111415.mail.gq1.yahoo.com via HTTP; Wed, 02 Feb 2011 18:23:24 PST X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.108.291010 References: <314265.17931.qm@web111409.mail.gq1.yahoo.com> Date: Wed, 2 Feb 2011 18:23:24 -0800 (PST) From: Behcet Sarikaya To: stefano faccin In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 02:20:07 -0000 Hi Stefano, > >Behcet, >thanks for the reminder that we are indeed targeting 3GPP and specific >interfaces as our customer. Indeed if a working solution that fits the framework > >of S2a and S2b is designed, it could be used at the discretion of 3GPP. However, > >if "a missing part" needs to be provided, I believe the technical issues I raise > >are indeed in the scope and need to be addressed in order to make the protocol >applicable to the customer. Expecting to define a solution that does not fit the > >customer and throwing the protocol over the fence to them to fix their part to >make the protocol work does not sound like a good design approach to me. If you can suggest some text that will address the above, I am sure the editor will be happy to incorporate that in the next version. Regards, Behcet From behcetsarikaya@yahoo.com Wed Feb 2 18:34:44 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 048D33A67AE for ; Wed, 2 Feb 2011 18:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-Btr4sZPIFo for ; Wed, 2 Feb 2011 18:34:42 -0800 (PST) Received: from nm15-vm0.bullet.mail.sp2.yahoo.com (nm15-vm0.bullet.mail.sp2.yahoo.com [98.139.91.208]) by core3.amsl.com (Postfix) with SMTP id 90D623A67AC for ; Wed, 2 Feb 2011 18:34:42 -0800 (PST) Received: from [98.139.91.61] by nm15.bullet.mail.sp2.yahoo.com with NNFMP; 03 Feb 2011 02:38:01 -0000 Received: from [98.139.91.33] by tm1.bullet.mail.sp2.yahoo.com with NNFMP; 03 Feb 2011 02:38:01 -0000 Received: from [127.0.0.1] by omp1033.mail.sp2.yahoo.com with NNFMP; 03 Feb 2011 02:38:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 8942.4264.bm@omp1033.mail.sp2.yahoo.com Received: (qmail 96603 invoked by uid 60001); 3 Feb 2011 02:38:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1296700680; bh=F1gz4jXVw2nA4BfSrEfLqC/JhF1/iEPqZdwwCMkx80M=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=k1eeqbG2rRvdX5Rn39lOob/QPrMAzgqnev8w5O0wH+1hKMoIEZydrq/INPEz8idMcWlrlqAtUlLhPFiv6b7tUNWbT51WmR8jxcEbO2QC+PPQfhztwVCzo0ObrNS0n0YvTK00TPP/BIeC1YVR/x7QjYeKStKxnvMOUt1N48gd9Ww= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qh3ZASjRLnRQ2I41eVeCG5/ikIhiGZWEJi7FI52bJFwXhXO/8+LTzlSX4AQ+asU7815rfFOR+YdKlXVQyQMloYLT5kT+iPvpEFhS3hq5/33yW67dqyIrdHgkjvJvGlp5hwIapUqnP6bAIlyHG1ZaWjjVi1z+J9C7Q5W+vXQNHFE=; Message-ID: <619017.96542.qm@web111406.mail.gq1.yahoo.com> X-YMail-OSG: GeK1FXAVM1lh6VxAsQCLyJHJXMh4vz0zGhWoMFfVUU6vXhQ PXiZwLv.1MNf07hVuHHeXjpskZi5Gkhxq3rGYThCf1LiVUS5d.MD.9AZmx8X dcBBflWiQkxdxohzmivUvtDQ48YSYR8ikH5apUU0D8HWw851CgFr2xMpc20Y jeNSA36jOYKUqRmFAtgWwKzWvlxGUEqZ3GPyi52v.K6vHFNk3zL5REmRLVA8 lEEPEp1L.l.cjVkpKz7mXjZOhNeTUPoHbQXD4_dSE8xoJcorYHnlIWiD_deV Je360Zpy.R69WggVm7D7deYpagAd8U4UVTBV8.yov3j3BXXaZzadYeU0DLDA QYoXTTCCKU9m1UUB09HKVkBmPK7A4LEAJbqS5eKFW79KB2LjPZvVShKRPYPy YwisY4hTORSZL Received: from [71.170.141.239] by web111406.mail.gq1.yahoo.com via HTTP; Wed, 02 Feb 2011 18:38:00 PST X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.108.291010 References: <1296689037.3593.20.camel@acorde.it.uc3m.es> Date: Wed, 2 Feb 2011 18:38:00 -0800 (PST) From: Behcet Sarikaya To: "Sri Gundavelli \(sgundave\)" , Julien Laganier In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 02:34:44 -0000 =0A=0A=0A=0A> =0A>[Sri] I tend to agree. The MAG does not have ability to c= onvey flow level info =0A>over ND interface. At the end of the day, the MAG= is hosting a set of prefixes =0A>on a link and that=E2=80=99s all. So, the= traffic selectors are not needed from the =0A>mobility perspective, but if= we look at this as exchange of policy, we can allow =0A>=0A>them optionall= y. But, I=E2=80=99m fine to get rid of this entirely, =0A=0A>but allowing = this =0A>exchange is not undesirable either.=0A=0AAgreed.=0A=0ABehcet=0A=0A= =0A=0A From sfaccin@rim.com Wed Feb 2 18:45:33 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CC933A67AE for ; Wed, 2 Feb 2011 18:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.204 X-Spam-Level: X-Spam-Status: No, score=-5.204 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZUnuhWrzlgB for ; Wed, 2 Feb 2011 18:45:31 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id D427F3A67AC for ; Wed, 2 Feb 2011 18:45:29 -0800 (PST) X-AuditID: 0a666446-b7b07ae0000009cd-b2-4d4a1791883f Received: from XCH139CNC.rim.net ( [10.65.10.235]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 2D.26.02509.1971A4D4; Wed, 2 Feb 2011 21:48:50 -0500 (EST) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH139CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Feb 2011 21:48:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Date: Wed, 2 Feb 2011 20:48:49 -0600 Message-ID: <680854867F7FD04BB9B06EB8ACA8D5AC0465FAAE@XCH02DFW.rim.net> In-Reply-To: <509304.85599.qm@web111415.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvDSVvvrCfZY6SbTeG7GeX+FUJHYQAA4Wzc From: "Stefano Faccin" To: , X-OriginalArrivalTime: 03 Feb 2011 02:48:49.0962 (UTC) FILETIME=[E2C408A0:01CBC34C] X-Brightmail-Tracker: AAAAAgAAAZEXVNa5 Cc: netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 03 Feb 2011 02:45:33 -0000 Behcet, I'd be very happy if I had a solution for the issues raised. Not having one= on my side should not mean the issues do not exist, though. Cheers, Stefano Stefano M. Faccin Standards Manager Research In Motion 122 West John Carpenter Parkway Irving, TX 75039 Internal: 820 63451 Desk: +1 972 910 3451 BlackBerry: +1 510 230 8422 sfaccin@rim.com Time zone: PST (GMT -8) ----- Original Message ----- From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] Sent: Wednesday, February 02, 2011 08:23 PM To: stefano faccin Cc: netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmi= pv6-flowmob as WG doc Hi Stefano, > >Behcet, >thanks for the reminder that we are indeed targeting 3GPP and specific >interfaces as our customer. Indeed if a working solution that fits the fram= ework > >of S2a and S2b is designed, it could be used at the discretion of 3GPP. How= ever, > >if "a missing part" needs to be provided, I believe the technical issues I= raise > >are indeed in the scope and need to be addressed in order to make the proto= col >applicable to the customer. Expecting to define a solution that does not fi= t the > >customer and throwing the protocol over the fence to them to fix their part= to >make the protocol work does not sound like a good design approach to me. If you can suggest some text that will address the above, I am sure the edit= or will be happy to incorporate that in the next version. Regards, Behcet _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From sgundave@cisco.com Wed Feb 2 18:46:44 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 703B83A67AE for ; Wed, 2 Feb 2011 18:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.361 X-Spam-Level: X-Spam-Status: No, score=-9.361 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IByH1FAiyae for ; Wed, 2 Feb 2011 18:46:28 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 97E353A67AC for ; Wed, 2 Feb 2011 18:46:28 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAGumSU2rR7Ht/2dsb2JhbACCRZREhgeHNGdzoG6bMIJ7AYJXBIR4hmqDMIMAhXE Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 03 Feb 2011 02:49:48 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p132nmLe022765; Thu, 3 Feb 2011 02:49:48 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Feb 2011 18:49:48 -0800 Received: from 10.32.243.75 ([10.32.243.75]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 Feb 2011 02:49:48 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Wed, 02 Feb 2011 18:50:20 -0800 From: Sri Gundavelli To: stefano faccin Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvDTRhukwEg6qmBJkas4BmovW56mg== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3379517420_83789248" X-OriginalArrivalTime: 03 Feb 2011 02:49:48.0689 (UTC) FILETIME=[05C51010:01CBC34D] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 03 Feb 2011 02:46:44 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3379517420_83789248 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Stefano, One comment. Agree with you there is no ANDSF interface to the network node, but the assumption of synchronized policies between the ANDSF server and the PDN GW/HA is there, implicitly IMO. With out this assumption, I do not know, ho= w the HA can ever validate the flow mobility options received in the BU. If the operator requires any control on enforcing a flow policy rule, the PDN GW/HA needs to have synchronized policies, without which its always the client decision. I=B9m not sure, operators in 3GPP would like that :) No doubt, the lack of MN-AR interface is surely an issue for supporting complex flow policies. I realize the issues and I agree with you. But, the assumption of synchronized policies can offer some solution with some configuration requirement on the HA (assuming there are no other issues). There are also the proposals on flow mirroring on the UE ..., requiring no flow policies. I=B9ve not evaluated this, however. Folks can comment on this. It is also to be noted, for some of the scenarios such, there is no flow policy interface needed. We can identify what scenarios create any configuration limitations on the HA and which one=B9s do not . As I=B9ve noted earlier, this is surely an open issue, that we need to discuss in the WG. Regards Sri =20 On 2/2/11 9:08 AM, "stefano faccin" wrote: > Sri, > thanks for the reply. Can you clarify in which system or scenario ANDSF i= s > available to network entities as well? There is no such availability in 3= GPP, > and making such information available would require considerable architec= tural > changes, therefore the applicability of this solution to what seems to be= the > only realistic scenario hinges on 3GPP making considerable architectural > changes. I would therefore not be so hastily concluding that the ANDSF > information is available to the LMA and underestimate what it would reall= y > take to make the solution applicable. >=20 > If we cannot guarantee that there is at least one realistic solution to h= ave > the MNa nd LMA in synch, how do we expect that this solution is applicabl= e at > all? In 3GPP there is no need to have such implicit assumption, be cause = 1) > the MN is provided policies explicitly through the ANDSF, and 2) it is th= e MN > and only the MN that makes IP flow mobility decisions and communicates th= em > explicitly (with well defined signalling) to the LMA, and therefore no ma= gic > is needed. There is no need in 3GPP to have the ANDSF and PDN GW policies > synchronized, since the PDN GW does not use such policies. >=20 > Sri, in the end it is a matter of whether we develop a solution that will= rely > on some unknown magic to be deployed, or a solution that we know can be > deployed in at least one way because there are solutions to what I consid= er > major open issues. >=20 > Cheers, > Stefano >=20 > On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli wrote= : >> Hi Stefano, >>=20 >> Thanks for the discussion. >>=20 >> As you say, the ANDSF policies are allowing the MN a.) to make the right >> network attachment decision and b.) make the access selection on a flow >> basis. This same policy that is present in the ANDSF server, is availabl= e for >> the network nodes as well. I=B9m not sure, with out this assumption the >> solution can work for all currently listed cases. We clearly need the MN= and >> the LMA to be in synch with respect to the configured policy. How, that = is >> done, I guess we will not try to know. =A0I thought even in 3GPP, this is = the >> implied assumption ? But, this is for you to clarify. Not specifically f= or >> IFOM where UE and PDN GW/HA are negotiating the flow policies, but gener= ally >> that the PDN GW and the ANDSF policy server will have synchronized polic= ies. >> The MAG and the LMA have the ability to carry this flow policy informati= on in >> signaling messages and influence the access selection. The policy is a o= paque >> object, with extensible formats, when carried in the signaling plane, sh= ould >> allow the LMA/MAG to apply those access policies, while assuming MN is >> following the same rules. These policies can surely reflect the specific= WLAN >> access/operator specific rule. I=B9m surely with you, the lack of MN-AR >> interface is surely an issue and I see that. But, we need to understand,= what >> are the limitations with the approach of =A0out of band policy interfaces = and >> what will be the solution limitations. If we need to tie the flow moveme= nt at >> the prefix granularity and rely on the natural ND interface in the form = of RA >> PIO option, more like PDN offload in MAPCON, or at the granularity of a = flow >> level, is open for discussion. I want to simplify this draft for sure, w= e can >> surely discuss each of these issues on the WG draft. >>=20 >>=20 >> Regards >> Sri >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2/1/11 8:29 PM, "stefano faccin" > > wrote: >>=20 >>> Sri, >>> thanks for the reply. >>>=20 >>> I'd like to comment on the "the flow policy decisions need not be based= on >>> the specific WLAN network". Does it mean, as I believe it does, that th= e >>> current solution would not allow an operator deploying such solution to >>> decide to route flows over a specific WLAN or not depending on which >>> specific WLAN the MN is connected to? E.g. the operator or the entity i= n >>> control of the decisions for the routing may want to direct certain tra= ffic >>> always over WLANs that the operator deploys, and instead route only som= e of >>> the traffic over WLANs of roaming partners or of the MN user home. How = does >>> this solution support that scenario if the LMA is not told specifically >>> which WLAN the MN is connected to? From a deployment point of view, I d= o not >>> believe we can afford to leave out this scenario. Please note that the >>> establishment of a security relationship between the MN and the MAG, an= d a >>> specific MAG identity, cannot guarantee that the LMA knows which specif= ic >>> WLAN access network the MN is connected to. Assuming that would severel= y >>> restrict the deployment scenarios. >>>=20 >>> As for the MN and the LMA being magically in synch, I am very concerned >>> about a "glass ball" solution. You mention ANDSF defined by 3GPP as a >>> solution for this "out of band" delivery of policy. Fair enough, howeve= r >>> there is an issue with that. ANDSF is designed specific to be a MN-cent= ric >>> solution where policies are provisioned in the MN and the MN decides wh= ich >>> network technologies and access networks it needs to connect to, under = what >>> conditions, and which IP traffic needs to be routed on such accesses. N= o IP >>> point of attachment in the network (i.e. the PDN GW in 3GPP that is the= LMA >>> in PMIPv6) is aware under any conditions of such policy. Therefore, eve= n if >>> in order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF w= ould >>> unfortunately not provide a solution unless the MN can communicate to t= he >>> MAG and the LMA the decisions the MN has taken based on the ANDSF polic= ies. >>>=20 >>> I believe the key point here is that we need to understand how the solu= tion >>> can be realistically applied to a real scenario, and that we need to en= sure >>> that important and realistic deployment scenarios are not excluded by t= he >>> solution. >>>=20 >>> Cheers, >>> Stefano >>>=20 >>> On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli >> > wrote: >>>> Hi Stefano: >>>>=20 >>>> These are valid points and some good comments. Let me share my thought= s. >>>>=20 >>>> Carlo=B9s draft is not assuming any new MN-AR interface. Its going with = the >>>> assumption there is established policy on the mobile and on the LMA, w= hich >>>> allows the mobile to select the access network at a flow level granula= rity, >>>> without requiring any explicit signaling between the MAG and the MN. T= o >>>> large part this is all about out of band policy interface, such as AND= SF, >>>> towards the UE, leading to the assumption that magically the MN and th= e LMA >>>> are in sync with respect to flow policies, access selection and they w= ill >>>> make the right forwarding decision. Secondly, the flow policy decision= s >>>> need not be based on the specific WLAN network, but it is implicitly d= riven >>>> by the MAG =AD LMA security relation, where the MAG attachment to the WL= AN >>>> network transitively allows the LMA to make the flow policy decisions = based >>>> on the MAG identity. If the WLAN network is not trusted, there is trul= y no >>>> MAG in that network, where the LMA shares a security relation with tha= t >>>> node. >>>>=20 >>>> There are still some open issues on this draft that needs to be discus= sed >>>> in the WG. =A0On the approaches to allow more a flow aggregate movement,= that >>>> is a discussion point. There are issues that we need to discuss, suppo= rting >>>> split link model, or eliminating some favorite brand of signaling mess= age >>>> (FMA) and riding on PBU/PBA and just with one FMI trigger, and on the >>>> aspects around MN applying the flow policies by flow mirroring. We hav= e no >>>> agreement on those issues yet. >>>>=20 >>>> Its just a base draft, for further discussion and resolving those issu= es. >>>> But, hope that is not a stopper for base draft selection. >>>> =A0 >>>>=20 >>>> Sri >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2/1/11 6:39 PM, "stefano faccin" >>> > wrote: >>>>=20 >>>>> Raj, >>>>> thanks for the email. >>>>>=20 >>>>> I need to apologize in advance if my questions have already been answ= ered >>>>> before (though I cannot find a conclusive answer anywhere). >>>>>=20 >>>>> I think that a protocol that is developed in NETEXT (or other groups) >>>>> should have at least a potential realistic scenario for applicability= . >>>>>=20 >>>>> In terms of applicability, though it is not part of the protocol >>>>> definition per se, unless there are solutions in place for either the= host >>>>> to indicate to the network where the flows should be routed or for th= e LMA >>>>> to receive somehow from somewhere some policies, the solution cannot >>>>> really provide flow mobility since there is no way to decide which fl= ows >>>>> are routed where. If we are thinking about a host-based solution, I h= ave >>>>> not yet seen a solution as to how the host can indicate to the MAG an= d >>>>> ultimately to the MAG which flows should be routed on each access. If= we >>>>> are relying on modifications of layer 2 protocols, aren't we defining= a >>>>> solution that works only with some technologies (since for other acce= ss >>>>> technologies it is rather unrealistic to modify L2 for IP flow mobili= ty >>>>> purposes)? If we are thinking of an LMA-based solution, can we hear o= f at >>>>> least one example of a real-life scenario where the LMA would receive= such >>>>> policies, and how such delivery would happen? Also, should there be a >>>>> solution to have policies in the LMA, how does the LMA actually decid= e to >>>>> route flows on one access or the other? E.g., if some flows need to b= e >>>>> routed on certain WLAN networks, but shall not be routed on other WLA= N >>>>> networks, how does the LMA know which specific WLAN network the host = is >>>>> connected to? Perhaps I missed the ability for the MAG to know e.g. t= he >>>>> WLAN SSID and provide it to the LMA, in which case I would appreciate= if >>>>> somebody could highlight to me where that is defined. >>>>>=20 >>>>> I think that, though not integral to the protocol specification, >>>>> understanding what framework the protocol would/needs to fit in is ra= ther >>>>> important.=20 >>>>>=20 >>>>> Cheers, >>>>> Stefano >>>>>=20 >>>>>=20 >>>>> On Tue, Feb 1, 2011 at 3:47 PM, =A0>>>> > >>>>> wrote: >>>>>>=20 >>>>>> Hello, >>>>>>=20 >>>>>> We have discussed the flow mobility solutions for Proxy MIP6 previou= sly >>>>>> at >>>>>> IETFs 78 and 79. >>>>>> This is a consensus call for adopting this I-D: >>>>>> draft-bernardos-netext-pmipv6-flowmob-02 >>>>>> as the working group document. >>>>>> I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02= .txt >>>>>>=20 >>>>>> The consensus call will expire on Feb 15th, 2011. Please indicate yo= ur >>>>>> support or concerns in adopting this I-D as the WG baseline document= on >>>>>> the mailing list. >>>>>>=20 >>>>>> Please note that this I-D will serve as the baseline in the WG and w= ill >>>>>> be >>>>>> developed further based on input and feedback from WG members. >>>>>>=20 >>>>>> -Basavaraj >>>>>>=20 >>>>>> _______________________________________________ >>>>>> netext mailing list >>>>>> netext@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netext >>>>>=20 >>>>>=20 >>>=20 >>>=20 >=20 >=20 --B_3379517420_83789248 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmi= pv6-flowmob as WG doc Hi Stefano,

One comment.

Agree with you there is no ANDSF interface to the network node, but the ass= umption of synchronized policies between the ANDSF server and the PDN GW/HA = is there, implicitly IMO. With out this assumption, I do not know, how the H= A can ever validate the flow mobility options received in the BU. If the ope= rator requires any control on enforcing a flow policy rule, the PDN GW/HA ne= eds to have synchronized policies, without which its always the client decis= ion. I’m not sure, operators in 3GPP would like that :)

No doubt, the lack of MN-AR interface is surely an issue for supporting com= plex flow policies. I realize the issues and I agree with you. But, the assu= mption of synchronized policies can offer some solution with some configurat= ion requirement on the HA (assuming there are no other issues). There are al= so the proposals on flow mirroring on the UE ..., requiring no flow policies= . I’ve not evaluated this, however. Folks can comment on this.

It is also to be noted, for some of the scenarios such, there is no flow po= licy interface needed. We can identify what scenarios create any configurati= on limitations on the HA and which one’s do not . As I’ve noted = earlier, this is surely an open issue, that we need to discuss in the WG.


Regards
Sri




 


On 2/2/11 9:08 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Sri,
thanks for the reply. Can you clarify in which system or scenario ANDSF is = available to network entities as well? There is no such availability in 3GPP= , and making such information available would require considerable architect= ural changes, therefore the applicability of this solution to what seems to = be the only realistic scenario hinges on 3GPP making considerable architectu= ral changes. I would therefore not be so hastily concluding that the ANDSF i= nformation is available to the LMA and underestimate what it would really ta= ke to make the solution applicable.

If we cannot guarantee that there is at least one realistic solution to hav= e the MNa nd LMA in synch, how do we expect that this solution is applicable= at all? In 3GPP there is no need to have such implicit assumption, be cause= 1) the MN is provided policies explicitly through the ANDSF, and 2) it is t= he MN and only the MN that makes IP flow mobility decisions and communicates= them explicitly (with well defined signalling) to the LMA, and therefore no= magic is needed. There is no need in 3GPP to have the ANDSF and PDN GW poli= cies synchronized, since the PDN GW does not use such policies.

Sri, in the end it is a matter of whether we develop a solution that will r= ely on some unknown magic to be deployed, or a solution that we know can be = deployed in at least one way because there are solutions to what I consider = major open issues.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli <sgundave@cisco.com> wrote:
<= SPAN STYLE=3D'font-size:11pt'>Hi Stefano,

Thanks for the discussion.

As you say, the ANDSF policies are allowing the MN a.) to make the right ne= twork attachment decision and b.) make the access selection on a flow basis.= This same policy that is present in the ANDSF server, is available for the = network nodes as well. I’m not sure, with out this assumption the solu= tion can work for all currently listed cases. We clearly need the MN and the= LMA to be in synch with respect to the configured policy. How, that is done= , I guess we will not try to know. =A0I thought even in 3GPP, this is the impl= ied assumption ? But, this is for you to clarify. Not specifically for IFOM = where UE and PDN GW/HA are negotiating the flow policies, but generally that= the PDN GW and the ANDSF policy server will have synchronized policies. The= MAG and the LMA have the ability to carry this flow policy information in s= ignaling messages and influence the access selection. The policy is a opaque= object, with extensible formats, when carried in the signaling plane, shoul= d allow the LMA/MAG to apply those access policies, while assuming MN is fol= lowing the same rules. These policies can surely reflect the specific WLAN a= ccess/operator specific rule. I’m surely with you, the lack of MN-AR i= nterface is surely an issue and I see that. But, we need to understand, what= are the limitations with the approach of =A0out of band policy interfaces and= what will be the solution limitations. If we need to tie the flow movement = at the prefix granularity and rely on the natural ND interface in the form o= f RA PIO option, more like PDN offload in MAPCON, or at the granularity of a= flow level, is open for discussion. I want to simplify this draft for sure,= we can surely discuss each of these issues on the WG draft.


Regards
Sri






On 2/1/11 8:29 PM, "stefano faccin" <sfaccinstd@gmail.com <htt= p://sfaccinstd@gmail.com> > wrote:

Sri,
thanks for the reply.

I'd like to comment on the "the flow policy decisions n= eed not be based on the specific WLAN network". Does it mean, as I beli= eve it does, that the current solution would not allow an operator deploying= such solution to decide to route flows over a specific WLAN or not dependin= g on which specific WLAN the MN is connected to? E.g. the operator or the en= tity in control of the decisions for the routing may want to direct certain = traffic always over WLANs that the operator deploys, and instead route only = some of the traffic over WLANs of roaming partners or of the MN user home. H= ow does this solution support that scenario if the LMA is not told specifica= lly which WLAN the MN is connected to? From a deployment point of view, I do= not believe we can afford to leave out this scenario. Please note that the = establishment of a security relationship between the MN and the MAG, and a s= pecific MAG identity, cannot guarantee that the LMA knows which specific WLA= N access network the MN is connected to. Assuming that would severely restri= ct the deployment scenarios.

As for the MN and the LMA being magically in synch, I am very concerned abo= ut a "glass ball" solution. You mention ANDSF defined by 3GPP as a= solution for this "out of band" delivery of policy. Fair enough, = however there is an issue with that. ANDSF is designed specific to be a MN-c= entric solution where policies are provisioned in the MN and the MN decides = which network technologies and access networks it needs to connect to, under= what conditions, and which IP traffic needs to be routed on such accesses. = No IP point of attachment in the network (i.e. the PDN GW in 3GPP that is th= e LMA in PMIPv6) is aware under any conditions of such policy. Therefore, ev= en if in order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF = would unfortunately not provide a solution unless the MN can communicate to = the MAG and the LMA the decisions the MN has taken based on the ANDSF polici= es.

I believe the key point here is that we need to understand how the solution= can be realistically applied to a real scenario, and that we need to ensure= that important and realistic deployment scenarios are not excluded by the s= olution.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli <sgundave@cisco.com <http://s= gundave@cisco.com> > wrote:
<= SPAN STYLE=3D'font-size:11pt'>Hi Stefano:

These are valid points and some good comments. Let me share my thoughts.
Carlo’s draft is not assuming any new MN-AR interface. Its going with= the assumption there is established policy on the mobile and on the LMA, wh= ich allows the mobile to select the access network at a flow level granulari= ty, without requiring any explicit signaling between the MAG and the MN. To = large part this is all about out of band policy interface, such as ANDSF, to= wards the UE, leading to the assumption that magically the MN and the LMA ar= e in sync with respect to flow policies, access selection and they will make= the right forwarding decision. Secondly, the flow policy decisions need not= be based on the specific WLAN network, but it is implicitly driven by the M= AG – LMA security relation, where the MAG attachment to the WLAN netwo= rk transitively allows the LMA to make the flow policy decisions based on th= e MAG identity. If the WLAN network is not trusted, there is truly no MAG in= that network, where the LMA shares a security relation with that node.

There are still some open issues on this draft that needs to be discussed i= n the WG. =A0On the approaches to allow more a flow aggregate movement, that i= s a discussion point. There are issues that we need to discuss, supporting s= plit link model, or eliminating some favorite brand of signaling message (FM= A) and riding on PBU/PBA and just with one FMI trigger, and on the aspects a= round MN applying the flow policies by flow mirroring. We have no agreement = on those issues yet.

Its just a base draft, for further discussion and resolving those issues. B= ut, hope that is not a stopper for base draft selection.
=A0

Sri






On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <htt= p://sfaccinstd@gmail.com>  <http://sfaccinstd@gmail.com> > wrote:

<= SPAN STYLE=3D'font-size:11pt'>Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicate= to the network where the flows should be routed or for the LMA to receive s= omehow from somewhere some policies, the solution cannot really provide flow= mobility since there is no way to decide which flows are routed where. If w= e are thinking about a host-based solution, I have not yet seen a solution a= s to how the host can indicate to the MAG and ultimately to the MAG which fl= ows should be routed on each access. If we are relying on modifications of l= ayer 2 protocols, aren't we defining a solution that works only with some te= chnologies (since for other access technologies it is rather unrealistic to = modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-based= solution, can we hear of at least one example of a real-life scenario where= the LMA would receive such policies, and how such delivery would happen? Al= so, should there be a solution to have policies in the LMA, how does the LMA= actually decide to route flows on one access or the other? E.g., if some fl= ows need to be routed on certain WLAN networks, but shall not be routed on o= ther WLAN networks, how does the LMA know which specific WLAN network the ho= st is connected to? Perhaps I missed the ability for the MAG to know e.g. th= e WLAN SSID and provide it to the LMA, in which case I would appreciate if s= omebody could highlight to me where that is defined.

I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important. <= BR>
Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM, =A0<Ba= savaraj.Patil@nokia.com <h= ttp://Basavaraj.Patil@nokia.com>  <http://Basavaraj.Patil@nokia.com> > wrote:
<= SPAN STYLE=3D'font-size:11pt'>
Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= BR> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt<= /a>

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= BR> developed further based on input and feedback from WG members.

-Basavaraj

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





--B_3379517420_83789248-- From gerardog@qualcomm.com Wed Feb 2 21:10:32 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D66623A6858 for ; Wed, 2 Feb 2011 21:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXivLsw7dwiy for ; Wed, 2 Feb 2011 21:10:16 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id DAE333A6856 for ; Wed, 2 Feb 2011 21:10:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1296710017; x=1328246017; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:mime-version; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20Sri=20Gundavelli=20,=20stefano =20faccin=20|CC:=20"netext@ietf.org "=20,=20"Basavaraj.Patil@nokia.com"=0D =0A=09|Subject:=20RE:=20[netex t]=20Consensus=20call=20to=20adopt=20I-D:=0D=0A=20draft-b ernardos-netext-pmipv6-flowmob=20as=20WG=20doc |Thread-Topic:=20[netext]=20Consensus=20call=20to=20adopt =20I-D:=0D=0A=20draft-bernardos-netext-pmipv6-flowmob=20a s=20WG=20doc|Thread-Index:=20AQHLwmpURzmRlysrlUidlexdQorG ZJPuBh2AgAAR4ICAAAzJgIAACkaAgADJ5gCAAKKGAP//oT5w|Date:=20 Thu,=203=20Feb=202011=2005:13:34=20+0000|Message-ID:=20|References:=20=0D=0A=20|In-Reply-To:=20|Accept-Language:=20en-US|Content-Language:=20en- US|X-MS-Has-Attach:|X-MS-TNEF-Correlator: |x-originating-ip:=20[199.106.114.10]|Content-Type:=20mul tipart/alternative=3B=0D=0A=09boundary=3D"_000_E5E9FF33C2 A27043B3BC96FE5A5160F1019E7Fnasanexd01enaqual_" |MIME-Version:=201.0; bh=1ufaW2hRUd5BPdIMBsbdMo5QBgATxVkPZaY1VWR/9W4=; b=W3Zd8FtSvsBHydZ8z/MS8jRUhyY9CyzXiPXrdlrcsx6sIoZwjgFZO2LD x6MlXCIxxIPejRJ5kweyaiAOsRe4+db6hrCY/xJTv2qOya+yjW/NcTBV5 KDFUP1Q/V8SL5K0zFMo92f5WkQD4Wh2+i9DMgOCOfBqT2XrnnNuVi7ZIz o=; X-IronPort-AV: E=McAfee;i="5400,1158,6245"; a="73007378" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 02 Feb 2011 21:13:36 -0800 X-IronPort-AV: E=Sophos;i="4.60,416,1291622400"; d="scan'208,217";a="27473737" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 02 Feb 2011 21:13:36 -0800 Received: from NASANEXD01E.na.qualcomm.com ([fe80::6555:8c37:4ee3:efc4]) by nasanexhc04.na.qualcomm.com ([::1]) with mapi id 14.01.0218.012; Wed, 2 Feb 2011 21:13:36 -0800 From: "Giaretta, Gerardo" To: Sri Gundavelli , stefano faccin Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLwmpURzmRlysrlUidlexdQorGZJPuBh2AgAAR4ICAAAzJgIAACkaAgADJ5gCAAKKGAP//oT5w Date: Thu, 3 Feb 2011 05:13:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.114.10] Content-Type: multipart/alternative; boundary="_000_E5E9FF33C2A27043B3BC96FE5A5160F1019E7Fnasanexd01enaqual_" MIME-Version: 1.0 Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 03 Feb 2011 05:10:33 -0000 --_000_E5E9FF33C2A27043B3BC96FE5A5160F1019E7Fnasanexd01enaqual_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sri, There is no implicit assumption of synchronized policies. A basic example t= hat shows that there is no assumption is the following: ANDSF policies may = be based also on location of the UE. For example the UE should prefer WLAN = only in a given location. When the UE is attached over WLAN there is no way= for the PDNGW/HA to verify the location of the UE and therefore to verify = UE actions based on policies. The assumption on synchronization of policies is only applicable to this dr= aft and I think it is a wrong one. Cheers Gerardo From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of= Sri Gundavelli Sent: Wednesday, February 02, 2011 6:50 PM To: stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-p= mipv6-flowmob as WG doc Hi Stefano, One comment. Agree with you there is no ANDSF interface to the network node, but the ass= umption of synchronized policies between the ANDSF server and the PDN GW/HA= is there, implicitly IMO. With out this assumption, I do not know, how the= HA can ever validate the flow mobility options received in the BU. If the = operator requires any control on enforcing a flow policy rule, the PDN GW/H= A needs to have synchronized policies, without which its always the client = decision. I'm not sure, operators in 3GPP would like that :) No doubt, the lack of MN-AR interface is surely an issue for supporting com= plex flow policies. I realize the issues and I agree with you. But, the ass= umption of synchronized policies can offer some solution with some configur= ation requirement on the HA (assuming there are no other issues). There are= also the proposals on flow mirroring on the UE ..., requiring no flow poli= cies. I've not evaluated this, however. Folks can comment on this. It is also to be noted, for some of the scenarios such, there is no flow po= licy interface needed. We can identify what scenarios create any configurat= ion limitations on the HA and which one's do not . As I've noted earlier, t= his is surely an open issue, that we need to discuss in the WG. Regards Sri On 2/2/11 9:08 AM, "stefano faccin" wrote: Sri, thanks for the reply. Can you clarify in which system or scenario ANDSF is = available to network entities as well? There is no such availability in 3GP= P, and making such information available would require considerable archite= ctural changes, therefore the applicability of this solution to what seems = to be the only realistic scenario hinges on 3GPP making considerable archit= ectural changes. I would therefore not be so hastily concluding that the AN= DSF information is available to the LMA and underestimate what it would rea= lly take to make the solution applicable. If we cannot guarantee that there is at least one realistic solution to hav= e the MNa nd LMA in synch, how do we expect that this solution is applicabl= e at all? In 3GPP there is no need to have such implicit assumption, be cau= se 1) the MN is provided policies explicitly through the ANDSF, and 2) it i= s the MN and only the MN that makes IP flow mobility decisions and communic= ates them explicitly (with well defined signalling) to the LMA, and therefo= re no magic is needed. There is no need in 3GPP to have the ANDSF and PDN G= W policies synchronized, since the PDN GW does not use such policies. Sri, in the end it is a matter of whether we develop a solution that will r= ely on some unknown magic to be deployed, or a solution that we know can be= deployed in at least one way because there are solutions to what I conside= r major open issues. Cheers, Stefano On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli wrote: Hi Stefano, Thanks for the discussion. As you say, the ANDSF policies are allowing the MN a.) to make the right ne= twork attachment decision and b.) make the access selection on a flow basis= . This same policy that is present in the ANDSF server, is available for th= e network nodes as well. I'm not sure, with out this assumption the solutio= n can work for all currently listed cases. We clearly need the MN and the L= MA to be in synch with respect to the configured policy. How, that is done,= I guess we will not try to know. I thought even in 3GPP, this is the impl= ied assumption ? But, this is for you to clarify. Not specifically for IFOM= where UE and PDN GW/HA are negotiating the flow policies, but generally th= at the PDN GW and the ANDSF policy server will have synchronized policies. = The MAG and the LMA have the ability to carry this flow policy information = in signaling messages and influence the access selection. The policy is a o= paque object, with extensible formats, when carried in the signaling plane,= should allow the LMA/MAG to apply those access policies, while assuming MN= is following the same rules. These policies can surely reflect the specifi= c WLAN access/operator specific rule. I'm surely with you, the lack of MN-A= R interface is surely an issue and I see that. But, we need to understand, = what are the limitations with the approach of out of band policy interface= s and what will be the solution limitations. If we need to tie the flow mov= ement at the prefix granularity and rely on the natural ND interface in the= form of RA PIO option, more like PDN offload in MAPCON, or at the granular= ity of a flow level, is open for discussion. I want to simplify this draft = for sure, we can surely discuss each of these issues on the WG draft. Regards Sri On 2/1/11 8:29 PM, "stefano faccin" > wrote: Sri, thanks for the reply. I'd like to comment on the "the flow policy decisions need not be based on = the specific WLAN network". Does it mean, as I believe it does, that the cu= rrent solution would not allow an operator deploying such solution to decid= e to route flows over a specific WLAN or not depending on which specific WL= AN the MN is connected to? E.g. the operator or the entity in control of th= e decisions for the routing may want to direct certain traffic always over = WLANs that the operator deploys, and instead route only some of the traffic= over WLANs of roaming partners or of the MN user home. How does this solut= ion support that scenario if the LMA is not told specifically which WLAN th= e MN is connected to? From a deployment point of view, I do not believe we = can afford to leave out this scenario. Please note that the establishment o= f a security relationship between the MN and the MAG, and a specific MAG id= entity, cannot guarantee that the LMA knows which specific WLAN access netw= ork the MN is connected to. Assuming that would severely restrict the deplo= yment scenarios. As for the MN and the LMA being magically in synch, I am very concerned abo= ut a "glass ball" solution. You mention ANDSF defined by 3GPP as a solution= for this "out of band" delivery of policy. Fair enough, however there is a= n issue with that. ANDSF is designed specific to be a MN-centric solution w= here policies are provisioned in the MN and the MN decides which network te= chnologies and access networks it needs to connect to, under what condition= s, and which IP traffic needs to be routed on such accesses. No IP point of= attachment in the network (i.e. the PDN GW in 3GPP that is the LMA in PMIP= v6) is aware under any conditions of such policy. Therefore, even if in ord= er to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would unfor= tunately not provide a solution unless the MN can communicate to the MAG an= d the LMA the decisions the MN has taken based on the ANDSF policies. I believe the key point here is that we need to understand how the solution= can be realistically applied to a real scenario, and that we need to ensur= e that important and realistic deployment scenarios are not excluded by the= solution. Cheers, Stefano On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli > wrote: Hi Stefano: These are valid points and some good comments. Let me share my thoughts. Carlo's draft is not assuming any new MN-AR interface. Its going with the a= ssumption there is established policy on the mobile and on the LMA, which a= llows the mobile to select the access network at a flow level granularity, = without requiring any explicit signaling between the MAG and the MN. To lar= ge part this is all about out of band policy interface, such as ANDSF, towa= rds the UE, leading to the assumption that magically the MN and the LMA are= in sync with respect to flow policies, access selection and they will make= the right forwarding decision. Secondly, the flow policy decisions need no= t be based on the specific WLAN network, but it is implicitly driven by the= MAG - LMA security relation, where the MAG attachment to the WLAN network = transitively allows the LMA to make the flow policy decisions based on the = MAG identity. If the WLAN network is not trusted, there is truly no MAG in = that network, where the LMA shares a security relation with that node. There are still some open issues on this draft that needs to be discussed i= n the WG. On the approaches to allow more a flow aggregate movement, that = is a discussion point. There are issues that we need to discuss, supporting= split link model, or eliminating some favorite brand of signaling message = (FMA) and riding on PBU/PBA and just with one FMI trigger, and on the aspec= ts around MN applying the flow policies by flow mirroring. We have no agree= ment on those issues yet. Its just a base draft, for further discussion and resolving those issues. B= ut, hope that is not a stopper for base draft selection. Sri On 2/1/11 6:39 PM, "stefano faccin" > wrote: Raj, thanks for the email. I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere). I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability. In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicat= e to the network where the flows should be routed or for the LMA to receive= somehow from somewhere some policies, the solution cannot really provide f= low mobility since there is no way to decide which flows are routed where. = If we are thinking about a host-based solution, I have not yet seen a solut= ion as to how the host can indicate to the MAG and ultimately to the MAG wh= ich flows should be routed on each access. If we are relying on modificatio= ns of layer 2 protocols, aren't we defining a solution that works only with= some technologies (since for other access technologies it is rather unreal= istic to modify L2 for IP flow mobility purposes)? If we are thinking of an= LMA-based solution, can we hear of at least one example of a real-life sce= nario where the LMA would receive such policies, and how such delivery woul= d happen? Also, should there be a solution to have policies in the LMA, how= does the LMA actually decide to route flows on one access or the other? E.= g., if some flows need to be routed on certain WLAN networks, but shall not= be routed on other WLAN networks, how does the LMA know which specific WLA= N network the host is connected to? Perhaps I missed the ability for the MA= G to know e.g. the WLAN SSID and provide it to the LMA, in which case I wou= ld appreciate if somebody could highlight to me where that is defined. I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important. Cheers, Stefano On Tue, Feb 1, 2011 at 3:47 PM, > wrote: Hello, We have discussed the flow mobility solutions for Proxy MIP6 previously at IETFs 78 and 79. This is a consensus call for adopting this I-D: draft-bernardos-netext-pmipv6-flowmob-02 as the working group document. I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt The consensus call will expire on Feb 15th, 2011. Please indicate your support or concerns in adopting this I-D as the WG baseline document on the mailing list. Please note that this I-D will serve as the baseline in the WG and will be developed further based on input and feedback from WG members. -Basavaraj _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext --_000_E5E9FF33C2A27043B3BC96FE5A5160F1019E7Fnasanexd01enaqual_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmi= pv6-flowmob as WG doc

Hi Sri,

 

There is no implicit assumption of synchronized policies. A = basic example that shows that there is no assumption is the following: ANDS= F policies may be based also on location of the UE. For example the UE should prefer WLAN only in = a given location. When the UE is attached over WLAN there is no way for the= PDNGW/HA to verify the location of the UE and therefore to verify UE actio= ns based on policies.

 

The assumption on synchronization of policies is only applic= able to this draft and I think it is a wrong one.

 

Cheers

Gerardo

 

From: netext-b= ounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Sri Gundavelli
Sent: Wednesday, February 02, 2011 6:50 PM
To: stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-n= etext-pmipv6-flowmob as WG doc

 

Hi Stefano,

One comment.

Agree with you there is no ANDSF interface to the network node, but the ass= umption of synchronized policies between the ANDSF server and the PDN GW/HA= is there, implicitly IMO. With out this assumption, I do not know, how the= HA can ever validate the flow mobility options received in the BU. If the operator requires any control on enforc= ing a flow policy rule, the PDN GW/HA needs to have synchronized policies, = without which its always the client decision. I’m not sure, operators= in 3GPP would like that :)

No doubt, the lack of MN-AR interface is surely an issue for supporting com= plex flow policies. I realize the issues and I agree with you. But, the ass= umption of synchronized policies can offer some solution with some configur= ation requirement on the HA (assuming there are no other issues). There are also the proposals on flow mirroring= on the UE ..., requiring no flow policies. I’ve not evaluated this, = however. Folks can comment on this.

It is also to be noted, for some of the scenarios such, there is no flow po= licy interface needed. We can identify what scenarios create any configurat= ion limitations on the HA and which one’s do not . As I’ve note= d earlier, this is surely an open issue, that we need to discuss in the WG.



Regards
Sri




 


On 2/2/11 9:08 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:

Sri,
thanks for the reply. Can you clarify in which system or scenario ANDSF is = available to network entities as well? There is no such availability in 3GP= P, and making such information available would require considerable archite= ctural changes, therefore the applicability of this solution to what seems to be the only realistic scenario hinges on= 3GPP making considerable architectural changes. I would therefore not be s= o hastily concluding that the ANDSF information is available to the LMA and= underestimate what it would really take to make the solution applicable.

If we cannot guarantee that there is at least one realistic solution to hav= e the MNa nd LMA in synch, how do we expect that this solution is applicabl= e at all? In 3GPP there is no need to have such implicit assumption, be cau= se 1) the MN is provided policies explicitly through the ANDSF, and 2) it is the MN and only the MN that mak= es IP flow mobility decisions and communicates them explicitly (with well d= efined signalling) to the LMA, and therefore no magic is needed. There is n= o need in 3GPP to have the ANDSF and PDN GW policies synchronized, since the PDN GW does not use such polic= ies.

Sri, in the end it is a matter of whether we develop a solution that will r= ely on some unknown magic to be deployed, or a solution that we know can be= deployed in at least one way because there are solutions to what I conside= r major open issues.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli <sgundave@cisco.com> wrote:

Hi Stefano,

Thanks for the discussion.

As you say, the ANDSF policies are allowing the MN a.) to make the right ne= twork attachment decision and b.) make the access selection on a flow basis= . This same policy that is present in the ANDSF server, is available for th= e network nodes as well. I’m not sure, with out this assumption the solution can work for all currently lis= ted cases. We clearly need the MN and the LMA to be in synch with respect t= o the configured policy. How, that is done, I guess we will not try to know= .  I thought even in 3GPP, this is the implied assumption ? But, this is for you to clarify. Not specifica= lly for IFOM where UE and PDN GW/HA are negotiating the flow policies, but = generally that the PDN GW and the ANDSF policy server will have synchronize= d policies. The MAG and the LMA have the ability to carry this flow policy information in signaling messag= es and influence the access selection. The policy is a opaque object, with = extensible formats, when carried in the signaling plane, should allow the L= MA/MAG to apply those access policies, while assuming MN is following the same rules. These policies can surely r= eflect the specific WLAN access/operator specific rule. I’m surely wi= th you, the lack of MN-AR interface is surely an issue and I see that. But,= we need to understand, what are the limitations with the approach of  out of band policy interfaces and what will be = the solution limitations. If we need to tie the flow movement at the prefix= granularity and rely on the natural ND interface in the form of RA PIO opt= ion, more like PDN offload in MAPCON, or at the granularity of a flow level, is open for discussion. I want to s= implify this draft for sure, we can surely discuss each of these issues on = the WG draft.


Regards
Sri






On 2/1/11 8:29 PM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com> > wrote:

Sri,
thanks for the reply.

I'd like to comment on the "the flow policy dec= isions need not be based on the specific WLAN network". Does it mean, = as I believe it does, that the current solution would not allow an operator deploying such solution to decide to route flows over a specific = WLAN or not depending on which specific WLAN the MN is connected to? E.g. t= he operator or the entity in control of the decisions for the routing may w= ant to direct certain traffic always over WLANs that the operator deploys, and instead route only some of the t= raffic over WLANs of roaming partners or of the MN user home. How does this= solution support that scenario if the LMA is not told specifically which W= LAN the MN is connected to? From a deployment point of view, I do not believe we can afford to leave out th= is scenario. Please note that the establishment of a security relationship = between the MN and the MAG, and a specific MAG identity, cannot guarantee t= hat the LMA knows which specific WLAN access network the MN is connected to. Assuming that would severely r= estrict the deployment scenarios.

As for the MN and the LMA being magically in synch, I am very concerned abo= ut a "glass ball" solution. You mention ANDSF defined by 3GPP as = a solution for this "out of band" delivery of policy. Fair enough= , however there is an issue with that. ANDSF is designed specific to be a MN-centric solution where policies are provisioned in the= MN and the MN decides which network technologies and access networks it ne= eds to connect to, under what conditions, and which IP traffic needs to be = routed on such accesses. No IP point of attachment in the network (i.e. the PDN GW in 3GPP that is the LMA in P= MIPv6) is aware under any conditions of such policy. Therefore, even if in = order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would un= fortunately not provide a solution unless the MN can communicate to the MAG and the LMA the decisions the MN = has taken based on the ANDSF policies.

I believe the key point here is that we need to understand how the solution= can be realistically applied to a real scenario, and that we need to ensur= e that important and realistic deployment scenarios are not excluded by the= solution.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli <sgundave@cisco.com <htt= p://sgundave@cisco.com> > wrote:

Hi Stefano:

These are valid points and some good comments. Let me share my thoughts.
Carlo’s draft is not assuming any new MN-AR interface. Its going with= the assumption there is established policy on the mobile and on the LMA, w= hich allows the mobile to select the access network at a flow level granula= rity, without requiring any explicit signaling between the MAG and the MN. To large part this is all about out of band po= licy interface, such as ANDSF, towards the UE, leading to the assumption th= at magically the MN and the LMA are in sync with respect to flow policies, = access selection and they will make the right forwarding decision. Secondly, the flow policy decisions need no= t be based on the specific WLAN network, but it is implicitly driven by the= MAG – LMA security relation, where the MAG attachment to the WLAN ne= twork transitively allows the LMA to make the flow policy decisions based on the MAG identity. If the WLAN network i= s not trusted, there is truly no MAG in that network, where the LMA shares = a security relation with that node.

There are still some open issues on this draft that needs to be discussed i= n the WG.  On the approaches to allow more a flow aggregate movement, = that is a discussion point. There are issues that we need to discuss, suppo= rting split link model, or eliminating some favorite brand of signaling message (FMA) and riding on PBU/PBA and j= ust with one FMI trigger, and on the aspects around MN applying the flow po= licies by flow mirroring. We have no agreement on those issues yet.

Its just a base draft, for further discussion and resolving those issues. B= ut, hope that is not a stopper for base draft selection.
 

Sri






On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com>  <http://sfaccinstd@gmail.com> > wrote:

Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicat= e to the network where the flows should be routed or for the LMA to receive= somehow from somewhere some policies, the solution cannot really provide flow mobility since there is no way to = decide which flows are routed where. If we are thinking about a host-based = solution, I have not yet seen a solution as to how the host can indicate to= the MAG and ultimately to the MAG which flows should be routed on each access. If we are relying on modifica= tions of layer 2 protocols, aren't we defining a solution that works only w= ith some technologies (since for other access technologies it is rather unr= ealistic to modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-based solution, can we he= ar of at least one example of a real-life scenario where the LMA would rece= ive such policies, and how such delivery would happen? Also, should there b= e a solution to have policies in the LMA, how does the LMA actually decide to route flows on one access or = the other? E.g., if some flows need to be routed on certain WLAN networks, = but shall not be routed on other WLAN networks, how does the LMA know which= specific WLAN network the host is connected to? Perhaps I missed the ability for the MAG to know e.g. the= WLAN SSID and provide it to the LMA, in which case I would appreciate if s= omebody could highlight to me where that is defined.

I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important.

Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM,  <Basavaraj.Patil@nokia.com <http://Basavaraj.Patil@nokia.com>  <http://Basavaraj.Patil@nokia.com> > wrote:


Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= br> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= br> developed further based on input and feedback from WG members.

-Basavaraj

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

 

 

 

--_000_E5E9FF33C2A27043B3BC96FE5A5160F1019E7Fnasanexd01enaqual_-- From sfaccin@rim.com Wed Feb 2 23:02:09 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFA373A6870 for ; Wed, 2 Feb 2011 23:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.652 X-Spam-Level: X-Spam-Status: No, score=-5.652 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwEGZtGKp7+v for ; Wed, 2 Feb 2011 23:01:51 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 141BB3A688B for ; Wed, 2 Feb 2011 23:01:50 -0800 (PST) X-AuditID: 0a666446-b7b07ae0000009cd-e7-4d4a53a7361d Received: from XCH139CNC.rim.net ( [10.65.10.235]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 3C.BB.02509.7A35A4D4; Thu, 3 Feb 2011 02:05:11 -0500 (EST) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH139CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Feb 2011 02:05:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBC370.B2E458E7" Date: Thu, 3 Feb 2011 01:05:11 -0600 Message-ID: <680854867F7FD04BB9B06EB8ACA8D5AC0465FAB1@XCH02DFW.rim.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLwmpURzmRlysrlUidlexdQorGZJPuBh2AgAAR4ICAAAzJgIAACkaAgADJ5gCAAKKGAP//oT5wgAAf2Nw= From: "Stefano Faccin" To: , , X-OriginalArrivalTime: 03 Feb 2011 07:05:11.0343 (UTC) FILETIME=[B2C883F0:01CBC370] X-Brightmail-Tracker: AAAAAwAAAZEXVB72F1TWuQ== Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 03 Feb 2011 07:02:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC370.B2E458E7 Content-Type: text/plain; charset="UTF-8" content-transfer-encoding: base64 SGVsbG8gU3JpLA0KRnJvbSBhIHBvaW50IG9mIHZpZXcgb2YgYXBwbGljYWJpbGl0eSBvZiB0 aGUgc29sdXRpb24sIEkgbXVzdCBhZ3JlZSB3aXRoIEdlcmFyZG8gdGhhdCBhc3N1bWluZyBz eW5jaHJvbml6YXRpb24gb2YgcG9saWNpZXMgaXMgYW4gaXNzdWUgb2YgdGhpcyBzb2x1dGlv biBzaW5jZSBpdCBjb21lcyB3aXRoIGEgc2V0IG9mIHJlc3RyaWN0aW9ucyBvbiBob3cgdGhl IHNvbHV0aW9uIGNhbiBiZSBhcHBsaWVkLg0KQ2hlZXJzLA0KU3RlZmFubw0KDQpTdGVmYW5v IA0KU3RlZmFubyBNLiBGYWNjaW4gDQoNClN0YW5kYXJkcyBNYW5hZ2VyIA0KUmVzZWFyY2gg SW4gTW90aW9uIA0KMTIyIFdlc3QgSm9obiBDYXJwZW50ZXIgUGFya3dheSANCklydmluZywg VFggNzUwMzkgDQpJbnRlcm5hbDogODIwIDYzNDUxIA0KRGVzazogKzEgOTcyIDkxMCAzNDUx IA0KQmxhY2tCZXJyeTogKzEgNTEwIDIzMCA4NDIyIA0Kc2ZhY2NpbkByaW0uY29tIA0KVGlt ZSB6b25lOiBQU1QgKEdNVCAtOCkNCiANCg0KRnJvbTogR2lhcmV0dGEsIEdlcmFyZG8gW21h aWx0bzpnZXJhcmRvZ0BxdWFsY29tbS5jb21dIA0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFy eSAwMiwgMjAxMSAxMToxMyBQTQ0KVG86IFNyaSBHdW5kYXZlbGxpIDxzZ3VuZGF2ZUBjaXNj by5jb20+OyBzdGVmYW5vIGZhY2NpbiA8c2ZhY2NpbnN0ZEBnbWFpbC5jb20+IA0KQ2M6IG5l dGV4dEBpZXRmLm9yZyA8bmV0ZXh0QGlldGYub3JnPjsgQmFzYXZhcmFqLlBhdGlsQG5va2lh LmNvbSA8QmFzYXZhcmFqLlBhdGlsQG5va2lhLmNvbT4gDQpTdWJqZWN0OiBSZTogW25ldGV4 dF0gQ29uc2Vuc3VzIGNhbGwgdG8gYWRvcHQgSS1EOiBkcmFmdC1iZXJuYXJkb3MtbmV0ZXh0 LXBtaXB2Ni1mbG93bW9iIGFzIFdHIGRvYyANCiANCg0KDQpIaSBTcmksDQoNCiANCg0KVGhl cmUgaXMgbm8gaW1wbGljaXQgYXNzdW1wdGlvbiBvZiBzeW5jaHJvbml6ZWQgcG9saWNpZXMu IEEgYmFzaWMgZXhhbXBsZSB0aGF0IHNob3dzIHRoYXQgdGhlcmUgaXMgbm8gYXNzdW1wdGlv biBpcyB0aGUgZm9sbG93aW5nOiBBTkRTRiBwb2xpY2llcyBtYXkgYmUgYmFzZWQgYWxzbyBv biBsb2NhdGlvbiBvZiB0aGUgVUUuIEZvciBleGFtcGxlIHRoZSBVRSBzaG91bGQgcHJlZmVy IFdMQU4gb25seSBpbiBhIGdpdmVuIGxvY2F0aW9uLiBXaGVuIHRoZSBVRSBpcyBhdHRhY2hl ZCBvdmVyIFdMQU4gdGhlcmUgaXMgbm8gd2F5IGZvciB0aGUgUEROR1cvSEEgdG8gdmVyaWZ5 IHRoZSBsb2NhdGlvbiBvZiB0aGUgVUUgYW5kIHRoZXJlZm9yZSB0byB2ZXJpZnkgVUUgYWN0 aW9ucyBiYXNlZCBvbiBwb2xpY2llcy4NCg0KIA0KDQpUaGUgYXNzdW1wdGlvbiBvbiBzeW5j aHJvbml6YXRpb24gb2YgcG9saWNpZXMgaXMgb25seSBhcHBsaWNhYmxlIHRvIHRoaXMgZHJh ZnQgYW5kIEkgdGhpbmsgaXQgaXMgYSB3cm9uZyBvbmUuIA0KDQogDQoNCkNoZWVycw0KDQpH ZXJhcmRvDQoNCiANCg0KRnJvbTogbmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpu ZXRleHQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNyaSBHdW5kYXZlbGxpDQpT ZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDAyLCAyMDExIDY6NTAgUE0NClRvOiBzdGVmYW5v IGZhY2Npbg0KQ2M6IG5ldGV4dEBpZXRmLm9yZzsgQmFzYXZhcmFqLlBhdGlsQG5va2lhLmNv bQ0KU3ViamVjdDogUmU6IFtuZXRleHRdIENvbnNlbnN1cyBjYWxsIHRvIGFkb3B0IEktRDog ZHJhZnQtYmVybmFyZG9zLW5ldGV4dC1wbWlwdjYtZmxvd21vYiBhcyBXRyBkb2MNCg0KIA0K DQpIaSBTdGVmYW5vLA0KDQpPbmUgY29tbWVudC4NCg0KQWdyZWUgd2l0aCB5b3UgdGhlcmUg aXMgbm8gQU5EU0YgaW50ZXJmYWNlIHRvIHRoZSBuZXR3b3JrIG5vZGUsIGJ1dCB0aGUgYXNz dW1wdGlvbiBvZiBzeW5jaHJvbml6ZWQgcG9saWNpZXMgYmV0d2VlbiB0aGUgQU5EU0Ygc2Vy dmVyIGFuZCB0aGUgUEROIEdXL0hBIGlzIHRoZXJlLCBpbXBsaWNpdGx5IElNTy4gV2l0aCBv dXQgdGhpcyBhc3N1bXB0aW9uLCBJIGRvIG5vdCBrbm93LCBob3cgdGhlIEhBIGNhbiBldmVy IHZhbGlkYXRlIHRoZSBmbG93IG1vYmlsaXR5IG9wdGlvbnMgcmVjZWl2ZWQgaW4gdGhlIEJV LiBJZiB0aGUgb3BlcmF0b3IgcmVxdWlyZXMgYW55IGNvbnRyb2wgb24gZW5mb3JjaW5nIGEg ZmxvdyBwb2xpY3kgcnVsZSwgdGhlIFBETiBHVy9IQSBuZWVkcyB0byBoYXZlIHN5bmNocm9u aXplZCBwb2xpY2llcywgd2l0aG91dCB3aGljaCBpdHMgYWx3YXlzIHRoZSBjbGllbnQgZGVj aXNpb24uIEnigJltIG5vdCBzdXJlLCBvcGVyYXRvcnMgaW4gM0dQUCB3b3VsZCBsaWtlIHRo YXQgOikgDQoNCk5vIGRvdWJ0LCB0aGUgbGFjayBvZiBNTi1BUiBpbnRlcmZhY2UgaXMgc3Vy ZWx5IGFuIGlzc3VlIGZvciBzdXBwb3J0aW5nIGNvbXBsZXggZmxvdyBwb2xpY2llcy4gSSBy ZWFsaXplIHRoZSBpc3N1ZXMgYW5kIEkgYWdyZWUgd2l0aCB5b3UuIEJ1dCwgdGhlIGFzc3Vt cHRpb24gb2Ygc3luY2hyb25pemVkIHBvbGljaWVzIGNhbiBvZmZlciBzb21lIHNvbHV0aW9u IHdpdGggc29tZSBjb25maWd1cmF0aW9uIHJlcXVpcmVtZW50IG9uIHRoZSBIQSAoYXNzdW1p bmcgdGhlcmUgYXJlIG5vIG90aGVyIGlzc3VlcykuIFRoZXJlIGFyZSBhbHNvIHRoZSBwcm9w b3NhbHMgb24gZmxvdyBtaXJyb3Jpbmcgb24gdGhlIFVFIC4uLiwgcmVxdWlyaW5nIG5vIGZs b3cgcG9saWNpZXMuIEnigJl2ZSBub3QgZXZhbHVhdGVkIHRoaXMsIGhvd2V2ZXIuIEZvbGtz IGNhbiBjb21tZW50IG9uIHRoaXMuDQoNCkl0IGlzIGFsc28gdG8gYmUgbm90ZWQsIGZvciBz b21lIG9mIHRoZSBzY2VuYXJpb3Mgc3VjaCwgdGhlcmUgaXMgbm8gZmxvdyBwb2xpY3kgaW50 ZXJmYWNlIG5lZWRlZC4gV2UgY2FuIGlkZW50aWZ5IHdoYXQgc2NlbmFyaW9zIGNyZWF0ZSBh bnkgY29uZmlndXJhdGlvbiBsaW1pdGF0aW9ucyBvbiB0aGUgSEEgYW5kIHdoaWNoIG9uZeKA mXMgZG8gbm90IC4gQXMgSeKAmXZlIG5vdGVkIGVhcmxpZXIsIHRoaXMgaXMgc3VyZWx5IGFu IG9wZW4gaXNzdWUsIHRoYXQgd2UgbmVlZCB0byBkaXNjdXNzIGluIHRoZSBXRy4gDQoNCg0K DQpSZWdhcmRzDQpTcmkNCg0KDQoNCg0KIA0KDQoNCk9uIDIvMi8xMSA5OjA4IEFNLCAic3Rl ZmFubyBmYWNjaW4iIDxzZmFjY2luc3RkQGdtYWlsLmNvbT4gd3JvdGU6DQoNClNyaSwNCnRo YW5rcyBmb3IgdGhlIHJlcGx5LiBDYW4geW91IGNsYXJpZnkgaW4gd2hpY2ggc3lzdGVtIG9y IHNjZW5hcmlvIEFORFNGIGlzIGF2YWlsYWJsZSB0byBuZXR3b3JrIGVudGl0aWVzIGFzIHdl bGw/IFRoZXJlIGlzIG5vIHN1Y2ggYXZhaWxhYmlsaXR5IGluIDNHUFAsIGFuZCBtYWtpbmcg c3VjaCBpbmZvcm1hdGlvbiBhdmFpbGFibGUgd291bGQgcmVxdWlyZSBjb25zaWRlcmFibGUg YXJjaGl0ZWN0dXJhbCBjaGFuZ2VzLCB0aGVyZWZvcmUgdGhlIGFwcGxpY2FiaWxpdHkgb2Yg dGhpcyBzb2x1dGlvbiB0byB3aGF0IHNlZW1zIHRvIGJlIHRoZSBvbmx5IHJlYWxpc3RpYyBz Y2VuYXJpbyBoaW5nZXMgb24gM0dQUCBtYWtpbmcgY29uc2lkZXJhYmxlIGFyY2hpdGVjdHVy YWwgY2hhbmdlcy4gSSB3b3VsZCB0aGVyZWZvcmUgbm90IGJlIHNvIGhhc3RpbHkgY29uY2x1 ZGluZyB0aGF0IHRoZSBBTkRTRiBpbmZvcm1hdGlvbiBpcyBhdmFpbGFibGUgdG8gdGhlIExN QSBhbmQgdW5kZXJlc3RpbWF0ZSB3aGF0IGl0IHdvdWxkIHJlYWxseSB0YWtlIHRvIG1ha2Ug dGhlIHNvbHV0aW9uIGFwcGxpY2FibGUuDQoNCklmIHdlIGNhbm5vdCBndWFyYW50ZWUgdGhh dCB0aGVyZSBpcyBhdCBsZWFzdCBvbmUgcmVhbGlzdGljIHNvbHV0aW9uIHRvIGhhdmUgdGhl IE1OYSBuZCBMTUEgaW4gc3luY2gsIGhvdyBkbyB3ZSBleHBlY3QgdGhhdCB0aGlzIHNvbHV0 aW9uIGlzIGFwcGxpY2FibGUgYXQgYWxsPyBJbiAzR1BQIHRoZXJlIGlzIG5vIG5lZWQgdG8g aGF2ZSBzdWNoIGltcGxpY2l0IGFzc3VtcHRpb24sIGJlIGNhdXNlIDEpIHRoZSBNTiBpcyBw cm92aWRlZCBwb2xpY2llcyBleHBsaWNpdGx5IHRocm91Z2ggdGhlIEFORFNGLCBhbmQgMikg aXQgaXMgdGhlIE1OIGFuZCBvbmx5IHRoZSBNTiB0aGF0IG1ha2VzIElQIGZsb3cgbW9iaWxp dHkgZGVjaXNpb25zIGFuZCBjb21tdW5pY2F0ZXMgdGhlbSBleHBsaWNpdGx5ICh3aXRoIHdl bGwgZGVmaW5lZCBzaWduYWxsaW5nKSB0byB0aGUgTE1BLCBhbmQgdGhlcmVmb3JlIG5vIG1h Z2ljIGlzIG5lZWRlZC4gVGhlcmUgaXMgbm8gbmVlZCBpbiAzR1BQIHRvIGhhdmUgdGhlIEFO RFNGIGFuZCBQRE4gR1cgcG9saWNpZXMgc3luY2hyb25pemVkLCBzaW5jZSB0aGUgUEROIEdX IGRvZXMgbm90IHVzZSBzdWNoIHBvbGljaWVzLiANCg0KU3JpLCBpbiB0aGUgZW5kIGl0IGlz IGEgbWF0dGVyIG9mIHdoZXRoZXIgd2UgZGV2ZWxvcCBhIHNvbHV0aW9uIHRoYXQgd2lsbCBy ZWx5IG9uIHNvbWUgdW5rbm93biBtYWdpYyB0byBiZSBkZXBsb3llZCwgb3IgYSBzb2x1dGlv biB0aGF0IHdlIGtub3cgY2FuIGJlIGRlcGxveWVkIGluIGF0IGxlYXN0IG9uZSB3YXkgYmVj YXVzZSB0aGVyZSBhcmUgc29sdXRpb25zIHRvIHdoYXQgSSBjb25zaWRlciBtYWpvciBvcGVu IGlzc3Vlcy4NCg0KQ2hlZXJzLA0KU3RlZmFubw0KDQpPbiBUdWUsIEZlYiAxLCAyMDExIGF0 IDk6MDYgUE0sIFNyaSBHdW5kYXZlbGxpIDxzZ3VuZGF2ZUBjaXNjby5jb20+IHdyb3RlOg0K DQpIaSBTdGVmYW5vLA0KDQpUaGFua3MgZm9yIHRoZSBkaXNjdXNzaW9uLg0KDQpBcyB5b3Ug c2F5LCB0aGUgQU5EU0YgcG9saWNpZXMgYXJlIGFsbG93aW5nIHRoZSBNTiBhLikgdG8gbWFr ZSB0aGUgcmlnaHQgbmV0d29yayBhdHRhY2htZW50IGRlY2lzaW9uIGFuZCBiLikgbWFrZSB0 aGUgYWNjZXNzIHNlbGVjdGlvbiBvbiBhIGZsb3cgYmFzaXMuIFRoaXMgc2FtZSBwb2xpY3kg dGhhdCBpcyBwcmVzZW50IGluIHRoZSBBTkRTRiBzZXJ2ZXIsIGlzIGF2YWlsYWJsZSBmb3Ig dGhlIG5ldHdvcmsgbm9kZXMgYXMgd2VsbC4gSeKAmW0gbm90IHN1cmUsIHdpdGggb3V0IHRo aXMgYXNzdW1wdGlvbiB0aGUgc29sdXRpb24gY2FuIHdvcmsgZm9yIGFsbCBjdXJyZW50bHkg bGlzdGVkIGNhc2VzLiBXZSBjbGVhcmx5IG5lZWQgdGhlIE1OIGFuZCB0aGUgTE1BIHRvIGJl IGluIHN5bmNoIHdpdGggcmVzcGVjdCB0byB0aGUgY29uZmlndXJlZCBwb2xpY3kuIEhvdywg dGhhdCBpcyBkb25lLCBJIGd1ZXNzIHdlIHdpbGwgbm90IHRyeSB0byBrbm93LiAgSSB0aG91 Z2h0IGV2ZW4gaW4gM0dQUCwgdGhpcyBpcyB0aGUgaW1wbGllZCBhc3N1bXB0aW9uID8gQnV0 LCB0aGlzIGlzIGZvciB5b3UgdG8gY2xhcmlmeS4gTm90IHNwZWNpZmljYWxseSBmb3IgSUZP TSB3aGVyZSBVRSBhbmQgUEROIEdXL0hBIGFyZSBuZWdvdGlhdGluZyB0aGUgZmxvdyBwb2xp Y2llcywgYnV0IGdlbmVyYWxseSB0aGF0IHRoZSBQRE4gR1cgYW5kIHRoZSBBTkRTRiBwb2xp Y3kgc2VydmVyIHdpbGwgaGF2ZSBzeW5jaHJvbml6ZWQgcG9saWNpZXMuIFRoZSBNQUcgYW5k IHRoZSBMTUEgaGF2ZSB0aGUgYWJpbGl0eSB0byBjYXJyeSB0aGlzIGZsb3cgcG9saWN5IGlu Zm9ybWF0aW9uIGluIHNpZ25hbGluZyBtZXNzYWdlcyBhbmQgaW5mbHVlbmNlIHRoZSBhY2Nl c3Mgc2VsZWN0aW9uLiBUaGUgcG9saWN5IGlzIGEgb3BhcXVlIG9iamVjdCwgd2l0aCBleHRl bnNpYmxlIGZvcm1hdHMsIHdoZW4gY2FycmllZCBpbiB0aGUgc2lnbmFsaW5nIHBsYW5lLCBz aG91bGQgYWxsb3cgdGhlIExNQS9NQUcgdG8gYXBwbHkgdGhvc2UgYWNjZXNzIHBvbGljaWVz LCB3aGlsZSBhc3N1bWluZyBNTiBpcyBmb2xsb3dpbmcgdGhlIHNhbWUgcnVsZXMuIFRoZXNl IHBvbGljaWVzIGNhbiBzdXJlbHkgcmVmbGVjdCB0aGUgc3BlY2lmaWMgV0xBTiBhY2Nlc3Mv b3BlcmF0b3Igc3BlY2lmaWMgcnVsZS4gSeKAmW0gc3VyZWx5IHdpdGggeW91LCB0aGUgbGFj ayBvZiBNTi1BUiBpbnRlcmZhY2UgaXMgc3VyZWx5IGFuIGlzc3VlIGFuZCBJIHNlZSB0aGF0 LiBCdXQsIHdlIG5lZWQgdG8gdW5kZXJzdGFuZCwgd2hhdCBhcmUgdGhlIGxpbWl0YXRpb25z IHdpdGggdGhlIGFwcHJvYWNoIG9mICBvdXQgb2YgYmFuZCBwb2xpY3kgaW50ZXJmYWNlcyBh bmQgd2hhdCB3aWxsIGJlIHRoZSBzb2x1dGlvbiBsaW1pdGF0aW9ucy4gSWYgd2UgbmVlZCB0 byB0aWUgdGhlIGZsb3cgbW92ZW1lbnQgYXQgdGhlIHByZWZpeCBncmFudWxhcml0eSBhbmQg cmVseSBvbiB0aGUgbmF0dXJhbCBORCBpbnRlcmZhY2UgaW4gdGhlIGZvcm0gb2YgUkEgUElP IG9wdGlvbiwgbW9yZSBsaWtlIFBETiBvZmZsb2FkIGluIE1BUENPTiwgb3IgYXQgdGhlIGdy YW51bGFyaXR5IG9mIGEgZmxvdyBsZXZlbCwgaXMgb3BlbiBmb3IgZGlzY3Vzc2lvbi4gSSB3 YW50IHRvIHNpbXBsaWZ5IHRoaXMgZHJhZnQgZm9yIHN1cmUsIHdlIGNhbiBzdXJlbHkgZGlz Y3VzcyBlYWNoIG9mIHRoZXNlIGlzc3VlcyBvbiB0aGUgV0cgZHJhZnQuDQoNCg0KUmVnYXJk cw0KU3JpDQoNCg0KDQoNCg0KDQpPbiAyLzEvMTEgODoyOSBQTSwgInN0ZWZhbm8gZmFjY2lu IiA8c2ZhY2NpbnN0ZEBnbWFpbC5jb20gPGh0dHA6Ly9zZmFjY2luc3RkQGdtYWlsLmNvbT4g PiB3cm90ZToNCg0KU3JpLA0KdGhhbmtzIGZvciB0aGUgcmVwbHkuDQoNCkknZCBsaWtlIHRv IGNvbW1lbnQgb24gdGhlICJ0aGUgZmxvdyBwb2xpY3kgZGVjaXNpb25zIG5lZWQgbm90IGJl IGJhc2VkIG9uIHRoZSBzcGVjaWZpYyBXTEFOIG5ldHdvcmsiLiBEb2VzIGl0IG1lYW4sIGFz IEkgYmVsaWV2ZSBpdCBkb2VzLCB0aGF0IHRoZSBjdXJyZW50IHNvbHV0aW9uIHdvdWxkIG5v dCBhbGxvdyBhbiBvcGVyYXRvciBkZXBsb3lpbmcgc3VjaCBzb2x1dGlvbiB0byBkZWNpZGUg dG8gcm91dGUgZmxvd3Mgb3ZlciBhIHNwZWNpZmljIFdMQU4gb3Igbm90IGRlcGVuZGluZyBv biB3aGljaCBzcGVjaWZpYyBXTEFOIHRoZSBNTiBpcyBjb25uZWN0ZWQgdG8/IEUuZy4gdGhl IG9wZXJhdG9yIG9yIHRoZSBlbnRpdHkgaW4gY29udHJvbCBvZiB0aGUgZGVjaXNpb25zIGZv ciB0aGUgcm91dGluZyBtYXkgd2FudCB0byBkaXJlY3QgY2VydGFpbiB0cmFmZmljIGFsd2F5 cyBvdmVyIFdMQU5zIHRoYXQgdGhlIG9wZXJhdG9yIGRlcGxveXMsIGFuZCBpbnN0ZWFkIHJv dXRlIG9ubHkgc29tZSBvZiB0aGUgdHJhZmZpYyBvdmVyIFdMQU5zIG9mIHJvYW1pbmcgcGFy dG5lcnMgb3Igb2YgdGhlIE1OIHVzZXIgaG9tZS4gSG93IGRvZXMgdGhpcyBzb2x1dGlvbiBz dXBwb3J0IHRoYXQgc2NlbmFyaW8gaWYgdGhlIExNQSBpcyBub3QgdG9sZCBzcGVjaWZpY2Fs bHkgd2hpY2ggV0xBTiB0aGUgTU4gaXMgY29ubmVjdGVkIHRvPyBGcm9tIGEgZGVwbG95bWVu dCBwb2ludCBvZiB2aWV3LCBJIGRvIG5vdCBiZWxpZXZlIHdlIGNhbiBhZmZvcmQgdG8gbGVh dmUgb3V0IHRoaXMgc2NlbmFyaW8uIFBsZWFzZSBub3RlIHRoYXQgdGhlIGVzdGFibGlzaG1l bnQgb2YgYSBzZWN1cml0eSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgTU4gYW5kIHRoZSBN QUcsIGFuZCBhIHNwZWNpZmljIE1BRyBpZGVudGl0eSwgY2Fubm90IGd1YXJhbnRlZSB0aGF0 IHRoZSBMTUEga25vd3Mgd2hpY2ggc3BlY2lmaWMgV0xBTiBhY2Nlc3MgbmV0d29yayB0aGUg TU4gaXMgY29ubmVjdGVkIHRvLiBBc3N1bWluZyB0aGF0IHdvdWxkIHNldmVyZWx5IHJlc3Ry aWN0IHRoZSBkZXBsb3ltZW50IHNjZW5hcmlvcy4NCg0KQXMgZm9yIHRoZSBNTiBhbmQgdGhl IExNQSBiZWluZyBtYWdpY2FsbHkgaW4gc3luY2gsIEkgYW0gdmVyeSBjb25jZXJuZWQgYWJv dXQgYSAiZ2xhc3MgYmFsbCIgc29sdXRpb24uIFlvdSBtZW50aW9uIEFORFNGIGRlZmluZWQg YnkgM0dQUCBhcyBhIHNvbHV0aW9uIGZvciB0aGlzICJvdXQgb2YgYmFuZCIgZGVsaXZlcnkg b2YgcG9saWN5LiBGYWlyIGVub3VnaCwgaG93ZXZlciB0aGVyZSBpcyBhbiBpc3N1ZSB3aXRo IHRoYXQuIEFORFNGIGlzIGRlc2lnbmVkIHNwZWNpZmljIHRvIGJlIGEgTU4tY2VudHJpYyBz b2x1dGlvbiB3aGVyZSBwb2xpY2llcyBhcmUgcHJvdmlzaW9uZWQgaW4gdGhlIE1OIGFuZCB0 aGUgTU4gZGVjaWRlcyB3aGljaCBuZXR3b3JrIHRlY2hub2xvZ2llcyBhbmQgYWNjZXNzIG5l dHdvcmtzIGl0IG5lZWRzIHRvIGNvbm5lY3QgdG8sIHVuZGVyIHdoYXQgY29uZGl0aW9ucywg YW5kIHdoaWNoIElQIHRyYWZmaWMgbmVlZHMgdG8gYmUgcm91dGVkIG9uIHN1Y2ggYWNjZXNz ZXMuIE5vIElQIHBvaW50IG9mIGF0dGFjaG1lbnQgaW4gdGhlIG5ldHdvcmsgKGkuZS4gdGhl IFBETiBHVyBpbiAzR1BQIHRoYXQgaXMgdGhlIExNQSBpbiBQTUlQdjYpIGlzIGF3YXJlIHVu ZGVyIGFueSBjb25kaXRpb25zIG9mIHN1Y2ggcG9saWN5LiBUaGVyZWZvcmUsIGV2ZW4gaWYg aW4gb3JkZXIgdG8gYXBwbHkgdGhpcyBzb2x1dGlvbiB0byAzR1BQIHdlIHdhbnRlZCB0byB1 c2UgQU5EU0YsIEFORFNGIHdvdWxkIHVuZm9ydHVuYXRlbHkgbm90IHByb3ZpZGUgYSBzb2x1 dGlvbiB1bmxlc3MgdGhlIE1OIGNhbiBjb21tdW5pY2F0ZSB0byB0aGUgTUFHIGFuZCB0aGUg TE1BIHRoZSBkZWNpc2lvbnMgdGhlIE1OIGhhcyB0YWtlbiBiYXNlZCBvbiB0aGUgQU5EU0Yg cG9saWNpZXMuDQoNCkkgYmVsaWV2ZSB0aGUga2V5IHBvaW50IGhlcmUgaXMgdGhhdCB3ZSBu ZWVkIHRvIHVuZGVyc3RhbmQgaG93IHRoZSBzb2x1dGlvbiBjYW4gYmUgcmVhbGlzdGljYWxs eSBhcHBsaWVkIHRvIGEgcmVhbCBzY2VuYXJpbywgYW5kIHRoYXQgd2UgbmVlZCB0byBlbnN1 cmUgdGhhdCBpbXBvcnRhbnQgYW5kIHJlYWxpc3RpYyBkZXBsb3ltZW50IHNjZW5hcmlvcyBh cmUgbm90IGV4Y2x1ZGVkIGJ5IHRoZSBzb2x1dGlvbi4NCg0KQ2hlZXJzLA0KU3RlZmFubw0K DQpPbiBUdWUsIEZlYiAxLCAyMDExIGF0IDc6NDMgUE0sIFNyaSBHdW5kYXZlbGxpIDxzZ3Vu ZGF2ZUBjaXNjby5jb20gPGh0dHA6Ly9zZ3VuZGF2ZUBjaXNjby5jb20+ID4gd3JvdGU6DQoN CkhpIFN0ZWZhbm86DQoNClRoZXNlIGFyZSB2YWxpZCBwb2ludHMgYW5kIHNvbWUgZ29vZCBj b21tZW50cy4gTGV0IG1lIHNoYXJlIG15IHRob3VnaHRzLg0KDQpDYXJsb+KAmXMgZHJhZnQg aXMgbm90IGFzc3VtaW5nIGFueSBuZXcgTU4tQVIgaW50ZXJmYWNlLiBJdHMgZ29pbmcgd2l0 aCB0aGUgYXNzdW1wdGlvbiB0aGVyZSBpcyBlc3RhYmxpc2hlZCBwb2xpY3kgb24gdGhlIG1v YmlsZSBhbmQgb24gdGhlIExNQSwgd2hpY2ggYWxsb3dzIHRoZSBtb2JpbGUgdG8gc2VsZWN0 IHRoZSBhY2Nlc3MgbmV0d29yayBhdCBhIGZsb3cgbGV2ZWwgZ3JhbnVsYXJpdHksIHdpdGhv dXQgcmVxdWlyaW5nIGFueSBleHBsaWNpdCBzaWduYWxpbmcgYmV0d2VlbiB0aGUgTUFHIGFu ZCB0aGUgTU4uIFRvIGxhcmdlIHBhcnQgdGhpcyBpcyBhbGwgYWJvdXQgb3V0IG9mIGJhbmQg cG9saWN5IGludGVyZmFjZSwgc3VjaCBhcyBBTkRTRiwgdG93YXJkcyB0aGUgVUUsIGxlYWRp bmcgdG8gdGhlIGFzc3VtcHRpb24gdGhhdCBtYWdpY2FsbHkgdGhlIE1OIGFuZCB0aGUgTE1B IGFyZSBpbiBzeW5jIHdpdGggcmVzcGVjdCB0byBmbG93IHBvbGljaWVzLCBhY2Nlc3Mgc2Vs ZWN0aW9uIGFuZCB0aGV5IHdpbGwgbWFrZSB0aGUgcmlnaHQgZm9yd2FyZGluZyBkZWNpc2lv bi4gU2Vjb25kbHksIHRoZSBmbG93IHBvbGljeSBkZWNpc2lvbnMgbmVlZCBub3QgYmUgYmFz ZWQgb24gdGhlIHNwZWNpZmljIFdMQU4gbmV0d29yaywgYnV0IGl0IGlzIGltcGxpY2l0bHkg ZHJpdmVuIGJ5IHRoZSBNQUcg4oCTIExNQSBzZWN1cml0eSByZWxhdGlvbiwgd2hlcmUgdGhl IE1BRyBhdHRhY2htZW50IHRvIHRoZSBXTEFOIG5ldHdvcmsgdHJhbnNpdGl2ZWx5IGFsbG93 cyB0aGUgTE1BIHRvIG1ha2UgdGhlIGZsb3cgcG9saWN5IGRlY2lzaW9ucyBiYXNlZCBvbiB0 aGUgTUFHIGlkZW50aXR5LiBJZiB0aGUgV0xBTiBuZXR3b3JrIGlzIG5vdCB0cnVzdGVkLCB0 aGVyZSBpcyB0cnVseSBubyBNQUcgaW4gdGhhdCBuZXR3b3JrLCB3aGVyZSB0aGUgTE1BIHNo YXJlcyBhIHNlY3VyaXR5IHJlbGF0aW9uIHdpdGggdGhhdCBub2RlLg0KDQpUaGVyZSBhcmUg c3RpbGwgc29tZSBvcGVuIGlzc3VlcyBvbiB0aGlzIGRyYWZ0IHRoYXQgbmVlZHMgdG8gYmUg ZGlzY3Vzc2VkIGluIHRoZSBXRy4gIE9uIHRoZSBhcHByb2FjaGVzIHRvIGFsbG93IG1vcmUg YSBmbG93IGFnZ3JlZ2F0ZSBtb3ZlbWVudCwgdGhhdCBpcyBhIGRpc2N1c3Npb24gcG9pbnQu IFRoZXJlIGFyZSBpc3N1ZXMgdGhhdCB3ZSBuZWVkIHRvIGRpc2N1c3MsIHN1cHBvcnRpbmcg c3BsaXQgbGluayBtb2RlbCwgb3IgZWxpbWluYXRpbmcgc29tZSBmYXZvcml0ZSBicmFuZCBv ZiBzaWduYWxpbmcgbWVzc2FnZSAoRk1BKSBhbmQgcmlkaW5nIG9uIFBCVS9QQkEgYW5kIGp1 c3Qgd2l0aCBvbmUgRk1JIHRyaWdnZXIsIGFuZCBvbiB0aGUgYXNwZWN0cyBhcm91bmQgTU4g YXBwbHlpbmcgdGhlIGZsb3cgcG9saWNpZXMgYnkgZmxvdyBtaXJyb3JpbmcuIFdlIGhhdmUg bm8gYWdyZWVtZW50IG9uIHRob3NlIGlzc3VlcyB5ZXQuDQoNCkl0cyBqdXN0IGEgYmFzZSBk cmFmdCwgZm9yIGZ1cnRoZXIgZGlzY3Vzc2lvbiBhbmQgcmVzb2x2aW5nIHRob3NlIGlzc3Vl cy4gQnV0LCBob3BlIHRoYXQgaXMgbm90IGEgc3RvcHBlciBmb3IgYmFzZSBkcmFmdCBzZWxl Y3Rpb24uDQogDQoNClNyaQ0KDQoNCg0KDQoNCg0KT24gMi8xLzExIDY6MzkgUE0sICJzdGVm YW5vIGZhY2NpbiIgPHNmYWNjaW5zdGRAZ21haWwuY29tIDxodHRwOi8vc2ZhY2NpbnN0ZEBn bWFpbC5jb20+ICA8aHR0cDovL3NmYWNjaW5zdGRAZ21haWwuY29tPiA+IHdyb3RlOg0KDQpS YWosDQp0aGFua3MgZm9yIHRoZSBlbWFpbC4NCg0KSSBuZWVkIHRvIGFwb2xvZ2l6ZSBpbiBh ZHZhbmNlIGlmIG15IHF1ZXN0aW9ucyBoYXZlIGFscmVhZHkgYmVlbiBhbnN3ZXJlZCBiZWZv cmUgKHRob3VnaCBJIGNhbm5vdCBmaW5kIGEgY29uY2x1c2l2ZSBhbnN3ZXIgYW55d2hlcmUp Lg0KDQpJIHRoaW5rIHRoYXQgYSBwcm90b2NvbCB0aGF0IGlzIGRldmVsb3BlZCBpbiBORVRF WFQgKG9yIG90aGVyIGdyb3Vwcykgc2hvdWxkIGhhdmUgYXQgbGVhc3QgYSBwb3RlbnRpYWwg cmVhbGlzdGljIHNjZW5hcmlvIGZvciBhcHBsaWNhYmlsaXR5Lg0KDQpJbiB0ZXJtcyBvZiBh cHBsaWNhYmlsaXR5LCB0aG91Z2ggaXQgaXMgbm90IHBhcnQgb2YgdGhlIHByb3RvY29sIGRl ZmluaXRpb24gcGVyIHNlLCB1bmxlc3MgdGhlcmUgYXJlIHNvbHV0aW9ucyBpbiBwbGFjZSBm b3IgZWl0aGVyIHRoZSBob3N0IHRvIGluZGljYXRlIHRvIHRoZSBuZXR3b3JrIHdoZXJlIHRo ZSBmbG93cyBzaG91bGQgYmUgcm91dGVkIG9yIGZvciB0aGUgTE1BIHRvIHJlY2VpdmUgc29t ZWhvdyBmcm9tIHNvbWV3aGVyZSBzb21lIHBvbGljaWVzLCB0aGUgc29sdXRpb24gY2Fubm90 IHJlYWxseSBwcm92aWRlIGZsb3cgbW9iaWxpdHkgc2luY2UgdGhlcmUgaXMgbm8gd2F5IHRv IGRlY2lkZSB3aGljaCBmbG93cyBhcmUgcm91dGVkIHdoZXJlLiBJZiB3ZSBhcmUgdGhpbmtp bmcgYWJvdXQgYSBob3N0LWJhc2VkIHNvbHV0aW9uLCBJIGhhdmUgbm90IHlldCBzZWVuIGEg c29sdXRpb24gYXMgdG8gaG93IHRoZSBob3N0IGNhbiBpbmRpY2F0ZSB0byB0aGUgTUFHIGFu ZCB1bHRpbWF0ZWx5IHRvIHRoZSBNQUcgd2hpY2ggZmxvd3Mgc2hvdWxkIGJlIHJvdXRlZCBv biBlYWNoIGFjY2Vzcy4gSWYgd2UgYXJlIHJlbHlpbmcgb24gbW9kaWZpY2F0aW9ucyBvZiBs YXllciAyIHByb3RvY29scywgYXJlbid0IHdlIGRlZmluaW5nIGEgc29sdXRpb24gdGhhdCB3 b3JrcyBvbmx5IHdpdGggc29tZSB0ZWNobm9sb2dpZXMgKHNpbmNlIGZvciBvdGhlciBhY2Nl c3MgdGVjaG5vbG9naWVzIGl0IGlzIHJhdGhlciB1bnJlYWxpc3RpYyB0byBtb2RpZnkgTDIg Zm9yIElQIGZsb3cgbW9iaWxpdHkgcHVycG9zZXMpPyBJZiB3ZSBhcmUgdGhpbmtpbmcgb2Yg YW4gTE1BLWJhc2VkIHNvbHV0aW9uLCBjYW4gd2UgaGVhciBvZiBhdCBsZWFzdCBvbmUgZXhh bXBsZSBvZiBhIHJlYWwtbGlmZSBzY2VuYXJpbyB3aGVyZSB0aGUgTE1BIHdvdWxkIHJlY2Vp dmUgc3VjaCBwb2xpY2llcywgYW5kIGhvdyBzdWNoIGRlbGl2ZXJ5IHdvdWxkIGhhcHBlbj8g QWxzbywgc2hvdWxkIHRoZXJlIGJlIGEgc29sdXRpb24gdG8gaGF2ZSBwb2xpY2llcyBpbiB0 aGUgTE1BLCBob3cgZG9lcyB0aGUgTE1BIGFjdHVhbGx5IGRlY2lkZSB0byByb3V0ZSBmbG93 cyBvbiBvbmUgYWNjZXNzIG9yIHRoZSBvdGhlcj8gRS5nLiwgaWYgc29tZSBmbG93cyBuZWVk IHRvIGJlIHJvdXRlZCBvbiBjZXJ0YWluIFdMQU4gbmV0d29ya3MsIGJ1dCBzaGFsbCBub3Qg YmUgcm91dGVkIG9uIG90aGVyIFdMQU4gbmV0d29ya3MsIGhvdyBkb2VzIHRoZSBMTUEga25v dyB3aGljaCBzcGVjaWZpYyBXTEFOIG5ldHdvcmsgdGhlIGhvc3QgaXMgY29ubmVjdGVkIHRv PyBQZXJoYXBzIEkgbWlzc2VkIHRoZSBhYmlsaXR5IGZvciB0aGUgTUFHIHRvIGtub3cgZS5n LiB0aGUgV0xBTiBTU0lEIGFuZCBwcm92aWRlIGl0IHRvIHRoZSBMTUEsIGluIHdoaWNoIGNh c2UgSSB3b3VsZCBhcHByZWNpYXRlIGlmIHNvbWVib2R5IGNvdWxkIGhpZ2hsaWdodCB0byBt ZSB3aGVyZSB0aGF0IGlzIGRlZmluZWQuDQoNCkkgdGhpbmsgdGhhdCwgdGhvdWdoIG5vdCBp bnRlZ3JhbCB0byB0aGUgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiwgdW5kZXJzdGFuZGluZyB3 aGF0IGZyYW1ld29yayB0aGUgcHJvdG9jb2wgd291bGQvbmVlZHMgdG8gZml0IGluIGlzIHJh dGhlciBpbXBvcnRhbnQuIA0KDQpDaGVlcnMsDQpTdGVmYW5vDQoNCg0KT24gVHVlLCBGZWIg MSwgMjAxMSBhdCAzOjQ3IFBNLCAgPEJhc2F2YXJhai5QYXRpbEBub2tpYS5jb20gPGh0dHA6 Ly9CYXNhdmFyYWouUGF0aWxAbm9raWEuY29tPiAgPGh0dHA6Ly9CYXNhdmFyYWouUGF0aWxA bm9raWEuY29tPiA+IHdyb3RlOg0KDQoNCkhlbGxvLA0KDQpXZSBoYXZlIGRpc2N1c3NlZCB0 aGUgZmxvdyBtb2JpbGl0eSBzb2x1dGlvbnMgZm9yIFByb3h5IE1JUDYgcHJldmlvdXNseSBh dA0KSUVURnMgNzggYW5kIDc5Lg0KVGhpcyBpcyBhIGNvbnNlbnN1cyBjYWxsIGZvciBhZG9w dGluZyB0aGlzIEktRDoNCmRyYWZ0LWJlcm5hcmRvcy1uZXRleHQtcG1pcHY2LWZsb3dtb2It MDINCmFzIHRoZSB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KSS1EOiBodHRwOi8vd3d3Lmll dGYub3JnL2lkL2RyYWZ0LWJlcm5hcmRvcy1uZXRleHQtcG1pcHY2LWZsb3dtb2ItMDIudHh0 IDxodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWJlcm5hcmRvcy1uZXRleHQtcG1pcHY2 LWZsb3dtb2ItMDIudHh0PiANCg0KVGhlIGNvbnNlbnN1cyBjYWxsIHdpbGwgZXhwaXJlIG9u IEZlYiAxNXRoLCAyMDExLiBQbGVhc2UgaW5kaWNhdGUgeW91cg0Kc3VwcG9ydCBvciBjb25j ZXJucyBpbiBhZG9wdGluZyB0aGlzIEktRCBhcyB0aGUgV0cgYmFzZWxpbmUgZG9jdW1lbnQg b24NCnRoZSBtYWlsaW5nIGxpc3QuDQoNClBsZWFzZSBub3RlIHRoYXQgdGhpcyBJLUQgd2ls bCBzZXJ2ZSBhcyB0aGUgYmFzZWxpbmUgaW4gdGhlIFdHIGFuZCB3aWxsIGJlDQpkZXZlbG9w ZWQgZnVydGhlciBiYXNlZCBvbiBpbnB1dCBhbmQgZmVlZGJhY2sgZnJvbSBXRyBtZW1iZXJz Lg0KDQotQmFzYXZhcmFqDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpuZXRleHQgbWFpbGluZyBsaXN0DQpuZXRleHRAaWV0Zi5vcmcgPGh0 dHA6Ly9uZXRleHRAaWV0Zi5vcmc+ICA8aHR0cDovL25ldGV4dEBpZXRmLm9yZz4gDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGV4dA0KDQogDQoNCiANCg0K IA0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpUaGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFu eSBhdHRhY2htZW50cykgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLCBw cml2aWxlZ2VkIG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0ZXJpYWwgcHJvdGVjdGVkIGJ5IHRo ZSBzb2xpY2l0b3ItY2xpZW50IG9yIG90aGVyIGFwcGxpY2FibGUgcHJpdmlsZWdlcyksIG9y IGNvbnN0aXR1dGUgbm9uLXB1YmxpYyBpbmZvcm1hdGlvbi4gQW55IHVzZSBvZiB0aGlzIGlu Zm9ybWF0aW9uIGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQg aXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24g aW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIGFuZCBk ZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lzdGVtLiBVc2UsIGRpc3NlbWlu YXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgdHJhbnNtaXNz aW9uIGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50cyBpcyBub3QgYXV0aG9yaXplZCBhbmQgbWF5 IGJlIHVubGF3ZnVsLg0K ------_=_NextPart_001_01CBC370.B2E458E7 Content-Type: text/html; charset="UTF-8" content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1p Y3Jvc29mdC1jb206b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1p Y3Jvc29mdC1jb206b2ZmaWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMt MTFkMS1BMkEzLTAwQUEwMEMxNDg4MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29m dC1jb206cm93c2V0IiB4bWxuczp6PSIjUm93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpwdWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJlYWRzaGVldCIgeG1sbnM6Yz0idXJuOnNj aGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9uZW50OnNwcmVhZHNoZWV0IiB4bWxu czpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9kYyIgeG1sbnM6b2E9 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2YXRpb24iIHhtbG5zOmh0 bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5zOnE9Imh0dHA6Ly9z Y2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9Imh0dHA6Ly9t aWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRBVjoiIHht bG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5zOm10 PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNl bC8yMDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNw YWNlLnhzZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJl cG9pbnQvc29hcC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vc2hhcmVwb2ludC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3Lncz Lm9yZy8yMDAwLzA5L3htbGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jv c29mdC5jb20vc2hhcmVwb2ludC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9kYXRhL3VkYyIgeG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAx L1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3No YXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRzLyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMu b3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29m dC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0 LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIw MDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRwOi8vc2NoZW1hcy5taWNy b3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRwOi8vc2NoZW1hcy5t aWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0iaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3Zj0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cvIiB4 bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9v ZmZpY2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1s Zm9ybWF0cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVy PSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxp dHkvMjAwNiIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2Uv MjAwNC8xMi9vbW1sIiB4bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1h dHMub3JnL3BhY2thZ2UvMjAwNi9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8v bWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0 dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBl cyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uv c2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1p Y3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRlTGlicmFyeS8iIHhtbG5zOnNwc2w9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1NoYXJlUG9pbnRQb3J0YWxTZXJ2 ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46c2NoZW1hcy1taWNyb3Nv ZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KDQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjx0aXRsZT5SZTogW25l dGV4dF0gQ29uc2Vuc3VzIGNhbGwgdG8gYWRvcHQgSS1EOiBkcmFmdC1iZXJuYXJkb3MtbmV0 ZXh0LXBtaXB2Ni1mbG93bW9iIGFzIFdHIGRvYzwvdGl0bGU+DQo8c3R5bGU+DQo8IS0tDQog LyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2Fs aWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9 DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj48Zm9u dCBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+DQpIZWxsbyBTcmks PGJyPkZyb20gYSBwb2ludCBvZiB2aWV3IG9mIGFwcGxpY2FiaWxpdHkgb2YgdGhlIHNvbHV0 aW9uLCBJIG11c3QgYWdyZWUgd2l0aCBHZXJhcmRvIHRoYXQgYXNzdW1pbmcgc3luY2hyb25p emF0aW9uIG9mIHBvbGljaWVzIGlzIGFuIGlzc3VlIG9mIHRoaXMgc29sdXRpb24gc2luY2Ug aXQgY29tZXMgd2l0aCBhIHNldCBvZiByZXN0cmljdGlvbnMgb24gaG93IHRoZSBzb2x1dGlv biBjYW4gYmUgYXBwbGllZC48YnI+Q2hlZXJzLDxicj5TdGVmYW5vPGJyPjxicj5TdGVmYW5v DTxicj5TdGVmYW5vIE0uIEZhY2Npbg08YnI+DTxicj5TdGFuZGFyZHMgTWFuYWdlcg08YnI+ UmVzZWFyY2ggSW4gTW90aW9uDTxicj4xMjIgV2VzdCBKb2huIENhcnBlbnRlciBQYXJrd2F5 DTxicj5JcnZpbmcsIFRYIDc1MDM5DTxicj5JbnRlcm5hbDogODIwIDYzNDUxDTxicj5EZXNr OiArMSA5NzIgOTEwIDM0NTENPGJyPkJsYWNrQmVycnk6ICsxIDUxMCAyMzAgODQyMg08YnI+ c2ZhY2NpbkByaW0uY29tDTxicj5UaW1lIHpvbmU6IFBTVCAoR01UIC04KTwvZm9udD48YnI+ Jm5ic3A7PGJyPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGZvbnQgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGI+RnJvbTwvYj46IEdpYXJldHRhLCBHZXJhcmRvIFtt YWlsdG86Z2VyYXJkb2dAcXVhbGNvbW0uY29tXQ08YnI+PGI+U2VudDwvYj46IFdlZG5lc2Rh eSwgRmVicnVhcnkgMDIsIDIwMTEgMTE6MTMgUE08YnI+PGI+VG88L2I+OiBTcmkgR3VuZGF2 ZWxsaSAmbHQ7c2d1bmRhdmVAY2lzY28uY29tJmd0Ozsgc3RlZmFubyBmYWNjaW4gJmx0O3Nm YWNjaW5zdGRAZ21haWwuY29tJmd0Ow08YnI+PGI+Q2M8L2I+OiBuZXRleHRAaWV0Zi5vcmcg Jmx0O25ldGV4dEBpZXRmLm9yZyZndDs7IEJhc2F2YXJhai5QYXRpbEBub2tpYS5jb20gJmx0 O0Jhc2F2YXJhai5QYXRpbEBub2tpYS5jb20mZ3Q7DTxicj48Yj5TdWJqZWN0PC9iPjogUmU6 IFtuZXRleHRdIENvbnNlbnN1cyBjYWxsIHRvIGFkb3B0IEktRDogZHJhZnQtYmVybmFyZG9z LW5ldGV4dC1wbWlwdjYtZmxvd21vYiBhcyBXRyBkb2MNPGJyPjwvZm9udD4mbmJzcDs8YnI+ PC9kaXY+DQoNCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5I aSBTcmksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+VGhlcmUgaXMgbm8gaW1wbGlj aXQgYXNzdW1wdGlvbiBvZiBzeW5jaHJvbml6ZWQgcG9saWNpZXMuIEEgYmFzaWMgZXhhbXBs ZSB0aGF0IHNob3dzIHRoYXQgdGhlcmUgaXMgbm8gYXNzdW1wdGlvbiBpcyB0aGUgZm9sbG93 aW5nOiBBTkRTRiBwb2xpY2llcyBtYXkgYmUgYmFzZWQNCiBhbHNvIG9uIGxvY2F0aW9uIG9m IHRoZSBVRS4gRm9yIGV4YW1wbGUgdGhlIFVFIHNob3VsZCBwcmVmZXIgV0xBTiBvbmx5IGlu IGEgZ2l2ZW4gbG9jYXRpb24uIFdoZW4gdGhlIFVFIGlzIGF0dGFjaGVkIG92ZXIgV0xBTiB0 aGVyZSBpcyBubyB3YXkgZm9yIHRoZSBQRE5HVy9IQSB0byB2ZXJpZnkgdGhlIGxvY2F0aW9u IG9mIHRoZSBVRSBhbmQgdGhlcmVmb3JlIHRvIHZlcmlmeSBVRSBhY3Rpb25zIGJhc2VkIG9u IHBvbGljaWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPlRoZSBhc3N1bXB0aW9u IG9uIHN5bmNocm9uaXphdGlvbiBvZiBwb2xpY2llcyBpcyBvbmx5IGFwcGxpY2FibGUgdG8g dGhpcyBkcmFmdCBhbmQgSSB0aGluayBpdCBpcyBhIHdyb25nIG9uZS4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OzsNCmNvbG9yOiMxRjQ5N0QiPkNoZWVyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9y OiMxRjQ5N0QiPkdlcmFyZG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBuZXRleHQtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOm5ldGV4dC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxm IE9mIDwvYj5TcmkgR3VuZGF2ZWxsaTxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZl YnJ1YXJ5IDAyLCAyMDExIDY6NTAgUE08YnI+DQo8Yj5Ubzo8L2I+IHN0ZWZhbm8gZmFjY2lu PGJyPg0KPGI+Q2M6PC9iPiBuZXRleHRAaWV0Zi5vcmc7IEJhc2F2YXJhai5QYXRpbEBub2tp YS5jb208YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRleHRdIENvbnNlbnN1cyBjYWxs IHRvIGFkb3B0IEktRDogZHJhZnQtYmVybmFyZG9zLW5ldGV4dC1wbWlwdjYtZmxvd21vYiBh cyBXRyBkb2M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ow0KZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5IaSBTdGVmYW5vLDxicj4NCjxicj4NCk9uZSBjb21tZW50Ljxicj4N Cjxicj4NCkFncmVlIHdpdGggeW91IHRoZXJlIGlzIG5vIEFORFNGIGludGVyZmFjZSB0byB0 aGUgbmV0d29yayBub2RlLCBidXQgdGhlIGFzc3VtcHRpb24gb2Ygc3luY2hyb25pemVkIHBv bGljaWVzIGJldHdlZW4gdGhlIEFORFNGIHNlcnZlciBhbmQgdGhlIFBETiBHVy9IQSBpcyB0 aGVyZSwgaW1wbGljaXRseSBJTU8uIFdpdGggb3V0IHRoaXMgYXNzdW1wdGlvbiwgSSBkbyBu b3Qga25vdywgaG93IHRoZSBIQSBjYW4gZXZlciB2YWxpZGF0ZSB0aGUgZmxvdyBtb2JpbGl0 eQ0KIG9wdGlvbnMgcmVjZWl2ZWQgaW4gdGhlIEJVLiBJZiB0aGUgb3BlcmF0b3IgcmVxdWly ZXMgYW55IGNvbnRyb2wgb24gZW5mb3JjaW5nIGEgZmxvdyBwb2xpY3kgcnVsZSwgdGhlIFBE TiBHVy9IQSBuZWVkcyB0byBoYXZlIHN5bmNocm9uaXplZCBwb2xpY2llcywgd2l0aG91dCB3 aGljaCBpdHMgYWx3YXlzIHRoZSBjbGllbnQgZGVjaXNpb24uIEkmIzgyMTc7bSBub3Qgc3Vy ZSwgb3BlcmF0b3JzIGluIDNHUFAgd291bGQgbGlrZSB0aGF0IDopDQo8YnI+DQo8YnI+DQpO byBkb3VidCwgdGhlIGxhY2sgb2YgTU4tQVIgaW50ZXJmYWNlIGlzIHN1cmVseSBhbiBpc3N1 ZSBmb3Igc3VwcG9ydGluZyBjb21wbGV4IGZsb3cgcG9saWNpZXMuIEkgcmVhbGl6ZSB0aGUg aXNzdWVzIGFuZCBJIGFncmVlIHdpdGggeW91LiBCdXQsIHRoZSBhc3N1bXB0aW9uIG9mIHN5 bmNocm9uaXplZCBwb2xpY2llcyBjYW4gb2ZmZXIgc29tZSBzb2x1dGlvbiB3aXRoIHNvbWUg Y29uZmlndXJhdGlvbiByZXF1aXJlbWVudCBvbiB0aGUgSEEgKGFzc3VtaW5nDQogdGhlcmUg YXJlIG5vIG90aGVyIGlzc3VlcykuIFRoZXJlIGFyZSBhbHNvIHRoZSBwcm9wb3NhbHMgb24g ZmxvdyBtaXJyb3Jpbmcgb24gdGhlIFVFIC4uLiwgcmVxdWlyaW5nIG5vIGZsb3cgcG9saWNp ZXMuIEkmIzgyMTc7dmUgbm90IGV2YWx1YXRlZCB0aGlzLCBob3dldmVyLiBGb2xrcyBjYW4g Y29tbWVudCBvbiB0aGlzLjxicj4NCjxicj4NCkl0IGlzIGFsc28gdG8gYmUgbm90ZWQsIGZv ciBzb21lIG9mIHRoZSBzY2VuYXJpb3Mgc3VjaCwgdGhlcmUgaXMgbm8gZmxvdyBwb2xpY3kg aW50ZXJmYWNlIG5lZWRlZC4gV2UgY2FuIGlkZW50aWZ5IHdoYXQgc2NlbmFyaW9zIGNyZWF0 ZSBhbnkgY29uZmlndXJhdGlvbiBsaW1pdGF0aW9ucyBvbiB0aGUgSEEgYW5kIHdoaWNoIG9u ZSYjODIxNztzIGRvIG5vdCAuIEFzIEkmIzgyMTc7dmUgbm90ZWQgZWFybGllciwgdGhpcyBp cyBzdXJlbHkgYW4gb3BlbiBpc3N1ZSwgdGhhdA0KIHdlIG5lZWQgdG8gZGlzY3VzcyBpbiB0 aGUgV0cuIDxicj4NCjxicj4NCjxicj4NCjxicj4NClJlZ2FyZHM8YnI+DQpTcmk8YnI+DQo8 YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQombmJzcDs8YnI+DQo8YnI+DQo8YnI+DQpPbiAyLzIv MTEgOTowOCBBTSwgJnF1b3Q7c3RlZmFubyBmYWNjaW4mcXVvdDsgJmx0OzxhIGhyZWY9InNm YWNjaW5zdGRAZ21haWwuY29tIj5zZmFjY2luc3RkQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3Rl Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U3JpLDxicj4NCnRoYW5rcyBmb3IgdGhlIHJlcGx5 LiBDYW4geW91IGNsYXJpZnkgaW4gd2hpY2ggc3lzdGVtIG9yIHNjZW5hcmlvIEFORFNGIGlz IGF2YWlsYWJsZSB0byBuZXR3b3JrIGVudGl0aWVzIGFzIHdlbGw/IFRoZXJlIGlzIG5vIHN1 Y2ggYXZhaWxhYmlsaXR5IGluIDNHUFAsIGFuZCBtYWtpbmcgc3VjaCBpbmZvcm1hdGlvbiBh dmFpbGFibGUgd291bGQgcmVxdWlyZSBjb25zaWRlcmFibGUgYXJjaGl0ZWN0dXJhbCBjaGFu Z2VzLCB0aGVyZWZvcmUgdGhlIGFwcGxpY2FiaWxpdHkNCiBvZiB0aGlzIHNvbHV0aW9uIHRv IHdoYXQgc2VlbXMgdG8gYmUgdGhlIG9ubHkgcmVhbGlzdGljIHNjZW5hcmlvIGhpbmdlcyBv biAzR1BQIG1ha2luZyBjb25zaWRlcmFibGUgYXJjaGl0ZWN0dXJhbCBjaGFuZ2VzLiBJIHdv dWxkIHRoZXJlZm9yZSBub3QgYmUgc28gaGFzdGlseSBjb25jbHVkaW5nIHRoYXQgdGhlIEFO RFNGIGluZm9ybWF0aW9uIGlzIGF2YWlsYWJsZSB0byB0aGUgTE1BIGFuZCB1bmRlcmVzdGlt YXRlIHdoYXQgaXQgd291bGQgcmVhbGx5DQogdGFrZSB0byBtYWtlIHRoZSBzb2x1dGlvbiBh cHBsaWNhYmxlLjxicj4NCjxicj4NCklmIHdlIGNhbm5vdCBndWFyYW50ZWUgdGhhdCB0aGVy ZSBpcyBhdCBsZWFzdCBvbmUgcmVhbGlzdGljIHNvbHV0aW9uIHRvIGhhdmUgdGhlIE1OYSBu ZCBMTUEgaW4gc3luY2gsIGhvdyBkbyB3ZSBleHBlY3QgdGhhdCB0aGlzIHNvbHV0aW9uIGlz IGFwcGxpY2FibGUgYXQgYWxsPyBJbiAzR1BQIHRoZXJlIGlzIG5vIG5lZWQgdG8gaGF2ZSBz dWNoIGltcGxpY2l0IGFzc3VtcHRpb24sIGJlIGNhdXNlIDEpIHRoZSBNTiBpcyBwcm92aWRl ZCBwb2xpY2llcw0KIGV4cGxpY2l0bHkgdGhyb3VnaCB0aGUgQU5EU0YsIGFuZCAyKSBpdCBp cyB0aGUgTU4gYW5kIG9ubHkgdGhlIE1OIHRoYXQgbWFrZXMgSVAgZmxvdyBtb2JpbGl0eSBk ZWNpc2lvbnMgYW5kIGNvbW11bmljYXRlcyB0aGVtIGV4cGxpY2l0bHkgKHdpdGggd2VsbCBk ZWZpbmVkIHNpZ25hbGxpbmcpIHRvIHRoZSBMTUEsIGFuZCB0aGVyZWZvcmUgbm8gbWFnaWMg aXMgbmVlZGVkLiBUaGVyZSBpcyBubyBuZWVkIGluIDNHUFAgdG8gaGF2ZSB0aGUgQU5EU0YN CiBhbmQgUEROIEdXIHBvbGljaWVzIHN5bmNocm9uaXplZCwgc2luY2UgdGhlIFBETiBHVyBk b2VzIG5vdCB1c2Ugc3VjaCBwb2xpY2llcy4gPGJyPg0KPGJyPg0KU3JpLCBpbiB0aGUgZW5k IGl0IGlzIGEgbWF0dGVyIG9mIHdoZXRoZXIgd2UgZGV2ZWxvcCBhIHNvbHV0aW9uIHRoYXQg d2lsbCByZWx5IG9uIHNvbWUgdW5rbm93biBtYWdpYyB0byBiZSBkZXBsb3llZCwgb3IgYSBz b2x1dGlvbiB0aGF0IHdlIGtub3cgY2FuIGJlIGRlcGxveWVkIGluIGF0IGxlYXN0IG9uZSB3 YXkgYmVjYXVzZSB0aGVyZSBhcmUgc29sdXRpb25zIHRvIHdoYXQgSSBjb25zaWRlciBtYWpv ciBvcGVuIGlzc3Vlcy48YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KU3RlZmFubzxicj4NCjxi cj4NCk9uIFR1ZSwgRmViIDEsIDIwMTEgYXQgOTowNiBQTSwgU3JpIEd1bmRhdmVsbGkgJmx0 OzxhIGhyZWY9InNndW5kYXZlQGNpc2NvLmNvbSI+c2d1bmRhdmVAY2lzY28uY29tPC9hPiZn dDsgd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDsNCmZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+SGkgU3RlZmFubyw8YnI+DQo8YnI+DQpUaGFua3MgZm9yIHRoZSBkaXNjdXNz aW9uLjxicj4NCjxicj4NCkFzIHlvdSBzYXksIHRoZSBBTkRTRiBwb2xpY2llcyBhcmUgYWxs b3dpbmcgdGhlIE1OIGEuKSB0byBtYWtlIHRoZSByaWdodCBuZXR3b3JrIGF0dGFjaG1lbnQg ZGVjaXNpb24gYW5kIGIuKSBtYWtlIHRoZSBhY2Nlc3Mgc2VsZWN0aW9uIG9uIGEgZmxvdyBi YXNpcy4gVGhpcyBzYW1lIHBvbGljeSB0aGF0IGlzIHByZXNlbnQgaW4gdGhlIEFORFNGIHNl cnZlciwgaXMgYXZhaWxhYmxlIGZvciB0aGUgbmV0d29yayBub2RlcyBhcyB3ZWxsLiBJJiM4 MjE3O20gbm90DQogc3VyZSwgd2l0aCBvdXQgdGhpcyBhc3N1bXB0aW9uIHRoZSBzb2x1dGlv biBjYW4gd29yayBmb3IgYWxsIGN1cnJlbnRseSBsaXN0ZWQgY2FzZXMuIFdlIGNsZWFybHkg bmVlZCB0aGUgTU4gYW5kIHRoZSBMTUEgdG8gYmUgaW4gc3luY2ggd2l0aCByZXNwZWN0IHRv IHRoZSBjb25maWd1cmVkIHBvbGljeS4gSG93LCB0aGF0IGlzIGRvbmUsIEkgZ3Vlc3Mgd2Ug d2lsbCBub3QgdHJ5IHRvIGtub3cuICZuYnNwO0kgdGhvdWdodCBldmVuIGluIDNHUFAsIHRo aXMNCiBpcyB0aGUgaW1wbGllZCBhc3N1bXB0aW9uID8gQnV0LCB0aGlzIGlzIGZvciB5b3Ug dG8gY2xhcmlmeS4gTm90IHNwZWNpZmljYWxseSBmb3IgSUZPTSB3aGVyZSBVRSBhbmQgUERO IEdXL0hBIGFyZSBuZWdvdGlhdGluZyB0aGUgZmxvdyBwb2xpY2llcywgYnV0IGdlbmVyYWxs eSB0aGF0IHRoZSBQRE4gR1cgYW5kIHRoZSBBTkRTRiBwb2xpY3kgc2VydmVyIHdpbGwgaGF2 ZSBzeW5jaHJvbml6ZWQgcG9saWNpZXMuIFRoZSBNQUcgYW5kIHRoZSBMTUENCiBoYXZlIHRo ZSBhYmlsaXR5IHRvIGNhcnJ5IHRoaXMgZmxvdyBwb2xpY3kgaW5mb3JtYXRpb24gaW4gc2ln bmFsaW5nIG1lc3NhZ2VzIGFuZCBpbmZsdWVuY2UgdGhlIGFjY2VzcyBzZWxlY3Rpb24uIFRo ZSBwb2xpY3kgaXMgYSBvcGFxdWUgb2JqZWN0LCB3aXRoIGV4dGVuc2libGUgZm9ybWF0cywg d2hlbiBjYXJyaWVkIGluIHRoZSBzaWduYWxpbmcgcGxhbmUsIHNob3VsZCBhbGxvdyB0aGUg TE1BL01BRyB0byBhcHBseSB0aG9zZSBhY2Nlc3MgcG9saWNpZXMsDQogd2hpbGUgYXNzdW1p bmcgTU4gaXMgZm9sbG93aW5nIHRoZSBzYW1lIHJ1bGVzLiBUaGVzZSBwb2xpY2llcyBjYW4g c3VyZWx5IHJlZmxlY3QgdGhlIHNwZWNpZmljIFdMQU4gYWNjZXNzL29wZXJhdG9yIHNwZWNp ZmljIHJ1bGUuIEkmIzgyMTc7bSBzdXJlbHkgd2l0aCB5b3UsIHRoZSBsYWNrIG9mIE1OLUFS IGludGVyZmFjZSBpcyBzdXJlbHkgYW4gaXNzdWUgYW5kIEkgc2VlIHRoYXQuIEJ1dCwgd2Ug bmVlZCB0byB1bmRlcnN0YW5kLCB3aGF0IGFyZSB0aGUgbGltaXRhdGlvbnMNCiB3aXRoIHRo ZSBhcHByb2FjaCBvZiAmbmJzcDtvdXQgb2YgYmFuZCBwb2xpY3kgaW50ZXJmYWNlcyBhbmQg d2hhdCB3aWxsIGJlIHRoZSBzb2x1dGlvbiBsaW1pdGF0aW9ucy4gSWYgd2UgbmVlZCB0byB0 aWUgdGhlIGZsb3cgbW92ZW1lbnQgYXQgdGhlIHByZWZpeCBncmFudWxhcml0eSBhbmQgcmVs eSBvbiB0aGUgbmF0dXJhbCBORCBpbnRlcmZhY2UgaW4gdGhlIGZvcm0gb2YgUkEgUElPIG9w dGlvbiwgbW9yZSBsaWtlIFBETiBvZmZsb2FkIGluIE1BUENPTiwNCiBvciBhdCB0aGUgZ3Jh bnVsYXJpdHkgb2YgYSBmbG93IGxldmVsLCBpcyBvcGVuIGZvciBkaXNjdXNzaW9uLiBJIHdh bnQgdG8gc2ltcGxpZnkgdGhpcyBkcmFmdCBmb3Igc3VyZSwgd2UgY2FuIHN1cmVseSBkaXNj dXNzIGVhY2ggb2YgdGhlc2UgaXNzdWVzIG9uIHRoZSBXRyBkcmFmdC48YnI+DQo8YnI+DQo8 YnI+DQpSZWdhcmRzPGJyPg0KU3JpPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KPGJyPg0KT24gMi8xLzExIDg6MjkgUE0sICZxdW90O3N0ZWZhbm8gZmFjY2luJnF1b3Q7 ICZsdDs8YSBocmVmPSJzZmFjY2luc3RkQGdtYWlsLmNvbSI+c2ZhY2NpbnN0ZEBnbWFpbC5j b208L2E+ICZsdDs8YSBocmVmPSJodHRwOi8vc2ZhY2NpbnN0ZEBnbWFpbC5jb20iPmh0dHA6 Ly9zZmFjY2luc3RkQGdtYWlsLmNvbTwvYT4mZ3Q7ICZndDsgd3JvdGU6PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+U3JpLDxicj4NCnRoYW5rcyBmb3IgdGhlIHJlcGx5Ljxicj4NCjxicj4NCkkn ZCBsaWtlIHRvIGNvbW1lbnQgb24gdGhlICZxdW90Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+dGhlIGZsb3cgcG9saWN5IGRlY2lzaW9ucyBuZWVkIG5vdCBi ZSBiYXNlZCBvbiB0aGUgc3BlY2lmaWMgV0xBTiBuZXR3b3JrJnF1b3Q7LiBEb2VzIGl0IG1l YW4sIGFzIEkgYmVsaWV2ZSBpdCBkb2VzLCB0aGF0IHRoZSBjdXJyZW50IHNvbHV0aW9uIHdv dWxkIG5vdCBhbGxvdyBhbg0KIG9wZXJhdG9yIGRlcGxveWluZyBzdWNoIHNvbHV0aW9uIHRv IGRlY2lkZSB0byByb3V0ZSBmbG93cyBvdmVyIGEgc3BlY2lmaWMgV0xBTiBvciBub3QgZGVw ZW5kaW5nIG9uIHdoaWNoIHNwZWNpZmljIFdMQU4gdGhlIE1OIGlzIGNvbm5lY3RlZCB0bz8g RS5nLiB0aGUgb3BlcmF0b3Igb3IgdGhlIGVudGl0eSBpbiBjb250cm9sIG9mIHRoZSBkZWNp c2lvbnMgZm9yIHRoZSByb3V0aW5nIG1heSB3YW50IHRvIGRpcmVjdCBjZXJ0YWluIHRyYWZm aWMgYWx3YXlzDQogb3ZlciBXTEFOcyB0aGF0IHRoZSBvcGVyYXRvciBkZXBsb3lzLCBhbmQg aW5zdGVhZCByb3V0ZSBvbmx5IHNvbWUgb2YgdGhlIHRyYWZmaWMgb3ZlciBXTEFOcyBvZiBy b2FtaW5nIHBhcnRuZXJzIG9yIG9mIHRoZSBNTiB1c2VyIGhvbWUuIEhvdyBkb2VzIHRoaXMg c29sdXRpb24gc3VwcG9ydCB0aGF0IHNjZW5hcmlvIGlmIHRoZSBMTUEgaXMgbm90IHRvbGQg c3BlY2lmaWNhbGx5IHdoaWNoIFdMQU4gdGhlIE1OIGlzIGNvbm5lY3RlZCB0bz8gRnJvbQ0K IGEgZGVwbG95bWVudCBwb2ludCBvZiB2aWV3LCBJIGRvIG5vdCBiZWxpZXZlIHdlIGNhbiBh ZmZvcmQgdG8gbGVhdmUgb3V0IHRoaXMgc2NlbmFyaW8uIFBsZWFzZSBub3RlIHRoYXQgdGhl IGVzdGFibGlzaG1lbnQgb2YgYSBzZWN1cml0eSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUg TU4gYW5kIHRoZSBNQUcsIGFuZCBhIHNwZWNpZmljIE1BRyBpZGVudGl0eSwgY2Fubm90IGd1 YXJhbnRlZSB0aGF0IHRoZSBMTUEga25vd3Mgd2hpY2ggc3BlY2lmaWMNCiBXTEFOIGFjY2Vz cyBuZXR3b3JrIHRoZSBNTiBpcyBjb25uZWN0ZWQgdG8uIEFzc3VtaW5nIHRoYXQgd291bGQg c2V2ZXJlbHkgcmVzdHJpY3QgdGhlIGRlcGxveW1lbnQgc2NlbmFyaW9zLjxicj4NCjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQpBcyBmb3IgdGhlIE1OIGFu ZCB0aGUgTE1BIGJlaW5nIG1hZ2ljYWxseSBpbiBzeW5jaCwgSSBhbSB2ZXJ5IGNvbmNlcm5l ZCBhYm91dCBhICZxdW90O2dsYXNzIGJhbGwmcXVvdDsgc29sdXRpb24uIFlvdSBtZW50aW9u IEFORFNGIGRlZmluZWQgYnkgM0dQUCBhcyBhIHNvbHV0aW9uIGZvciB0aGlzICZxdW90O291 dCBvZiBiYW5kJnF1b3Q7IGRlbGl2ZXJ5IG9mIHBvbGljeS4gRmFpciBlbm91Z2gsIGhvd2V2 ZXIgdGhlcmUgaXMgYW4gaXNzdWUgd2l0aCB0aGF0LiBBTkRTRiBpcyBkZXNpZ25lZA0KIHNw ZWNpZmljIHRvIGJlIGEgTU4tY2VudHJpYyBzb2x1dGlvbiB3aGVyZSBwb2xpY2llcyBhcmUg cHJvdmlzaW9uZWQgaW4gdGhlIE1OIGFuZCB0aGUgTU4gZGVjaWRlcyB3aGljaCBuZXR3b3Jr IHRlY2hub2xvZ2llcyBhbmQgYWNjZXNzIG5ldHdvcmtzIGl0IG5lZWRzIHRvIGNvbm5lY3Qg dG8sIHVuZGVyIHdoYXQgY29uZGl0aW9ucywgYW5kIHdoaWNoIElQIHRyYWZmaWMgbmVlZHMg dG8gYmUgcm91dGVkIG9uIHN1Y2ggYWNjZXNzZXMuIE5vIElQIHBvaW50DQogb2YgYXR0YWNo bWVudCBpbiB0aGUgbmV0d29yayAoaS5lLiB0aGUgUEROIEdXIGluIDNHUFAgdGhhdCBpcyB0 aGUgTE1BIGluIFBNSVB2NikgaXMgYXdhcmUgdW5kZXIgYW55IGNvbmRpdGlvbnMgb2Ygc3Vj aCBwb2xpY3kuIFRoZXJlZm9yZSwgZXZlbiBpZiBpbiBvcmRlciB0byBhcHBseSB0aGlzIHNv bHV0aW9uIHRvIDNHUFAgd2Ugd2FudGVkIHRvIHVzZSBBTkRTRiwgQU5EU0Ygd291bGQgdW5m b3J0dW5hdGVseSBub3QgcHJvdmlkZSBhIHNvbHV0aW9uDQogdW5sZXNzIHRoZSBNTiBjYW4g Y29tbXVuaWNhdGUgdG8gdGhlIE1BRyBhbmQgdGhlIExNQSB0aGUgZGVjaXNpb25zIHRoZSBN TiBoYXMgdGFrZW4gYmFzZWQgb24gdGhlIEFORFNGIHBvbGljaWVzLjxicj4NCjxicj4NCkkg YmVsaWV2ZSB0aGUga2V5IHBvaW50IGhlcmUgaXMgdGhhdCB3ZSBuZWVkIHRvIHVuZGVyc3Rh bmQgaG93IHRoZSBzb2x1dGlvbiBjYW4gYmUgcmVhbGlzdGljYWxseSBhcHBsaWVkIHRvIGEg cmVhbCBzY2VuYXJpbywgYW5kIHRoYXQgd2UgbmVlZCB0byBlbnN1cmUgdGhhdCBpbXBvcnRh bnQgYW5kIHJlYWxpc3RpYyBkZXBsb3ltZW50IHNjZW5hcmlvcyBhcmUgbm90IGV4Y2x1ZGVk IGJ5IHRoZSBzb2x1dGlvbi48YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KU3RlZmFubzxicj4N Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCk9uIFR1ZSwg RmViIDEsIDIwMTEgYXQgNzo0MyBQTSwgU3JpIEd1bmRhdmVsbGkgJmx0OzxhIGhyZWY9InNn dW5kYXZlQGNpc2NvLmNvbSI+c2d1bmRhdmVAY2lzY28uY29tPC9hPiAmbHQ7PGEgaHJlZj0i aHR0cDovL3NndW5kYXZlQGNpc2NvLmNvbSI+aHR0cDovL3NndW5kYXZlQGNpc2NvLmNvbTwv YT4mZ3Q7ICZndDsgd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDsNCmZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+SGkgU3RlZmFubzo8YnI+DQo8YnI+DQpUaGVzZSBhcmUgdmFs aWQgcG9pbnRzIGFuZCBzb21lIGdvb2QgY29tbWVudHMuIExldCBtZSBzaGFyZSBteSB0aG91 Z2h0cy48YnI+DQo8YnI+DQpDYXJsbyYjODIxNztzIGRyYWZ0IGlzIG5vdCBhc3N1bWluZyBh bnkgbmV3IE1OLUFSIGludGVyZmFjZS4gSXRzIGdvaW5nIHdpdGggdGhlIGFzc3VtcHRpb24g dGhlcmUgaXMgZXN0YWJsaXNoZWQgcG9saWN5IG9uIHRoZSBtb2JpbGUgYW5kIG9uIHRoZSBM TUEsIHdoaWNoIGFsbG93cyB0aGUgbW9iaWxlIHRvIHNlbGVjdCB0aGUgYWNjZXNzIG5ldHdv cmsgYXQgYSBmbG93IGxldmVsIGdyYW51bGFyaXR5LCB3aXRob3V0IHJlcXVpcmluZyBhbnkg ZXhwbGljaXQgc2lnbmFsaW5nDQogYmV0d2VlbiB0aGUgTUFHIGFuZCB0aGUgTU4uIFRvIGxh cmdlIHBhcnQgdGhpcyBpcyBhbGwgYWJvdXQgb3V0IG9mIGJhbmQgcG9saWN5IGludGVyZmFj ZSwgc3VjaCBhcyBBTkRTRiwgdG93YXJkcyB0aGUgVUUsIGxlYWRpbmcgdG8gdGhlIGFzc3Vt cHRpb24gdGhhdCBtYWdpY2FsbHkgdGhlIE1OIGFuZCB0aGUgTE1BIGFyZSBpbiBzeW5jIHdp dGggcmVzcGVjdCB0byBmbG93IHBvbGljaWVzLCBhY2Nlc3Mgc2VsZWN0aW9uIGFuZCB0aGV5 IHdpbGwgbWFrZQ0KIHRoZSByaWdodCBmb3J3YXJkaW5nIGRlY2lzaW9uLiBTZWNvbmRseSwg dGhlIGZsb3cgcG9saWN5IGRlY2lzaW9ucyBuZWVkIG5vdCBiZSBiYXNlZCBvbiB0aGUgc3Bl Y2lmaWMgV0xBTiBuZXR3b3JrLCBidXQgaXQgaXMgaW1wbGljaXRseSBkcml2ZW4gYnkgdGhl IE1BRyAmIzgyMTE7IExNQSBzZWN1cml0eSByZWxhdGlvbiwgd2hlcmUgdGhlIE1BRyBhdHRh Y2htZW50IHRvIHRoZSBXTEFOIG5ldHdvcmsgdHJhbnNpdGl2ZWx5IGFsbG93cyB0aGUgTE1B IHRvIG1ha2UNCiB0aGUgZmxvdyBwb2xpY3kgZGVjaXNpb25zIGJhc2VkIG9uIHRoZSBNQUcg aWRlbnRpdHkuIElmIHRoZSBXTEFOIG5ldHdvcmsgaXMgbm90IHRydXN0ZWQsIHRoZXJlIGlz IHRydWx5IG5vIE1BRyBpbiB0aGF0IG5ldHdvcmssIHdoZXJlIHRoZSBMTUEgc2hhcmVzIGEg c2VjdXJpdHkgcmVsYXRpb24gd2l0aCB0aGF0IG5vZGUuPGJyPg0KPGJyPg0KVGhlcmUgYXJl IHN0aWxsIHNvbWUgb3BlbiBpc3N1ZXMgb24gdGhpcyBkcmFmdCB0aGF0IG5lZWRzIHRvIGJl IGRpc2N1c3NlZCBpbiB0aGUgV0cuICZuYnNwO09uIHRoZSBhcHByb2FjaGVzIHRvIGFsbG93 IG1vcmUgYSBmbG93IGFnZ3JlZ2F0ZSBtb3ZlbWVudCwgdGhhdCBpcyBhIGRpc2N1c3Npb24g cG9pbnQuIFRoZXJlIGFyZSBpc3N1ZXMgdGhhdCB3ZSBuZWVkIHRvIGRpc2N1c3MsIHN1cHBv cnRpbmcgc3BsaXQgbGluayBtb2RlbCwgb3IgZWxpbWluYXRpbmcNCiBzb21lIGZhdm9yaXRl IGJyYW5kIG9mIHNpZ25hbGluZyBtZXNzYWdlIChGTUEpIGFuZCByaWRpbmcgb24gUEJVL1BC QSBhbmQganVzdCB3aXRoIG9uZSBGTUkgdHJpZ2dlciwgYW5kIG9uIHRoZSBhc3BlY3RzIGFy b3VuZCBNTiBhcHBseWluZyB0aGUgZmxvdyBwb2xpY2llcyBieSBmbG93IG1pcnJvcmluZy4g V2UgaGF2ZSBubyBhZ3JlZW1lbnQgb24gdGhvc2UgaXNzdWVzIHlldC48YnI+DQo8YnI+DQpJ dHMganVzdCBhIGJhc2UgZHJhZnQsIGZvciBmdXJ0aGVyIGRpc2N1c3Npb24gYW5kIHJlc29s dmluZyB0aG9zZSBpc3N1ZXMuIEJ1dCwgaG9wZSB0aGF0IGlzIG5vdCBhIHN0b3BwZXIgZm9y IGJhc2UgZHJhZnQgc2VsZWN0aW9uLjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4 Ij4mbmJzcDs8YnI+DQo8YnI+DQpTcmk8YnI+DQo8L3NwYW4+PGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KT24gMi8xLzExIDY6MzkgUE0sICZxdW90O3N0ZWZhbm8gZmFj Y2luJnF1b3Q7ICZsdDs8YSBocmVmPSJzZmFjY2luc3RkQGdtYWlsLmNvbSI+c2ZhY2NpbnN0 ZEBnbWFpbC5jb208L2E+ICZsdDs8YSBocmVmPSJodHRwOi8vc2ZhY2NpbnN0ZEBnbWFpbC5j b20iPmh0dHA6Ly9zZmFjY2luc3RkQGdtYWlsLmNvbTwvYT4mZ3Q7ICZuYnNwOyZsdDs8YSBo cmVmPSJodHRwOi8vc2ZhY2NpbnN0ZEBnbWFpbC5jb20iPmh0dHA6Ly9zZmFjY2luc3RkQGdt YWlsLmNvbTwvYT4mZ3Q7ICZndDsgd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5SYWos PGJyPg0KdGhhbmtzIGZvciB0aGUgZW1haWwuPGJyPg0KPGJyPg0KSSBuZWVkIHRvIGFwb2xv Z2l6ZSBpbiBhZHZhbmNlIGlmIG15IHF1ZXN0aW9ucyBoYXZlIGFscmVhZHkgYmVlbiBhbnN3 ZXJlZCBiZWZvcmUgKHRob3VnaCBJIGNhbm5vdCBmaW5kIGEgY29uY2x1c2l2ZSBhbnN3ZXIg YW55d2hlcmUpLjxicj4NCjxicj4NCkkgdGhpbmsgdGhhdCBhIHByb3RvY29sIHRoYXQgaXMg ZGV2ZWxvcGVkIGluIE5FVEVYVCAob3Igb3RoZXIgZ3JvdXBzKSBzaG91bGQgaGF2ZSBhdCBs ZWFzdCBhIHBvdGVudGlhbCByZWFsaXN0aWMgc2NlbmFyaW8gZm9yIGFwcGxpY2FiaWxpdHku PGJyPg0KPGJyPg0KSW4gdGVybXMgb2YgYXBwbGljYWJpbGl0eSwgdGhvdWdoIGl0IGlzIG5v dCBwYXJ0IG9mIHRoZSBwcm90b2NvbCBkZWZpbml0aW9uIHBlciBzZSwgdW5sZXNzIHRoZXJl IGFyZSBzb2x1dGlvbnMgaW4gcGxhY2UgZm9yIGVpdGhlciB0aGUgaG9zdCB0byBpbmRpY2F0 ZSB0byB0aGUgbmV0d29yayB3aGVyZSB0aGUgZmxvd3Mgc2hvdWxkIGJlIHJvdXRlZCBvciBm b3IgdGhlIExNQSB0byByZWNlaXZlIHNvbWVob3cgZnJvbSBzb21ld2hlcmUgc29tZSBwb2xp Y2llcywNCiB0aGUgc29sdXRpb24gY2Fubm90IHJlYWxseSBwcm92aWRlIGZsb3cgbW9iaWxp dHkgc2luY2UgdGhlcmUgaXMgbm8gd2F5IHRvIGRlY2lkZSB3aGljaCBmbG93cyBhcmUgcm91 dGVkIHdoZXJlLiBJZiB3ZSBhcmUgdGhpbmtpbmcgYWJvdXQgYSBob3N0LWJhc2VkIHNvbHV0 aW9uLCBJIGhhdmUgbm90IHlldCBzZWVuIGEgc29sdXRpb24gYXMgdG8gaG93IHRoZSBob3N0 IGNhbiBpbmRpY2F0ZSB0byB0aGUgTUFHIGFuZCB1bHRpbWF0ZWx5IHRvIHRoZSBNQUcNCiB3 aGljaCBmbG93cyBzaG91bGQgYmUgcm91dGVkIG9uIGVhY2ggYWNjZXNzLiBJZiB3ZSBhcmUg cmVseWluZyBvbiBtb2RpZmljYXRpb25zIG9mIGxheWVyIDIgcHJvdG9jb2xzLCBhcmVuJ3Qg d2UgZGVmaW5pbmcgYSBzb2x1dGlvbiB0aGF0IHdvcmtzIG9ubHkgd2l0aCBzb21lIHRlY2hu b2xvZ2llcyAoc2luY2UgZm9yIG90aGVyIGFjY2VzcyB0ZWNobm9sb2dpZXMgaXQgaXMgcmF0 aGVyIHVucmVhbGlzdGljIHRvIG1vZGlmeSBMMiBmb3IgSVAgZmxvdw0KIG1vYmlsaXR5IHB1 cnBvc2VzKT8gSWYgd2UgYXJlIHRoaW5raW5nIG9mIGFuIExNQS1iYXNlZCBzb2x1dGlvbiwg Y2FuIHdlIGhlYXIgb2YgYXQgbGVhc3Qgb25lIGV4YW1wbGUgb2YgYSByZWFsLWxpZmUgc2Nl bmFyaW8gd2hlcmUgdGhlIExNQSB3b3VsZCByZWNlaXZlIHN1Y2ggcG9saWNpZXMsIGFuZCBo b3cgc3VjaCBkZWxpdmVyeSB3b3VsZCBoYXBwZW4/IEFsc28sIHNob3VsZCB0aGVyZSBiZSBh IHNvbHV0aW9uIHRvIGhhdmUgcG9saWNpZXMgaW4NCiB0aGUgTE1BLCBob3cgZG9lcyB0aGUg TE1BIGFjdHVhbGx5IGRlY2lkZSB0byByb3V0ZSBmbG93cyBvbiBvbmUgYWNjZXNzIG9yIHRo ZSBvdGhlcj8gRS5nLiwgaWYgc29tZSBmbG93cyBuZWVkIHRvIGJlIHJvdXRlZCBvbiBjZXJ0 YWluIFdMQU4gbmV0d29ya3MsIGJ1dCBzaGFsbCBub3QgYmUgcm91dGVkIG9uIG90aGVyIFdM QU4gbmV0d29ya3MsIGhvdyBkb2VzIHRoZSBMTUEga25vdyB3aGljaCBzcGVjaWZpYyBXTEFO IG5ldHdvcmsgdGhlIGhvc3QNCiBpcyBjb25uZWN0ZWQgdG8/IFBlcmhhcHMgSSBtaXNzZWQg dGhlIGFiaWxpdHkgZm9yIHRoZSBNQUcgdG8ga25vdyBlLmcuIHRoZSBXTEFOIFNTSUQgYW5k IHByb3ZpZGUgaXQgdG8gdGhlIExNQSwgaW4gd2hpY2ggY2FzZSBJIHdvdWxkIGFwcHJlY2lh dGUgaWYgc29tZWJvZHkgY291bGQgaGlnaGxpZ2h0IHRvIG1lIHdoZXJlIHRoYXQgaXMgZGVm aW5lZC48YnI+DQo8YnI+DQpJIHRoaW5rIHRoYXQsIHRob3VnaCBub3QgaW50ZWdyYWwgdG8g dGhlIHByb3RvY29sIHNwZWNpZmljYXRpb24sIHVuZGVyc3RhbmRpbmcgd2hhdCBmcmFtZXdv cmsgdGhlIHByb3RvY29sIHdvdWxkL25lZWRzIHRvIGZpdCBpbiBpcyByYXRoZXIgaW1wb3J0 YW50Lg0KPGJyPg0KPGJyPg0KQ2hlZXJzLDxicj4NClN0ZWZhbm88YnI+DQo8YnI+DQo8YnI+ DQpPbiBUdWUsIEZlYiAxLCAyMDExIGF0IDM6NDcgUE0sICZuYnNwOyZsdDs8YSBocmVmPSJC YXNhdmFyYWouUGF0aWxAbm9raWEuY29tIj5CYXNhdmFyYWouUGF0aWxAbm9raWEuY29tPC9h PiAmbHQ7PGEgaHJlZj0iaHR0cDovL0Jhc2F2YXJhai5QYXRpbEBub2tpYS5jb20iPmh0dHA6 Ly9CYXNhdmFyYWouUGF0aWxAbm9raWEuY29tPC9hPiZndDsgJm5ic3A7Jmx0OzxhIGhyZWY9 Imh0dHA6Ly9CYXNhdmFyYWouUGF0aWxAbm9raWEuY29tIj5odHRwOi8vQmFzYXZhcmFqLlBh dGlsQG5va2lhLmNvbTwvYT4mZ3Q7DQogJmd0OyB3cm90ZTo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjxicj4NCkhlbGxvLDxicj4NCjxicj4NCldlIGhhdmUgZGlzY3Vzc2VkIHRoZSBmbG93 IG1vYmlsaXR5IHNvbHV0aW9ucyBmb3IgUHJveHkgTUlQNiBwcmV2aW91c2x5IGF0PGJyPg0K SUVURnMgNzggYW5kIDc5Ljxicj4NClRoaXMgaXMgYSBjb25zZW5zdXMgY2FsbCBmb3IgYWRv cHRpbmcgdGhpcyBJLUQ6PGJyPg0KZHJhZnQtYmVybmFyZG9zLW5ldGV4dC1wbWlwdjYtZmxv d21vYi0wMjxicj4NCmFzIHRoZSB3b3JraW5nIGdyb3VwIGRvY3VtZW50Ljxicj4NCkktRDog PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1iZXJuYXJkb3MtbmV0ZXh0 LXBtaXB2Ni1mbG93bW9iLTAyLnR4dCI+DQpodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0 LWJlcm5hcmRvcy1uZXRleHQtcG1pcHY2LWZsb3dtb2ItMDIudHh0PC9hPjxicj4NCjxicj4N ClRoZSBjb25zZW5zdXMgY2FsbCB3aWxsIGV4cGlyZSBvbiBGZWIgMTV0aCwgMjAxMS4gUGxl YXNlIGluZGljYXRlIHlvdXI8YnI+DQpzdXBwb3J0IG9yIGNvbmNlcm5zIGluIGFkb3B0aW5n IHRoaXMgSS1EIGFzIHRoZSBXRyBiYXNlbGluZSBkb2N1bWVudCBvbjxicj4NCnRoZSBtYWls aW5nIGxpc3QuPGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUgdGhhdCB0aGlzIEktRCB3aWxsIHNl cnZlIGFzIHRoZSBiYXNlbGluZSBpbiB0aGUgV0cgYW5kIHdpbGwgYmU8YnI+DQpkZXZlbG9w ZWQgZnVydGhlciBiYXNlZCBvbiBpbnB1dCBhbmQgZmVlZGJhY2sgZnJvbSBXRyBtZW1iZXJz Ljxicj4NCjxicj4NCi1CYXNhdmFyYWo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm5ldGV4dCBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJuZXRleHRAaWV0Zi5vcmciPm5ldGV4dEBpZXRmLm9yZzwvYT4gJmx0 OzxhIGhyZWY9Imh0dHA6Ly9uZXRleHRAaWV0Zi5vcmciPmh0dHA6Ly9uZXRleHRAaWV0Zi5v cmc8L2E+Jmd0OyAmbmJzcDsmbHQ7PGEgaHJlZj0iaHR0cDovL25ldGV4dEBpZXRmLm9yZyI+ aHR0cDovL25ldGV4dEBpZXRmLm9yZzwvYT4mZ3Q7DQo8YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGV4dCI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRleHQ8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSA8YnI+ClRoaXMgdHJhbnNt aXNzaW9uIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRl bnRpYWwgaW5mb3JtYXRpb24sIHByaXZpbGVnZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRl cmlhbCBwcm90ZWN0ZWQgYnkgdGhlIHNvbGljaXRvci1jbGllbnQgb3Igb3RoZXIgYXBwbGlj YWJsZSBwcml2aWxlZ2VzKSwgb3IgY29uc3RpdHV0ZSBub24tcHVibGljIGluZm9ybWF0aW9u LiBBbnkgdXNlIG9mIHRoaXMgaW5mb3JtYXRpb24gYnkgYW55b25lIG90aGVyIHRoYW4gdGhl IGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5 IHRvIHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGluZm9ybWF0aW9uIGZyb20geW91ciBz eXN0ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvciByZXByb2R1Y3Rp b24gb2YgdGhpcyB0cmFuc21pc3Npb24gYnkgdW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5v dCBhdXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuDQo8L2JvZHk+DQo8L2h0bWw+DQo= ------_=_NextPart_001_01CBC370.B2E458E7-- From telemaco.melia@alcatel-lucent.com Thu Feb 3 02:04:48 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C84AF3A68F1 for ; Thu, 3 Feb 2011 02:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtbvzWwv0cvX for ; Thu, 3 Feb 2011 02:04:25 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 01F483A68E7 for ; Thu, 3 Feb 2011 02:04:24 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p13A7YFp009838 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 3 Feb 2011 11:07:43 +0100 Received: from FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com ([135.120.45.54]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 3 Feb 2011 11:07:41 +0100 From: "MELIA, TELEMACO (TELEMACO)" To: stefano faccin , "Zuniga, Juan Carlos" Date: Thu, 3 Feb 2011 11:07:40 +0100 Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvDKEfVhRTvigQDTYKLdu0oaKRqrwAYN5Mw Message-ID: <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CB1A@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CB1AFRMRSSXCHMBSE_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "netext@ietf.org" Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 03 Feb 2011 10:04:48 -0000 --_000_3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CB1AFRMRSSXCHMBSE_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Stefano, I guess what JC means by "MAG forward the packet with no problem" is that u= pon network attachment the MAG has the required routing states to properly = process packet forwarding. As for your second comment we do not need to modify current specifications.= The authors during the offline discussions agreed on the fact that the LMA= can receive multiple triggers and act upon these triggers to perform flow = mobility (i.e. the act of routing a flow on a different network access). Th= e mechanism JC suggest is another way of sending implicit triggers to the L= MA. We can of course update the text on LMA behaviour but I do not think we= really need to update the specifications. Rajeev commented along the same = lines in earlier mails. telemaco ________________________________ De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part de= stefano faccin Envoy=E9 : mercredi 2 f=E9vrier 2011 23:26 =C0 : Zuniga, Juan Carlos Cc : netext@ietf.org Objet : Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pm= ipv6-flowmob as WG doc Hello JC, thanks for acknowledging that there is indeed an issue with the current dra= ft. For my clarification, how would the "MAG forward the packet with no problem= "? I am not sure I am understanding what the sequence of steps would be. Also, I guess that as you say the solution is not included in the current d= raft, which means modifying the protocol that we have in the current draft. Cheers, Stefano On Wed, Feb 2, 2011 at 12:37 PM, Zuniga, Juan Carlos > wrote: Hi Stefano, Thanks for the response (you forgot to copy the list again ;). What I had in mind was what they call Basic solution in the document, in wh= ich the same set of prefixes are assigned to different interfaces (or MAGs)= . In this case the MN can decide (based on policies) to change the flow and= send packets over a new interface. The MAG would forward the packet with n= o problem and upon receiving this packet the LMA would implicitly know that= the MN has performed a flow movement (again, based on policies). At this p= oint the LMA would just need to change its routing table accordingly and st= art sending packets for this flow over the new interface (similar rule to t= he one already specified for the mobile). I see this as a lightweight solution to the problem you pointed out that co= uld easily be added to the document. Jc From: stefano faccin [mailto:sfaccinstd@gmail.com] Sent: February 2, 2011 3:11 PM To: Zuniga, Juan Carlos Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-p= mipv6-flowmob as WG doc Hi JC, As you say in 3GPP for the MN-based model this has been solved. However, if= we want to apply a similar solution, we go back to the argument that it wo= uld require the MN to be able to communicate the decisions to the MAG/LMA b= ut, as we discussed previously, we don't have a solution for that. This mea= ns that applying this protocol with a model similar to the one currently sp= ecified in IETF and 3GPP requires the definition of a solution that does no= t yet exist (at Layer 3 or at Layer 2). I am concerned about developing onl= y some pieces of a solution. Alternatively, as you say the MAG reacts. However, it is not clear to me th= at the current draft describes how that happens. Cheers, Stefano On Wed, Feb 2, 2011 at 11:56 AM, Zuniga, Juan Carlos > wrote: Stefano, As much as I agree with most of your points about the problem from the 3GPP= architecture point of view, I think that there is more than one solution. We are assuming of course that what we have is a scenario where both networ= ks are in the same PMIP domain and IP flow mobility is then possible. You p= oint out that there are no means to convey policies to the LMA or MAG. Howe= ver, there are means to convey these policies to the MN as it is already de= fined in 3GPP for the client-based IP flow mobility case (i.e. ANDSF). Henc= e, one different solution could be to let the MN apply the policy by moving= the flow and make the MAG and LMA "react" to the IP flow change assuming t= hat the flow change was made according to the policy being applied at the m= obile. I would see this scenario equivalent to the one specified in 3GPP from the = point of view of node's responsibilities, don't you think? Jc From: netext-bounces@ietf.org [mailto:netex= t-bounces@ietf.org] On Behalf Of stefano fa= ccin Sent: February 2, 2011 2:41 PM To: Rajeev Koodli; netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-p= mipv6-flowmob as WG doc Sorry, I forgot to reply to the whole list. Cheers, Stefano On Wed, Feb 2, 2011 at 11:29 AM, stefano faccin > wrote: Hi Rajeev, in current solution the policy is in sync, since it is the ANDSF (the netwo= rk counterpart of the MN for the policy) that configures it in the MN. That= does not mean that the LMA has such policy. Cheers, Stefano On Wed, Feb 2, 2011 at 11:46 AM, Rajeev Koodli > wrote: Hi Gerardo, * my point is that someone/something is configuring the policy on the MN= which needs to be in sync with the MN's partner, i.e., the network. If thi= s is not the case, please let me know. * The last I heard, PMIP6 is applicable on the eHRPD (trusted non-3GPP n= etwork). Also, 33.402 does not specify whether a particular type of access = network (such as WLAN) is considered trusted or untrusted (although a major= ity of the WLAN access could be considered untrusted today). -Rajeev On 2/2/11 11:16 AM, "Giaretta, Gerardo" > wrote: Hi Rajeev, A couple of considerations on this: - This draft assumes there is consistency in the rules. This is a n= ew requirement for the system architecture where this solution will be appl= ied. There is no this requirement for other solutions already adopted by IE= TF and 3GPP. In my view this seems a fairly important issue. - The routing decisions based on WLAN SSID are different from trust= ed/untrusted. Note also that PMIPv6 cannot be used in trusted networks so i= t is not clear at all what you are referring to. Gerardo From: netext-bounces@ietf.org [mailto:netex= t-bounces@ietf.org] On Behalf Of Rajeev Koodli Sent: Wednesday, February 02, 2011 11:28 AM To: stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-p= mipv6-flowmob as WG doc Stefano, Regardless of how the policy is configured on the LMA, there is a consisten= cy of the rules which needs to be ensured regardless. Whatever the entity (= OMA-DM?!) is that configures the policy has to ensure such a consistency. We can debate about how policy interaction works, but that's another topic.= I would note that there are choices here (modulo respective pros and cons)= . I didn't suggest that an operator should just trust the software on a MN, a= lthough I suspect some device vendors might argue for their robustness (sur= prise?). I would frame the WLAN access problem as whether the access is considered t= rusted or not. Accordingly, you apply the policy. -Rajeev On 2/2/11 10:50 AM, "stefano faccin" > wrote: Raj, thanks for the reply. If the LMA has statically configured policies, how do we ensure that the MN= has the same policies? That would mean implicitly assuming that the polici= es provisioned to the MN by the ANDSF "always" match what has been set in t= he LMA, which I think it is unrealistic because the policies change over ti= me, and every time you need to update all the LMAs, which has a considerabl= e operational cost. Instead, if we leave the MN to make the choice, there a= re easy and well specified mechanisms that allow the provisioning of polici= es in the MN and for the MN to make such decision and communicate it to the= network, so that the network can As for extensions to Gx, I am not stating that in theory one could extend G= x. However, at present such solution does not exists, and without it, I do = not see how the draft is applicable to 3GPP that is at present the only pot= ential customer identified (I guess I did not see any other identified?) Even assuming that Gx could be modified, the issue of the per-access networ= k granularity remains. Even if the LMA has the right policies in place, the= LMA has no way of knowing exactly what access network of a specific access= technology (e.g. which SSID for WLAN0 the MN is connecting to. I cannot agree with your assumption below that if the MN connects to an SSI= D it is because the operator is OK with routing traffic on that SSID, and t= hat we should just "trust the software on the MN". There are two aspects to= consider: 1) whether it is OK for certain traffic to be routed at all over a certain = access access network of a specific access technology 2) how different traffic should be routed over different access networks of= different access technologies Regarding these two points, the issue is whether the operator wants to allo= w traffic e.g. over a certain SSID or not. So, in that case, it is obvious = as you say that if the MN has connected to an SSID configured by the operat= or in the MN, then traffic could be allowed over that SSID. However, we nee= d to consider that 3GPP allows the decision of which WLAN the MN can connec= t to based on user preferences. This means that my MN can e.g. connect to m= y home WLAN (which is not controlled necessarily by the operator and whose = SSID the operator does not know) or to a coffee shop WLAN, even if the devi= ce does not have those SSID configured. Those are typical examples of untru= sted WLAN access networks. Therefore, in such cases, just because the MN ha= s connected to a WLAN SSID, does not mean that the operator wants to route = certain traffic over that SSID just because the policy says "route traffic = X over WLAN". That brings us to a solution that, if applied to 3GPP, provides less functi= onality than what is available and has been specified today, so back to my = point above. Unfortunately, there is no solution I am aware of that allows the WLAN netw= ork to indicate to the MAG/LMA the specific SSID (and as you say, there is = no easy solution for that). Due to this and the points above about policy p= rovisioning, it means that the applicability of this solution to a real cas= e like 3GPP depends on the feasibility of extending policy mechanisms in 3G= PP, and the ability to have a solution where the WLAN network provides the = SSID information to the MAG/LMA. Moreover, the provisioning of such SSID is= not in the scope of IETF, but not even of 3GPP (since the interface betwee= n the WLAN AP and the ePDG is not defined), thus I wonder how this could be= defined at all (I am afraid of asking what magic should happen here). So, = now we have two big dependencies. In general, I am also wondering if there is a customer that has asked us to= define this solution. I am not aware of any but I may have missed that. Cheers, Stefano On Wed, Feb 2, 2011 at 10:44 AM, Rajeev Koodli > wrote: Hi Stefano, You make two interesting points: First, the defined solution should be usef= ul for 3GPP deployments. Second, if it's not defined today in 3GPP, it's no= t useful. I tend to agree with you on the first - 3GPP is a big potential customer. I cannot agree with your second point. There are multiple ways I could envision policy on the LMA. Locally configu= red policy is one (which we use today in deployments) that does not need Gx= interaction. Gx extensions can be proposed in the future. I hope you are n= ot suggesting that these are not feasible choices. For the MN (IETF term for UE) to even connect to the MAG via WLAN today, yo= u need an IPsec termination point (ePDG). If the operator pre-configures th= e list of SSIDs or there is some out-of-band mechanism to inform the MN whi= ch SSID is "white-listed", then I expect the MN to decide when to connect t= o the ePDG and hence the MAG. At this point, the MN is already on the WLAN = the operator cares about I presume. There is no easy way for the network (LMA, MAG) to know what SSID the MN is= connected to - the network has to either trust the software on the MN or t= he WLAN infrastructure has to provide the SSID information to the network. -Rajeev On 2/2/11 9:56 AM, "stefano faccin" > wrote: Hello rajeev, the use of PCRF is an interesting suggestion. However, unfortunately, PCRF = does not contain any policies or information that will tell the LMA what ar= e the policies to be used for decisions of IP flow mobility. This is not pa= rt of current PCC functionality, and there is no work ongoing or planned to= extend PCC in such way. Therefore, the applicability of the solution in th= is draft would hinge on hypotetical future solutions and not on a current s= olution for the open issues, which brings us back to my point that we are d= efining a solution with open issues for which there is not a single realist= ic solution out there, thus making this draft not applicable to a real scen= ario. I am not thinking of the UE connecting to more than one WLAN at the same ti= me, but the UE being able to connect to different WLANs (one at a time) bec= ause the UE is e.g. provisioned with a list of SSIDs or the UE discovers a = hotspot somewhere. I am talking about the scenario where the UE is capable = to connect to WLAN, but the operator has different policies wrt which WLAN = the UE should use or not. If you have followed the work in 3GPP, it is clear that operators have inte= rest in applying policies not only at RAT level, but also at access network= level (please see how ANDSF was defined and why). I guess we can all agree= that an operator deploying PMIP-based mobility may be interested in having= policies that allow traffic on the WLAN the operator owns or that belongs = to a roaming partner, while not allowing traffic on WLAN of other operators= for which it might need to pay an extra fee or where e.g. no QoS can be gu= aranteed. That means that the entity deciding whether traffic needs to be r= outed on WLAN or not cannot just consider "WLAN is available", but "WLAN SS= IDx is available", so that the decision can be based on the operator prefer= ences as to which WLAN certain traffic needs to be routed on. If the draft allows decisions to be made only at the RAT level, then we hav= e an issue because we are defining a solution that should be applicable to = 3GPP but does not meet the deployment scenarios of interest. In other words= , if we want to make this solution applicable e.g. to 3GPP, we need to be a= ble to provide the same functionality available today in 3GPP with other so= lution in order to satisfy the use cases supported by 3GPP, and not step ba= ckwards in terms of what can be supported. Cheers, Stefano On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli > wrote: Hi Stefano, Thanks for your input. I expect the LMA interacting with PCRF for policy rules specific to the sub= scriber for different RAT types. You are right that the LMA does not know the SSID the mobile is connected t= o. It's not clear if the MAG can get that from the MN either without additi= onal signaling. However, the LMA knows that the MN is connected to WLAN; so= it can apply the policy at the RAT type level. Are you thinking of the MN = connecting to more than one WLAN network (and each of those connections com= ing back to the LMA)? If so, please explain the scenario. Regards, -Rajeev On 2/1/11 6:39 PM, "stefano faccin" > = wrote: Raj, thanks for the email. I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere). I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability. In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicat= e to the network where the flows should be routed or for the LMA to receive= somehow from somewhere some policies, the solution cannot really provide f= low mobility since there is no way to decide which flows are routed where. = If we are thinking about a host-based solution, I have not yet seen a solut= ion as to how the host can indicate to the MAG and ultimately to the MAG wh= ich flows should be routed on each access. If we are relying on modificatio= ns of layer 2 protocols, aren't we defining a solution that works only with= some technologies (since for other access technologies it is rather unreal= istic to modify L2 for IP flow mobility purposes)? If we are thinking of an= LMA-based solution, can we hear of at least one example of a real-life sce= nario where the LMA would receive such policies, and how such delivery woul= d happen? Also, should there be a solution to have policies in the LMA, how= does the LMA actually decide to route flows on one access or the other? E.= g., if some flows need to be routed on certain WLAN networks, but shall not= be routed on other WLAN networks, how does the LMA know which specific WLA= N network the host is connected to? Perhaps I missed the ability for the MA= G to know e.g. the WLAN SSID and provide it to the LMA, in which case I wou= ld appreciate if somebody could highlight to me where that is defined. I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important. Cheers, Stefano On Tue, Feb 1, 2011 at 3:47 PM, > wrote: Hello, We have discussed the flow mobility solutions for Proxy MIP6 previously at IETFs 78 and 79. This is a consensus call for adopting this I-D: draft-bernardos-netext-pmipv6-flowmob-02 as the working group document. I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt The consensus call will expire on Feb 15th, 2011. Please indicate your support or concerns in adopting this I-D as the WG baseline document on the mailing list. Please note that this I-D will serve as the baseline in the WG and will be developed further based on input and feedback from WG members. -Basavaraj _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext -- Stefano M. Faccin =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D May the Force be with you -- Stefano M. Faccin =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D May the Force be with you -- Stefano M. Faccin =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D May the Force be with you -- Stefano M. Faccin =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D May the Force be with you --_000_3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CB1AFRMRSSXCHMBSE_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Stefa= no,

 =

I guess wha= t JC means by “MAG forward the packet with no problem” is that upon network attachment the MAG has the required routing states to properly proc= ess packet forwarding.

 =

As for your second comment we do not need to modify current specifications. The authors during the offline discussions agreed on the fact that the LMA can receive = multiple triggers and act upon these triggers to perform flow mobility (i.e. the act= of routing a flow on a different network access). The mechanism JC suggest is another way of sending implicit triggers to the LMA. We can of course updat= e the text on LMA behaviour but I do not think we really need to update the specifications. Rajeev commented along the same lines in earlier mails.

 =

telemaco

De : netext-b= ounces@ietf.org [mailto:netext-bounces@ietf.org] De la = part de stefano faccin
Envoy=E9 : mercredi 2 f= =E9vrier 2011 23:26
=C0 : Zuniga, Juan Carl= os
Cc : netext@ietf.org Objet : Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG do= c

 

Hello JC,
thanks for acknowledging that there is indeed an issue with the current dra= ft.

For my clarification, how would the "MAG forward the packet with no problem"? I am not sure I am understanding what the sequence of steps would be.

Also, I guess that as you say the solution is not included in the current draft, which means modifying the protocol that we have in the current draft= .

Cheers,
Stefano

On Wed, Feb 2, 2011 at 12:37 PM, Zuniga, Juan Carlos <JuanCarlos.Zuniga@interd= igital.com> wrote:

Hi Stefano,

 

Thanks for the response (you forgo= t to copy the list again ;). =

 

What I had in mind was what they c= all Basic solution in the document, in which the same set of prefixes are assig= ned to different interfaces (or MAGs). In this case the MN can decide (based on policies) to change the flow and send packets over a new interface. The MAG would forward the packet with no problem and upon receiving this packet the= LMA would implicitly know that the MN has performed a flow movement (again, bas= ed on policies). At this point the LMA would just need to change its routing t= able accordingly and start sending packets for this flow over the new interface (similar rule to the one already specified for the mobile).

 

I see this as a lightweight soluti= on to the problem you pointed out that could easily be added to the document.

 

Jc

 

 

 

From: stefano faccin [mailto:sfaccinstd@gmail.com= ]
Sent: February 2, 2011 3:11 = PM
To: Zuniga, Juan Carlos=


Subject: Re: [netext] Consen= sus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

 

Hi JC,

As you say in 3GPP for the MN-based model this has been solved. However, if= we want to apply a similar solution, we go back to the argument that it would require the MN to be able to communicate the decisions to the MAG/LMA but, = as we discussed previously, we don't have a solution for that. This means that applying this protocol with a model similar to the one currently specified = in IETF and 3GPP requires the definition of a solution that does not yet exist= (at Layer 3 or at Layer 2). I am concerned about developing only some pieces of= a solution.

Alternatively, as you say the MAG reacts. However, it is not clear to me th= at the current draft describes how that happens.

Cheers,
Stefano

On Wed, Feb 2, 2011 at 11:56 AM, Zuniga, Juan Carlos <JuanCa= rlos.Zuniga@interdigital.com> wrote:

Stefano,

 

As much as I agree with most of yo= ur points about the problem from the 3GPP architecture point of view, I think = that there is more than one solution.

 

We are assuming of course that wha= t we have is a scenario where both networks are in the same PMIP domain and IP f= low mobility is then possible. You point out that there are no means to convey policies to the LMA or MAG. However, there are means to convey these polici= es to the MN as it is already defined in 3GPP for the client-based IP flow mobility case (i.e. ANDSF). Hence, one different solution could be to let t= he MN apply the policy by moving the flow and make the MAG and LMA “react” to the IP flow change assuming that the flow change was made according to the policy being applied at the mobile.

 

I would see this scenario equivale= nt to the one specified in 3GPP from the point of view of node’s responsibilities, don’t you think?

 

Jc

 

 

From: netext-bounces@ietf.org [mailto:netext-bounces@ie= tf.org] On Behalf Of stefano faccin<= br> Sent: February 2, 2011 2:41 = PM
To: Rajeev Koodli; netext@ietf.org


Subject: Re: [netext] Consen= sus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

 

Sorry, I forgot to reply to the whole list.
Cheers,
Stefano

On Wed, Feb 2, 2011 at 11:29 AM, stefano faccin <sfaccinstd@gmail.com= > wrote:

Hi Rajeev,
in current solution the policy is in sync, since it is the ANDSF (the netwo= rk counterpart of the MN for the policy) that configures it in the MN. That do= es not mean that the LMA has such policy.

Cheers,
Stefano=

 

On Wed, Feb 2, 2011 at 11:46 AM, Rajeev Koodli <rkoodli@cisco.com> wrote:=


Hi Gerardo,

  • my point is that someone/somet= hing is configuring the policy on the MN which needs to be in sync with the MN’s partner, i.e., the network. If this is not the case, please= let me know.
  • The last I heard, PMIP6 is app= licable on the eHRPD (trusted non-3GPP network). Also, 33.402 does not specify= whether a particular type of access network (such as WLAN) is considered trust= ed or untrusted (although a majority of the WLAN access could be consider= ed untrusted today). <= /li>


-Rajeev




On 2/2/11 11:16 AM, "Giaretta, Gerardo" <gerardog@qualcomm.c= om> wrote:

Hi Rajeev,
 
A couple of considerations on this:
 
-         This draft assumes there = is consistency in the rules. This is a new requirement for the system architec= ture where this solution will be applied. There is no this requirement for other solutions already adopted by IETF and 3GPP. In my view this seems a fairly important issue.

-         The routing decisions bas= ed on WLAN SSID are different from trusted/untrusted. Note also that PMIPv6 ca= nnot be used in trusted networks so it is not clear at all what you are referrin= g to.

 
Gerardo
 

From: netext-bounces@ietf.org [mailto:netext-bou= nces@ietf.org] On Behalf Of Rajeev Koodli Sent: Wednesday, February 02= , 2011 11:28 AM
To: stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil= @nokia.com
Subject: Re: [netext] Consen= sus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc


Stefano,

Regardless of how the policy is configured on the LMA, there is a consisten= cy of the rules which needs to be ensured regardless. Whatever the entity (OMA-DM?!) is that configures the policy has to ensure such a consistency.<= br>
We can debate about how policy interaction works, but that’s another topic. I would note that there are choices here (modulo respective pros and cons).

I didn’t suggest that an operator should just trust the software on a= MN, although I suspect some device vendors might argue for their robustness (surprise?).

I would frame the WLAN access problem as whether the access is considered trusted or not. Accordingly, you apply the policy.

-Rajeev


On 2/2/11 10:50 AM, "stefano faccin" <sfaccinstd@gmail.com= > wrote:
Raj,
thanks for the reply.

If the LMA has statically configured policies, how do we ensure that the MN= has the same policies? That would mean implicitly assuming that the policies provisioned to the MN by the ANDSF "always" match what has been s= et in the LMA, which I think it is unrealistic because the policies change ove= r time, and every time you need to update all the LMAs, which has a considerable operational cost. Instead, if we leave the MN to make the choice, there are easy and well specified mechanisms that allow the provisioning of policies = in the MN and for the MN to make such decision and communicate it to the netwo= rk, so that the network can

As for extensions to Gx, I am not stating that in theory one could extend G= x. However, at present such solution does not exists, and without it, I do not= see how the draft is applicable to 3GPP that is at present the only potential customer identified (I guess I did not see any other identified?)  
Even assuming that Gx could be modified, the issue of the per-access networ= k granularity remains. Even if the LMA has the right policies in place, the L= MA has no way of knowing exactly what access network of a specific access technology (e.g. which SSID for WLAN0 the MN is connecting to.

I cannot agree with your assumption below that if the MN connects to an SSI= D it is because the operator is OK with routing traffic on that SSID, and that w= e should just "trust the software on the MN". There are two aspects= to consider:
1) whether it is OK for certain traffic to be routed at all over a certain access access network of a specific access technology
2) how different traffic should be routed over different access networks of different access technologies

Regarding these two points, the issue is whether the operator wants to allo= w traffic e.g. over a certain SSID or not. So, in that case, it is obvious as= you say that if the MN has connected to an SSID configured by the operator in t= he MN, then traffic could be allowed over that SSID. However, we need to consi= der that 3GPP allows the decision of which WLAN the MN can connect to based on = user preferences. This means that my MN can e.g. connect to my home WLAN (which = is not controlled necessarily by the operator and whose SSID the operator does= not know) or to a coffee shop WLAN, even if the device does not have those SSID configured. Those are typical examples of untrusted WLAN access networks. Therefore, in such cases, just because the MN has connected to a WLAN SSID, does not mean that the operator wants to route certain traffic over that SS= ID just because the policy says "route traffic X over WLAN".

That brings us to a solution that, if applied to 3GPP, provides less functionality than what is available and has been specified today, so back = to my point above.

Unfortunately, there is no solution I am aware of that allows the WLAN netw= ork to indicate to the MAG/LMA the specific SSID (and as you say, there is no e= asy solution for that). Due to this and the points above about policy provision= ing, it means that the applicability of this solution to a real case like 3GPP depends on the feasibility of extending policy mechanisms in 3GPP, and the ability to have a solution where the WLAN network provides the SSID informa= tion to the MAG/LMA. Moreover, the provisioning of such SSID is not in the scope= of IETF, but not even of 3GPP (since the interface between the WLAN AP and the ePDG is not defined), thus I wonder how this could be defined at all (I am afraid of asking what magic should happen here). So, now we have two big dependencies.

In general, I am also wondering if there is a customer that has asked us to define this solution. I am not aware of any but I may have missed that.

Cheers,
Stefano

On Wed, Feb 2, 2011 at 10:44 AM, Rajeev Koodli <rkoodli@cisco.com&g= t; wrote:

Hi Stefano,

You make two interesting points: First, the defined solution should be usef= ul for 3GPP deployments. Second, if it’s not defined today in 3GPP, it’s not useful.=

I tend to agree with you on the first – 3GPP is a big potential custo= mer.
I cannot agree with your second point.

There are multiple ways I could envision policy on the LMA. Locally configu= red policy is one (which we use today in deployments) that does not need Gx interaction. Gx extensions can be proposed in the future. I hope you are no= t suggesting that these are not feasible choices.

For the MN (IETF term for UE) to even connect to the MAG via WLAN today, yo= u need an IPsec termination point (ePDG). If the operator pre-configures the = list of SSIDs or there is some out-of-band mechanism to inform the MN which SSID= is “white-listed”, then I expect the MN to decide when to connect = to the ePDG and hence the MAG. At this point, the MN is already on the WLAN th= e operator cares about I presume.
There is no easy way for the network (LMA, MAG) to know what SSID the MN is connected to – the network has to either trust the software on the MN= or the WLAN infrastructure has to provide the SSID information to the network.=

-Rajeev



On 2/2/11 9:56 AM, "stefano faccin" <sfaccinstd@gmail.com= <http://sfacci= nstd@gmail.com> > wrote:
Hello rajeev,
the use of PCRF is an interesting suggestion. However, unfortunately, PCRF = does not contain any policies or information that will tell the LMA what are the policies to be used for decisions of IP flow mobility. This is not part of current PCC functionality, and there is no work ongoing or planned to exten= d PCC in such way. Therefore, the applicability of the solution in this draft would hinge on hypotetical future solutions and not on a current solution f= or the open issues, which brings us back to my point that we are defining a solution with open issues for which there is not a single realistic solutio= n out there, thus making this draft not applicable to a real scenario.

I am not thinking of the UE connecting to more than one WLAN at the same ti= me, but the UE being able to connect to different WLANs (one at a time) because= the UE is e.g. provisioned with a list of SSIDs or the UE discovers a hotspot somewhere. I am talking about the scenario where the UE is capable to conne= ct to WLAN, but the operator has different policies wrt which WLAN the UE shou= ld use or not.

If you have followed the work in 3GPP, it is clear that operators have inte= rest in applying policies not only at RAT level, but also at access network leve= l (please see how ANDSF was defined and why). I guess we can all agree that a= n operator deploying PMIP-based mobility may be interested in having policies= that allow traffic on the WLAN the operator owns or that belongs to a roaming partner, while not allowing traffic on WLAN of other operators for which it might need to pay an extra fee or where e.g. no QoS can be guaranteed. That means that the entity deciding whether traffic needs to be routed on WLAN o= r not cannot just consider "WLAN is available", but "WLAN SSID= x is available", so that the decision can be based on the operator preferen= ces as to which WLAN certain traffic needs to be routed on.

If the draft allows decisions to be made only at the RAT level, then we hav= e an issue because we are defining a solution that should be applicable to 3GPP = but does not meet the deployment scenarios of interest. In other words, if we w= ant to make this solution applicable e.g. to 3GPP, we need to be able to provid= e the same functionality available today in 3GPP with other solution in order= to satisfy the use cases supported by 3GPP, and not step backwards in terms of what can be supported.

Cheers,

Stefano

On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli <rkoodli@cisco.com &= lt;http://rkoodli@cisco.co= m> > wrote:

Hi Stefano,

Thanks for your input.

I expect the LMA interacting with PCRF for policy rules specific to the subscriber for different RAT types.
You are right that the LMA does not know the SSID the mobile is connected t= o. It’s not clear if the MAG can get that from the MN either without add= itional signaling. However, the LMA knows that the MN is connected to WLAN; so it c= an apply the policy at the RAT type level. Are you thinking of the MN connecti= ng to more than one WLAN network (and each of those connections coming back to= the LMA)? If so, please explain the scenario.

Regards,

-Rajeev




On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com= <http://sfacci= nstd@gmail.com>  <http://= sfaccinstd@gmail.com> > wrote:
Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered before (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicate to = the network where the flows should be routed or for the LMA to receive somehow = from somewhere some policies, the solution cannot really provide flow mobility s= ince there is no way to decide which flows are routed where. If we are thinking about a host-based solution, I have not yet seen a solution as to how the h= ost can indicate to the MAG and ultimately to the MAG which flows should be rou= ted on each access. If we are relying on modifications of layer 2 protocols, ar= en't we defining a solution that works only with some technologies (since for ot= her access technologies it is rather unrealistic to modify L2 for IP flow mobil= ity purposes)? If we are thinking of an LMA-based solution, can we hear of at l= east one example of a real-life scenario where the LMA would receive such polici= es, and how such delivery would happen? Also, should there be a solution to hav= e policies in the LMA, how does the LMA actually decide to route flows on one access or the other? E.g., if some flows need to be routed on certain WLAN networks, but shall not be routed on other WLAN networks, how does the LMA = know which specific WLAN network the host is connected to? Perhaps I missed the ability for the MAG to know e.g. the WLAN SSID and provide it to the LMA, i= n which case I would appreciate if somebody could highlight to me where that = is defined.

I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important.

Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM,  <Basavaraj.Patil= @nokia.com <http://B= asavaraj.Patil@nokia.com>  <ht= tp://Basavaraj.Patil@nokia.com> > wrote:

Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= br> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flow= mob-02.txt

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= br> developed further based on input and feedback from WG members.

-Basavaraj

_______________________________________________
netext mailing list
netext@ietf.org &l= t;http://netext@ietf.org>  <http://netex= t@ietf.org>
= https://www.ietf.org/mailman/listinfo/netext

 
 



--
Stefano M. Faccin
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
May the Force be with you




--
Stefano M. Faccin
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
May the Force be with you




--
Stefano M. Faccin
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
May the Force be with you




--
Stefano M. Faccin
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
May the Force be with you

--_000_3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CB1AFRMRSSXCHMBSE_-- From telemaco.melia@alcatel-lucent.com Thu Feb 3 02:06:42 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 605FA3A68D2 for ; Thu, 3 Feb 2011 02:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jt+-7pad2IGZ for ; Thu, 3 Feb 2011 02:06:40 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id CD89F3A68A0 for ; Thu, 3 Feb 2011 02:06:39 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p13A9s6m003165 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 3 Feb 2011 11:09:55 +0100 Received: from FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com ([135.120.45.54]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 3 Feb 2011 11:09:55 +0100 From: "MELIA, TELEMACO (TELEMACO)" To: "Sri Gundavelli (sgundave)" , Julien Laganier , "cjbc@it.uc3m.es" Date: Thu, 3 Feb 2011 11:09:54 +0100 Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvDM0AHyD43qnn3QvSC6GDbt86rIwAAh/7QABU9/BA= Message-ID: <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CB1C@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> References: <1296689037.3593.20.camel@acorde.it.uc3m.es> In-Reply-To: Accept-Language: en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CB1CFRMRSSXCHMBSE_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 03 Feb 2011 10:06:42 -0000 --_000_3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CB1CFRMRSSXCHMBSE_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Tend to agree on Sri's comment. telemcao 2. there is no need to convey traffic selectors between the MAG and the LMA= . The LMA forwards downlink packets as per the network-based policy, and th= e uplink packets to the Internet. The MAG forwards downlink packets to the = MN, and uplink packets to the LMA. End of the story. As above, unless someo= ne comes up with a rebuttal of why that is not sufficient to address the sc= enario we're concerned with (network-based flow mobility), the traffic sele= ctors shall be removed from the specification. [Sri] I tend to agree. The MAG does not have ability to convey flow level i= nfo over ND interface. At the end of the day, the MAG is hosting a set of p= refixes on a link and that's all. So, the traffic selectors are not needed = from the mobility perspective, but if we look at this as exchange of policy= , we can allow them optionally. But, I'm fine to get rid of this entirely,= but allowing this exchange is not undesirable either. --_000_3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CB1CFRMRSSXCHMBSE_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,=

 =

Tend to agr= ee on Sri’s comment.

 =

telemcao

 =

 

 

2. there is no need to convey traffic selectors between the MAG and the LMA. The LMA forwards downlink packets as per the network-based policy, and the uplink packets to the Internet. The MAG forwa= rds downlink packets to the MN, and uplink packets to the LMA. End of the story= . As above, unless someone comes up with a rebuttal of why that is not suff= icient to address the scenario we're concerned with (network-based flow mobility), th= e traffic selectors shall be removed from the specification.

 

 

[Sri] I tend t= o agree. The MAG does not have ability to convey flow level info over ND interface. At the end of the day, the MAG is hosting a set of prefixes on a link and that’s all. So, the traffic selectors are not needed from th= e mobility perspective, but if we look at this as exchange of policy, we can allow the= m optionally. But,  I’m fine to get rid of this entirely, but allo= wing this exchange is not undesirable either.

 

 

--_000_3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CB1CFRMRSSXCHMBSE_-- From pierrick.seite@orange-ftgroup.com Thu Feb 3 07:32:59 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB7963A69C2 for ; Thu, 3 Feb 2011 07:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2G4VAIetDsfy for ; Thu, 3 Feb 2011 07:32:39 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id B26E33A69AF for ; Thu, 3 Feb 2011 07:32:38 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D4F02768006; Thu, 3 Feb 2011 16:41:01 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id C44F4760004; Thu, 3 Feb 2011 16:41:01 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Feb 2011 16:36:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBC3B8.0EA25FC6" Date: Thu, 3 Feb 2011 16:35:59 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C4620179629E@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <680854867F7FD04BB9B06EB8ACA8D5AC0465FAB1@XCH02DFW.rim.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLwmpURzmRlysrlUidlexdQorGZJPuBh2AgAAR4ICAAAzJgIAACkaAgADJ5gCAAKKGAP//oT5wgAAf2NyAAIzc8A== References: <680854867F7FD04BB9B06EB8ACA8D5AC0465FAB1@XCH02DFW.rim.net> From: To: , , , X-OriginalArrivalTime: 03 Feb 2011 15:36:00.0228 (UTC) FILETIME=[0EF13A40:01CBC3B8] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 03 Feb 2011 15:32:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC3B8.0EA25FC6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 This is an interesting discussion, thanks for bringing the ANDSF issues = on the table. Effectively, mobility control, i.e. access selection, is a = key point for an operator. From an operator point of view, criteria for = selection is not only RAT type or SSID; we can imagine plenty of other = criteria. Different mobility control models can be envisaged such as = Network controlled or terminal controlled and so on... For sure, in PMIP = context, policies synchronization can be an issue and how decision made = on the terminal can interact with network managed mobility should be = discussed. But, I don't think draft-bernardos should go in this space. I = think, we should clearly distinguish mobility functions. IMHO, = draft-bernardos should not be expected to deal with selection = management, or mobility triggers, but only on the handover execution. In = other words, the draft should assume that handover decision has been = made (how decision is made is out of scope) and, then, only focus on = mechanism allowing the LMA to transfer flow(s). Although related, = mobility decision management, e.g. policy based, should be discussed in = a separated thread. =20 BR, Pierrick =20 =20 ________________________________ De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part = de Stefano Faccin Envoy=E9 : jeudi 3 f=E9vrier 2011 08:05 =C0 : gerardog@qualcomm.com; sgundave@cisco.com; sfaccinstd@gmail.com Cc : netext@ietf.org; Basavaraj.Patil@nokia.com Objet : Re: [netext] Consensus call to adopt = I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc =20 Hello Sri, >From a point of view of applicability of the solution, I must agree with = Gerardo that assuming synchronization of policies is an issue of this = solution since it comes with a set of restrictions on how the solution = can be applied. Cheers, Stefano Stefano=20 Stefano M. Faccin=20 Standards Manager=20 Research In Motion=20 122 West John Carpenter Parkway=20 Irving, TX 75039=20 Internal: 820 63451=20 Desk: +1 972 910 3451=20 BlackBerry: +1 510 230 8422=20 sfaccin@rim.com=20 Time zone: PST (GMT -8) =20 From: Giaretta, Gerardo [mailto:gerardog@qualcomm.com]=20 Sent: Wednesday, February 02, 2011 11:13 PM To: Sri Gundavelli ; stefano faccin = =20 Cc: netext@ietf.org ; Basavaraj.Patil@nokia.com = =20 Subject: Re: [netext] Consensus call to adopt I-D: = draft-bernardos-netext-pmipv6-flowmob as WG doc=20 =20 Hi Sri, =20 There is no implicit assumption of synchronized policies. A basic = example that shows that there is no assumption is the following: ANDSF = policies may be based also on location of the UE. For example the UE = should prefer WLAN only in a given location. When the UE is attached = over WLAN there is no way for the PDNGW/HA to verify the location of the = UE and therefore to verify UE actions based on policies. =20 The assumption on synchronization of policies is only applicable to this = draft and I think it is a wrong one.=20 =20 Cheers Gerardo =20 From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of Sri Gundavelli Sent: Wednesday, February 02, 2011 6:50 PM To: stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: = draft-bernardos-netext-pmipv6-flowmob as WG doc =20 Hi Stefano, One comment. Agree with you there is no ANDSF interface to the network node, but the = assumption of synchronized policies between the ANDSF server and the PDN = GW/HA is there, implicitly IMO. With out this assumption, I do not know, = how the HA can ever validate the flow mobility options received in the = BU. If the operator requires any control on enforcing a flow policy = rule, the PDN GW/HA needs to have synchronized policies, without which = its always the client decision. I'm not sure, operators in 3GPP would = like that :)=20 No doubt, the lack of MN-AR interface is surely an issue for supporting = complex flow policies. I realize the issues and I agree with you. But, = the assumption of synchronized policies can offer some solution with = some configuration requirement on the HA (assuming there are no other = issues). There are also the proposals on flow mirroring on the UE ..., = requiring no flow policies. I've not evaluated this, however. Folks can = comment on this. It is also to be noted, for some of the scenarios such, there is no flow = policy interface needed. We can identify what scenarios create any = configuration limitations on the HA and which one's do not . As I've = noted earlier, this is surely an open issue, that we need to discuss in = the WG.=20 Regards Sri =20 On 2/2/11 9:08 AM, "stefano faccin" wrote: Sri, thanks for the reply. Can you clarify in which system or scenario ANDSF = is available to network entities as well? There is no such availability = in 3GPP, and making such information available would require = considerable architectural changes, therefore the applicability of this = solution to what seems to be the only realistic scenario hinges on 3GPP = making considerable architectural changes. I would therefore not be so = hastily concluding that the ANDSF information is available to the LMA = and underestimate what it would really take to make the solution = applicable. If we cannot guarantee that there is at least one realistic solution to = have the MNa nd LMA in synch, how do we expect that this solution is = applicable at all? In 3GPP there is no need to have such implicit = assumption, be cause 1) the MN is provided policies explicitly through = the ANDSF, and 2) it is the MN and only the MN that makes IP flow = mobility decisions and communicates them explicitly (with well defined = signalling) to the LMA, and therefore no magic is needed. There is no = need in 3GPP to have the ANDSF and PDN GW policies synchronized, since = the PDN GW does not use such policies.=20 Sri, in the end it is a matter of whether we develop a solution that = will rely on some unknown magic to be deployed, or a solution that we = know can be deployed in at least one way because there are solutions to = what I consider major open issues. Cheers, Stefano On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli = wrote: Hi Stefano, Thanks for the discussion. As you say, the ANDSF policies are allowing the MN a.) to make the right = network attachment decision and b.) make the access selection on a flow = basis. This same policy that is present in the ANDSF server, is = available for the network nodes as well. I'm not sure, with out this = assumption the solution can work for all currently listed cases. We = clearly need the MN and the LMA to be in synch with respect to the = configured policy. How, that is done, I guess we will not try to know. = I thought even in 3GPP, this is the implied assumption ? But, this is = for you to clarify. Not specifically for IFOM where UE and PDN GW/HA are = negotiating the flow policies, but generally that the PDN GW and the = ANDSF policy server will have synchronized policies. The MAG and the LMA = have the ability to carry this flow policy information in signaling = messages and influence the access selection. The policy is a opaque = object, with extensible formats, when carried in the signaling plane, = should allow the LMA/MAG to apply those access policies, while assuming = MN is following the same rules. These policies can surely reflect the = specific WLAN access/operator specific rule. I'm surely with you, the = lack of MN-AR interface is surely an issue and I see that. But, we need = to understand, what are the limitations with the approach of out of = band policy interfaces and what will be the solution limitations. If we = need to tie the flow movement at the prefix granularity and rely on the = natural ND interface in the form of RA PIO option, more like PDN offload = in MAPCON, or at the granularity of a flow level, is open for = discussion. I want to simplify this draft for sure, we can surely = discuss each of these issues on the WG draft. Regards Sri On 2/1/11 8:29 PM, "stefano faccin" > wrote: Sri, thanks for the reply. I'd like to comment on the "the flow policy decisions need not be based = on the specific WLAN network". Does it mean, as I believe it does, that = the current solution would not allow an operator deploying such solution = to decide to route flows over a specific WLAN or not depending on which = specific WLAN the MN is connected to? E.g. the operator or the entity in = control of the decisions for the routing may want to direct certain = traffic always over WLANs that the operator deploys, and instead route = only some of the traffic over WLANs of roaming partners or of the MN = user home. How does this solution support that scenario if the LMA is = not told specifically which WLAN the MN is connected to? From a = deployment point of view, I do not believe we can afford to leave out = this scenario. Please note that the establishment of a security = relationship between the MN and the MAG, and a specific MAG identity, = cannot guarantee that the LMA knows which specific WLAN access network = the MN is connected to. Assuming that would severely restrict the = deployment scenarios. As for the MN and the LMA being magically in synch, I am very concerned = about a "glass ball" solution. You mention ANDSF defined by 3GPP as a = solution for this "out of band" delivery of policy. Fair enough, however = there is an issue with that. ANDSF is designed specific to be a = MN-centric solution where policies are provisioned in the MN and the MN = decides which network technologies and access networks it needs to = connect to, under what conditions, and which IP traffic needs to be = routed on such accesses. No IP point of attachment in the network (i.e. = the PDN GW in 3GPP that is the LMA in PMIPv6) is aware under any = conditions of such policy. Therefore, even if in order to apply this = solution to 3GPP we wanted to use ANDSF, ANDSF would unfortunately not = provide a solution unless the MN can communicate to the MAG and the LMA = the decisions the MN has taken based on the ANDSF policies. I believe the key point here is that we need to understand how the = solution can be realistically applied to a real scenario, and that we = need to ensure that important and realistic deployment scenarios are not = excluded by the solution. Cheers, Stefano On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli > wrote: Hi Stefano: These are valid points and some good comments. Let me share my thoughts. Carlo's draft is not assuming any new MN-AR interface. Its going with = the assumption there is established policy on the mobile and on the LMA, = which allows the mobile to select the access network at a flow level = granularity, without requiring any explicit signaling between the MAG = and the MN. To large part this is all about out of band policy = interface, such as ANDSF, towards the UE, leading to the assumption that = magically the MN and the LMA are in sync with respect to flow policies, = access selection and they will make the right forwarding decision. = Secondly, the flow policy decisions need not be based on the specific = WLAN network, but it is implicitly driven by the MAG - LMA security = relation, where the MAG attachment to the WLAN network transitively = allows the LMA to make the flow policy decisions based on the MAG = identity. If the WLAN network is not trusted, there is truly no MAG in = that network, where the LMA shares a security relation with that node. There are still some open issues on this draft that needs to be = discussed in the WG. On the approaches to allow more a flow aggregate = movement, that is a discussion point. There are issues that we need to = discuss, supporting split link model, or eliminating some favorite brand = of signaling message (FMA) and riding on PBU/PBA and just with one FMI = trigger, and on the aspects around MN applying the flow policies by flow = mirroring. We have no agreement on those issues yet. Its just a base draft, for further discussion and resolving those = issues. But, hope that is not a stopper for base draft selection. =20 Sri On 2/1/11 6:39 PM, "stefano faccin" > wrote: Raj, thanks for the email. I need to apologize in advance if my questions have already been = answered before (though I cannot find a conclusive answer anywhere). I think that a protocol that is developed in NETEXT (or other groups) = should have at least a potential realistic scenario for applicability. In terms of applicability, though it is not part of the protocol = definition per se, unless there are solutions in place for either the = host to indicate to the network where the flows should be routed or for = the LMA to receive somehow from somewhere some policies, the solution = cannot really provide flow mobility since there is no way to decide = which flows are routed where. If we are thinking about a host-based = solution, I have not yet seen a solution as to how the host can indicate = to the MAG and ultimately to the MAG which flows should be routed on = each access. If we are relying on modifications of layer 2 protocols, = aren't we defining a solution that works only with some technologies = (since for other access technologies it is rather unrealistic to modify = L2 for IP flow mobility purposes)? If we are thinking of an LMA-based = solution, can we hear of at least one example of a real-life scenario = where the LMA would receive such policies, and how such delivery would = happen? Also, should there be a solution to have policies in the LMA, = how does the LMA actually decide to route flows on one access or the = other? E.g., if some flows need to be routed on certain WLAN networks, = but shall not be routed on other WLAN networks, how does the LMA know = which specific WLAN network the host is connected to? Perhaps I missed = the ability for the MAG to know e.g. the WLAN SSID and provide it to the = LMA, in which case I would appreciate if somebody could highlight to me = where that is defined. I think that, though not integral to the protocol specification, = understanding what framework the protocol would/needs to fit in is = rather important.=20 Cheers, Stefano On Tue, Feb 1, 2011 at 3:47 PM, > = wrote: Hello, We have discussed the flow mobility solutions for Proxy MIP6 previously = at IETFs 78 and 79. This is a consensus call for adopting this I-D: draft-bernardos-netext-pmipv6-flowmob-02 as the working group document. I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt The consensus call will expire on Feb 15th, 2011. Please indicate your support or concerns in adopting this I-D as the WG baseline document on the mailing list. Please note that this I-D will serve as the baseline in the WG and will = be developed further based on input and feedback from WG members. -Basavaraj _______________________________________________ netext mailing list netext@ietf.org =20 https://www.ietf.org/mailman/listinfo/netext =20 =20 =20 ---------------------------------------------------------------------=20 This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this = transmission in error, please immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be unlawful.=20 ------_=_NextPart_001_01CBC3B8.0EA25FC6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

Hello,

 

This is an interesting discussion, thanks for = bringing the ANDSF issues on the table. Effectively, mobility control, i.e. = access selection, is a key point for an operator. From an operator point of = view, criteria for selection is not only RAT type or SSID; we can imagine = plenty of other criteria. Different mobility control models can be envisaged such = as Network controlled or terminal controlled and so on... For sure, in PMIP = context, policies synchronization can be an issue and how decision made on the terminal = can interact with network managed mobility should be discussed. But, I don't = think draft-bernardos should go in this space. I think, we should clearly distinguish mobility functions. IMHO, draft-bernardos should not be expected to deal with = selection management, or mobility triggers, but only on the handover execution. In = other words, the draft should assume that handover decision has been made (how decision is made is out of scope) and, then, only focus on mechanism = allowing the LMA to transfer flow(s). Although related, mobility decision management, = e.g. policy based, should be discussed in a separated = thread.

 

BR,

Pierrick

 

 

De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part de Stefano Faccin
Envoy=E9 : jeudi 3 = f=E9vrier 2011 08:05
=C0 : = gerardog@qualcomm.com; sgundave@cisco.com; sfaccinstd@gmail.com
Cc : = netext@ietf.org; Basavaraj.Patil@nokia.com
Objet : Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG = doc

 

Hello = Sri,
>From a point of view of applicability of the solution, I must agree with Gerardo that assuming synchronization of policies is an issue of this = solution since it comes with a set of restrictions on how the solution can be = applied.
Cheers,
Stefano

Stefano
Stefano M. Faccin

Standards Manager
Research In Motion
122 West John Carpenter Parkway
Irving, TX 75039
Internal: 820 63451
Desk: +1 972 910 3451
BlackBerry: +1 510 230 8422
sfaccin@rim.com
Time zone: PST (GMT -8)
 

From: Giaretta, Gerardo [mailto:gerardog@qualcomm.com]
Sent: Wednesday, February = 02, 2011 11:13 PM
To: Sri Gundavelli <sgundave@cisco.com>; stefano faccin <sfaccinstd@gmail.com> =
Cc: netext@ietf.org <netext@ietf.org>; Basavaraj.Patil@nokia.com = <Basavaraj.Patil@nokia.com>
Subject: Re: [netext] = Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc
 

Hi = Sri,

 <= /o:p>

There is no = implicit assumption of synchronized policies. A basic example that shows that = there is no assumption is the following: ANDSF policies may be based also on = location of the UE. For example the UE should prefer WLAN only in a given location. = When the UE is attached over WLAN there is no way for the PDNGW/HA to verify = the location of the UE and therefore to verify UE actions based on = policies.

 <= /o:p>

The = assumption on synchronization of policies is only applicable to this draft and I think = it is a wrong one.

 <= /o:p>

Cheers<= /o:p>

Gerardo=

 <= /o:p>

From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Sri Gundavelli
Sent: Wednesday, February = 02, 2011 6:50 PM
To: stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] = Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG = doc

 

Hi = Stefano,

One comment.

Agree with you there is no ANDSF interface to the network node, but the assumption of synchronized policies between the ANDSF server and the PDN = GW/HA is there, implicitly IMO. With out this assumption, I do not know, how = the HA can ever validate the flow mobility options received in the BU. If the = operator requires any control on enforcing a flow policy rule, the PDN GW/HA = needs to have synchronized policies, without which its always the client = decision. I’m not sure, operators in 3GPP would like that :)

No doubt, the lack of MN-AR interface is surely an issue for supporting = complex flow policies. I realize the issues and I agree with you. But, the = assumption of synchronized policies can offer some solution with some configuration requirement on the HA (assuming there are no other issues). There are = also the proposals on flow mirroring on the UE ..., requiring no flow policies. I’ve not evaluated this, however. Folks can comment on this.

It is also to be noted, for some of the scenarios such, there is no flow = policy interface needed. We can identify what scenarios create any = configuration limitations on the HA and which one’s do not . As I’ve noted earlier, this is surely an open issue, that we need to discuss in the = WG.



Regards
Sri




 


On 2/2/11 9:08 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:

Sri,
thanks for the reply. Can you clarify in which system or scenario ANDSF = is available to network entities as well? There is no such availability in = 3GPP, and making such information available would require considerable = architectural changes, therefore the applicability of this solution to what seems to = be the only realistic scenario hinges on 3GPP making considerable architectural changes. I would therefore not be so hastily concluding that the ANDSF information is available to the LMA and underestimate what it would = really take to make the solution applicable.

If we cannot guarantee that there is at least one realistic solution to = have the MNa nd LMA in synch, how do we expect that this solution is = applicable at all? In 3GPP there is no need to have such implicit assumption, be cause = 1) the MN is provided policies explicitly through the ANDSF, and 2) it is the = MN and only the MN that makes IP flow mobility decisions and communicates them explicitly (with well defined signalling) to the LMA, and therefore no = magic is needed. There is no need in 3GPP to have the ANDSF and PDN GW policies synchronized, since the PDN GW does not use such policies.

Sri, in the end it is a matter of whether we develop a solution that = will rely on some unknown magic to be deployed, or a solution that we know can be deployed in at least one way because there are solutions to what I = consider major open issues.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli <sgundave@cisco.com> wrote:

Hi = Stefano,

Thanks for the discussion.

As you say, the ANDSF policies are allowing the MN a.) to make the right network attachment decision and b.) make the access selection on a flow = basis. This same policy that is present in the ANDSF server, is available for = the network nodes as well. I’m not sure, with out this assumption the solution can work for all currently listed cases. We clearly need the MN = and the LMA to be in synch with respect to the configured policy. How, that = is done, I guess we will not try to know.  I thought even in 3GPP, = this is the implied assumption ? But, this is for you to clarify. Not = specifically for IFOM where UE and PDN GW/HA are negotiating the flow policies, but = generally that the PDN GW and the ANDSF policy server will have synchronized = policies. The MAG and the LMA have the ability to carry this flow policy = information in signaling messages and influence the access selection. The policy is a = opaque object, with extensible formats, when carried in the signaling plane, = should allow the LMA/MAG to apply those access policies, while assuming MN is following the same rules. These policies can surely reflect the specific = WLAN access/operator specific rule. I’m surely with you, the lack of = MN-AR interface is surely an issue and I see that. But, we need to understand, = what are the limitations with the approach of  out of band policy = interfaces and what will be the solution limitations. If we need to tie the flow = movement at the prefix granularity and rely on the natural ND interface in the = form of RA PIO option, more like PDN offload in MAPCON, or at the granularity of = a flow level, is open for discussion. I want to simplify this draft for sure, = we can surely discuss each of these issues on the WG draft.


Regards
Sri






On 2/1/11 8:29 PM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com> > wrote:

Sri,
thanks for the reply.

I'd like to comment on the "the flow = policy decisions need not be based on the specific WLAN network". Does it = mean, as I believe it does, that the current solution would not allow an = operator deploying such solution to decide to route flows over a specific WLAN or = not depending on which specific WLAN the MN is connected to? E.g. the = operator or the entity in control of the decisions for the routing may want to = direct certain traffic always over WLANs that the operator deploys, and instead = route only some of the traffic over WLANs of roaming partners or of the MN = user home. How does this solution support that scenario if the LMA is not told specifically which WLAN the MN is connected to? From a deployment point = of view, I do not believe we can afford to leave out this scenario. Please = note that the establishment of a security relationship between the MN and the = MAG, and a specific MAG identity, cannot guarantee that the LMA knows which = specific WLAN access network the MN is connected to. Assuming that would severely restrict the deployment scenarios.

As for the MN and the LMA being magically in synch, I am very concerned = about a "glass ball" solution. You mention ANDSF defined by 3GPP as a solution for this "out of band" delivery of policy. Fair = enough, however there is an issue with that. ANDSF is designed specific to be a MN-centric solution where policies are provisioned in the MN and the MN = decides which network technologies and access networks it needs to connect to, = under what conditions, and which IP traffic needs to be routed on such = accesses. No IP point of attachment in the network (i.e. the PDN GW in 3GPP that is = the LMA in PMIPv6) is aware under any conditions of such policy. Therefore, even = if in order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would unfortunately not provide a solution unless the MN can communicate to = the MAG and the LMA the decisions the MN has taken based on the ANDSF = policies.

I believe the key point here is that we need to understand how the = solution can be realistically applied to a real scenario, and that we need to ensure = that important and realistic deployment scenarios are not excluded by the = solution.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli <sgundave@cisco.com <http://sgundave@cisco.com> = > wrote:

Hi = Stefano:

These are valid points and some good comments. Let me share my = thoughts.

Carlo’s draft is not assuming any new MN-AR interface. Its going = with the assumption there is established policy on the mobile and on the LMA, = which allows the mobile to select the access network at a flow level = granularity, without requiring any explicit signaling between the MAG and the MN. To = large part this is all about out of band policy interface, such as ANDSF, = towards the UE, leading to the assumption that magically the MN and the LMA are in = sync with respect to flow policies, access selection and they will make the = right forwarding decision. Secondly, the flow policy decisions need not be = based on the specific WLAN network, but it is implicitly driven by the MAG = – LMA security relation, where the MAG attachment to the WLAN network = transitively allows the LMA to make the flow policy decisions based on the MAG = identity. If the WLAN network is not trusted, there is truly no MAG in that network, = where the LMA shares a security relation with that node.

There are still some open issues on this draft that needs to be = discussed in the WG.  On the approaches to allow more a flow aggregate movement, = that is a discussion point. There are issues that we need to discuss, = supporting split link model, or eliminating some favorite brand of signaling = message (FMA) and riding on PBU/PBA and just with one FMI trigger, and on the aspects = around MN applying the flow policies by flow mirroring. We have no agreement on = those issues yet.

Its just a base draft, for further discussion and resolving those = issues. But, hope that is not a stopper for base draft selection.
 

Sri






On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com>  <http://sfaccinstd@gmail.com> > wrote:

Raj,
thanks for the email.

I need to apologize in advance if my questions have already been = answered before (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) = should have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol = definition per se, unless there are solutions in place for either the host to indicate = to the network where the flows should be routed or for the LMA to receive = somehow from somewhere some policies, the solution cannot really provide flow = mobility since there is no way to decide which flows are routed where. If we are = thinking about a host-based solution, I have not yet seen a solution as to how = the host can indicate to the MAG and ultimately to the MAG which flows should be = routed on each access. If we are relying on modifications of layer 2 protocols, = aren't we defining a solution that works only with some technologies (since for = other access technologies it is rather unrealistic to modify L2 for IP flow = mobility purposes)? If we are thinking of an LMA-based solution, can we hear of = at least one example of a real-life scenario where the LMA would receive such = policies, and how such delivery would happen? Also, should there be a solution to = have policies in the LMA, how does the LMA actually decide to route flows on = one access or the other? E.g., if some flows need to be routed on certain = WLAN networks, but shall not be routed on other WLAN networks, how does the = LMA know which specific WLAN network the host is connected to? Perhaps I missed = the ability for the MAG to know e.g. the WLAN SSID and provide it to the = LMA, in which case I would appreciate if somebody could highlight to me where = that is defined.

I think that, though not integral to the protocol specification, = understanding what framework the protocol would/needs to fit in is rather important. =

Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM,  <Basavaraj.Patil@nokia.com <http://Basavaraj.Patil@nokia.co= m>  <http://Basavaraj.Patil@nokia.co= m> > wrote:


Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously = at
IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt

The consensus call will expire on Feb 15th, 2011. Please indicate = your
support or concerns in adopting this I-D as the WG baseline document = on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will = be
developed further based on input and feedback from WG members.

-Basavaraj

_______________________________________________
netext mailing list
netext@ietf.org <http://netext@ietf.org> =  <http://netext@ietf.org>
https://www.ietf.or= g/mailman/listinfo/netext

 

 

 

----------------------------------------------= -----------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than the = intended recipient is prohibited. If you have received this transmission in = error, please immediately reply to the sender and delete this information from = your system. Use, dissemination, distribution, or reproduction of this = transmission by unintended recipients is not authorized and may be unlawful. =

------_=_NextPart_001_01CBC3B8.0EA25FC6-- From behcetsarikaya@yahoo.com Thu Feb 3 08:15:46 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF3F73A6A1A for ; Thu, 3 Feb 2011 08:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYR6CXetQaVE for ; Thu, 3 Feb 2011 08:15:46 -0800 (PST) Received: from nm26-vm1.bullet.mail.sp2.yahoo.com (nm26-vm1.bullet.mail.sp2.yahoo.com [98.139.91.231]) by core3.amsl.com (Postfix) with SMTP id F237C3A6A08 for ; Thu, 3 Feb 2011 08:15:45 -0800 (PST) Received: from [98.139.91.63] by nm26.bullet.mail.sp2.yahoo.com with NNFMP; 03 Feb 2011 16:19:08 -0000 Received: from [98.139.91.9] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 03 Feb 2011 16:19:08 -0000 Received: from [127.0.0.1] by omp1009.mail.sp2.yahoo.com with NNFMP; 03 Feb 2011 16:19:08 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 885252.6498.bm@omp1009.mail.sp2.yahoo.com Received: (qmail 49971 invoked by uid 60001); 3 Feb 2011 16:19:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1296749948; bh=SShoI4Hd+lcYCysr2KSUMvhA+mL6jo/1WqwhuIRTb9s=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=VkrUWnw9CHg2rebtevj1uvqwPekbH8hInKb0YyAFrY/1O2Jx495bWlPoJxpmYq7AO9M7i3eGY34sArPkMhJxaf7WfD3JirToAO5ysS5uouBaCR6nHOwUO71OCGYq11rxMRNOdkwu53zVmSP+r9k9F6nSuMgGP8FbTTpm/u+uKu8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Tuhorc33LGwaTvOP5FkA6UgGO1Zgff4EheyAnwnOZbJ7UBKxUYsKy09JJ44Usv3Gz7CZ/wXYTA3SsWr7AWJ6AUGl00610QrjhT+w1qDY2c36UWtwVwQ0PPkLRdjeGEiazyZkU7bLcBXwTghYAYGvJlu5Q9yzsUwPtl8yGMDqbP4=; Message-ID: <510561.49948.qm@web111403.mail.gq1.yahoo.com> X-YMail-OSG: Pmpy8jsVM1lk3ryfdhl5V2yXay59EYGpnrOUphBdiBDZWOv Q16_l0.5HO9hHufsBYuI68AEb9ghOCR7oZ5PJtbyXtEn_k6OO8hp1xCp5ZUk Cb8n75LF5yBbCivYr6c1gwmSzT5CltwtxUD5jykKWon8T3TQL8wSPWyfU.Ei BEvtjd46kxruDwVc7ajEhxcQXt92vOH7O38pA25P1UNpwzHHEPCxFkcKVmVn VD1XEe1mfx8ICW0BPvKsNMwa4JgMyhr7EZgLbhR9INQhfv8ykPnAKKwO.nio Dypb2jZkEQYRBrU7TcXVdg3s5WdnTZSINmLY5mAp64_gyVnmF5hFZ6SQ8u2J 8GyBcepeGBa12ImMcYmrAWp9bW.tVj9qQHezlwHMHqpkHnvH03iczP_Uv7Fl IJS.gn.MOaQT. Received: from [71.170.141.239] by web111403.mail.gq1.yahoo.com via HTTP; Thu, 03 Feb 2011 08:19:08 PST X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.108.291010 References: <680854867F7FD04BB9B06EB8ACA8D5AC0465FAB1@XCH02DFW.rim.net> <843DA8228A1BA74CA31FB4E111A5C4620179629E@ftrdmel0.rd.francetelecom.fr> Date: Thu, 3 Feb 2011 08:19:08 -0800 (PST) From: Behcet Sarikaya To: pierrick.seite@orange-ftgroup.com In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C4620179629E@ftrdmel0.rd.francetelecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 16:15:46 -0000 Hi Pierrick, >Hello, > >This is an interesting discussion, thanks for bringing the ANDSF issues on the >table. Effectively, mobility control, i.e. access selection, is a key point for >an operator. From an operator point of view, criteria for selection is not only >RAT type or SSID; we can imagine plenty of other criteria. Different mobility >control models can be envisaged such as Network controlled or terminal >controlled and so on... For sure, in PMIP context, policies synchronization can >be an issue and how decision made on the terminal can interact with network >managed mobility should be discussed. But, I don't think draft-bernardos should >go in this space. I think, we should clearly distinguish mobility functions. >IMHO, draft-bernardos should not be expected to deal with selection management, >or mobility triggers, + 1 > but only on the handover execution. In other words, the >draft should assume that handover decision has been made (how decision is made >is out of scope) and, then, only focus on mechanism allowing the LMA to transfer > >flow(s). Although related, mobility decision management, e.g. policy based, >should be discussed in a separated thread. Why do you say flow mobility should be tied only to handover? Handovers may happen in the same technology not necessarily requiring any flow mobility. If it is an inter technology handover then flow mobility may be required. draft-bernardos makes it as if flow = prefix. Why? Maybe because of what you said above. In fact flow >= prefix. And flow mobility >= handover. Flow mobility may not necessarily be tied to handover. There are all sorts of cases. Flow mobility's basic assumption is availability of simultaneously active interfaces. Defining an abstract flow mobility protocol would fit to all those cases, IMHO. Regards, Behcet From julien.ietf@gmail.com Thu Feb 3 10:49:23 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DF793A6AAD for ; Thu, 3 Feb 2011 10:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sFQXjRP+xhE for ; Thu, 3 Feb 2011 10:49:22 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id A32443A6A47 for ; Thu, 3 Feb 2011 10:49:21 -0800 (PST) Received: by eyd10 with SMTP id 10so936394eyd.31 for ; Thu, 03 Feb 2011 10:52:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PWDJLzz/m1MJRKwXPp7NRE9AlndLQah0jyPA9uOIhxI=; b=xi2yn5WLiqW+9E3kZLHp2744Q+ky1O0aW5iFPMuxTPyHjrLOaSTp67yzlMwa3mCbWZ ef9cZbKHZuTT8Ww92ygooiiwGyXpd2JVqx6AOlDawpHyhUfYnpE8Ild4K+xrs7up+ugH 3HrAp0nozDEmIyfvHXWC+WRmUsgr26T1+WrVc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Zzil8P4GIsnnfKvcW5LtYY0FPuD+9sG5nFtgGGDm/WPhDHjoki48p6pN0UeNeoKAmf MrQkRB57cd33rqk2kB7Uq6eYxuvkbUcF/5Aut3+cUwL/8PKyuA1KJx/4TCojPoZvaBaG Q20tjstF1fgfwB9dkyRUk6DxCAQ5BwnhC5S3Y= MIME-Version: 1.0 Received: by 10.103.220.10 with SMTP id x10mr6475637muq.93.1296759163731; Thu, 03 Feb 2011 10:52:43 -0800 (PST) Received: by 10.103.221.9 with HTTP; Thu, 3 Feb 2011 10:52:43 -0800 (PST) In-Reply-To: References: <1296689037.3593.20.camel@acorde.it.uc3m.es> Date: Thu, 3 Feb 2011 10:52:43 -0800 Message-ID: From: Julien Laganier To: "Sri Gundavelli (sgundave)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 03 Feb 2011 18:49:23 -0000 Hi Sri, Please see inline: On Wed, Feb 2, 2011 at 4:13 PM, Sri Gundavelli (sgundave) wrote: > > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of Julien Laganier > Sent: Wednesday, February 02, 2011 3:45 PM > To: cjbc@it.uc3m.es > > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext= -pmipv6-flowmob as WG doc > > > 1. there is no need to support multiple addressing models. All scenarios = can be supported by a single addressing model in which each PMIPv6 session = maps to a set of prefixes that are equally accessible through the set of ph= ysical interfaces attached to that PMIPv6 session. This allows all scenario= s, including one in which two prefix sets are available through different p= hysical interfaces set. I understand that the WG has been divided on that q= uestion but that does not constitute a mandate to include everyone's wish l= ist =A0in a standard specification. Thus unless someone can come up with a= =A0rebuttal=A0of my argument on why single addressing model (prefix-set per= interface-set) satisfies all scenarios, e.g., by pointing out a scenario i= n which it does not, that should be the only addressing model supported in = that spec. > > > > [Sri] I guess, this goes back to our last discussion in this list. We all= ow the hosting of multiple prefixes on an IPv6 link and the base RFC-5213 a= llows the same. You agreed and your comments on to take the approach of ses= sion management, as supposed to addressing models. Now, we allow the abilit= y to move a full/partial set of prefixes to a different interface, and opti= onally allow the sharing of prefixes across links. This is one issue to dis= cuss the shared link approach and see how to capture the final text. The te= xt can be updated once we decide the scenarios that we support. This also p= robably ties to the policy interface to MN. Lets take this as an open issue= . Adopting a solution draft before we have decided what scenarios we want to support with solution sounds a bit like putting the cart before the horse. In the addressing model I outlined: at PMIPv6 session creation a set of prefixes is assigned the mobile node's session. Then physical interfaces can attach to / detach from this session. A single mobile node can also have multiple sessions (say 2) in parallel, associated with distinct set of prefixes, which results in the ability for the prefixes set to move across interfaces fully or partially as the interfaces are attached to / detached from the session. So all scenarios are supported in this simple addressing model which also has a minimal deviation from the basic 5213 model. If you think this model places unreasonable limitations on what scenarios can be supported, please explain how and why. >From my perspective the way forward is to revise the individual draft submission to document this addressing model only, after which we know what we are asked to adopt as a WG item. > 2. there is no need to convey traffic selectors between the MAG and the L= MA. The LMA forwards downlink packets as per the network-based policy, and = the uplink packets to the Internet. The MAG forwards downlink packets to th= e MN, and uplink packets to the LMA. End of the story. As above, unless som= eone comes up with a rebuttal of why that is not=A0sufficient=A0to address = the scenario we're concerned with (network-based flow mobility), the traffi= c selectors shall be removed from the specification. > > [Sri] I tend to agree. The MAG does not have ability to convey flow level= info over ND interface. At the end of the day, the MAG is hosting a set of= prefixes on a link and that=92s all. So, the traffic selectors are not nee= ded from the mobility perspective, but if we look at this as exchange of po= licy, we can allow them optionally. But, =A0I=92m fine to get rid of this e= ntirely, but allowing this exchange is not undesirable either. > As you rightfully note, "the traffic selectors are not needed from the mobility perspective." Thus, since PMIPv6 is not a policy exchange protocol (or did it stand for Policy and Mobility for IPv6 ;-) they are undesirable, should not be allowed optionally, and should be getting rid of entirely :-) Best, --julien From rkoodli@cisco.com Thu Feb 3 12:49:03 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D0C13A6AF5 for ; Thu, 3 Feb 2011 12:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.198 X-Spam-Level: X-Spam-Status: No, score=-110.198 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3n0Di3erKmx for ; Thu, 3 Feb 2011 12:49:02 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 171323A6405 for ; Thu, 3 Feb 2011 12:49:02 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD+kSk2tJV2Y/2dsb2JhbAClNHOiPJsKhVgEhHmGbYMzgwE Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-2.cisco.com with ESMTP; 03 Feb 2011 20:52:24 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p13KqO3n010214; Thu, 3 Feb 2011 20:52:24 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Feb 2011 14:52:24 -0600 Received: from 10.21.83.244 ([10.21.83.244]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 Feb 2011 20:52:23 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 03 Feb 2011 13:10:52 -0800 From: Rajeev Koodli To: Julien Laganier , "Sri Gundavelli (sgundave)" Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvD5taSRyhTTuntcECoUjZ8eZ2ByA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Feb 2011 20:52:24.0292 (UTC) FILETIME=[42538240:01CBC3E4] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 03 Feb 2011 20:49:03 -0000 Hi Julien, On 2/3/11 10:52 AM, "Julien Laganier" wrote: > In the addressing model I outlined: at PMIPv6 session creation a set > of prefixes is assigned the mobile node's session. Then physical > interfaces can attach to / detach from this session. A single mobile > node can also have multiple sessions (say 2) in parallel, associated > with distinct set of prefixes, which results in the ability for the > prefixes set to move across interfaces fully or partially as the > interfaces are attached to / detached from the session. So all > scenarios are supported in this simple addressing model which also has > a minimal deviation from the basic 5213 model. > If I understand this correctly, the LMA has a set of prefixes (which are pre-assigned on *some* attach) which remain constant, but the physical interfaces come and go. This is another way to look at the problem, agree. I think this scenario is covered in the draft (perhaps not necessarily with the same thinking as yours) where the LMA is free to allocate whatever and any number of the prefix(es) it wishes to assign on any attach. So, if the LMA chooses to move a flow from one MAG to another, it need not perform any signaling. What this does not provide me is the flexibility, for instance, of providing a prefix *when* I want to provide it, and assigning a prefix based on what the physical interface the MN is attached to (so that I could route traffic differently at the LMA if I so choose). I also would like to be able to offer a prefix and revoke it based on TOD triggers. I do not *have* to pre-assign my prefixes in anticipation of *potential* flow mobility. Regards, -Rajeev From sgundave@cisco.com Thu Feb 3 13:46:47 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE9B33A6A4D for ; Thu, 3 Feb 2011 13:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.302 X-Spam-Level: X-Spam-Status: No, score=-8.302 tagged_above=-999 required=5 tests=[AWL=-1.166, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63gGWgsg0Roe for ; Thu, 3 Feb 2011 13:46:46 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A544E3A6A4A for ; Thu, 3 Feb 2011 13:46:46 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8CAE+ySk2rR7Ht/2dsb2JhbACWUI19ZgJzoiGbBYVYBIR5hm2DM4MBghc Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 03 Feb 2011 21:50:03 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p13Lo32P004590; Thu, 3 Feb 2011 21:50:03 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Feb 2011 13:50:03 -0800 Received: from 171.70.228.143 ([171.70.228.143]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 Feb 2011 21:50:02 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 03 Feb 2011 13:50:37 -0800 From: Sri Gundavelli To: Julien Laganier Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvD7GQkCJ5HT13gdUqW89BBonO/ww== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 03 Feb 2011 21:50:03.0683 (UTC) FILETIME=[5048AF30:01CBC3EC] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 03 Feb 2011 21:46:48 -0000 Hi Julien, Thanks for your response, please see inline. On 2/3/11 10:52 AM, "Julien Laganier" wrote: > Hi Sri, >=20 > Please see inline: >=20 > On Wed, Feb 2, 2011 at 4:13 PM, Sri Gundavelli (sgundave) > wrote: >>=20 >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf= Of >> Julien Laganier >> Sent: Wednesday, February 02, 2011 3:45 PM >> To: cjbc@it.uc3m.es >>=20 >> Cc: netext@ietf.org; Basavaraj.Patil@nokia.com >> Subject: Re: [netext] Consensus call to adopt I-D: >> draft-bernardos-netext-pmipv6-flowmob as WG doc >>=20 >>=20 >> 1. there is no need to support multiple addressing models. All scenarios= can >> be supported by a single addressing model in which each PMIPv6 session m= aps >> to a set of prefixes that are equally accessible through the set of phys= ical >> interfaces attached to that PMIPv6 session. This allows all scenarios, >> including one in which two prefix sets are available through different >> physical interfaces set. I understand that the WG has been divided on th= at >> question but that does not constitute a mandate to include everyone's wi= sh >> list =A0in a standard specification. Thus unless someone can come up with >> a=A0rebuttal=A0of my argument on why single addressing model (prefix-set per >> interface-set) satisfies all scenarios, e.g., by pointing out a scenario= in >> which it does not, that should be the only addressing model supported in= that >> spec. >>=20 >>=20 >>=20 >> [Sri] I guess, this goes back to our last discussion in this list. We al= low >> the hosting of multiple prefixes on an IPv6 link and the base RFC-5213 a= llows >> the same. You agreed and your comments on to take the approach of sessio= n >> management, as supposed to addressing models. Now, we allow the ability = to >> move a full/partial set of prefixes to a different interface, and option= ally >> allow the sharing of prefixes across links. This is one issue to discuss= the >> shared link approach and see how to capture the final text. The text can= be >> updated once we decide the scenarios that we support. This also probably= ties >> to the policy interface to MN. Lets take this as an open issue. >=20 > Adopting a solution draft before we have decided what scenarios we > want to support with solution sounds a bit like putting the cart > before the horse. >=20 > In the addressing model I outlined: at PMIPv6 session creation a set > of prefixes is assigned the mobile node's session. Then physical > interfaces can attach to / detach from this session. A single mobile > node can also have multiple sessions (say 2) in parallel, associated > with distinct set of prefixes, which results in the ability for the > prefixes set to move across interfaces fully or partially as the > interfaces are attached to / detached from the session. So all > scenarios are supported in this simple addressing model which also has > a minimal deviation from the basic 5213 model. >=20 > If you think this model places unreasonable limitations on what > scenarios can be supported, please explain how and why. >=20 > From my perspective the way forward is to revise the individual draft > submission to document this addressing model only, after which we know > what we are asked to adopt as a WG item. >=20 This way of structuring makes sense. Having the ability to create one more mobility sessions with distinct set of prefixes and bind those prefixes uniquely to individual interfaces associated to the mobility session, and have the ability to move the session objects between interfaces (as in 5213), and/or have the ability to move partial/full set of prefixes between those session objects, or between interfaces part of the session object. Very much close to what is in base spec. This covers the cases I'm looking for and should keep simple ND requirements on the access link. Its still a simple hosted IPv6 link. We just need to make sure, the signaling semantics are clearly presented and have access technology type awareness in the stat= e change decisions. In general, I agree, this presentation approach should greatly clarify things. =20 >> 2. there is no need to convey traffic selectors between the MAG and the = LMA. >> The LMA forwards downlink packets as per the network-based policy, and t= he >> uplink packets to the Internet. The MAG forwards downlink packets to the= MN, >> and uplink packets to the LMA. End of the story. As above, unless someon= e >> comes up with a rebuttal of why that is not=A0sufficient=A0to address the >> scenario we're concerned with (network-based flow mobility), the traffic >> selectors shall be removed from the specification. >>=20 >> [Sri] I tend to agree. The MAG does not have ability to convey flow leve= l >> info over ND interface. At the end of the day, the MAG is hosting a set = of >> prefixes on a link and that=B9s all. So, the traffic selectors are not nee= ded >> from the mobility perspective, but if we look at this as exchange of pol= icy, >> we can allow them optionally. But, =A0I=B9m fine to get rid of this entirely= , but >> allowing this exchange is not undesirable either. >>=20 >=20 > As you rightfully note, "the traffic selectors are not needed from the > mobility perspective." Thus, since PMIPv6 is not a policy exchange > protocol (or did it stand for Policy and Mobility for IPv6 ;-) they > are undesirable, should not be allowed optionally, and should be > getting rid of entirely :-) >=20 Works for me. No traffic spec in the protocol signaling is fine with me. Regards Sri > Best, >=20 > --julien From sfaccin@rim.com Thu Feb 3 14:19:19 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 144123A6B14 for ; Thu, 3 Feb 2011 14:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.778 X-Spam-Level: X-Spam-Status: No, score=-4.778 tagged_above=-999 required=5 tests=[AWL=-0.576, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zi55+t4TCgCB for ; Thu, 3 Feb 2011 14:18:57 -0800 (PST) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 0BD333A6B25 for ; Thu, 3 Feb 2011 14:18:55 -0800 (PST) X-AuditID: 0a401fcb-b7bb3ae000007d4f-27-4d4b2a994dc5 Received: from XCH138CNC.rim.net ( [10.65.20.127]) by mhs03ykf.rim.net (RIM Mail) with SMTP id 12.28.32079.99A2B4D4; Thu, 3 Feb 2011 17:22:17 -0500 (EST) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH138CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Feb 2011 17:22:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CBC3F0.CF3D4DF0" Date: Thu, 3 Feb 2011 16:22:14 -0600 Message-ID: <680854867F7FD04BB9B06EB8ACA8D5AC05E1F0A3@XCH02DFW.rim.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLwmpURzmRlysrlUidlexdQorGZJPuBh2AgAAR4ICAAAzJgIAACkaAgADJ5gCAAKKGAP//oT5wgAEesLA= References: From: "Stefano Faccin" To: "Giaretta, Gerardo" , "Sri Gundavelli" , "stefano faccin" X-OriginalArrivalTime: 03 Feb 2011 22:22:17.0621 (UTC) FILETIME=[D1003450:01CBC3F0] X-Brightmail-Tracker: AAAABgAAAZEXVB72F1QozBdUKM0XVCjOF1TWuQ== Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 03 Feb 2011 22:19:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC3F0.CF3D4DF0 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CBC3F0.CF3D4DF0" ------_=_NextPart_002_01CBC3F0.CF3D4DF0 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Hi Sri, I need to agree with the Gerardo. You are making an assumption that is incorrect.Synchronizing policies between the MN and the LMA is not an easy and scalable solution. I understand synchronizing policies between a MN and a policy server that is the only repository for a given MN (i.e. one MN has its policy in a single policy server). Assuming that all the LMAs in a network that the MN can be connected to have synchronized policies with the MN is clearly not realistic. As as for simplified policies versus what current solutions already provide (e.g. per access network policy and not just per access technology), why should we go ahead with a solution that brings us back in time wrt what we can provide to users and operators? Please note that even today (and not just future releases of 3GPP or future IETF protocols) there are deployment scenarios where the decisions to choose or not whether to route traffic over a certain WLAN is based on the specific WLAN (e.g. SSID) and not just on the fact that the MN is connected to WLAN. Therefore, if we want to provide a protocol for network based flow mobility to provide an alternative to existing solutions, we need to provide a solution that realistically provides the same functionality. Cheers, Stefano Faccin Standards Manager Research In Motion Corporation 5000 Riverside Drive Building 6, Brazos East, Ste. 100 Irving, Texas 75039 USA Office: (972) 910 3451 Internal: 820.63451 : (510) 230 8422 www.rim.com ; www.blackberry.com P Consider the environment before printing. From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Giaretta, Gerardo Sent: Wednesday, February 02, 2011 9:14 PM To: Sri Gundavelli; stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Hi Sri, There is no implicit assumption of synchronized policies. A basic example that shows that there is no assumption is the following: ANDSF policies may be based also on location of the UE. For example the UE should prefer WLAN only in a given location. When the UE is attached over WLAN there is no way for the PDNGW/HA to verify the location of the UE and therefore to verify UE actions based on policies. The assumption on synchronization of policies is only applicable to this draft and I think it is a wrong one. Cheers Gerardo From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Sri Gundavelli Sent: Wednesday, February 02, 2011 6:50 PM To: stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Hi Stefano, One comment. Agree with you there is no ANDSF interface to the network node, but the assumption of synchronized policies between the ANDSF server and the PDN GW/HA is there, implicitly IMO. With out this assumption, I do not know, how the HA can ever validate the flow mobility options received in the BU. If the operator requires any control on enforcing a flow policy rule, the PDN GW/HA needs to have synchronized policies, without which its always the client decision. I'm not sure, operators in 3GPP would like that :) No doubt, the lack of MN-AR interface is surely an issue for supporting complex flow policies. I realize the issues and I agree with you. But, the assumption of synchronized policies can offer some solution with some configuration requirement on the HA (assuming there are no other issues). There are also the proposals on flow mirroring on the UE ..., requiring no flow policies. I've not evaluated this, however. Folks can comment on this. It is also to be noted, for some of the scenarios such, there is no flow policy interface needed. We can identify what scenarios create any configuration limitations on the HA and which one's do not . As I've noted earlier, this is surely an open issue, that we need to discuss in the WG. Regards Sri On 2/2/11 9:08 AM, "stefano faccin" wrote: Sri, thanks for the reply. Can you clarify in which system or scenario ANDSF is available to network entities as well? There is no such availability in 3GPP, and making such information available would require considerable architectural changes, therefore the applicability of this solution to what seems to be the only realistic scenario hinges on 3GPP making considerable architectural changes. I would therefore not be so hastily concluding that the ANDSF information is available to the LMA and underestimate what it would really take to make the solution applicable. If we cannot guarantee that there is at least one realistic solution to have the MNa nd LMA in synch, how do we expect that this solution is applicable at all? In 3GPP there is no need to have such implicit assumption, be cause 1) the MN is provided policies explicitly through the ANDSF, and 2) it is the MN and only the MN that makes IP flow mobility decisions and communicates them explicitly (with well defined signalling) to the LMA, and therefore no magic is needed. There is no need in 3GPP to have the ANDSF and PDN GW policies synchronized, since the PDN GW does not use such policies. Sri, in the end it is a matter of whether we develop a solution that will rely on some unknown magic to be deployed, or a solution that we know can be deployed in at least one way because there are solutions to what I consider major open issues. Cheers, Stefano On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli wrote: Hi Stefano, Thanks for the discussion. As you say, the ANDSF policies are allowing the MN a.) to make the right network attachment decision and b.) make the access selection on a flow basis. This same policy that is present in the ANDSF server, is available for the network nodes as well. I'm not sure, with out this assumption the solution can work for all currently listed cases. We clearly need the MN and the LMA to be in synch with respect to the configured policy. How, that is done, I guess we will not try to know. I thought even in 3GPP, this is the implied assumption ? But, this is for you to clarify. Not specifically for IFOM where UE and PDN GW/HA are negotiating the flow policies, but generally that the PDN GW and the ANDSF policy server will have synchronized policies. The MAG and the LMA have the ability to carry this flow policy information in signaling messages and influence the access selection. The policy is a opaque object, with extensible formats, when carried in the signaling plane, should allow the LMA/MAG to apply those access policies, while assuming MN is following the same rules. These policies can surely reflect the specific WLAN access/operator specific rule. I'm surely with you, the lack of MN-AR interface is surely an issue and I see that. But, we need to understand, what are the limitations with the approach of out of band policy interfaces and what will be the solution limitations. If we need to tie the flow movement at the prefix granularity and rely on the natural ND interface in the form of RA PIO option, more like PDN offload in MAPCON, or at the granularity of a flow level, is open for discussion. I want to simplify this draft for sure, we can surely discuss each of these issues on the WG draft. Regards Sri On 2/1/11 8:29 PM, "stefano faccin" > wrote: Sri, thanks for the reply. I'd like to comment on the "the flow policy decisions need not be based on the specific WLAN network". Does it mean, as I believe it does, that the current solution would not allow an operator deploying such solution to decide to route flows over a specific WLAN or not depending on which specific WLAN the MN is connected to? E.g. the operator or the entity in control of the decisions for the routing may want to direct certain traffic always over WLANs that the operator deploys, and instead route only some of the traffic over WLANs of roaming partners or of the MN user home. How does this solution support that scenario if the LMA is not told specifically which WLAN the MN is connected to? From a deployment point of view, I do not believe we can afford to leave out this scenario. Please note that the establishment of a security relationship between the MN and the MAG, and a specific MAG identity, cannot guarantee that the LMA knows which specific WLAN access network the MN is connected to. Assuming that would severely restrict the deployment scenarios. As for the MN and the LMA being magically in synch, I am very concerned about a "glass ball" solution. You mention ANDSF defined by 3GPP as a solution for this "out of band" delivery of policy. Fair enough, however there is an issue with that. ANDSF is designed specific to be a MN-centric solution where policies are provisioned in the MN and the MN decides which network technologies and access networks it needs to connect to, under what conditions, and which IP traffic needs to be routed on such accesses. No IP point of attachment in the network (i.e. the PDN GW in 3GPP that is the LMA in PMIPv6) is aware under any conditions of such policy. Therefore, even if in order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would unfortunately not provide a solution unless the MN can communicate to the MAG and the LMA the decisions the MN has taken based on the ANDSF policies. I believe the key point here is that we need to understand how the solution can be realistically applied to a real scenario, and that we need to ensure that important and realistic deployment scenarios are not excluded by the solution. Cheers, Stefano On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli > wrote: Hi Stefano: These are valid points and some good comments. Let me share my thoughts. Carlo's draft is not assuming any new MN-AR interface. Its going with the assumption there is established policy on the mobile and on the LMA, which allows the mobile to select the access network at a flow level granularity, without requiring any explicit signaling between the MAG and the MN. To large part this is all about out of band policy interface, such as ANDSF, towards the UE, leading to the assumption that magically the MN and the LMA are in sync with respect to flow policies, access selection and they will make the right forwarding decision. Secondly, the flow policy decisions need not be based on the specific WLAN network, but it is implicitly driven by the MAG - LMA security relation, where the MAG attachment to the WLAN network transitively allows the LMA to make the flow policy decisions based on the MAG identity. If the WLAN network is not trusted, there is truly no MAG in that network, where the LMA shares a security relation with that node. There are still some open issues on this draft that needs to be discussed in the WG. On the approaches to allow more a flow aggregate movement, that is a discussion point. There are issues that we need to discuss, supporting split link model, or eliminating some favorite brand of signaling message (FMA) and riding on PBU/PBA and just with one FMI trigger, and on the aspects around MN applying the flow policies by flow mirroring. We have no agreement on those issues yet. Its just a base draft, for further discussion and resolving those issues. But, hope that is not a stopper for base draft selection. Sri On 2/1/11 6:39 PM, "stefano faccin" > wrote: Raj, thanks for the email. I need to apologize in advance if my questions have already been answered before (though I cannot find a conclusive answer anywhere). I think that a protocol that is developed in NETEXT (or other groups) should have at least a potential realistic scenario for applicability. In terms of applicability, though it is not part of the protocol definition per se, unless there are solutions in place for either the host to indicate to the network where the flows should be routed or for the LMA to receive somehow from somewhere some policies, the solution cannot really provide flow mobility since there is no way to decide which flows are routed where. If we are thinking about a host-based solution, I have not yet seen a solution as to how the host can indicate to the MAG and ultimately to the MAG which flows should be routed on each access. If we are relying on modifications of layer 2 protocols, aren't we defining a solution that works only with some technologies (since for other access technologies it is rather unrealistic to modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-based solution, can we hear of at least one example of a real-life scenario where the LMA would receive such policies, and how such delivery would happen? Also, should there be a solution to have policies in the LMA, how does the LMA actually decide to route flows on one access or the other? E.g., if some flows need to be routed on certain WLAN networks, but shall not be routed on other WLAN networks, how does the LMA know which specific WLAN network the host is connected to? Perhaps I missed the ability for the MAG to know e.g. the WLAN SSID and provide it to the LMA, in which case I would appreciate if somebody could highlight to me where that is defined. I think that, though not integral to the protocol specification, understanding what framework the protocol would/needs to fit in is rather important. Cheers, Stefano On Tue, Feb 1, 2011 at 3:47 PM, > wrote: Hello, We have discussed the flow mobility solutions for Proxy MIP6 previously at IETFs 78 and 79. This is a consensus call for adopting this I-D: draft-bernardos-netext-pmipv6-flowmob-02 as the working group document. I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt The consensus call will expire on Feb 15th, 2011. Please indicate your support or concerns in adopting this I-D as the WG baseline document on the mailing list. Please note that this I-D will serve as the baseline in the WG and will be developed further based on input and feedback from WG members. -Basavaraj _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_002_01CBC3F0.CF3D4DF0 Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable Re: [netext] Consensus call to adopt I-D: draft-b= ernardos-netext-pmipv6-flowmob as WG doc

Hi Sri,=

I need to agree with the Gerardo= . You are making an assumption that is incorrect.Synchronizing policies betw= een the MN and the LMA is not an easy and scalable solution. I understand sy= nchronizing policies between a MN and a policy server that is the only repos= itory for a given MN (i.e. one MN has its policy in a single policy server).= Assuming that all the LMAs in a network that the MN can be connected to hav= e synchronized policies with the MN is clearly not realistic.


As as for simplified policies versus w= hat current solutions already provide (e.g. per access network policy and no= t just per access technology), why should we go ahead with a solution that b= rings us back in time wrt what we can provide to users and operators? Please= note that even today (and not just future releases of 3GPP or future= IETF protocols) there are deployment scenarios where the decisions to choos= e or not whether to route traffic over a certain WLAN is based on the specif= ic WLAN (e.g. SSID) and not just on the fact that the MN is connected to WLA= N.

 =

Therefore, if we want to provide a protocol f= or network based flow mobility to provide an alternative to existing solutio= ns, we need to provide a solution that realistically provides the same funct= ionality.

 =

Cheers,

 

Stefano Faccin

 

Standards Manager

R= esearch In Motion Corporation
5000 Riverside Drive
Bu= ilding 6, Brazos East, Ste. 100

Irving, Texas 75039 USA
Office: (972) 910 3451  <= /o:p>

Internal: 820.63451

3DUntitled-1: (510) 23= 0 8422

= www.rim.com; www.blackberry.com=

3D"cid:image004.png@01CB49EA.87D92140"<= o:p>

 

=

P Consider the environment before prin= ting.

 

From: netext-bounces@= ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Giaretta, Gera= rdo
Sent: Wednesday, February 02, 2011 9:14 PM
To: Sri G= undavelli; stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nok= ia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-be= rnardos-netext-pmipv6-flowmob as WG doc

 

Hi Sri,

 

<= p class=3DMsoNormal>There is no implicit assumption of synchronized po= licies. A basic example that shows that there is no assumption is the follow= ing: ANDSF policies may be based also on location of the UE. For example the= UE should prefer WLAN only in a given location. When the UE is attached ove= r WLAN there is no way for the PDNGW/HA to verify the location of the UE and= therefore to verify UE actions based on policies.

 

The assumption on synchronization of policies is only applicable to this d= raft and I think it is a wrong one.

 

Cheers<= /o:p>

Gerardo

 

From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Sri Gundavelli
Sent: Wednesday, February 02, 201= 1 6:50 PM
To: stefano faccin
Cc: netext@ietf.org; Basava= raj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt= I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

<= /div>

 

Hi Stefano,

One comment.

Agree with you t= here is no ANDSF interface to the network node, but the assumption of synchr= onized policies between the ANDSF server and the PDN GW/HA is there, implici= tly IMO. With out this assumption, I do not know, how the HA can ever valida= te the flow mobility options received in the BU. If the operator requires an= y control on enforcing a flow policy rule, the PDN GW/HA needs to have synch= ronized policies, without which its always the client decision. I’m no= t sure, operators in 3GPP would like that :)

No doubt, the lack of M= N-AR interface is surely an issue for supporting complex flow policies. I re= alize the issues and I agree with you. But, the assumption of synchronized p= olicies can offer some solution with some configuration requirement on the H= A (assuming there are no other issues). There are also the proposals on flow= mirroring on the UE ..., requiring no flow policies. I’ve not evaluat= ed this, however. Folks can comment on this.

It is also to be noted,= for some of the scenarios such, there is no flow policy interface needed. W= e can identify what scenarios create any configuration limitations on the HA= and which one’s do not . As I’ve noted earlier, this is surely= an open issue, that we need to discuss in the WG.



RegardsSri




 


On 2/2/11 9:08 AM, "stefano= faccin" <sfaccinstd@gmail.com&= gt; wrote:

Sri,
thanks for the reply. C= an you clarify in which system or scenario ANDSF is available to network ent= ities as well? There is no such availability in 3GPP, and making such inform= ation available would require considerable architectural changes, therefore= the applicability of this solution to what seems to be the only realistic s= cenario hinges on 3GPP making considerable architectural changes. I would th= erefore not be so hastily concluding that the ANDSF information is available= to the LMA and underestimate what it would really take to make the solution= applicable.

If we cannot guarantee that there is at least one realis= tic solution to have the MNa nd LMA in synch, how do we expect that this sol= ution is applicable at all? In 3GPP there is no need to have such implicit a= ssumption, be cause 1) the MN is provided policies explicitly through the AN= DSF, and 2) it is the MN and only the MN that makes IP flow mobility decisio= ns and communicates them explicitly (with well defined signalling) to the LM= A, and therefore no magic is needed. There is no need in 3GPP to have the AN= DSF and PDN GW policies synchronized, since the PDN GW does not use such pol= icies.

Sri, in the end it is a matter of whether we develop a soluti= on that will rely on some unknown magic to be deployed, or a solution that w= e know can be deployed in at least one way because there are solutions to wh= at I consider major open issues.

Cheers,
Stefano

On Tue, Fe= b 1, 2011 at 9:06 PM, Sri Gundavelli <sgun= dave@cisco.com> wrote:

Hi Stefano,

Thanks for the discussion.

As y= ou say, the ANDSF policies are allowing the MN a.) to make the right network= attachment decision and b.) make the access selection on a flow basis. This= same policy that is present in the ANDSF server, is available for the netwo= rk nodes as well. I’m not sure, with out this assumption the solution= can work for all currently listed cases. We clearly need the MN and the LMA= to be in synch with respect to the configured policy. How, that is done, I= guess we will not try to know.  I thought even in 3GPP, this is the im= plied assumption ? But, this is for you to clarify. Not specifically for IFO= M where UE and PDN GW/HA are negotiating the flow policies, but generally th= at the PDN GW and the ANDSF policy server will have synchronized policies. T= he MAG and the LMA have the ability to carry this flow policy information in= signaling messages and influence the access selection. The policy is a opaq= ue object, with extensible formats, when carried in the signaling plane, sho= uld allow the LMA/MAG to apply those access policies, while assuming MN is f= ollowing the same rules. These policies can surely reflect the specific WLAN= access/operator specific rule. I’m surely with you, the lack of MN-AR= interface is surely an issue and I see that. But, we need to understand, wh= at are the limitations with the approach of  out of band policy interfa= ces and what will be the solution limitations. If we need to tie the flow mo= vement at the prefix granularity and rely on the natural ND interface in the= form of RA PIO option, more like PDN offload in MAPCON, or at the granulari= ty of a flow level, is open for discussion. I want to simplify this draft fo= r sure, we can surely discuss each of these issues on the WG draft.

<= br>Regards
Sri






On 2/1/11 8:29 PM, "stefan= o faccin" <sfaccinstd@gmail.com= <http://sfaccinstd@gmail.com= > > wrote:

Sri,
thanks for the repl= y.

I'd like to comment on the "the flow policy decisions need not= be based on the specific WLAN network". Does it mean, as I believe it= does, that the current solution would not allow an operator deploying such= solution to decide to route flows over a specific WLAN or not depending on= which specific WLAN the MN is connected to? E.g. the operator or the entity= in control of the decisions for the routing may want to direct certain traf= fic always over WLANs that the operator deploys, and instead route only some= of the traffic over WLANs of roaming partners or of the MN user home. How d= oes this solution support that scenario if the LMA is not told specifically= which WLAN the MN is connected to? From a deployment point of view, I do no= t believe we can afford to leave out this scenario. Please note that the est= ablishment of a security relationship between the MN and the MAG, and a spec= ific MAG identity, cannot guarantee that the LMA knows which specific WLAN a= ccess network the MN is connected to. Assuming that would severely restrict= the deployment scenarios.

As for the MN and the LMA being magically in= synch, I am very concerned about a "glass ball" solution. You men= tion ANDSF defined by 3GPP as a solution for this "out of band" de= livery of policy. Fair enough, however there is an issue with that. ANDSF is= designed specific to be a MN-centric solution where policies are provisione= d in the MN and the MN decides which network technologies and access network= s it needs to connect to, under what conditions, and which IP traffic needs= to be routed on such accesses. No IP point of attachment in the network (i.= e. the PDN GW in 3GPP that is the LMA in PMIPv6) is aware under any conditio= ns of such policy. Therefore, even if in order to apply this solution to 3GP= P we wanted to use ANDSF, ANDSF would unfortunately not provide a solution u= nless the MN can communicate to the MAG and the LMA the decisions the MN has= taken based on the ANDSF policies.

I believe the key point here is t= hat we need to understand how the solution can be realistically applied to a= real scenario, and that we need to ensure that important and realistic depl= oyment scenarios are not excluded by the solution.

Cheers,
Stefano=

On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli <sgundave@cisco.com <http://sgundave@cisco.com> > wrote:

Hi Stefano:

These are valid poin= ts and some good comments. Let me share my thoughts.

Carlo’s dr= aft is not assuming any new MN-AR interface. Its going with the assumption t= here is established policy on the mobile and on the LMA, which allows the mo= bile to select the access network at a flow level granularity, without requi= ring any explicit signaling between the MAG and the MN. To large part this i= s all about out of band policy interface, such as ANDSF, towards the UE, lea= ding to the assumption that magically the MN and the LMA are in sync with re= spect to flow policies, access selection and they will make the right forwar= ding decision. Secondly, the flow policy decisions need not be based on the= specific WLAN network, but it is implicitly driven by the MAG – LMA s= ecurity relation, where the MAG attachment to the WLAN network transitively= allows the LMA to make the flow policy decisions based on the MAG identity.= If the WLAN network is not trusted, there is truly no MAG in that network,= where the LMA shares a security relation with that node.

There are s= till some open issues on this draft that needs to be discussed in the WG. &n= bsp;On the approaches to allow more a flow aggregate movement, that is a dis= cussion point. There are issues that we need to discuss, supporting split li= nk model, or eliminating some favorite brand of signaling message (FMA) and= riding on PBU/PBA and just with one FMI trigger, and on the aspects around= MN applying the flow policies by flow mirroring. We have no agreement on th= ose issues yet.

Its just a base draft, for further discussion and res= olving those issues. But, hope that is not a stopper for base draft selectio= n.
 

Sri



=


On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com>  <http://sfaccinstd@gmail.com> > wrote:=

Raj,
thanks for the email.

I need to a= pologize in advance if my questions have already been answered before (thoug= h I cannot find a conclusive answer anywhere).

I think that a protoco= l that is developed in NETEXT (or other groups) should have at least a poten= tial realistic scenario for applicability.

In terms of applicability,= though it is not part of the protocol definition per se, unless there are s= olutions in place for either the host to indicate to the network where the f= lows should be routed or for the LMA to receive somehow from somewhere some= policies, the solution cannot really provide flow mobility since there is n= o way to decide which flows are routed where. If we are thinking about a hos= t-based solution, I have not yet seen a solution as to how the host can indi= cate to the MAG and ultimately to the MAG which flows should be routed on ea= ch access. If we are relying on modifications of layer 2 protocols, aren't w= e defining a solution that works only with some technologies (since for othe= r access technologies it is rather unrealistic to modify L2 for IP flow mobi= lity purposes)? If we are thinking of an LMA-based solution, can we hear of= at least one example of a real-life scenario where the LMA would receive su= ch policies, and how such delivery would happen? Also, should there be a sol= ution to have policies in the LMA, how does the LMA actually decide to route= flows on one access or the other? E.g., if some flows need to be routed on= certain WLAN networks, but shall not be routed on other WLAN networks, how= does the LMA know which specific WLAN network the host is connected to? Per= haps I missed the ability for the MAG to know e.g. the WLAN SSID and provide= it to the LMA, in which case I would appreciate if somebody could highlight= to me where that is defined.

I think that, though not integral to th= e protocol specification, understanding what framework the protocol would/ne= eds to fit in is rather important.

Cheers,
Stefano


On= Tue, Feb 1, 2011 at 3:47 PM,  <Basavaraj.Patil@nokia.com <http://Basavaraj.Patil@nokia.com>  <http://Basavaraj.Patil@nokia.com> > wrote= :


Hello,

We have discussed the= flow mobility solutions for Proxy MIP6 previously at
IETFs 78 and 79.This is a consensus call for adopting this I-D:
draft-bernardos-netext-p= mipv6-flowmob-02
as the working group document.
I-D: http://www.ie= tf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt

The consen= sus call will expire on Feb 15th, 2011. Please indicate your
support or c= oncerns in adopting this I-D as the WG baseline document on
the mailing l= ist.

Please note that this I-D will serve as the baseline in the WG a= nd will be
developed further based on input and feedback from WG members.=

-Basavaraj

_______________________________________________netext mailing list
netext@ietf.org <= http://netext@ietf.org>  <= http://netext@ietf.org>
https://www.ietf.org/mail= man/listinfo/netext

 

 

 

----------------------------= -----------------------------------------
=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_002_01CBC3F0.CF3D4DF0-- ------_=_NextPart_001_01CBC3F0.CF3D4DF0 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAKAA4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDSu9Nv V0vVpbjQL2KfU7xR5T6qqmRclsrnhecDFbGl6hqL69Noem63ZRQ6faops5Y2mmiYBQdz8BuSR1qD 4pxpLdeHo5UV0N2cqwyD93tXexW0ELtJFBGjv95lQAt9T3oA/9k= ------_=_NextPart_001_01CBC3F0.CF3D4DF0 Content-Type: image/png; name="image002.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.png Content-Location: image002.png iVBORw0KGgoAAAANSUhEUgAAAIoAAAA+CAIAAAB7vhRQAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAIthJREFUeF7tfAeYHdWV5q1b8eXXudXKoAyIIH1IgESwMTKDSDZebNKsZa8/ xh8MNgxj1mYxLGZtgseDDcwABsb2YH9ggglDMAiEyCIMEkkSCOWW1Orw8qt0b+1/ql4/tbJEN9t8 OxSPp3rVFc+555z//OfcUtjwLZyxAB/8I8ObUMLfGmNCYYES/Yq+63/ETyz1LdH6Hvbh4RXCwxX8 I2vrOH3tSNqK1W2X7j/78Ill4JWj5x2epaaeSPZ1qdPPUKpDs9TUs93JdrhcXflDc8X/T8+CAQ65 QWef7dJ/DbV+mf4hqjO2beNnexP7evbhtJ6d7xGOLc30pKpLJjh5nMEtsBw1kIH0hfRZUGXS7fej kUMV0elxVfyQpBts9wZ3zaE9etAiGPTtbIsciqIFwXg1MbtpkukFYkj8mxJIJv1AQtt24FUDv2rb ObfQy7xe6Zajm4dawrj0OXRyw68euBQasByxm9RzmN5wZHysXvZ2Np4IBezPgt0FziMVnFuRipRc VVTF80XOlJ1Bpada6HKKBSagGjjW2ngYkmGxP3e5h32H2dlCfpFrCWOOYgTsEKO1mZmKH4TOTYm+ EZbqPyHpaAtW9rBPwBQ1YDzA3gHgGcdvEQRCqjLgMlClbFStsWa2XUvEGPdEFffgq5zJz5Ny9ns4 DtGgqJ0GFiOZyZgD7xJ6mIRkp6cnZ3wdGovA9iAWIHboxYdiAtK1VELpS5iKpsSEwt1wi8bzOlsj c+9UOrtxB3VXO4gLD+Ghw2o9oavCHfj0D9lDo9QPNVpMH0Kt+5pP+bBwaQFXuEwF3GO8wgKLC2jL NgwWuDGcXdU8FQZIMc5PGNaIRNat5l0W+NGVDTJqstPo+vQP7pTEFW4kkBnZfKTQMEnAV/jvtsM+ 5c3XDxtu9URZYaSeIGhXE1P0BtUVUuHkmsLH/bQfWA9XpMG5w3mF+xlViWvcF76tsWygWK6iicDA h3ELu5k8meXpXr+UIzkbiFdhwqzhJAFpJfSoFMLwk/TCSUHQN6kpUlWo1iH2jcOnnn43su2BJBsX bxwDD+d6gabCfsIIM7gPsxVeIbGKRilMRfV9WRIycPA//Qefx6AxSL3ienHDsiXbKMsMcI90QzKH a+y3EODwSAF0y+H2yHhgaBBjDaX32xp8Nv40WA+9n1BosMa60/EDfD0g3DGZ8Qfb8ELMh3qG4FqQ shuoNqEJdxzQhuQbmjsc3/cRegLmqTBSSBF64tyHm1OCSlJ9Nd/TY4uqChjJkH9BC+CYYNyBp1Rt GFWAw30xUPCRkgaqB9oibipy24NZhlU90cX7zadZs2anx4wra1wEQ6QeISFftQwHJbyRrl9oG1ue d1qHLXPkqHTJJf4AyStCCkVVgRrcGN/Iq1vsfCEIDENTfYGI5UFRAVd9U2B3qZYroq9Q6S3wrm73 veV9FQCbmslggJnYVVFsYMTBaKV+7LCqZ8ATYLCNt1IzzI4OV/dcT+j6oK1HQKaA0KriBBwDPusp XVOP8A6dAyvqczyLKSaoPWgoCuTwcnBkUmM2l+vL+T78TSXlQTVkPdAwTDGkalVV182UZLphGlXb Xdvtvfpm5ePldsmDyQB7AhpWB6a6g9HT8MWe7UeIxdhIJd6hpmMe/AYH6Br0wAkQtxURI96Ae8DW Us1PODiebMhJ3ZXCkkEyCDRIWUodbiwI9EDRmQBE0asiKApfKpoCG0A2S7icQADpDw7LF7YD8qFU KuZ5UMlkxWEHJVoam/K91VK5CtRJHhPLYOMOneNzpJ7RVqZNTZquj2GKYABRcNFPXRMHF3lBCH27 TzjoMbjDuE0SQcZEcEKEyEqVJlMxlitSqJrFD5jabCSQgSIrtSBvsgYcgDPjULg7rGOroRY1v1fa Piwa8JwjRgUCvo3DlkhfgiuGYZIqQ3ARuKJcqI4ebY4+INFbKG/tiTBBPNTPYIHccKonKihEfiCl 8AOtxgbgYMQLxdAgD8arhi9U6MV3VaEHXpwMS0V8hyGE3xwUgIbwLuHpdQQRgW0QvYqggi8SO4Vw 7CVjbuClmt2JByX0uOv7psI5Zy6cFwcgQKzDChcC+ADy17ijyB7XJkRNtAQCIWmcSV1wrGnwb67n wbp0AyRUoPksnmQ9hUos5s6c0dy92d7SjcdKhuigPy59Wgc3aA//aS/cH05rxycUtYHFFV8Knfu6 qgeq5SvIUDyOtF94ug8MnILiyEoge8QDaIf8Hwa3RtEBnBoxOIFKPo1clMI0IQIV5J3p+yMVpsaz RT21STEKwquqVO7TVaFxMAdCVel0+EAd+AluSbU8FhPc8EjthkcFKD1wLGHrim0EXkwNDEjOR/YM olCtYucYCxzJ8uUzTkq0QjWspCiDhW3D7NxqGV2Irdu4OUrPxMD7g/lHFAiEJjFylbSjxzyzymI+ h7tgtpn3NN/ThVB9T3U9zXORXKq+JRwdQV1xFcVD+AZdI7jucoOrCDMSwVyyraMPVEaNM1y/xJGH 1vJ/KBXATYXwWYDBrsPwYLalwO/yq74BuEAWFLIE8Lak0uiDhf5FPoXxIaFr7EjUkRRBIq1WpbFq jT0kzm04rYd8M54vhKAZNW4oOp5cwsErAnIXGtM8riNmMAPS9aRflkKr6pqrKRUDOhS26dsxz447 +Pa49FWiviEWTxGu6vlGVcR9G5ahStf1PSeTbGZ+UlbjikyhxsAk4K8bSA80HOAD0aZS00AHBEDj vkdWqbrIh8APMFWDqYa8QY3TIe3U2AJKU8MclaIY94uFypSpMQMYe7tM6FM6mV3HnjBM7t8y8JD9 PRxjZHK8oVVJaJTBBxY4A6l1uvl8YPeygs2KCVMkY7aluczVbGFrgYEYA0emBDrkhKFb1dQi1GUq qZhiqm5cF5bhW7qIm25Mh3SrmUbnoMMbzWSFaDfdZLxk6GVVRX5FsYch52S+DACqwTKIQmB3o0Jk IPIjlCkYJwQa4P52LGiQI4U/hFtEhFQQmngAbWcakytXy3x+CJzbbtVwySWXnHvuucuWLbvyyis3 b968V11FKom+ETCj/esr9cN1Xfc87/jjj7/22muF5137s58tfO45uK1TUpNbhaa5wtWVmMs3id5J X/nKOddcVu3deufPfsRWvP+tL83u9HuThx1+0FFz0uMPhC8KwDyHIAkykqZR2fTxsof+zV2zrNkS ik+igWB9jsCD8CBEbOv0WY026wJe84HoRIoJi7wnRC8VDArHAVz2pes7rreqVFleZFqCIfkC6Pbh vuC5iELYUVxECwmDaa7PmerD0MkejWzmwSe8d5ZW9iq0ve6w3fXqwh05cuSGDRuig2+//fYLL7xw dyci/xsqIzoWgEgigMOlAzgRbagIsYv8edGiRccddxz2f/fdd08+dX7v2nXfaj4sWXA0wSqQh+0l Jh1w5ZN/yh7QhH1eeeTeRy757twJDeljjpn1kztNI7u7mym889Qj/7igI+GbQGUE2zSHJRSNV7zu bIeceEhDNegBVgMhEAYScNXEe4LlZICCBOXBw6LOwPLSX1u0t/ZWK4WgDHSQYm5UaoiiDT1tffzB h4XqUeGKgScxZmRgJha/pS5cVNir9Pe6w65jz4QJE3Ck4xAuPO200/ZwloGGgnUoA9/QDQ1eKXep G/zJNMEYMtfxJk6YOHnSBHCKloockGhI7gc5Zp/ygwXQjY0kL2CZTEvLyLEl3z/2ssugm4rwkTaW A4YPUhhHSlfKcohgY9kW3UggaxeSu4HuKDGQXhwkmV1pa0xRsMAVgIwlyn40rNCIQBgQJ2BVIcuB KMqgLJSCqdlTWpMzxzbMmtg4MqOVy6RtSrAoSwrNtT/ehAEozD/DqhKNT8L+pOohWbZTDyQbGUEk 30j0kSh3ucyePfsPf/jDzTfffMcdd8BfYZ9Jkyb95je/ufXWW2+77bYzzjhj5yA00PsZJjJ2ZCe8 mSWE42JEAgP1+bmDTjnuhL/7ZgkZkabi6Tdt3NKzsThu9ldYehJaOpBn6lxJKLALFuPM5MBnPEH3 6L/86P0lpxRoBhg0Qm4YzcB1fgWxJdVgSkgf8iMyvErx3wdmxpBA6FJNRdNBgRKoJmihigpz+jKB 0Z6MHz65beqkNLIk4YZZrI6UGfKJKGtKlQNVEMGNcwVSU6TnMcM0C7khCDx4JAS97ZZIMdFioHTV 77UG7qRpGjgsbDn77LPPO++86E8IVIlEAkq66KKLoi3z589/++23161bVz82Cjx1xVNXIIjgwBtj NRgeYJPquU4P87932/XYBzaR0Hi5u/D23XePMTZZo1sYa3Q4s+CNyptfeuwPaQvjGDCaiqJm38au F1/rW782kY2XNLNBagm7xPXNuZjVUI7HzSY37sVk0VOa/HJb0vogxpSylq3qNpQUVxJWscLUWNnw dIyIKugcoSRcUbGkV0ynSoc3j2hLO++95+Rd7qLcITQL+yHN8TQJt2YGvNJgsRxXBQxXseJVuOgq PbQK2Bj6dpgTlkho9QE6bty4fD7vum61Gu7dbxUDRb0nYL1DnK8fFl0Gy5w5c+obFy5ciPW5c+fW t7zzzju5XA66TKfTqVQqmUxGutm2UAWOJZAwuj4GpC3FSrbm76+/vnXMKOG7CYWw7FO33LVy2ZKx IxvdCkVancHI8izoefa6f1zyq58sv/nKVb/6nx/885Vv/flud8P77UY1w6oqnQnQwRRmCsEMGVRG r8TMXNlk6P4wp33VaZjRR56oL+EmY46le8W+WLkczyUwImzdaxhlN4+WBnPVzbrWKxxghc0dCeew qUaGx5Uyg2eErbsurMTlQQz9Pp7EcwW+w0gXaDXx+KYuWCF+CoSGY489FoO+Pu6jaB2LxW666aYH H3zwlltuwfpAqxgooR2tZzvx7eZHHQ7g7I899hi0tWXLlieeeAK7P/7442vWrMFtwWgQ/wuFwr33 3nvggQdCMbAtgMBot9pC0TZoDCyffFDQ7RemHTj3lEu/g3IPfpoKy6/e+O//++eHTWowdQr1OKqi aCkFoTirptvMVFzzqokA7t7xrSAh/JhbQRZKgV5Nu0q8RyDB8SiRSsIdFvq4Vu7155zw7U9eNzZt eauD61rVBYODQJVvyoh8YSxT8pVKZvp3M+MnrH70iga9YCpBoZKwjfZ4blU2npk2ofn1FR/mcn4C BJHoyeWDRMIzYJEcdgluuyHQSoKXN2+NdedqTuiCCy4oFouLFy+GAqAGGEqkCQgNIeDQQw+1bZtU vSsvRRt3qQIYAc4YhaLe3t6mJkJQ9YX4qtAS68a7B6UOxNZQ3qmnnoqdX3755aOPPhor0N8V37jA +evbqCav93v++ZGHDp5/fCGoJDxTNdSfnblgyV/uOWPGxI50Z/vJ3zrk8ju3IoEFBPCdJX+5N2Px JDyG43dvXP3BS/e1F3qaglLJ8h0lqYlMsSLTR88YP+uYl//XT6af9VUj/Xyx7cBEdsS4GdcrpTVa Kub16B8+d1mu9PERx/46M+O0/IcfaIl1nyy86oDjb0uMP6n02vc+WHhnE+oLjceMPnFB570XNZzw 3arrP3rfnbNPvPjIs35Y6vn4X2+4elP3m9847+pXX/9d58fvn3POL99a+uC6zldfeNl8+XX1xUUL m9qypmn97ne/++lPf3r55ZffcMMNn3zyCXz+hx9+WA8QkWIiSe6ch+zJue3O4iLdnHDCCRgCOCOW 9evXYyN8XfQTC1IlGE2kSFwYS7lcBo4YqEg4Hl3T04GV4tYWN/e1y34A3TghSwrdPPfHp/7jL7+f bna0N8UAq4SmIoVuQwLjVZmoHnnWeZPnnz/yb84de+aCGRdd+zfX3r3V7OjjTdJooEIA/IePdLaY POLY9JxTpl1xV3r838Wbz40Zh6DMU8h3Lbn9HN+0EtNOGTflv8cPmvv6Lcd0vnd7YswpxULQu3zh +rVvvfPSbxMNqoyxiuUnRx+/SfG9bCbPqvNO/f7EE753yYJZD/715n+4/r687Y8Ye6QWz6LY0zhq rpYcnSuZi1+177jt1s7ujZMnT8HDwGK++c1vfv/734carr76aviPMWPGQHRQSSQNiCuS5M6jfO+x Z+djopg0b968+p9GjRrV0dGBGFPf0tbWdtBBB0E9wA5nnnkmQAT2uf/++weeDXEUi6mpfTI/8uBp Z//wQoAFz7PhvsrrCndcedME1pYwAyvmoXsmRN2oNIBh1oQWp/zRd8pS5hl6A5hvtPBMu6PFcoBd qgGA35JJbl21lBV6R8w/3+9cGp84L94wS65eCdY1t+lD1tnj51ZypzvR0rJl49LCx8tXvPGIw7oV UZGsV7ELdhFZglJBkNVitm30BAkHVIWTz04ZtfI/n1j60ab/WPgo4mZTi1IpF+ySU0AEEjyRbHn6 GYo6X5p3wrL/XIqVp556Kh6PT548GYEAP//85z9/9NFHSCujUbtXemW/Obco5cTZx44di2/YxIoV K6677rrOzs6pU6diS6lU6uvru+qqq3BnEydOhG/FMOnq6gJMqOumPlKASU3V/JB1XXzlFU0jWtEL nQDKZcojt99TWd0VY2oyGVNiPgqXUXW4rGkO131gaSOua3GD63HGE4B5ne/yYpcKrg68CogWsJzg 4PxqYfOaw78yb91jv060x9rHN9tbl6LFIBMXforlWNrPWqs7l7ccMKX5qIOnzV9gsGQllgaCzCTT HdlpnqubpsoKWjyZnTLrghEjTner0worlh4ye+bXvnzet8+6xS/1yl6eSKgHHzF35qy5B0467LXX tq5cRff51LNPzvvqScfOnXvWWWfBMpB9A9lGXAnG8fLly7EC5LZLixk4gveknl0eXM+NAKBhEFDA UUcdhZiPkyIBymaz7e3tuDAuj4j34x//+IEHHsCQQST75S9/GV0YRgYUhxWPCVPVenq7jxs5e/rZ J/fYZQd2oirvvrj44d/8FrpJK4lsOmNTxT9MMZC9BgJsqKmUtix51l72vL76VfXVh1645m8X/ury RGltIy/rYFXIm2sYFvFEYuVLi9gnL/nFNyufPCr7Him6a7n/hsx3gSYz3bfHVlZobz5eevP+w8++ qjE1RikuzijehvWLY8m+KV/+uiurSECLq97a+swVo0YHPfm3mrPjVr/5l+L7//L3V19+4kktN143 R69WH/njvx4/98QfXn7PrTf+/JZbHgjrV+kf/cOljltF9vfGG29gvD700EN4/Oeff/7EE0/8+te/ juGL7x0i+s5eClt2hAYRKhsIDXp6epqbm3c4uJ7BDNyOkQL1YAvs6cUXX2xsbIRW4OKifXCLuCes tLS0ANRNnTLV4Uo1l7vizPNu/OOf0iNSwDQxeDCVXXHo8SuXLZtgzBLuu0d9mTU2+ZVNW1pPv/jI y35dCWQcBOTWj6+YPXF8BmQKM5PMSmttaCSE/nxWVlFBQx+BAWYNjQOb7E0dY+MTJigAyEBLqay+ vttrzqRjmlLOF7knsxljfc6l3ilTR3xpbNMKKP9t9VWdNbQhX4kVS23ZcUcEo8eNGTdh9dNP+92L uyt9z77FPiqw0WNYm2n2BtbmnurjT7o9pagTOR6yCvtEuNUx8C51g43bWc8Oe0dObMdkJTwTNkZh PyLWsAJ/et99990ZLtAKgBlsCx7v1XB58sknr7nmmugmIuwABxTOVgsuvOonqZZ4gN4k4UM3z/zT 799ZtqQ51l4RjmUAOVSRigegqsGWIO8BTEaJLmmMSLJRjfrYDpZJQw16V9HvdrUcHKOCD4KsCHCY 5G1ZbcKYrK5a7UmtIROD7Y1psgxe8AKU5rjerBe4bGrVW8arrR2ydQyqgDyjqa3tjAakx3wH8xry SDvNwF/5/MPFrkUGz3e0xKcfmjh4mtbYmGbxRE+X+GCZki9FbW0GSNJ91E0kit0pJtq+nfUQVxQu 8JKwRMQuhA3YJkIL4lvtgDD2gMl++OGHB0I74EXkQPWLwVBgLplMJmJIK5VKhFVwTqSosC1A/kqA Zmque4p0XMQczrXeTZtPPXhmk6eaepoXrAmZLXPmsVhQLazrbv3ad+Zc+lsknEhhVLf04M8vb08G pvT8wLLVpK76xc2rty5/O6N5BuoC0A9IHcn1ZG7q9HY0gQhWRo2Oghh1doBfhixR3AE/SLRtWGkj n4jqAkSiSir3oNMObQ/CMHNVTzPigeJlFAdO2U8k3umyXl/lbtiiLH+/vHK1ADVIsiZ2G54NKerQ dFHtQj1021IioqxcuTJaj6xkhwXbH330UUCy+vbzzz//4osvBlIAkQoG4cYbb6z/qW6UdZcIjzxz 5kyU16AuI6x0+YjyjJ9+xunPPvJoFnWYAKVKeXIzP+OkJtfOeT2lscd89ZjrnvQks9FfoCmGhwoz ckFwXgbqAzT9I8i998Bti3/7i7Y4GhDQpqHagTZiUmXC1IRQ4HeIXkG3GjVEoREIoAktOCCow177 6AnBMAUijoInNutIVtFT4NpqApexHbB4fialVCt9+U1+6sEl+r2LenttaidFGtbfUQNelmrtdbEO nhfdbb3nvffeQ9iArDHksURmCFVFJFKE2feMC+vZK8HnfrwX6eyuu+5asGCBg9ovknwfHWM6fN3d /3bPd769AGVGjSlVXIqJi6am5s1q7c11qV6p4mS/8/RaxlO4gSoGuIJ+DrR84MZQmoPrY+iYEl1v 3vnd+RmlZKGsoXBHGplGnkqDHi0rHNU2dG7gQmCqHfTdEIEJSyIvS2U3PA1WoEEk26iwGS4VSVFj 9aQjuOchkpXjQamMaxWsjj8tk0+v2KQoTeSlyW6gmGpYZajVTfu7RAeroN2qB0wR3BfC+86mE215 4YUXIpZ6v5aoIATQ8sorr4Derh/712eeOeecb/V09/T3iNGsrF/NbxqnWbbmgKdcv6Y8/Rs/+NKl NyHFpmaz/gkDEcePb5TVVj1z5+M3/ag9IQ3pUREUNuamBNqq0UtFHVGWRCeQgokj0Ca0r1OhFW3y YUEP56BWQ7UY6BW063Cpc4E+RSpKU+sPlYKAN6pcV/qsUfcuLT+zYiPjiHugjKAbKnyE56g/ECh0 3ONgvdyeitbTp09HugvcjJrCQEYPtwC68xe/+EVEFuzXUudukaldfullM2bOqLru66+/dt11/6d7 61aiOjCqkUVLFRbw+79tT26WOQ3NNiVDptcV5ZTj5h987MnZtjEoJWH8U3CFQUNhQm54/9XXHrpH K3VlkZgi+aSeNNghXJbLVJe601CLkEZoRqH5hX+l6BwW2cLm26jPEBaEPyFOGqizRlP4EaE0VuKi hDvsMttuXbT57S0guUP5R1oJvzG2+gn/qEvsM7OeutCBlevOLdqIxwDaxgoqDhGdt+8Ljo3AXkR7 t7a2wllFZ7NUtNVIZhmq7XgBnzxaufFL6dQGc2tS2mYhBipfFD1cT0tyoxFhwlKQ4viOqrhaTPVB 9FQ15sdVtHNgRJOQMewD1ZMK2jYdKIZLdIaaauDBmKgHETMLSC31MR92LUjM/DJRoGZalfw5tgBN SLRjQ1ueGbhcMzay5hueXr2aGIVIKaSc2hQT8NaRTrazpH0Xz4577rYNMUJx2B35HVijHZZIxDCp vULDHS6I0UeSC102QFKpXI6qHXA0VMDEwIVZcBPczdwpqUOTLvcMYTLHLVgq8lRmIV5wjeYOeI4m weej3uMrvp3Ah8uYTsM/RCLRKKKCBbXUUhMHSqNgFKi8GfXcADsQwUCSDGNjBN5gjGFPPOKNROGW urDJ0+G+0HmCmamSW6tyyqKPAQvgvgwUW8Nz4BqYCUTqrdlLZDyDXnarnj3LvU597u8NRBqlZfv7 h0+oEbbkX1AIFd8Ynx6ZopmFQeAkwcVxboOhpuY3TP2BP0OER20aokShE3CZOtSonR1yrk0oDZEY NRBCC4C8YeCGUqhmjvYb2nFgX1RtKhXabRBLaGTi7CgQoaSAO9AxprioAGmLVPq1TnfJRqQ5uKhH o6HmxFCKGzAxdSh0A9nuN+e2v/r4NPsHTloLWhujgEfN52HvX1hLpr4NiL023CF9GAT1SpMxh/Im kWMc1z7hBsqAqameWgFqT0wH7HLaHTWbUgsp4TuGVkgXGB1pEGVCMClNL0tjyXJyxeGJqLf3M10+ l+phTmNcTxqqcF2yFgx/ShbDcBItxDhEGqhJPPRRtclq0Xr9U1ujM0TaCw/ejVAx0xRXJI9I14Ql oU0XU1DRJEzsMo8n31tXWVFEuAV2qKGG/4LqYe1JNaa6od9AdzqaLWha2mcqCDo58jD0g8LOwuhI U63IdNBaj0urwkxWldSTb28Jx0RUZaZb+kxv6/NoPYiHk9tT8cCl8Rm2n5GtgEUboilnu1dzNIuH SGFUMAAQwDPZmM5jWGVulszWB1/bsryMGIM/omJO0/2HYg7Pnkbd51E9lspGpDCp2oagPLAzJLLI i4Vpyf43GO+32RHAI0LB9QMtnoIz09PNS9fbr3ycD0+F8QP/9v/i5TufR/XENK0xoWnCQcZBegnn 54KWq01Tp7ewRO2A+/DZjesByhrwGZhAApeHs+AolGmaZRVtv3lEx5othftfWdtFExl1pmtoBKYe s5qqPkN88HlUT3NSbUxgZrTqCY8SFHr/HmgwmuVObTlIt8IZBXv9EK+w42Q6aubEpDbCz9SESA6M 3jyBJQSJ4QxTmiCEpnaUbm0/iDV3vPJ+5x1PdXZiAiQQgRrH/Iloqnyolv4JJfttoft0wGeo+X24 PooUrop32eAfglOwFhwkTplk/Y8jUlUPbZmUH9IMjoi/IcQcvVxg7wuxcEBp1Ly5484wPw0MOSZU QTFq2N4JIhA6ozQV/W0o2pTjeM9OLF7Umx/+yPvTErSbQyMRP0K4IZLaPt3H3u90T3sMr3ow4Zfm tuE5Q+4QFRZ6v9cPDmv8b1PNzlzJMjC/wKf5GSGpFQIq6h/Z90f2qId6Z0GG7dUhpRBOHg1nFRGY Vgi7SdVMpnwttryr+tLyvufWlqm3g6ZoDZbf3Pfbru+5H4/6Kc6+50MigVMUpv2QSSgWCDHGrjmx fXqjV3YEKnSkHnRab+MYIvZx7wsN7ZChJG3Wx3nt0MAHhw1DpDwWhTcYKOgZaujWrVhFUzeUtcff Lby+BjVYcmJgb3CCWqPt3q88lHvs06MO5QUHnAtPDgGGAAhvhkJRi2azYWbUP51/gOl2YtYvKmIh /4XcEEA2OpLKnbu5n+3MJFKjRTMUIo9U90Y0KnSwAGin51rALa6iO8A0Y0m7ai9b37ukq7hso7MW 0+dIL8hv/BhoHsyG+IyksMfTDqd6UEvB5UOPjrFrYaaHIpzpTea1Z01XeteB90eiDhqSwvu2F+aC AcP+FMe38fgDifxI2VFdAKQYAj0B8tCWAAKiCEYgA3K3XKb1VN28p27I2R+u71m9tbwRE7BCeYVn xz7Ru1eiK/6Xc241QYbCQzEGz+8fPSZz5swDZK4rbBbpb9uKvFOIssMpCdgzfBsBRaSQ8yfJh6/t ILlGTg1/V3y814o8WFgbQPSXCtJMcPA9Za/L0fpcpTufhwvDZJV+Ugi0JyIizu/0GyPOhgkNOM8+ Nd8MrY0Np/VQGQE1mfBdkf20vEhREIBDq72FY9foaHtfVauGRd6r7uFCnUQGSm/co76J6N0U9IGJ bHvlAM2BDKdqI/5jwjFKqVToxFyV/rYBGhAYDUMzZWe/9De86kG8wTsd0BZDEYjIf4A3VEprXPIu 4Wu9PNnvgequaNtK/cC6A4xkQtojo8MXiG56HxL4NUzLA69G7zUIVenR/AjaGcU6HIHEK+oerpdB 90u8g915eNWDwU2tLQNielQfhsevF6IG2g+Jr//NuRHii+4/Guh1UBdtDDtwavXQunpCpaKQjf7m mm2EnEQIOcLXwVANIzST8AbIc9Yx4GBl/cXxX0jgCwl8IYEvJBBJ4P8CkLsiseCTLsQAAAAASUVO RK5CYII= ------_=_NextPart_001_01CBC3F0.CF3D4DF0-- From sfaccin@rim.com Thu Feb 3 14:23:19 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CC0A3A6B14 for ; Thu, 3 Feb 2011 14:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.696 X-Spam-Level: X-Spam-Status: No, score=-4.696 tagged_above=-999 required=5 tests=[AWL=-0.494, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-hVN89T0jfN for ; Thu, 3 Feb 2011 14:23:00 -0800 (PST) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id B04343A6A50 for ; Thu, 3 Feb 2011 14:22:59 -0800 (PST) X-AuditID: 0a401fcb-b7bb3ae000007d4f-ff-4d4b2b8d9e7f Received: from XCH138CNC.rim.net ( [10.65.20.127]) by mhs03ykf.rim.net (RIM Mail) with SMTP id BA.68.32079.D8B2B4D4; Thu, 3 Feb 2011 17:26:22 -0500 (EST) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH138CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Feb 2011 17:26:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CBC3F1.60E2658D" Date: Thu, 3 Feb 2011 16:26:18 -0600 Message-ID: <680854867F7FD04BB9B06EB8ACA8D5AC05E1F0AF@XCH02DFW.rim.net> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C4620179629E@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLwmpURzmRlysrlUidlexdQorGZJPuBh2AgAAR4ICAAAzJgIAACkaAgADJ5gCAAKKGAP//oT5wgAAf2NyAAIzc8IAAc+fQ References: <680854867F7FD04BB9B06EB8ACA8D5AC0465FAB1@XCH02DFW.rim.net> <843DA8228A1BA74CA31FB4E111A5C4620179629E@ftrdmel0.rd.francetelecom.fr> From: "Stefano Faccin" To: X-OriginalArrivalTime: 03 Feb 2011 22:26:21.0945 (UTC) FILETIME=[62A11690:01CBC3F1] X-Brightmail-Tracker: AAAABgAAAZEXVB72F1QozBdUKM0XVCjOF1TWuQ== Cc: netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 03 Feb 2011 22:23:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC3F1.60E2658D Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CBC3F1.60E2658D" ------_=_NextPart_002_01CBC3F1.60E2658D Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Pierrick, Thanks for the comments. I can agree on discussing the issues some of us rai= sed separately. If we want to discuss the key elements that make this draft= applicable separately, then I guess that we should wait to adopt this draft= until those key issues are solved, otherwise we risk to adopt a solution th= at is not applicable to anything. Cheers, Stefano Faccin Standards Manager Research In Motion Corporation 5000 Riverside Drive Building 6, Brazos East, Ste. 100 Irving, Texas 75039 USA Office: (972) 910 3451 Internal: 820.63451 : (510) 230 8422 www.rim.com ; www.blackberry.com P Consider the environment before printing. From: pierrick.seite@orange-ftgroup.com [mailto:pierrick.seite@orange-ftgrou= p.com] Sent: Thursday, February 03, 2011 7:36 AM To: Stefano Faccin; gerardog@qualcomm.com; sgundave@cisco.com; sfaccinstd@gm= ail.com Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: RE: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmi= pv6-flowmob as WG doc Hello, This is an interesting discussion, thanks for bringing the ANDSF issues on t= he table. Effectively, mobility control, i.e. access selection, is a key poi= nt for an operator. From an operator point of view, criteria for selection i= s not only RAT type or SSID; we can imagine plenty of other criteria. Differ= ent mobility control models can be envisaged such as Network controlled or t= erminal controlled and so on... For sure, in PMIP context, policies synchron= ization can be an issue and how decision made on the terminal can interact w= ith network managed mobility should be discussed. But, I don't think draft-b= ernardos should go in this space. I think, we should clearly distinguish mob= ility functions. IMHO, draft-bernardos should not be expected to deal with s= election management, or mobility triggers, but only on the handover executio= n. In other words, the draft should assume that handover decision has been m= ade (how decision is made is out of scope) and, then, only focus on mechanis= m allowing the LMA to transfer flow(s). Although related, mobility decision= management, e.g. policy based, should be discussed in a separated thread. BR, Pierrick ________________________________ De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part de= Stefano Faccin Envoy=E9 : jeudi 3 f=E9vrier 2011 08:05 =C0 : gerardog@qualcomm.com; sgundave@cisco.com; sfaccinstd@gmail.com Cc : netext@ietf.org; Basavaraj.Patil@nokia.com Objet : Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmip= v6-flowmob as WG doc Hello Sri, >From a point of view of applicability of the solution, I must agree with Ger= ardo that assuming synchronization of policies is an issue of this solution= since it comes with a set of restrictions on how the solution can be applie= d. Cheers, Stefano Stefano Stefano M. Faccin Standards Manager Research In Motion 122 West John Carpenter Parkway Irving, TX 75039 Internal: 820 63451 Desk: +1 972 910 3451 BlackBerry: +1 510 230 8422 sfaccin@rim.com Time zone: PST (GMT -8) From: Giaretta, Gerardo [mailto:gerardog@qualcomm.com] Sent: Wednesday, February 02, 2011 11:13 PM To: Sri Gundavelli ; stefano faccin Cc: netext@ietf.org ; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pm= ipv6-flowmob as WG doc Hi Sri, There is no implicit assumption of synchronized policies. A basic example th= at shows that there is no assumption is the following: ANDSF policies may be= based also on location of the UE. For example the UE should prefer WLAN onl= y in a given location. When the UE is attached over WLAN there is no way for= the PDNGW/HA to verify the location of the UE and therefore to verify UE ac= tions based on policies. The assumption on synchronization of policies is only applicable to this dra= ft and I think it is a wrong one. Cheers Gerardo From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of= Sri Gundavelli Sent: Wednesday, February 02, 2011 6:50 PM To: stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pm= ipv6-flowmob as WG doc Hi Stefano, One comment. Agree with you there is no ANDSF interface to the network node, but the assu= mption of synchronized policies between the ANDSF server and the PDN GW/HA i= s there, implicitly IMO. With out this assumption, I do not know, how the HA= can ever validate the flow mobility options received in the BU. If the oper= ator requires any control on enforcing a flow policy rule, the PDN GW/HA nee= ds to have synchronized policies, without which its always the client decisi= on. I'm not sure, operators in 3GPP would like that :) No doubt, the lack of MN-AR interface is surely an issue for supporting comp= lex flow policies. I realize the issues and I agree with you. But, the assum= ption of synchronized policies can offer some solution with some configurati= on requirement on the HA (assuming there are no other issues). There are als= o the proposals on flow mirroring on the UE ..., requiring no flow policies.= I've not evaluated this, however. Folks can comment on this. It is also to be noted, for some of the scenarios such, there is no flow pol= icy interface needed. We can identify what scenarios create any configuratio= n limitations on the HA and which one's do not . As I've noted earlier, this= is surely an open issue, that we need to discuss in the WG. Regards Sri On 2/2/11 9:08 AM, "stefano faccin" wrote: Sri, thanks for the reply. Can you clarify in which system or scenario ANDSF is a= vailable to network entities as well? There is no such availability in 3GPP,= and making such information available would require considerable architectu= ral changes, therefore the applicability of this solution to what seems to b= e the only realistic scenario hinges on 3GPP making considerable architectur= al changes. I would therefore not be so hastily concluding that the ANDSF in= formation is available to the LMA and underestimate what it would really tak= e to make the solution applicable. If we cannot guarantee that there is at least one realistic solution to have= the MNa nd LMA in synch, how do we expect that this solution is applicable= at all? In 3GPP there is no need to have such implicit assumption, be cause= 1) the MN is provided policies explicitly through the ANDSF, and 2) it is t= he MN and only the MN that makes IP flow mobility decisions and communicates= them explicitly (with well defined signalling) to the LMA, and therefore no= magic is needed. There is no need in 3GPP to have the ANDSF and PDN GW poli= cies synchronized, since the PDN GW does not use such policies. Sri, in the end it is a matter of whether we develop a solution that will re= ly on some unknown magic to be deployed, or a solution that we know can be d= eployed in at least one way because there are solutions to what I consider m= ajor open issues. Cheers, Stefano On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli wrote: Hi Stefano, Thanks for the discussion. As you say, the ANDSF policies are allowing the MN a.) to make the right net= work attachment decision and b.) make the access selection on a flow basis.= This same policy that is present in the ANDSF server, is available for the= network nodes as well. I'm not sure, with out this assumption the solution= can work for all currently listed cases. We clearly need the MN and the LMA= to be in synch with respect to the configured policy. How, that is done, I= guess we will not try to know. I thought even in 3GPP, this is the implied= assumption ? But, this is for you to clarify. Not specifically for IFOM whe= re UE and PDN GW/HA are negotiating the flow policies, but generally that th= e PDN GW and the ANDSF policy server will have synchronized policies. The MA= G and the LMA have the ability to carry this flow policy information in sign= aling messages and influence the access selection. The policy is a opaque ob= ject, with extensible formats, when carried in the signaling plane, should a= llow the LMA/MAG to apply those access policies, while assuming MN is follow= ing the same rules. These policies can surely reflect the specific WLAN acce= ss/operator specific rule. I'm surely with you, the lack of MN-AR interface= is surely an issue and I see that. But, we need to understand, what are the= limitations with the approach of out of band policy interfaces and what wi= ll be the solution limitations. If we need to tie the flow movement at the p= refix granularity and rely on the natural ND interface in the form of RA PIO= option, more like PDN offload in MAPCON, or at the granularity of a flow le= vel, is open for discussion. I want to simplify this draft for sure, we can= surely discuss each of these issues on the WG draft. Regards Sri On 2/1/11 8:29 PM, "stefano faccin" > wrote: Sri, thanks for the reply. I'd like to comment on the "the flow policy decisions need not be based on t= he specific WLAN network". Does it mean, as I believe it does, that the curr= ent solution would not allow an operator deploying such solution to decide t= o route flows over a specific WLAN or not depending on which specific WLAN t= he MN is connected to? E.g. the operator or the entity in control of the dec= isions for the routing may want to direct certain traffic always over WLANs= that the operator deploys, and instead route only some of the traffic over= WLANs of roaming partners or of the MN user home. How does this solution su= pport that scenario if the LMA is not told specifically which WLAN the MN is= connected to? From a deployment point of view, I do not believe we can affo= rd to leave out this scenario. Please note that the establishment of a secur= ity relationship between the MN and the MAG, and a specific MAG identity, ca= nnot guarantee that the LMA knows which specific WLAN access network the MN= is connected to. Assuming that would severely restrict the deployment scena= rios. As for the MN and the LMA being magically in synch, I am very concerned abou= t a "glass ball" solution. You mention ANDSF defined by 3GPP as a solution f= or this "out of band" delivery of policy. Fair enough, however there is an i= ssue with that. ANDSF is designed specific to be a MN-centric solution where= policies are provisioned in the MN and the MN decides which network technol= ogies and access networks it needs to connect to, under what conditions, and= which IP traffic needs to be routed on such accesses. No IP point of attach= ment in the network (i.e. the PDN GW in 3GPP that is the LMA in PMIPv6) is a= ware under any conditions of such policy. Therefore, even if in order to app= ly this solution to 3GPP we wanted to use ANDSF, ANDSF would unfortunately n= ot provide a solution unless the MN can communicate to the MAG and the LMA t= he decisions the MN has taken based on the ANDSF policies. I believe the key point here is that we need to understand how the solution= can be realistically applied to a real scenario, and that we need to ensure= that important and realistic deployment scenarios are not excluded by the s= olution. Cheers, Stefano On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli > wrote: Hi Stefano: These are valid points and some good comments. Let me share my thoughts. Carlo's draft is not assuming any new MN-AR interface. Its going with the as= sumption there is established policy on the mobile and on the LMA, which all= ows the mobile to select the access network at a flow level granularity, wit= hout requiring any explicit signaling between the MAG and the MN. To large p= art this is all about out of band policy interface, such as ANDSF, towards t= he UE, leading to the assumption that magically the MN and the LMA are in sy= nc with respect to flow policies, access selection and they will make the ri= ght forwarding decision. Secondly, the flow policy decisions need not be bas= ed on the specific WLAN network, but it is implicitly driven by the MAG - LM= A security relation, where the MAG attachment to the WLAN network transitive= ly allows the LMA to make the flow policy decisions based on the MAG identit= y. If the WLAN network is not trusted, there is truly no MAG in that network= , where the LMA shares a security relation with that node. There are still some open issues on this draft that needs to be discussed in= the WG. On the approaches to allow more a flow aggregate movement, that is= a discussion point. There are issues that we need to discuss, supporting sp= lit link model, or eliminating some favorite brand of signaling message (FMA= ) and riding on PBU/PBA and just with one FMI trigger, and on the aspects ar= ound MN applying the flow policies by flow mirroring. We have no agreement o= n those issues yet. Its just a base draft, for further discussion and resolving those issues. Bu= t, hope that is not a stopper for base draft selection. Sri On 2/1/11 6:39 PM, "stefano faccin" > wrote: Raj, thanks for the email. I need to apologize in advance if my questions have already been answered be= fore (though I cannot find a conclusive answer anywhere). I think that a protocol that is developed in NETEXT (or other groups) should= have at least a potential realistic scenario for applicability. In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicate= to the network where the flows should be routed or for the LMA to receive s= omehow from somewhere some policies, the solution cannot really provide flow= mobility since there is no way to decide which flows are routed where. If w= e are thinking about a host-based solution, I have not yet seen a solution a= s to how the host can indicate to the MAG and ultimately to the MAG which fl= ows should be routed on each access. If we are relying on modifications of l= ayer 2 protocols, aren't we defining a solution that works only with some te= chnologies (since for other access technologies it is rather unrealistic to= modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-base= d solution, can we hear of at least one example of a real-life scenario wher= e the LMA would receive such policies, and how such delivery would happen? A= lso, should there be a solution to have policies in the LMA, how does the LM= A actually decide to route flows on one access or the other? E.g., if some f= lows need to be routed on certain WLAN networks, but shall not be routed on= other WLAN networks, how does the LMA know which specific WLAN network the= host is connected to? Perhaps I missed the ability for the MAG to know e.g.= the WLAN SSID and provide it to the LMA, in which case I would appreciate i= f somebody could highlight to me where that is defined. I think that, though not integral to the protocol specification, understandi= ng what framework the protocol would/needs to fit in is rather important. Cheers, Stefano On Tue, Feb 1, 2011 at 3:47 PM, > wrote: Hello, We have discussed the flow mobility solutions for Proxy MIP6 previously at IETFs 78 and 79. This is a consensus call for adopting this I-D: draft-bernardos-netext-pmipv6-flowmob-02 as the working group document. I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt The consensus call will expire on Feb 15th, 2011. Please indicate your support or concerns in adopting this I-D as the WG baseline document on the mailing list. Please note that this I-D will serve as the baseline in the WG and will be developed further based on input and feedback from WG members. -Basavaraj _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_002_01CBC3F1.60E2658D Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable Re: [netext] Consensus call to adopt I-D: draft-b= ernardos-netext-pmipv6-flowmob as WG doc

Pierrick,

Thanks for the comments. I can= agree on discussing the issues some of us raised separately. If we want to= discuss the key elements that make this draft applicable separately, then I= guess that we should wait to adopt this draft until those key issues are so= lved, otherwise we risk to adopt a solution that is not applicable to anythi= ng.

Cheers,

<= /table>

3D"cid:image004.png@01CB=

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F4= 97D'> 

P Con= sider the environment before printing.

 

From: pierrick.seite@orange-ftgroup.com [mailto:pierrick.seite@o= range-ftgroup.com]
Sent: Thursday, February 03, 2011 7:36 AM
<= b>To: Stefano Faccin; gerardog@qualcomm.com; sgundave@cisco.com; sfaccin= std@gmail.com
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: RE: [netext] Consensus call to adopt I-D:draft-bernardos-netex= t-pmipv6-flowmob as WG doc

 

Hello,<= o:p>

 <= /o:p>

This is an intere= sting discussion, thanks for bringing the ANDSF issues on the table. Effecti= vely, mobility control, i.e. access selection, is a key point for an operato= r. From an operator point of view, criteria for selection is not only RAT ty= pe or SSID; we can imagine plenty of other criteria. Different mobility cont= rol models can be envisaged such as Network controlled or terminal controlle= d and so on... For sure, in PMIP context, policies synchronization can be an= issue and how decision made on the terminal can interact with network manag= ed mobility should be discussed. But, I don't think draft-bernardos should g= o in this space. I think, we should clearly distinguish mobility functions.= IMHO, draft-bernardos should not be expected to deal with selection managem= ent, or mobility triggers, but only on the handover execution. In other word= s, the draft should assume that handover decision has been made (how decisio= n is made is out of scope) and, then, only focus on mechanism allowing the L= MA to transfer flow(s). Although related, mobility decision management, e.g.= policy based, should be discussed in a separated thread.<= /p>

 

BR,

Pierrick

 

 

De := netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part de<= /b> Stefano Faccin
Envoy=E9 : jeudi 3 f=E9vrier 2011 08:05=C0 : gerardog@qualcomm.com; sgundave@cisco.com; sfaccinstd@gma= il.com
Cc : netext@ietf.org; Basavaraj.Patil@nokia.com
= Objet : Re: [netext] Consensus call to adopt I-D:draft-bernardos-ne= text-pmipv6-flowmob as WG doc

 

Hello Sri,
From a point of view of applicability of t= he solution, I must agree with Gerardo that assuming synchronization of poli= cies is an issue of this solution since it comes with a set of restrictions= on how the solution can be applied.
Cheers,
Stefano

Stefano Stefano M. Faccin

Standards Manager
Research In Motion
122= West John Carpenter Parkway
Irving, TX 75039
Internal: 820 63451 Desk: +1 972 910 3451
BlackBerry: +1 510 230 8422
sfaccin@rim.com=
Time zone: PST (GMT -8)
 

From: Giaretta, Gerardo [mailto:gerardog@qualcomm.com]
Sent<= /b>: Wednesday, February 02, 2011 11:13 PM
To: Sri Gundavelli <= sgundave@cisco.com>; stefano faccin <sfaccinstd@gmail.com>
C= c: netext@ietf.org <netext@ietf.org>; Basavaraj.Patil@nokia.com &l= t;Basavaraj.Patil@nokia.com>
Subject: Re: [netext] Consensus c= all to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc
 

Hi Sri,

 

There is no implicit assumption of synchronized policies. A ba= sic example that shows that there is no assumption is the following: ANDSF p= olicies may be based also on location of the UE. For example the UE should p= refer WLAN only in a given location. When the UE is attached over WLAN there= is no way for the PDNGW/HA to verify the location of the UE and therefore t= o verify UE actions based on policies.

 

The assump= tion on synchronization of policies is only applicable to this draft and I t= hink it is a wrong one.

 

Cheers=

Gerardo

 

Fro= m: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf O= f Sri Gundavelli
Sent: Wednesday, February 02, 2011 6:50 PMTo: stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@no= kia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-b= ernardos-netext-pmipv6-flowmob as WG doc

 

Hi Stefano,

One comment.

Agree with you there is no AN= DSF interface to the network node, but the assumption of synchronized polici= es between the ANDSF server and the PDN GW/HA is there, implicitly IMO. With= out this assumption, I do not know, how the HA can ever validate the flow m= obility options received in the BU. If the operator requires any control on= enforcing a flow policy rule, the PDN GW/HA needs to have synchronized poli= cies, without which its always the client decision. I’m not sure, oper= ators in 3GPP would like that :)

No doubt, the lack of MN-AR interfa= ce is surely an issue for supporting complex flow policies. I realize the is= sues and I agree with you. But, the assumption of synchronized policies can= offer some solution with some configuration requirement on the HA (assuming= there are no other issues). There are also the proposals on flow mirroring= on the UE ..., requiring no flow policies. I’ve not evaluated this, h= owever. Folks can comment on this.

It is also to be noted, for some o= f the scenarios such, there is no flow policy interface needed. We can ident= ify what scenarios create any configuration limitations on the HA and which= one’s do not . As I’ve noted earlier, this is surely an open is= sue, that we need to discuss in the WG.



Regards
Sri



 


On 2/2/11 9:08 AM, "stefano faccin"= ; <sfaccinstd@gmail.com> wrote:

Sri,
thanks for the reply. Can you clari= fy in which system or scenario ANDSF is available to network entities as wel= l? There is no such availability in 3GPP, and making such information availa= ble would require considerable architectural changes, therefore the applicab= ility of this solution to what seems to be the only realistic scenario hinge= s on 3GPP making considerable architectural changes. I would therefore not b= e so hastily concluding that the ANDSF information is available to the LMA a= nd underestimate what it would really take to make the solution applicable.<= br>
If we cannot guarantee that there is at least one realistic solution= to have the MNa nd LMA in synch, how do we expect that this solution is app= licable at all? In 3GPP there is no need to have such implicit assumption, b= e cause 1) the MN is provided policies explicitly through the ANDSF, and 2)= it is the MN and only the MN that makes IP flow mobility decisions and comm= unicates them explicitly (with well defined signalling) to the LMA, and ther= efore no magic is needed. There is no need in 3GPP to have the ANDSF and PDN= GW policies synchronized, since the PDN GW does not use such policies.
=
Sri, in the end it is a matter of whether we develop a solution that wil= l rely on some unknown magic to be deployed, or a solution that we know can= be deployed in at least one way because there are solutions to what I consi= der major open issues.

Cheers,
Stefano

On Tue, Feb 1, 2011= at 9:06 PM, Sri Gundavelli <sgundave@cisc= o.com> wrote:

Hi Stefano,

Thanks for the discussion.

As you say, t= he ANDSF policies are allowing the MN a.) to make the right network attachme= nt decision and b.) make the access selection on a flow basis. This same pol= icy that is present in the ANDSF server, is available for the network nodes= as well. I’m not sure, with out this assumption the solution can work= for all currently listed cases. We clearly need the MN and the LMA to be in= synch with respect to the configured policy. How, that is done, I guess we= will not try to know.  I thought even in 3GPP, this is the implied ass= umption ? But, this is for you to clarify. Not specifically for IFOM where U= E and PDN GW/HA are negotiating the flow policies, but generally that the PD= N GW and the ANDSF policy server will have synchronized policies. The MAG an= d the LMA have the ability to carry this flow policy information in signalin= g messages and influence the access selection. The policy is a opaque object= , with extensible formats, when carried in the signaling plane, should allow= the LMA/MAG to apply those access policies, while assuming MN is following= the same rules. These policies can surely reflect the specific WLAN access/= operator specific rule. I’m surely with you, the lack of MN-AR interfa= ce is surely an issue and I see that. But, we need to understand, what are t= he limitations with the approach of  out of band policy interfaces and= what will be the solution limitations. If we need to tie the flow movement= at the prefix granularity and rely on the natural ND interface in the form= of RA PIO option, more like PDN offload in MAPCON, or at the granularity of= a flow level, is open for discussion. I want to simplify this draft for sur= e, we can surely discuss each of these issues on the WG draft.


Re= gards
Sri






On 2/1/11 8:29 PM, "stefano fac= cin" <sfaccinstd@gmail.com <= http://sfaccinstd@gmail.com>= > wrote:

Sri,
thanks for the reply.
I'd like to comment on the "the flow policy decisions need not be= based on the specific WLAN network". Does it mean, as I believe it doe= s, that the current solution would not allow an operator deploying such solu= tion to decide to route flows over a specific WLAN or not depending on which= specific WLAN the MN is connected to? E.g. the operator or the entity in co= ntrol of the decisions for the routing may want to direct certain traffic al= ways over WLANs that the operator deploys, and instead route only some of th= e traffic over WLANs of roaming partners or of the MN user home. How does th= is solution support that scenario if the LMA is not told specifically which= WLAN the MN is connected to? From a deployment point of view, I do not beli= eve we can afford to leave out this scenario. Please note that the establish= ment of a security relationship between the MN and the MAG, and a specific M= AG identity, cannot guarantee that the LMA knows which specific WLAN access= network the MN is connected to. Assuming that would severely restrict the d= eployment scenarios.

As for the MN and the LMA being magically in synch,= I am very concerned about a "glass ball" solution. You mention AN= DSF defined by 3GPP as a solution for this "out of band" delivery= of policy. Fair enough, however there is an issue with that. ANDSF is desig= ned specific to be a MN-centric solution where policies are provisioned in t= he MN and the MN decides which network technologies and access networks it n= eeds to connect to, under what conditions, and which IP traffic needs to be= routed on such accesses. No IP point of attachment in the network (i.e. the= PDN GW in 3GPP that is the LMA in PMIPv6) is aware under any conditions of= such policy. Therefore, even if in order to apply this solution to 3GPP we= wanted to use ANDSF, ANDSF would unfortunately not provide a solution unles= s the MN can communicate to the MAG and the LMA the decisions the MN has tak= en based on the ANDSF policies.

I believe the key point here is that= we need to understand how the solution can be realistically applied to a re= al scenario, and that we need to ensure that important and realistic deploym= ent scenarios are not excluded by the solution.

Cheers,
Stefano=
On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli <sgundave@cisco.com <h= ttp://sgundave@cisco.com> > wrote:

Hi Stefano:

These are valid point= s and some good comments. Let me share my thoughts.

Carlo’s dra= ft is not assuming any new MN-AR interface. Its going with the assumption th= ere is established policy on the mobile and on the LMA, which allows the mob= ile to select the access network at a flow level granularity, without requir= ing any explicit signaling between the MAG and the MN. To large part this is= all about out of band policy interface, such as ANDSF, towards the UE, lead= ing to the assumption that magically the MN and the LMA are in sync with res= pect to flow policies, access selection and they will make the right forward= ing decision. Secondly, the flow policy decisions need not be based on the s= pecific WLAN network, but it is implicitly driven by the MAG – LMA sec= urity relation, where the MAG attachment to the WLAN network transitively al= lows the LMA to make the flow policy decisions based on the MAG identity. If= the WLAN network is not trusted, there is truly no MAG in that network, whe= re the LMA shares a security relation with that node.

There are still= some open issues on this draft that needs to be discussed in the WG.  = On the approaches to allow more a flow aggregate movement, that is a discuss= ion point. There are issues that we need to discuss, supporting split link m= odel, or eliminating some favorite brand of signaling message (FMA) and ridi= ng on PBU/PBA and just with one FMI trigger, and on the aspects around MN ap= plying the flow policies by flow mirroring. We have no agreement on those is= sues yet.

Its just a base draft, for further discussion and resolving= those issues. But, hope that is not a stopper for base draft selection.
=  

Sri





On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com>  <http://sfaccinstd@gmail.com> > wrote:<= /o:p>

Raj,
thanks for the email.

I need to apologi= ze in advance if my questions have already been answered before (though I ca= nnot find a conclusive answer anywhere).

I think that a protocol that= is developed in NETEXT (or other groups) should have at least a potential r= ealistic scenario for applicability.

In terms of applicability, thoug= h it is not part of the protocol definition per se, unless there are solutio= ns in place for either the host to indicate to the network where the flows s= hould be routed or for the LMA to receive somehow from somewhere some polici= es, the solution cannot really provide flow mobility since there is no way t= o decide which flows are routed where. If we are thinking about a host-based= solution, I have not yet seen a solution as to how the host can indicate to= the MAG and ultimately to the MAG which flows should be routed on each acce= ss. If we are relying on modifications of layer 2 protocols, aren't we defin= ing a solution that works only with some technologies (since for other acces= s technologies it is rather unrealistic to modify L2 for IP flow mobility pu= rposes)? If we are thinking of an LMA-based solution, can we hear of at leas= t one example of a real-life scenario where the LMA would receive such polic= ies, and how such delivery would happen? Also, should there be a solution to= have policies in the LMA, how does the LMA actually decide to route flows o= n one access or the other? E.g., if some flows need to be routed on certain= WLAN networks, but shall not be routed on other WLAN networks, how does the= LMA know which specific WLAN network the host is connected to? Perhaps I mi= ssed the ability for the MAG to know e.g. the WLAN SSID and provide it to th= e LMA, in which case I would appreciate if somebody could highlight to me wh= ere that is defined.

I think that, though not integral to the protoco= l specification, understanding what framework the protocol would/needs to fi= t in is rather important.

Cheers,
Stefano


On Tue, Feb= 1, 2011 at 3:47 PM,  <Basavar= aj.Patil@nokia.com <http= ://Basavaraj.Patil@nokia.com>  <http://Basavaraj.Patil@nokia.com> > wrote:<= o:p>


Hello,

We have discussed the flow mobi= lity solutions for Proxy MIP6 previously at
IETFs 78 and 79.
This is a= consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flow= mob-02
as the working group document.
I-D: http://www.ietf.org/id/= draft-bernardos-netext-pmipv6-flowmob-02.txt

The consensus call w= ill expire on Feb 15th, 2011. Please indicate your
support or concerns in= adopting this I-D as the WG baseline document on
the mailing list.
Please note that this I-D will serve as the baseline in the WG and will be=
developed further based on input and feedback from WG members.

-B= asavaraj

_______________________________________________
netext ma= iling list
netext@ietf.org <http://netext@ietf.org>  <http://netext@ietf.org>
https://www.ietf.org/mailman/listin= fo/netext

 

 

 

-----------------------= ----------------------------------------------
This transmission (includ= ing any attachments) may contain confidential information, privileged materi= al (including material protected by the solicitor-client or other applicable= privileges), or constitute non-public information. Any use of this informat= ion by anyone other than the intended recipient is prohibited. If you have r= eceived this transmission in error, please immediately reply to the sender a= nd delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not auth= orized and may be unlawful.

---------------------= ------------------------------------------------
=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_002_01CBC3F1.60E2658D-- ------_=_NextPart_001_01CBC3F1.60E2658D Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAKAA4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDSu9Nv V0vVpbjQL2KfU7xR5T6qqmRclsrnhecDFbGl6hqL69Noem63ZRQ6faops5Y2mmiYBQdz8BuSR1qD 4pxpLdeHo5UV0N2cqwyD93tXexW0ELtJFBGjv95lQAt9T3oA/9k= ------_=_NextPart_001_01CBC3F1.60E2658D Content-Type: image/png; name="image002.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.png Content-Location: image002.png iVBORw0KGgoAAAANSUhEUgAAAIoAAAA+CAIAAAB7vhRQAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAIthJREFUeF7tfAeYHdWV5q1b8eXXudXKoAyIIH1IgESwMTKDSDZebNKsZa8/ xh8MNgxj1mYxLGZtgseDDcwABsb2YH9ggglDMAiEyCIMEkkSCOWW1Orw8qt0b+1/ql4/tbJEN9t8 OxSPp3rVFc+555z//OfcUtjwLZyxAB/8I8ObUMLfGmNCYYES/Yq+63/ETyz1LdH6Hvbh4RXCwxX8 I2vrOH3tSNqK1W2X7j/78Ill4JWj5x2epaaeSPZ1qdPPUKpDs9TUs93JdrhcXflDc8X/T8+CAQ65 QWef7dJ/DbV+mf4hqjO2beNnexP7evbhtJ6d7xGOLc30pKpLJjh5nMEtsBw1kIH0hfRZUGXS7fej kUMV0elxVfyQpBts9wZ3zaE9etAiGPTtbIsciqIFwXg1MbtpkukFYkj8mxJIJv1AQtt24FUDv2rb ObfQy7xe6Zajm4dawrj0OXRyw68euBQasByxm9RzmN5wZHysXvZ2Np4IBezPgt0FziMVnFuRipRc VVTF80XOlJ1Bpada6HKKBSagGjjW2ngYkmGxP3e5h32H2dlCfpFrCWOOYgTsEKO1mZmKH4TOTYm+ EZbqPyHpaAtW9rBPwBQ1YDzA3gHgGcdvEQRCqjLgMlClbFStsWa2XUvEGPdEFffgq5zJz5Ny9ns4 DtGgqJ0GFiOZyZgD7xJ6mIRkp6cnZ3wdGovA9iAWIHboxYdiAtK1VELpS5iKpsSEwt1wi8bzOlsj c+9UOrtxB3VXO4gLD+Ghw2o9oavCHfj0D9lDo9QPNVpMH0Kt+5pP+bBwaQFXuEwF3GO8wgKLC2jL NgwWuDGcXdU8FQZIMc5PGNaIRNat5l0W+NGVDTJqstPo+vQP7pTEFW4kkBnZfKTQMEnAV/jvtsM+ 5c3XDxtu9URZYaSeIGhXE1P0BtUVUuHkmsLH/bQfWA9XpMG5w3mF+xlViWvcF76tsWygWK6iicDA h3ELu5k8meXpXr+UIzkbiFdhwqzhJAFpJfSoFMLwk/TCSUHQN6kpUlWo1iH2jcOnnn43su2BJBsX bxwDD+d6gabCfsIIM7gPsxVeIbGKRilMRfV9WRIycPA//Qefx6AxSL3ienHDsiXbKMsMcI90QzKH a+y3EODwSAF0y+H2yHhgaBBjDaX32xp8Nv40WA+9n1BosMa60/EDfD0g3DGZ8Qfb8ELMh3qG4FqQ shuoNqEJdxzQhuQbmjsc3/cRegLmqTBSSBF64tyHm1OCSlJ9Nd/TY4uqChjJkH9BC+CYYNyBp1Rt GFWAw30xUPCRkgaqB9oibipy24NZhlU90cX7zadZs2anx4wra1wEQ6QeISFftQwHJbyRrl9oG1ue d1qHLXPkqHTJJf4AyStCCkVVgRrcGN/Iq1vsfCEIDENTfYGI5UFRAVd9U2B3qZYroq9Q6S3wrm73 veV9FQCbmslggJnYVVFsYMTBaKV+7LCqZ8ATYLCNt1IzzI4OV/dcT+j6oK1HQKaA0KriBBwDPusp XVOP8A6dAyvqczyLKSaoPWgoCuTwcnBkUmM2l+vL+T78TSXlQTVkPdAwTDGkalVV182UZLphGlXb Xdvtvfpm5ePldsmDyQB7AhpWB6a6g9HT8MWe7UeIxdhIJd6hpmMe/AYH6Br0wAkQtxURI96Ae8DW Us1PODiebMhJ3ZXCkkEyCDRIWUodbiwI9EDRmQBE0asiKApfKpoCG0A2S7icQADpDw7LF7YD8qFU KuZ5UMlkxWEHJVoam/K91VK5CtRJHhPLYOMOneNzpJ7RVqZNTZquj2GKYABRcNFPXRMHF3lBCH27 TzjoMbjDuE0SQcZEcEKEyEqVJlMxlitSqJrFD5jabCSQgSIrtSBvsgYcgDPjULg7rGOroRY1v1fa Piwa8JwjRgUCvo3DlkhfgiuGYZIqQ3ARuKJcqI4ebY4+INFbKG/tiTBBPNTPYIHccKonKihEfiCl 8AOtxgbgYMQLxdAgD8arhi9U6MV3VaEHXpwMS0V8hyGE3xwUgIbwLuHpdQQRgW0QvYqggi8SO4Vw 7CVjbuClmt2JByX0uOv7psI5Zy6cFwcgQKzDChcC+ADy17ijyB7XJkRNtAQCIWmcSV1wrGnwb67n wbp0AyRUoPksnmQ9hUos5s6c0dy92d7SjcdKhuigPy59Wgc3aA//aS/cH05rxycUtYHFFV8Knfu6 qgeq5SvIUDyOtF94ug8MnILiyEoge8QDaIf8Hwa3RtEBnBoxOIFKPo1clMI0IQIV5J3p+yMVpsaz RT21STEKwquqVO7TVaFxMAdCVel0+EAd+AluSbU8FhPc8EjthkcFKD1wLGHrim0EXkwNDEjOR/YM olCtYucYCxzJ8uUzTkq0QjWspCiDhW3D7NxqGV2Irdu4OUrPxMD7g/lHFAiEJjFylbSjxzyzymI+ h7tgtpn3NN/ThVB9T3U9zXORXKq+JRwdQV1xFcVD+AZdI7jucoOrCDMSwVyyraMPVEaNM1y/xJGH 1vJ/KBXATYXwWYDBrsPwYLalwO/yq74BuEAWFLIE8Lak0uiDhf5FPoXxIaFr7EjUkRRBIq1WpbFq jT0kzm04rYd8M54vhKAZNW4oOp5cwsErAnIXGtM8riNmMAPS9aRflkKr6pqrKRUDOhS26dsxz447 +Pa49FWiviEWTxGu6vlGVcR9G5ahStf1PSeTbGZ+UlbjikyhxsAk4K8bSA80HOAD0aZS00AHBEDj vkdWqbrIh8APMFWDqYa8QY3TIe3U2AJKU8MclaIY94uFypSpMQMYe7tM6FM6mV3HnjBM7t8y8JD9 PRxjZHK8oVVJaJTBBxY4A6l1uvl8YPeygs2KCVMkY7aluczVbGFrgYEYA0emBDrkhKFb1dQi1GUq qZhiqm5cF5bhW7qIm25Mh3SrmUbnoMMbzWSFaDfdZLxk6GVVRX5FsYch52S+DACqwTKIQmB3o0Jk IPIjlCkYJwQa4P52LGiQI4U/hFtEhFQQmngAbWcakytXy3x+CJzbbtVwySWXnHvuucuWLbvyyis3 b968V11FKom+ETCj/esr9cN1Xfc87/jjj7/22muF5137s58tfO45uK1TUpNbhaa5wtWVmMs3id5J X/nKOddcVu3deufPfsRWvP+tL83u9HuThx1+0FFz0uMPhC8KwDyHIAkykqZR2fTxsof+zV2zrNkS ik+igWB9jsCD8CBEbOv0WY026wJe84HoRIoJi7wnRC8VDArHAVz2pes7rreqVFleZFqCIfkC6Pbh vuC5iELYUVxECwmDaa7PmerD0MkejWzmwSe8d5ZW9iq0ve6w3fXqwh05cuSGDRuig2+//fYLL7xw dyci/xsqIzoWgEgigMOlAzgRbagIsYv8edGiRccddxz2f/fdd08+dX7v2nXfaj4sWXA0wSqQh+0l Jh1w5ZN/yh7QhH1eeeTeRy757twJDeljjpn1kztNI7u7mym889Qj/7igI+GbQGUE2zSHJRSNV7zu bIeceEhDNegBVgMhEAYScNXEe4LlZICCBOXBw6LOwPLSX1u0t/ZWK4WgDHSQYm5UaoiiDT1tffzB h4XqUeGKgScxZmRgJha/pS5cVNir9Pe6w65jz4QJE3Ck4xAuPO200/ZwloGGgnUoA9/QDQ1eKXep G/zJNMEYMtfxJk6YOHnSBHCKloockGhI7gc5Zp/ygwXQjY0kL2CZTEvLyLEl3z/2ssugm4rwkTaW A4YPUhhHSlfKcohgY9kW3UggaxeSu4HuKDGQXhwkmV1pa0xRsMAVgIwlyn40rNCIQBgQJ2BVIcuB KMqgLJSCqdlTWpMzxzbMmtg4MqOVy6RtSrAoSwrNtT/ehAEozD/DqhKNT8L+pOohWbZTDyQbGUEk 30j0kSh3ucyePfsPf/jDzTfffMcdd8BfYZ9Jkyb95je/ufXWW2+77bYzzjhj5yA00PsZJjJ2ZCe8 mSWE42JEAgP1+bmDTjnuhL/7ZgkZkabi6Tdt3NKzsThu9ldYehJaOpBn6lxJKLALFuPM5MBnPEH3 6L/86P0lpxRoBhg0Qm4YzcB1fgWxJdVgSkgf8iMyvErx3wdmxpBA6FJNRdNBgRKoJmihigpz+jKB 0Z6MHz65beqkNLIk4YZZrI6UGfKJKGtKlQNVEMGNcwVSU6TnMcM0C7khCDx4JAS97ZZIMdFioHTV 77UG7qRpGjgsbDn77LPPO++86E8IVIlEAkq66KKLoi3z589/++23161bVz82Cjx1xVNXIIjgwBtj NRgeYJPquU4P87932/XYBzaR0Hi5u/D23XePMTZZo1sYa3Q4s+CNyptfeuwPaQvjGDCaiqJm38au F1/rW782kY2XNLNBagm7xPXNuZjVUI7HzSY37sVk0VOa/HJb0vogxpSylq3qNpQUVxJWscLUWNnw dIyIKugcoSRcUbGkV0ynSoc3j2hLO++95+Rd7qLcITQL+yHN8TQJt2YGvNJgsRxXBQxXseJVuOgq PbQK2Bj6dpgTlkho9QE6bty4fD7vum61Gu7dbxUDRb0nYL1DnK8fFl0Gy5w5c+obFy5ciPW5c+fW t7zzzju5XA66TKfTqVQqmUxGutm2UAWOJZAwuj4GpC3FSrbm76+/vnXMKOG7CYWw7FO33LVy2ZKx IxvdCkVancHI8izoefa6f1zyq58sv/nKVb/6nx/885Vv/flud8P77UY1w6oqnQnQwRRmCsEMGVRG r8TMXNlk6P4wp33VaZjRR56oL+EmY46le8W+WLkczyUwImzdaxhlN4+WBnPVzbrWKxxghc0dCeew qUaGx5Uyg2eErbsurMTlQQz9Pp7EcwW+w0gXaDXx+KYuWCF+CoSGY489FoO+Pu6jaB2LxW666aYH H3zwlltuwfpAqxgooR2tZzvx7eZHHQ7g7I899hi0tWXLlieeeAK7P/7442vWrMFtwWgQ/wuFwr33 3nvggQdCMbAtgMBot9pC0TZoDCyffFDQ7RemHTj3lEu/g3IPfpoKy6/e+O//++eHTWowdQr1OKqi aCkFoTirptvMVFzzqokA7t7xrSAh/JhbQRZKgV5Nu0q8RyDB8SiRSsIdFvq4Vu7155zw7U9eNzZt eauD61rVBYODQJVvyoh8YSxT8pVKZvp3M+MnrH70iga9YCpBoZKwjfZ4blU2npk2ofn1FR/mcn4C BJHoyeWDRMIzYJEcdgluuyHQSoKXN2+NdedqTuiCCy4oFouLFy+GAqAGGEqkCQgNIeDQQw+1bZtU vSsvRRt3qQIYAc4YhaLe3t6mJkJQ9YX4qtAS68a7B6UOxNZQ3qmnnoqdX3755aOPPhor0N8V37jA +evbqCav93v++ZGHDp5/fCGoJDxTNdSfnblgyV/uOWPGxI50Z/vJ3zrk8ju3IoEFBPCdJX+5N2Px JDyG43dvXP3BS/e1F3qaglLJ8h0lqYlMsSLTR88YP+uYl//XT6af9VUj/Xyx7cBEdsS4GdcrpTVa Kub16B8+d1mu9PERx/46M+O0/IcfaIl1nyy86oDjb0uMP6n02vc+WHhnE+oLjceMPnFB570XNZzw 3arrP3rfnbNPvPjIs35Y6vn4X2+4elP3m9847+pXX/9d58fvn3POL99a+uC6zldfeNl8+XX1xUUL m9qypmn97ne/++lPf3r55ZffcMMNn3zyCXz+hx9+WA8QkWIiSe6ch+zJue3O4iLdnHDCCRgCOCOW 9evXYyN8XfQTC1IlGE2kSFwYS7lcBo4YqEg4Hl3T04GV4tYWN/e1y34A3TghSwrdPPfHp/7jL7+f bna0N8UAq4SmIoVuQwLjVZmoHnnWeZPnnz/yb84de+aCGRdd+zfX3r3V7OjjTdJooEIA/IePdLaY POLY9JxTpl1xV3r838Wbz40Zh6DMU8h3Lbn9HN+0EtNOGTflv8cPmvv6Lcd0vnd7YswpxULQu3zh +rVvvfPSbxMNqoyxiuUnRx+/SfG9bCbPqvNO/f7EE753yYJZD/715n+4/r687Y8Ye6QWz6LY0zhq rpYcnSuZi1+177jt1s7ujZMnT8HDwGK++c1vfv/734carr76aviPMWPGQHRQSSQNiCuS5M6jfO+x Z+djopg0b968+p9GjRrV0dGBGFPf0tbWdtBBB0E9wA5nnnkmQAT2uf/++weeDXEUi6mpfTI/8uBp Z//wQoAFz7PhvsrrCndcedME1pYwAyvmoXsmRN2oNIBh1oQWp/zRd8pS5hl6A5hvtPBMu6PFcoBd qgGA35JJbl21lBV6R8w/3+9cGp84L94wS65eCdY1t+lD1tnj51ZypzvR0rJl49LCx8tXvPGIw7oV UZGsV7ELdhFZglJBkNVitm30BAkHVIWTz04ZtfI/n1j60ab/WPgo4mZTi1IpF+ySU0AEEjyRbHn6 GYo6X5p3wrL/XIqVp556Kh6PT548GYEAP//85z9/9NFHSCujUbtXemW/Obco5cTZx44di2/YxIoV K6677rrOzs6pU6diS6lU6uvru+qqq3BnEydOhG/FMOnq6gJMqOumPlKASU3V/JB1XXzlFU0jWtEL nQDKZcojt99TWd0VY2oyGVNiPgqXUXW4rGkO131gaSOua3GD63HGE4B5ne/yYpcKrg68CogWsJzg 4PxqYfOaw78yb91jv060x9rHN9tbl6LFIBMXforlWNrPWqs7l7ccMKX5qIOnzV9gsGQllgaCzCTT HdlpnqubpsoKWjyZnTLrghEjTner0worlh4ye+bXvnzet8+6xS/1yl6eSKgHHzF35qy5B0467LXX tq5cRff51LNPzvvqScfOnXvWWWfBMpB9A9lGXAnG8fLly7EC5LZLixk4gveknl0eXM+NAKBhEFDA UUcdhZiPkyIBymaz7e3tuDAuj4j34x//+IEHHsCQQST75S9/GV0YRgYUhxWPCVPVenq7jxs5e/rZ J/fYZQd2oirvvrj44d/8FrpJK4lsOmNTxT9MMZC9BgJsqKmUtix51l72vL76VfXVh1645m8X/ury RGltIy/rYFXIm2sYFvFEYuVLi9gnL/nFNyufPCr7Him6a7n/hsx3gSYz3bfHVlZobz5eevP+w8++ qjE1RikuzijehvWLY8m+KV/+uiurSECLq97a+swVo0YHPfm3mrPjVr/5l+L7//L3V19+4kktN143 R69WH/njvx4/98QfXn7PrTf+/JZbHgjrV+kf/cOljltF9vfGG29gvD700EN4/Oeff/7EE0/8+te/ juGL7x0i+s5eClt2hAYRKhsIDXp6epqbm3c4uJ7BDNyOkQL1YAvs6cUXX2xsbIRW4OKifXCLuCes tLS0ANRNnTLV4Uo1l7vizPNu/OOf0iNSwDQxeDCVXXHo8SuXLZtgzBLuu0d9mTU2+ZVNW1pPv/jI y35dCWQcBOTWj6+YPXF8BmQKM5PMSmttaCSE/nxWVlFBQx+BAWYNjQOb7E0dY+MTJigAyEBLqay+ vttrzqRjmlLOF7knsxljfc6l3ilTR3xpbNMKKP9t9VWdNbQhX4kVS23ZcUcEo8eNGTdh9dNP+92L uyt9z77FPiqw0WNYm2n2BtbmnurjT7o9pagTOR6yCvtEuNUx8C51g43bWc8Oe0dObMdkJTwTNkZh PyLWsAJ/et99990ZLtAKgBlsCx7v1XB58sknr7nmmugmIuwABxTOVgsuvOonqZZ4gN4k4UM3z/zT 799ZtqQ51l4RjmUAOVSRigegqsGWIO8BTEaJLmmMSLJRjfrYDpZJQw16V9HvdrUcHKOCD4KsCHCY 5G1ZbcKYrK5a7UmtIROD7Y1psgxe8AKU5rjerBe4bGrVW8arrR2ydQyqgDyjqa3tjAakx3wH8xry SDvNwF/5/MPFrkUGz3e0xKcfmjh4mtbYmGbxRE+X+GCZki9FbW0GSNJ91E0kit0pJtq+nfUQVxQu 8JKwRMQuhA3YJkIL4lvtgDD2gMl++OGHB0I74EXkQPWLwVBgLplMJmJIK5VKhFVwTqSosC1A/kqA Zmque4p0XMQczrXeTZtPPXhmk6eaepoXrAmZLXPmsVhQLazrbv3ad+Zc+lsknEhhVLf04M8vb08G pvT8wLLVpK76xc2rty5/O6N5BuoC0A9IHcn1ZG7q9HY0gQhWRo2Oghh1doBfhixR3AE/SLRtWGkj n4jqAkSiSir3oNMObQ/CMHNVTzPigeJlFAdO2U8k3umyXl/lbtiiLH+/vHK1ADVIsiZ2G54NKerQ dFHtQj1021IioqxcuTJaj6xkhwXbH330UUCy+vbzzz//4osvBlIAkQoG4cYbb6z/qW6UdZcIjzxz 5kyU16AuI6x0+YjyjJ9+xunPPvJoFnWYAKVKeXIzP+OkJtfOeT2lscd89ZjrnvQks9FfoCmGhwoz ckFwXgbqAzT9I8i998Bti3/7i7Y4GhDQpqHagTZiUmXC1IRQ4HeIXkG3GjVEoREIoAktOCCow177 6AnBMAUijoInNutIVtFT4NpqApexHbB4fialVCt9+U1+6sEl+r2LenttaidFGtbfUQNelmrtdbEO nhfdbb3nvffeQ9iArDHksURmCFVFJFKE2feMC+vZK8HnfrwX6eyuu+5asGCBg9ovknwfHWM6fN3d /3bPd769AGVGjSlVXIqJi6am5s1q7c11qV6p4mS/8/RaxlO4gSoGuIJ+DrR84MZQmoPrY+iYEl1v 3vnd+RmlZKGsoXBHGplGnkqDHi0rHNU2dG7gQmCqHfTdEIEJSyIvS2U3PA1WoEEk26iwGS4VSVFj 9aQjuOchkpXjQamMaxWsjj8tk0+v2KQoTeSlyW6gmGpYZajVTfu7RAeroN2qB0wR3BfC+86mE215 4YUXIpZ6v5aoIATQ8sorr4Derh/712eeOeecb/V09/T3iNGsrF/NbxqnWbbmgKdcv6Y8/Rs/+NKl NyHFpmaz/gkDEcePb5TVVj1z5+M3/ag9IQ3pUREUNuamBNqq0UtFHVGWRCeQgokj0Ca0r1OhFW3y YUEP56BWQ7UY6BW063Cpc4E+RSpKU+sPlYKAN6pcV/qsUfcuLT+zYiPjiHugjKAbKnyE56g/ECh0 3ONgvdyeitbTp09HugvcjJrCQEYPtwC68xe/+EVEFuzXUudukaldfullM2bOqLru66+/dt11/6d7 61aiOjCqkUVLFRbw+79tT26WOQ3NNiVDptcV5ZTj5h987MnZtjEoJWH8U3CFQUNhQm54/9XXHrpH K3VlkZgi+aSeNNghXJbLVJe601CLkEZoRqH5hX+l6BwW2cLm26jPEBaEPyFOGqizRlP4EaE0VuKi hDvsMttuXbT57S0guUP5R1oJvzG2+gn/qEvsM7OeutCBlevOLdqIxwDaxgoqDhGdt+8Ljo3AXkR7 t7a2wllFZ7NUtNVIZhmq7XgBnzxaufFL6dQGc2tS2mYhBipfFD1cT0tyoxFhwlKQ4viOqrhaTPVB 9FQ15sdVtHNgRJOQMewD1ZMK2jYdKIZLdIaaauDBmKgHETMLSC31MR92LUjM/DJRoGZalfw5tgBN SLRjQ1ueGbhcMzay5hueXr2aGIVIKaSc2hQT8NaRTrazpH0Xz4577rYNMUJx2B35HVijHZZIxDCp vULDHS6I0UeSC102QFKpXI6qHXA0VMDEwIVZcBPczdwpqUOTLvcMYTLHLVgq8lRmIV5wjeYOeI4m weej3uMrvp3Ah8uYTsM/RCLRKKKCBbXUUhMHSqNgFKi8GfXcADsQwUCSDGNjBN5gjGFPPOKNROGW urDJ0+G+0HmCmamSW6tyyqKPAQvgvgwUW8Nz4BqYCUTqrdlLZDyDXnarnj3LvU597u8NRBqlZfv7 h0+oEbbkX1AIFd8Ynx6ZopmFQeAkwcVxboOhpuY3TP2BP0OER20aokShE3CZOtSonR1yrk0oDZEY NRBCC4C8YeCGUqhmjvYb2nFgX1RtKhXabRBLaGTi7CgQoaSAO9AxprioAGmLVPq1TnfJRqQ5uKhH o6HmxFCKGzAxdSh0A9nuN+e2v/r4NPsHTloLWhujgEfN52HvX1hLpr4NiL023CF9GAT1SpMxh/Im kWMc1z7hBsqAqameWgFqT0wH7HLaHTWbUgsp4TuGVkgXGB1pEGVCMClNL0tjyXJyxeGJqLf3M10+ l+phTmNcTxqqcF2yFgx/ShbDcBItxDhEGqhJPPRRtclq0Xr9U1ujM0TaCw/ejVAx0xRXJI9I14Ql oU0XU1DRJEzsMo8n31tXWVFEuAV2qKGG/4LqYe1JNaa6od9AdzqaLWha2mcqCDo58jD0g8LOwuhI U63IdNBaj0urwkxWldSTb28Jx0RUZaZb+kxv6/NoPYiHk9tT8cCl8Rm2n5GtgEUboilnu1dzNIuH SGFUMAAQwDPZmM5jWGVulszWB1/bsryMGIM/omJO0/2HYg7Pnkbd51E9lspGpDCp2oagPLAzJLLI i4Vpyf43GO+32RHAI0LB9QMtnoIz09PNS9fbr3ycD0+F8QP/9v/i5TufR/XENK0xoWnCQcZBegnn 54KWq01Tp7ewRO2A+/DZjesByhrwGZhAApeHs+AolGmaZRVtv3lEx5othftfWdtFExl1pmtoBKYe s5qqPkN88HlUT3NSbUxgZrTqCY8SFHr/HmgwmuVObTlIt8IZBXv9EK+w42Q6aubEpDbCz9SESA6M 3jyBJQSJ4QxTmiCEpnaUbm0/iDV3vPJ+5x1PdXZiAiQQgRrH/Iloqnyolv4JJfttoft0wGeo+X24 PooUrop32eAfglOwFhwkTplk/Y8jUlUPbZmUH9IMjoi/IcQcvVxg7wuxcEBp1Ly5484wPw0MOSZU QTFq2N4JIhA6ozQV/W0o2pTjeM9OLF7Umx/+yPvTErSbQyMRP0K4IZLaPt3H3u90T3sMr3ow4Zfm tuE5Q+4QFRZ6v9cPDmv8b1PNzlzJMjC/wKf5GSGpFQIq6h/Z90f2qId6Z0GG7dUhpRBOHg1nFRGY Vgi7SdVMpnwttryr+tLyvufWlqm3g6ZoDZbf3Pfbru+5H4/6Kc6+50MigVMUpv2QSSgWCDHGrjmx fXqjV3YEKnSkHnRab+MYIvZx7wsN7ZChJG3Wx3nt0MAHhw1DpDwWhTcYKOgZaujWrVhFUzeUtcff Lby+BjVYcmJgb3CCWqPt3q88lHvs06MO5QUHnAtPDgGGAAhvhkJRi2azYWbUP51/gOl2YtYvKmIh /4XcEEA2OpLKnbu5n+3MJFKjRTMUIo9U90Y0KnSwAGin51rALa6iO8A0Y0m7ai9b37ukq7hso7MW 0+dIL8hv/BhoHsyG+IyksMfTDqd6UEvB5UOPjrFrYaaHIpzpTea1Z01XeteB90eiDhqSwvu2F+aC AcP+FMe38fgDifxI2VFdAKQYAj0B8tCWAAKiCEYgA3K3XKb1VN28p27I2R+u71m9tbwRE7BCeYVn xz7Ru1eiK/6Xc241QYbCQzEGz+8fPSZz5swDZK4rbBbpb9uKvFOIssMpCdgzfBsBRaSQ8yfJh6/t ILlGTg1/V3y814o8WFgbQPSXCtJMcPA9Za/L0fpcpTufhwvDZJV+Ugi0JyIizu/0GyPOhgkNOM8+ Nd8MrY0Np/VQGQE1mfBdkf20vEhREIBDq72FY9foaHtfVauGRd6r7uFCnUQGSm/co76J6N0U9IGJ bHvlAM2BDKdqI/5jwjFKqVToxFyV/rYBGhAYDUMzZWe/9De86kG8wTsd0BZDEYjIf4A3VEprXPIu 4Wu9PNnvgequaNtK/cC6A4xkQtojo8MXiG56HxL4NUzLA69G7zUIVenR/AjaGcU6HIHEK+oerpdB 90u8g915eNWDwU2tLQNielQfhsevF6IG2g+Jr//NuRHii+4/Guh1UBdtDDtwavXQunpCpaKQjf7m mm2EnEQIOcLXwVANIzST8AbIc9Yx4GBl/cXxX0jgCwl8IYEvJBBJ4P8CkLsiseCTLsQAAAAASUVO RK5CYII= ------_=_NextPart_001_01CBC3F1.60E2658D-- From rkoodli@cisco.com Thu Feb 3 14:29:43 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A36F53A6B24 for ; Thu, 3 Feb 2011 14:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.526 X-Spam-Level: X-Spam-Status: No, score=-109.526 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivUU1DMPlNUM for ; Thu, 3 Feb 2011 14:29:29 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 085E83A6B20 for ; Thu, 3 Feb 2011 14:29:27 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8CAK+7Sk2tJV2c/2dsb2JhbACCRZQMQIYJAYczaHOiEpsIgnsBglwEhHmGbYMzgwGFcg Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 03 Feb 2011 22:32:49 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p13MWnlS006529; Thu, 3 Feb 2011 22:32:49 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Feb 2011 16:32:49 -0600 Received: from 10.21.83.244 ([10.21.83.244]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 Feb 2011 22:32:49 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 03 Feb 2011 14:51:17 -0800 From: Rajeev Koodli To: "Giaretta, Gerardo" , Sri Gundavelli , stefano faccin Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLwmpURzmRlysrlUidlexdQorGZJPuBh2AgAAR4ICAAAzJgIAACkaAgADJ5gCAAKKGAP//oT5wgAEoMGk= In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3379589477_53914351" X-OriginalArrivalTime: 03 Feb 2011 22:32:49.0650 (UTC) FILETIME=[49B82D20:01CBC3F2] Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 03 Feb 2011 22:29:44 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3379589477_53914351 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Gerardo, Okay, so let=B9s agree that the current version of the draft does not have SSID/ULI propagation to the LMA. Do you care to suggest how the network deems such an information from the M= N trustworthy? I am sure you agree if we could have good input, we could design protocols accordingly. You will also probably agree that=B9s much better than just arguing about =B3it does not work in today=B9s 3GPP deployment=B2. Regards, -Rajeev On 2/2/11 9:13 PM, "Giaretta, Gerardo" wrote: > Hi Sri, > =20 > There is no implicit assumption of synchronized policies. A basic example= that > shows that there is no assumption is the following: ANDSF policies may be > based also on location of the UE. For example the UE should prefer WLAN o= nly > in a given location. When the UE is attached over WLAN there is no way fo= r the > PDNGW/HA to verify the location of the UE and therefore to verify UE acti= ons > based on policies. > =20 > The assumption on synchronization of policies is only applicable to this = draft > and I think it is a wrong one. > =20 > Cheers > Gerardo > =20 >=20 > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of > Sri Gundavelli > Sent: Wednesday, February 02, 2011 6:50 PM > To: stefano faccin > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > Subject: Re: [netext] Consensus call to adopt I-D: > draft-bernardos-netext-pmipv6-flowmob as WG doc > =20 > Hi Stefano, >=20 > One comment. >=20 > Agree with you there is no ANDSF interface to the network node, but the > assumption of synchronized policies between the ANDSF server and the PDN = GW/HA > is there, implicitly IMO. With out this assumption, I do not know, how th= e HA > can ever validate the flow mobility options received in the BU. If the > operator requires any control on enforcing a flow policy rule, the PDN GW= /HA > needs to have synchronized policies, without which its always the client > decision. I=B9m not sure, operators in 3GPP would like that :) >=20 > No doubt, the lack of MN-AR interface is surely an issue for supporting > complex flow policies. I realize the issues and I agree with you. But, th= e > assumption of synchronized policies can offer some solution with some > configuration requirement on the HA (assuming there are no other issues). > There are also the proposals on flow mirroring on the UE ..., requiring n= o > flow policies. I=B9ve not evaluated this, however. Folks can comment on thi= s. >=20 > It is also to be noted, for some of the scenarios such, there is no flow > policy interface needed. We can identify what scenarios create any > configuration limitations on the HA and which one=B9s do not . As I=B9ve note= d > earlier, this is surely an open issue, that we need to discuss in the WG. >=20 >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 > =20 >=20 >=20 > On 2/2/11 9:08 AM, "stefano faccin" wrote: > Sri, > thanks for the reply. Can you clarify in which system or scenario ANDSF i= s > available to network entities as well? There is no such availability in 3= GPP, > and making such information available would require considerable architec= tural > changes, therefore the applicability of this solution to what seems to be= the > only realistic scenario hinges on 3GPP making considerable architectural > changes. I would therefore not be so hastily concluding that the ANDSF > information is available to the LMA and underestimate what it would reall= y > take to make the solution applicable. >=20 > If we cannot guarantee that there is at least one realistic solution to h= ave > the MNa nd LMA in synch, how do we expect that this solution is applicabl= e at > all? In 3GPP there is no need to have such implicit assumption, be cause = 1) > the MN is provided policies explicitly through the ANDSF, and 2) it is th= e MN > and only the MN that makes IP flow mobility decisions and communicates th= em > explicitly (with well defined signalling) to the LMA, and therefore no ma= gic > is needed. There is no need in 3GPP to have the ANDSF and PDN GW policies > synchronized, since the PDN GW does not use such policies. >=20 > Sri, in the end it is a matter of whether we develop a solution that will= rely > on some unknown magic to be deployed, or a solution that we know can be > deployed in at least one way because there are solutions to what I consid= er > major open issues. >=20 > Cheers, > Stefano >=20 > On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli wrote= : > Hi Stefano, >=20 > Thanks for the discussion. >=20 > As you say, the ANDSF policies are allowing the MN a.) to make the right > network attachment decision and b.) make the access selection on a flow b= asis. > This same policy that is present in the ANDSF server, is available for th= e > network nodes as well. I=B9m not sure, with out this assumption the solutio= n can > work for all currently listed cases. We clearly need the MN and the LMA t= o be > in synch with respect to the configured policy. How, that is done, I gues= s we > will not try to know. I thought even in 3GPP, this is the implied assump= tion > ? But, this is for you to clarify. Not specifically for IFOM where UE and= PDN > GW/HA are negotiating the flow policies, but generally that the PDN GW an= d the > ANDSF policy server will have synchronized policies. The MAG and the LMA = have > the ability to carry this flow policy information in signaling messages a= nd > influence the access selection. The policy is a opaque object, with exten= sible > formats, when carried in the signaling plane, should allow the LMA/MAG to > apply those access policies, while assuming MN is following the same rule= s. > These policies can surely reflect the specific WLAN access/operator speci= fic > rule. I=B9m surely with you, the lack of MN-AR interface is surely an issue= and > I see that. But, we need to understand, what are the limitations with the > approach of out of band policy interfaces and what will be the solution > limitations. If we need to tie the flow movement at the prefix granularit= y and > rely on the natural ND interface in the form of RA PIO option, more like = PDN > offload in MAPCON, or at the granularity of a flow level, is open for > discussion. I want to simplify this draft for sure, we can surely discuss= each > of these issues on the WG draft. >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 >=20 >=20 > On 2/1/11 8:29 PM, "stefano faccin" > wrote: > Sri, > thanks for the reply. >=20 > I'd like to comment on the "the flow policy decisions need not be based o= n the > specific WLAN network". Does it mean, as I believe it does, that the curr= ent > solution would not allow an operator deploying such solution to decide to > route flows over a specific WLAN or not depending on which specific WLAN = the > MN is connected to? E.g. the operator or the entity in control of the > decisions for the routing may want to direct certain traffic always over = WLANs > that the operator deploys, and instead route only some of the traffic ove= r > WLANs of roaming partners or of the MN user home. How does this solution > support that scenario if the LMA is not told specifically which WLAN the = MN is > connected to? From a deployment point of view, I do not believe we can af= ford > to leave out this scenario. Please note that the establishment of a secur= ity > relationship between the MN and the MAG, and a specific MAG identity, can= not > guarantee that the LMA knows which specific WLAN access network the MN is > connected to. Assuming that would severely restrict the deployment scenar= ios. >=20 > As for the MN and the LMA being magically in synch, I am very concerned a= bout > a "glass ball" solution. You mention ANDSF defined by 3GPP as a solution = for > this "out of band" delivery of policy. Fair enough, however there is an i= ssue > with that. ANDSF is designed specific to be a MN-centric solution where > policies are provisioned in the MN and the MN decides which network > technologies and access networks it needs to connect to, under what > conditions, and which IP traffic needs to be routed on such accesses. No = IP > point of attachment in the network (i.e. the PDN GW in 3GPP that is the L= MA in > PMIPv6) is aware under any conditions of such policy. Therefore, even if = in > order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would > unfortunately not provide a solution unless the MN can communicate to the= MAG > and the LMA the decisions the MN has taken based on the ANDSF policies. >=20 > I believe the key point here is that we need to understand how the soluti= on > can be realistically applied to a real scenario, and that we need to ensu= re > that important and realistic deployment scenarios are not excluded by the > solution. >=20 > Cheers, > Stefano >=20 > On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli > wrote: > Hi Stefano: >=20 > These are valid points and some good comments. Let me share my thoughts. >=20 > Carlo=B9s draft is not assuming any new MN-AR interface. Its going with the > assumption there is established policy on the mobile and on the LMA, whic= h > allows the mobile to select the access network at a flow level granularit= y, > without requiring any explicit signaling between the MAG and the MN. To l= arge > part this is all about out of band policy interface, such as ANDSF, towar= ds > the UE, leading to the assumption that magically the MN and the LMA are i= n > sync with respect to flow policies, access selection and they will make t= he > right forwarding decision. Secondly, the flow policy decisions need not b= e > based on the specific WLAN network, but it is implicitly driven by the MA= G =AD > LMA security relation, where the MAG attachment to the WLAN network > transitively allows the LMA to make the flow policy decisions based on th= e MAG > identity. If the WLAN network is not trusted, there is truly no MAG in th= at > network, where the LMA shares a security relation with that node. >=20 > There are still some open issues on this draft that needs to be discussed= in > the WG. On the approaches to allow more a flow aggregate movement, that = is a > discussion point. There are issues that we need to discuss, supporting sp= lit > link model, or eliminating some favorite brand of signaling message (FMA)= and > riding on PBU/PBA and just with one FMI trigger, and on the aspects aroun= d MN > applying the flow policies by flow mirroring. We have no agreement on tho= se > issues yet. >=20 > Its just a base draft, for further discussion and resolving those issues.= But, > hope that is not a stopper for base draft selection. > =20 >=20 > Sri >=20 >=20 >=20 >=20 >=20 >=20 > On 2/1/11 6:39 PM, "stefano faccin" > wrote: > Raj, > thanks for the email. >=20 > I need to apologize in advance if my questions have already been answered > before (though I cannot find a conclusive answer anywhere). >=20 > I think that a protocol that is developed in NETEXT (or other groups) sho= uld > have at least a potential realistic scenario for applicability. >=20 > In terms of applicability, though it is not part of the protocol definiti= on > per se, unless there are solutions in place for either the host to indica= te to > the network where the flows should be routed or for the LMA to receive so= mehow > from somewhere some policies, the solution cannot really provide flow mob= ility > since there is no way to decide which flows are routed where. If we are > thinking about a host-based solution, I have not yet seen a solution as t= o how > the host can indicate to the MAG and ultimately to the MAG which flows sh= ould > be routed on each access. If we are relying on modifications of layer 2 > protocols, aren't we defining a solution that works only with some > technologies (since for other access technologies it is rather unrealisti= c to > modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-ba= sed > solution, can we hear of at least one example of a real-life scenario whe= re > the LMA would receive such policies, and how such delivery would happen? = Also, > should there be a solution to have policies in the LMA, how does the LMA > actually decide to route flows on one access or the other? E.g., if some = flows > need to be routed on certain WLAN networks, but shall not be routed on ot= her > WLAN networks, how does the LMA know which specific WLAN network the host= is > connected to? Perhaps I missed the ability for the MAG to know e.g. the W= LAN > SSID and provide it to the LMA, in which case I would appreciate if someb= ody > could highlight to me where that is defined. >=20 > I think that, though not integral to the protocol specification, understa= nding > what framework the protocol would/needs to fit in is rather important. >=20 > Cheers, > Stefano >=20 >=20 > On Tue, Feb 1, 2011 at 3:47 PM, > > wrote: >=20 > Hello, >=20 > We have discussed the flow mobility solutions for Proxy MIP6 previously a= t > IETFs 78 and 79. > This is a consensus call for adopting this I-D: > draft-bernardos-netext-pmipv6-flowmob-02 > as the working group document. > I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt >=20 > The consensus call will expire on Feb 15th, 2011. Please indicate your > support or concerns in adopting this I-D as the WG baseline document on > the mailing list. >=20 > Please note that this I-D will serve as the baseline in the WG and will b= e > developed further based on input and feedback from WG members. >=20 > -Basavaraj >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > =20 > =20 > =20 >=20 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --B_3379589477_53914351 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmi= pv6-flowmob as WG doc
Hi Gerardo,

Okay, so let’s agree that the current version of the draft does not h= ave SSID/ULI propagation to the LMA.

Do you care to suggest how the network deems such an information from the M= N trustworthy?

I am sure you agree if we could have good input, we could design protocols = accordingly.
You will also probably agree that’s much better than just arguing abo= ut “it does not work in today’s 3GPP deployment”.

Regards,

-Rajeev


On 2/2/11 9:13 PM, "Giaretta, Gerardo" <gerardog@qualcomm.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Hi Sri,
 
There is no implicit assumption of synchronized policies. A basic example t= hat shows that there is no assumption is the following: ANDSF policies may b= e based also on location of the UE. For example the UE should prefer WLAN on= ly in a given location. When the UE is attached over WLAN there is no way fo= r the PDNGW/HA to verify the location of the UE and therefore to verify UE a= ctions based on policies.
 
The assumption on synchronization of policies is only applicable to this dr= aft and I think it is a wrong one.
 
Cheers
Gerardo
 

From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Sri= Gundavelli
Sent: Wednesday, February 02, 2011 6:50 PM
To: stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-n= etext-pmipv6-flowmob as WG doc
Hi Stefano,

One comment.

Agree with you there is no ANDSF interface to the network node, but the ass= umption of synchronized policies between the ANDSF server and the PDN GW/HA = is there, implicitly IMO. With out this assumption, I do not know, how the H= A can ever validate the flow mobility options received in the BU. If the ope= rator requires any control on enforcing a flow policy rule, the PDN GW/HA ne= eds to have synchronized policies, without which its always the client decis= ion. I’m not sure, operators in 3GPP would like that :)

No doubt, the lack of MN-AR interface is surely an issue for supporting com= plex flow policies. I realize the issues and I agree with you. But, the assu= mption of synchronized policies can offer some solution with some configurat= ion requirement on the HA (assuming there are no other issues). There are al= so the proposals on flow mirroring on the UE ..., requiring no flow policies= . I’ve not evaluated this, however. Folks can comment on this.

It is also to be noted, for some of the scenarios such, there is no flow po= licy interface needed. We can identify what scenarios create any configurati= on limitations on the HA and which one’s do not . As I’ve noted = earlier, this is surely an open issue, that we need to discuss in the WG.


Regards
Sri




 


On 2/2/11 9:08 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:
Sri,
thanks for the reply. Can you clarify in which system or scenario ANDSF is = available to network entities as well? There is no such availability in 3GPP= , and making such information available would require considerable architect= ural changes, therefore the applicability of this solution to what seems to = be the only realistic scenario hinges on 3GPP making considerable architectu= ral changes. I would therefore not be so hastily concluding that the ANDSF i= nformation is available to the LMA and underestimate what it would really ta= ke to make the solution applicable.

If we cannot guarantee that there is at least one realistic solution to hav= e the MNa nd LMA in synch, how do we expect that this solution is applicable= at all? In 3GPP there is no need to have such implicit assumption, be cause= 1) the MN is provided policies explicitly through the ANDSF, and 2) it is t= he MN and only the MN that makes IP flow mobility decisions and communicates= them explicitly (with well defined signalling) to the LMA, and therefore no= magic is needed. There is no need in 3GPP to have the ANDSF and PDN GW poli= cies synchronized, since the PDN GW does not use such policies.

Sri, in the end it is a matter of whether we develop a solution that will r= ely on some unknown magic to be deployed, or a solution that we know can be = deployed in at least one way because there are solutions to what I consider = major open issues.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli <sgundave@cisco.com> wrote:
Hi Stefano,

Thanks for the discussion.

As you say, the ANDSF policies are allowing the MN a.) to make the right ne= twork attachment decision and b.) make the access selection on a flow basis.= This same policy that is present in the ANDSF server, is available for the = network nodes as well. I’m not sure, with out this assumption the solu= tion can work for all currently listed cases. We clearly need the MN and the= LMA to be in synch with respect to the configured policy. How, that is done= , I guess we will not try to know.  I thought even in 3GPP, this is the= implied assumption ? But, this is for you to clarify. Not specifically for = IFOM where UE and PDN GW/HA are negotiating the flow policies, but generally= that the PDN GW and the ANDSF policy server will have synchronized policies= . The MAG and the LMA have the ability to carry this flow policy information= in signaling messages and influence the access selection. The policy is a o= paque object, with extensible formats, when carried in the signaling plane, = should allow the LMA/MAG to apply those access policies, while assuming MN i= s following the same rules. These policies can surely reflect the specific W= LAN access/operator specific rule. I’m surely with you, the lack of MN= -AR interface is surely an issue and I see that. But, we need to understand,= what are the limitations with the approach of  out of band policy inte= rfaces and what will be the solution limitations. If we need to tie the flow= movement at the prefix granularity and rely on the natural ND interface in = the form of RA PIO option, more like PDN offload in MAPCON, or at the granul= arity of a flow level, is open for discussion. I want to simplify this draft= for sure, we can surely discuss each of these issues on the WG draft.


Regards
Sri






On 2/1/11 8:29 PM, "stefano faccin" <sfaccinstd@gmail.com <htt= p://sfaccinstd@gmail.com> > wrote:
Sri,
thanks for the reply.

I'd like to comment on the "the flow policy decisions need not be base= d on the specific WLAN network". Does it mean, as I believe it does, th= at the current solution would not allow an operator deploying such solution = to decide to route flows over a specific WLAN or not depending on which spec= ific WLAN the MN is connected to? E.g. the operator or the entity in control= of the decisions for the routing may want to direct certain traffic always = over WLANs that the operator deploys, and instead route only some of the tra= ffic over WLANs of roaming partners or of the MN user home. How does this so= lution support that scenario if the LMA is not told specifically which WLAN = the MN is connected to? From a deployment point of view, I do not believe we= can afford to leave out this scenario. Please note that the establishment o= f a security relationship between the MN and the MAG, and a specific MAG ide= ntity, cannot guarantee that the LMA knows which specific WLAN access networ= k the MN is connected to. Assuming that would severely restrict the deployme= nt scenarios.

As for the MN and the LMA being magically in synch, I am very concerned abo= ut a "glass ball" solution. You mention ANDSF defined by 3GPP as a= solution for this "out of band" delivery of policy. Fair enough, = however there is an issue with that. ANDSF is designed specific to be a MN-c= entric solution where policies are provisioned in the MN and the MN decides = which network technologies and access networks it needs to connect to, under= what conditions, and which IP traffic needs to be routed on such accesses. = No IP point of attachment in the network (i.e. the PDN GW in 3GPP that is th= e LMA in PMIPv6) is aware under any conditions of such policy. Therefore, ev= en if in order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF = would unfortunately not provide a solution unless the MN can communicate to = the MAG and the LMA the decisions the MN has taken based on the ANDSF polici= es.

I believe the key point here is that we need to understand how the solution= can be realistically applied to a real scenario, and that we need to ensure= that important and realistic deployment scenarios are not excluded by the s= olution.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli <sgundave@cisco.com <http://s= gundave@cisco.com> > wrote:
Hi Stefano:

These are valid points and some good comments. Let me share my thoughts.
Carlo’s draft is not assuming any new MN-AR interface. Its going with= the assumption there is established policy on the mobile and on the LMA, wh= ich allows the mobile to select the access network at a flow level granulari= ty, without requiring any explicit signaling between the MAG and the MN. To = large part this is all about out of band policy interface, such as ANDSF, to= wards the UE, leading to the assumption that magically the MN and the LMA ar= e in sync with respect to flow policies, access selection and they will make= the right forwarding decision. Secondly, the flow policy decisions need not= be based on the specific WLAN network, but it is implicitly driven by the M= AG – LMA security relation, where the MAG attachment to the WLAN netwo= rk transitively allows the LMA to make the flow policy decisions based on th= e MAG identity. If the WLAN network is not trusted, there is truly no MAG in= that network, where the LMA shares a security relation with that node.

There are still some open issues on this draft that needs to be discussed i= n the WG.  On the approaches to allow more a flow aggregate movement, t= hat is a discussion point. There are issues that we need to discuss, support= ing split link model, or eliminating some favorite brand of signaling messag= e (FMA) and riding on PBU/PBA and just with one FMI trigger, and on the aspe= cts around MN applying the flow policies by flow mirroring. We have no agree= ment on those issues yet.

Its just a base draft, for further discussion and resolving those issues. B= ut, hope that is not a stopper for base draft selection.


Sri






On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <htt= p://sfaccinstd@gmail.com>  <http://sfaccinstd@gmail.com> > wrote:
Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicate= to the network where the flows should be routed or for the LMA to receive s= omehow from somewhere some policies, the solution cannot really provide flow= mobility since there is no way to decide which flows are routed where. If w= e are thinking about a host-based solution, I have not yet seen a solution a= s to how the host can indicate to the MAG and ultimately to the MAG which fl= ows should be routed on each access. If we are relying on modifications of l= ayer 2 protocols, aren't we defining a solution that works only with some te= chnologies (since for other access technologies it is rather unrealistic to = modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-based= solution, can we hear of at least one example of a real-life scenario where= the LMA would receive such policies, and how such delivery would happen? Al= so, should there be a solution to have policies in the LMA, how does the LMA= actually decide to route flows on one access or the other? E.g., if some fl= ows need to be routed on certain WLAN networks, but shall not be routed on o= ther WLAN networks, how does the LMA know which specific WLAN network the ho= st is connected to? Perhaps I missed the ability for the MAG to know e.g. th= e WLAN SSID and provide it to the LMA, in which case I would appreciate if s= omebody could highlight to me where that is defined.

I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important. <= BR>
Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM,  <Basavaraj.Patil@nokia.com <http://Basavaraj.Patil@nokia.com>  <http://Basavaraj.Patil@nokia.com> > wrote:
Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= BR> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt<= /a>

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= BR> developed further based on input and feedback from WG members.

-Basavaraj

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

___________= ____________________________________
netext mailing list
netext@ietf.org
https://www.ietf.org= /mailman/listinfo/netext
--B_3379589477_53914351-- From gerardog@qualcomm.com Thu Feb 3 14:40:47 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39B983A687A for ; Thu, 3 Feb 2011 14:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBCFeLGan0HA for ; Thu, 3 Feb 2011 14:40:28 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 1CDEA3A6B16 for ; Thu, 3 Feb 2011 14:40:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1296773031; x=1328309031; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:mime-version; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20Rajeev=20Koodli=20,=20Sri=20Gun davelli=20,=0D=0A=09stefano=20faccin =20|CC:=20"netext@ietf.org"=20,=20"Basavaraj.Patil@nokia.com"=0D=0A=09|Subject:=20RE:=20[netext]=20Consen sus=20call=20to=20adopt=20I-D:=0D=0A=20draft-bernardos-ne text-pmipv6-flowmob=20as=20WG=20doc|Thread-Topic:=20[nete xt]=20Consensus=20call=20to=20adopt=20I-D:=0D=0A=20draft- bernardos-netext-pmipv6-flowmob=20as=20WG=20doc |Thread-Index:=20AQHLwmpURzmRlysrlUidlexdQorGZJPuBh2AgAAR 4ICAAAzJgIAACkaAgADJ5gCAAKKGAP//oT5wgAEoMGn///x5AA=3D=3D |Date:=20Thu,=203=20Feb=202011=2022:43:49=20+0000 |Message-ID:=20|References:=20=0D =0A=20|In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|x-originating-ip:=20[172.30.48.1] |Content-Type:=20multipart/alternative=3B=0D=0A=09boundar y=3D"_000_E5E9FF33C2A27043B3BC96FE5A5160F101B74Anasanexd0 1enaqual_"|MIME-Version:=201.0; bh=bdNERs4gqCTl+YfI6xe4T81EcD/enAb6F0dJo4+yigc=; b=TuwdbpLUo9G2ovYkyuAhm7ECYgYIcSZnSidNv+hLCgznUnoOxop4uB5M Lj+a2Lu8NalXe99JuyeJzRlZawB4xMxOocAqHnk2V9p0Sx+bwPjivpIqr HoXQ5IehQkh+g7XAoxRmIe1duuHcV5kDXNu+wWxX1wldi4hcehgj5HXgq A=; X-IronPort-AV: E=McAfee;i="5400,1158,6245"; a="72907039" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 03 Feb 2011 14:43:51 -0800 X-IronPort-AV: E=Sophos;i="4.60,418,1291622400"; d="scan'208,217";a="47328352" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 03 Feb 2011 14:43:51 -0800 Received: from NASANEXD01E.na.qualcomm.com ([fe80::6555:8c37:4ee3:efc4]) by nasanexhc08.na.qualcomm.com ([::1]) with mapi id 14.01.0218.012; Thu, 3 Feb 2011 14:43:50 -0800 From: "Giaretta, Gerardo" To: Rajeev Koodli , Sri Gundavelli , stefano faccin Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLwmpURzmRlysrlUidlexdQorGZJPuBh2AgAAR4ICAAAzJgIAACkaAgADJ5gCAAKKGAP//oT5wgAEoMGn///x5AA== Date: Thu, 3 Feb 2011 22:43:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.48.1] Content-Type: multipart/alternative; boundary="_000_E5E9FF33C2A27043B3BC96FE5A5160F101B74Anasanexd01enaqual_" MIME-Version: 1.0 Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 03 Feb 2011 22:40:47 -0000 --_000_E5E9FF33C2A27043B3BC96FE5A5160F101B74Anasanexd01enaqual_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rajeev, Not sure I understand what you are asking me. My comment was mainly referre= d to synchronization of policies which is an assumption not correct in my o= pinion. Based on the current policy model adopted by 3GPP, the only way I can think= of to make the system working is to replicate the behavior of RFC 6089 whe= re the MN initiates the flow movement. The assumption on synchronization of policies may however be considered acc= eptable in other SDOs or even in 3GPP in future. I am just raising an appli= cability flag to the group (actually the flag was initially raised by Stefa= no :)) Gerardo From: Rajeev Koodli [mailto:rkoodli@cisco.com] Sent: Thursday, February 03, 2011 2:51 PM To: Giaretta, Gerardo; Sri Gundavelli; stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-p= mipv6-flowmob as WG doc Hi Gerardo, Okay, so let's agree that the current version of the draft does not have SS= ID/ULI propagation to the LMA. Do you care to suggest how the network deems such an information from the M= N trustworthy? I am sure you agree if we could have good input, we could design protocols = accordingly. You will also probably agree that's much better than just arguing about "it= does not work in today's 3GPP deployment". Regards, -Rajeev On 2/2/11 9:13 PM, "Giaretta, Gerardo" wrote: Hi Sri, There is no implicit assumption of synchronized policies. A basic example t= hat shows that there is no assumption is the following: ANDSF policies may = be based also on location of the UE. For example the UE should prefer WLAN = only in a given location. When the UE is attached over WLAN there is no way= for the PDNGW/HA to verify the location of the UE and therefore to verify = UE actions based on policies. The assumption on synchronization of policies is only applicable to this dr= aft and I think it is a wrong one. Cheers Gerardo From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of= Sri Gundavelli Sent: Wednesday, February 02, 2011 6:50 PM To: stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-p= mipv6-flowmob as WG doc Hi Stefano, One comment. Agree with you there is no ANDSF interface to the network node, but the ass= umption of synchronized policies between the ANDSF server and the PDN GW/HA= is there, implicitly IMO. With out this assumption, I do not know, how the= HA can ever validate the flow mobility options received in the BU. If the = operator requires any control on enforcing a flow policy rule, the PDN GW/H= A needs to have synchronized policies, without which its always the client = decision. I'm not sure, operators in 3GPP would like that :) No doubt, the lack of MN-AR interface is surely an issue for supporting com= plex flow policies. I realize the issues and I agree with you. But, the ass= umption of synchronized policies can offer some solution with some configur= ation requirement on the HA (assuming there are no other issues). There are= also the proposals on flow mirroring on the UE ..., requiring no flow poli= cies. I've not evaluated this, however. Folks can comment on this. It is also to be noted, for some of the scenarios such, there is no flow po= licy interface needed. We can identify what scenarios create any configurat= ion limitations on the HA and which one's do not . As I've noted earlier, t= his is surely an open issue, that we need to discuss in the WG. Regards Sri On 2/2/11 9:08 AM, "stefano faccin" wrote: Sri, thanks for the reply. Can you clarify in which system or scenario ANDSF is = available to network entities as well? There is no such availability in 3GP= P, and making such information available would require considerable archite= ctural changes, therefore the applicability of this solution to what seems = to be the only realistic scenario hinges on 3GPP making considerable archit= ectural changes. I would therefore not be so hastily concluding that the AN= DSF information is available to the LMA and underestimate what it would rea= lly take to make the solution applicable. If we cannot guarantee that there is at least one realistic solution to hav= e the MNa nd LMA in synch, how do we expect that this solution is applicabl= e at all? In 3GPP there is no need to have such implicit assumption, be cau= se 1) the MN is provided policies explicitly through the ANDSF, and 2) it i= s the MN and only the MN that makes IP flow mobility decisions and communic= ates them explicitly (with well defined signalling) to the LMA, and therefo= re no magic is needed. There is no need in 3GPP to have the ANDSF and PDN G= W policies synchronized, since the PDN GW does not use such policies. Sri, in the end it is a matter of whether we develop a solution that will r= ely on some unknown magic to be deployed, or a solution that we know can be= deployed in at least one way because there are solutions to what I conside= r major open issues. Cheers, Stefano On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli wrote: Hi Stefano, Thanks for the discussion. As you say, the ANDSF policies are allowing the MN a.) to make the right ne= twork attachment decision and b.) make the access selection on a flow basis= . This same policy that is present in the ANDSF server, is available for th= e network nodes as well. I'm not sure, with out this assumption the solutio= n can work for all currently listed cases. We clearly need the MN and the L= MA to be in synch with respect to the configured policy. How, that is done,= I guess we will not try to know. I thought even in 3GPP, this is the impl= ied assumption ? But, this is for you to clarify. Not specifically for IFOM= where UE and PDN GW/HA are negotiating the flow policies, but generally th= at the PDN GW and the ANDSF policy server will have synchronized policies. = The MAG and the LMA have the ability to carry this flow policy information = in signaling messages and influence the access selection. The policy is a o= paque object, with extensible formats, when carried in the signaling plane,= should allow the LMA/MAG to apply those access policies, while assuming MN= is following the same rules. These policies can surely reflect the specifi= c WLAN access/operator specific rule. I'm surely with you, the lack of MN-A= R interface is surely an issue and I see that. But, we need to understand, = what are the limitations with the approach of out of band policy interface= s and what will be the solution limitations. If we need to tie the flow mov= ement at the prefix granularity and rely on the natural ND interface in the= form of RA PIO option, more like PDN offload in MAPCON, or at the granular= ity of a flow level, is open for discussion. I want to simplify this draft = for sure, we can surely discuss each of these issues on the WG draft. Regards Sri On 2/1/11 8:29 PM, "stefano faccin" > wrote: Sri, thanks for the reply. I'd like to comment on the "the flow policy decisions need not be based on = the specific WLAN network". Does it mean, as I believe it does, that the cu= rrent solution would not allow an operator deploying such solution to decid= e to route flows over a specific WLAN or not depending on which specific WL= AN the MN is connected to? E.g. the operator or the entity in control of th= e decisions for the routing may want to direct certain traffic always over = WLANs that the operator deploys, and instead route only some of the traffic= over WLANs of roaming partners or of the MN user home. How does this solut= ion support that scenario if the LMA is not told specifically which WLAN th= e MN is connected to? From a deployment point of view, I do not believe we = can afford to leave out this scenario. Please note that the establishment o= f a security relationship between the MN and the MAG, and a specific MAG id= entity, cannot guarantee that the LMA knows which specific WLAN access netw= ork the MN is connected to. Assuming that would severely restrict the deplo= yment scenarios. As for the MN and the LMA being magically in synch, I am very concerned abo= ut a "glass ball" solution. You mention ANDSF defined by 3GPP as a solution= for this "out of band" delivery of policy. Fair enough, however there is a= n issue with that. ANDSF is designed specific to be a MN-centric solution w= here policies are provisioned in the MN and the MN decides which network te= chnologies and access networks it needs to connect to, under what condition= s, and which IP traffic needs to be routed on such accesses. No IP point of= attachment in the network (i.e. the PDN GW in 3GPP that is the LMA in PMIP= v6) is aware under any conditions of such policy. Therefore, even if in ord= er to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would unfor= tunately not provide a solution unless the MN can communicate to the MAG an= d the LMA the decisions the MN has taken based on the ANDSF policies. I believe the key point here is that we need to understand how the solution= can be realistically applied to a real scenario, and that we need to ensur= e that important and realistic deployment scenarios are not excluded by the= solution. Cheers, Stefano On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli > wrote: Hi Stefano: These are valid points and some good comments. Let me share my thoughts. Carlo's draft is not assuming any new MN-AR interface. Its going with the a= ssumption there is established policy on the mobile and on the LMA, which a= llows the mobile to select the access network at a flow level granularity, = without requiring any explicit signaling between the MAG and the MN. To lar= ge part this is all about out of band policy interface, such as ANDSF, towa= rds the UE, leading to the assumption that magically the MN and the LMA are= in sync with respect to flow policies, access selection and they will make= the right forwarding decision. Secondly, the flow policy decisions need no= t be based on the specific WLAN network, but it is implicitly driven by the= MAG - LMA security relation, where the MAG attachment to the WLAN network = transitively allows the LMA to make the flow policy decisions based on the = MAG identity. If the WLAN network is not trusted, there is truly no MAG in = that network, where the LMA shares a security relation with that node. There are still some open issues on this draft that needs to be discussed i= n the WG. On the approaches to allow more a flow aggregate movement, that = is a discussion point. There are issues that we need to discuss, supporting= split link model, or eliminating some favorite brand of signaling message = (FMA) and riding on PBU/PBA and just with one FMI trigger, and on the aspec= ts around MN applying the flow policies by flow mirroring. We have no agree= ment on those issues yet. Its just a base draft, for further discussion and resolving those issues. B= ut, hope that is not a stopper for base draft selection. Sri On 2/1/11 6:39 PM, "stefano faccin" > wrote: Raj, thanks for the email. I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere). I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability. In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicat= e to the network where the flows should be routed or for the LMA to receive= somehow from somewhere some policies, the solution cannot really provide f= low mobility since there is no way to decide which flows are routed where. = If we are thinking about a host-based solution, I have not yet seen a solut= ion as to how the host can indicate to the MAG and ultimately to the MAG wh= ich flows should be routed on each access. If we are relying on modificatio= ns of layer 2 protocols, aren't we defining a solution that works only with= some technologies (since for other access technologies it is rather unreal= istic to modify L2 for IP flow mobility purposes)? If we are thinking of an= LMA-based solution, can we hear of at least one example of a real-life sce= nario where the LMA would receive such policies, and how such delivery woul= d happen? Also, should there be a solution to have policies in the LMA, how= does the LMA actually decide to route flows on one access or the other? E.= g., if some flows need to be routed on certain WLAN networks, but shall not= be routed on other WLAN networks, how does the LMA know which specific WLA= N network the host is connected to? Perhaps I missed the ability for the MA= G to know e.g. the WLAN SSID and provide it to the LMA, in which case I wou= ld appreciate if somebody could highlight to me where that is defined. I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important. Cheers, Stefano On Tue, Feb 1, 2011 at 3:47 PM, > wrote: Hello, We have discussed the flow mobility solutions for Proxy MIP6 previously at IETFs 78 and 79. This is a consensus call for adopting this I-D: draft-bernardos-netext-pmipv6-flowmob-02 as the working group document. I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt The consensus call will expire on Feb 15th, 2011. Please indicate your support or concerns in adopting this I-D as the WG baseline document on the mailing list. Please note that this I-D will serve as the baseline in the WG and will be developed further based on input and feedback from WG members. -Basavaraj _______________________________________________ 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 --_000_E5E9FF33C2A27043B3BC96FE5A5160F101B74Anasanexd01enaqual_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmi= pv6-flowmob as WG doc

Hi Rajeev,

 

Not sure I understand what you are asking me. My comment was= mainly referred to synchronization of policies which is an assumption not = correct in my opinion.

 

Based on the current policy model adopted by 3GPP, the only = way I can think of to make the system working is to replicate the behavior = of RFC 6089 where the MN initiates the flow movement.

 

The assumption on synchronization of policies may however be= considered acceptable in other SDOs or even in 3GPP in future. I am just r= aising an applicability flag to the group (actually the flag was initially raised by Stefano J)

 

Gerardo

 

From: Rajeev K= oodli [mailto:rkoodli@cisco.com]
Sent: Thursday, February 03, 2011 2:51 PM
To: Giaretta, Gerardo; Sri Gundavelli; stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-n= etext-pmipv6-flowmob as WG doc

 


Hi Gerardo,

Okay, so let’s agree that the current version of the draft does not h= ave SSID/ULI propagation to the LMA.

Do you care to suggest how the network deems such an information from the M= N trustworthy?

I am sure you agree if we could have good input, we could design protocols = accordingly.
You will also probably agree that’s much better than just arguing abo= ut “it does not work in today’s 3GPP deployment”.

Regards,

-Rajeev


On 2/2/11 9:13 PM, "Giaretta, Gerardo" <gerardog@qualcomm.com> wrote:

Hi Sri,
 
There is no implicit assumption of synchronized policies. A basic example t= hat shows that there is no assumption is the following: ANDSF policies may = be based also on location of the UE. For example the UE should prefer WLAN = only in a given location. When the UE is attached over WLAN there is no way for the PDNGW/HA to verify the lo= cation of the UE and therefore to verify UE actions based on policies.
 
The assumption on synchronization of policies is only applicable to this dr= aft and I think it is a wrong one.
 
Cheers
Gerardo
 

From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Sri Gundavelli
Sent: Wednesday, February 02, 2011 6:50 PM
To: stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-n= etext-pmipv6-flowmob as WG doc

Hi Stefano,

One comment.

Agree with you there is no ANDSF interface to the network node, but the ass= umption of synchronized policies between the ANDSF server and the PDN GW/HA= is there, implicitly IMO. With out this assumption, I do not know, how the= HA can ever validate the flow mobility options received in the BU. If the operator requires any control on enforc= ing a flow policy rule, the PDN GW/HA needs to have synchronized policies, = without which its always the client decision. I’m not sure, operators= in 3GPP would like that :)

No doubt, the lack of MN-AR interface is surely an issue for supporting com= plex flow policies. I realize the issues and I agree with you. But, the ass= umption of synchronized policies can offer some solution with some configur= ation requirement on the HA (assuming there are no other issues). There are also the proposals on flow mirroring= on the UE ..., requiring no flow policies. I’ve not evaluated this, = however. Folks can comment on this.

It is also to be noted, for some of the scenarios such, there is no flow po= licy interface needed. We can identify what scenarios create any configurat= ion limitations on the HA and which one’s do not . As I’ve note= d earlier, this is surely an open issue, that we need to discuss in the WG.



Regards
Sri




 


On 2/2/11 9:08 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:
Sri,
thanks for the reply. Can you clarify in which system or scenario ANDSF is = available to network entities as well? There is no such availability in 3GP= P, and making such information available would require considerable archite= ctural changes, therefore the applicability of this solution to what seems to be the only realistic scenario hinges on= 3GPP making considerable architectural changes. I would therefore not be s= o hastily concluding that the ANDSF information is available to the LMA and= underestimate what it would really take to make the solution applicable.

If we cannot guarantee that there is at least one realistic solution to hav= e the MNa nd LMA in synch, how do we expect that this solution is applicabl= e at all? In 3GPP there is no need to have such implicit assumption, be cau= se 1) the MN is provided policies explicitly through the ANDSF, and 2) it is the MN and only the MN that mak= es IP flow mobility decisions and communicates them explicitly (with well d= efined signalling) to the LMA, and therefore no magic is needed. There is n= o need in 3GPP to have the ANDSF and PDN GW policies synchronized, since the PDN GW does not use such polic= ies.

Sri, in the end it is a matter of whether we develop a solution that will r= ely on some unknown magic to be deployed, or a solution that we know can be= deployed in at least one way because there are solutions to what I conside= r major open issues.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli <sgundave@cisco.com> wrote:
Hi Stefano,

Thanks for the discussion.

As you say, the ANDSF policies are allowing the MN a.) to make the right ne= twork attachment decision and b.) make the access selection on a flow basis= . This same policy that is present in the ANDSF server, is available for th= e network nodes as well. I’m not sure, with out this assumption the solution can work for all currently lis= ted cases. We clearly need the MN and the LMA to be in synch with respect t= o the configured policy. How, that is done, I guess we will not try to know= .  I thought even in 3GPP, this is the implied assumption ? But, this is for you to clarify. Not specifica= lly for IFOM where UE and PDN GW/HA are negotiating the flow policies, but = generally that the PDN GW and the ANDSF policy server will have synchronize= d policies. The MAG and the LMA have the ability to carry this flow policy information in signaling messag= es and influence the access selection. The policy is a opaque object, with = extensible formats, when carried in the signaling plane, should allow the L= MA/MAG to apply those access policies, while assuming MN is following the same rules. These policies can surely r= eflect the specific WLAN access/operator specific rule. I’m surely wi= th you, the lack of MN-AR interface is surely an issue and I see that. But,= we need to understand, what are the limitations with the approach of  out of band policy interfaces and what will be = the solution limitations. If we need to tie the flow movement at the prefix= granularity and rely on the natural ND interface in the form of RA PIO opt= ion, more like PDN offload in MAPCON, or at the granularity of a flow level, is open for discussion. I want to s= implify this draft for sure, we can surely discuss each of these issues on = the WG draft.


Regards
Sri






On 2/1/11 8:29 PM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com> > wrote:
Sri,
thanks for the reply.

I'd like to comment on the "the flow policy decisions need not be base= d on the specific WLAN network". Does it mean, as I believe it does, t= hat the current solution would not allow an operator deploying such solutio= n to decide to route flows over a specific WLAN or not depending on which specific WLAN the MN is connected to? E.g. = the operator or the entity in control of the decisions for the routing may = want to direct certain traffic always over WLANs that the operator deploys,= and instead route only some of the traffic over WLANs of roaming partners or of the MN user home. How doe= s this solution support that scenario if the LMA is not told specifically w= hich WLAN the MN is connected to? From a deployment point of view, I do not= believe we can afford to leave out this scenario. Please note that the establishment of a security relati= onship between the MN and the MAG, and a specific MAG identity, cannot guar= antee that the LMA knows which specific WLAN access network the MN is conne= cted to. Assuming that would severely restrict the deployment scenarios.

As for the MN and the LMA being magically in synch, I am very concerned abo= ut a "glass ball" solution. You mention ANDSF defined by 3GPP as = a solution for this "out of band" delivery of policy. Fair enough= , however there is an issue with that. ANDSF is designed specific to be a MN-centric solution where policies are provisioned in the= MN and the MN decides which network technologies and access networks it ne= eds to connect to, under what conditions, and which IP traffic needs to be = routed on such accesses. No IP point of attachment in the network (i.e. the PDN GW in 3GPP that is the LMA in P= MIPv6) is aware under any conditions of such policy. Therefore, even if in = order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would un= fortunately not provide a solution unless the MN can communicate to the MAG and the LMA the decisions the MN = has taken based on the ANDSF policies.

I believe the key point here is that we need to understand how the solution= can be realistically applied to a real scenario, and that we need to ensur= e that important and realistic deployment scenarios are not excluded by the= solution.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli <sgundave@cisco.com <htt= p://sgundave@cisco.com> > wrote:
Hi Stefano:

These are valid points and some good comments. Let me share my thoughts.
Carlo’s draft is not assuming any new MN-AR interface. Its going with= the assumption there is established policy on the mobile and on the LMA, w= hich allows the mobile to select the access network at a flow level granula= rity, without requiring any explicit signaling between the MAG and the MN. To large part this is all about out of band po= licy interface, such as ANDSF, towards the UE, leading to the assumption th= at magically the MN and the LMA are in sync with respect to flow policies, = access selection and they will make the right forwarding decision. Secondly, the flow policy decisions need no= t be based on the specific WLAN network, but it is implicitly driven by the= MAG – LMA security relation, where the MAG attachment to the WLAN ne= twork transitively allows the LMA to make the flow policy decisions based on the MAG identity. If the WLAN network i= s not trusted, there is truly no MAG in that network, where the LMA shares = a security relation with that node.

There are still some open issues on this draft that needs to be discussed i= n the WG.  On the approaches to allow more a flow aggregate movement, = that is a discussion point. There are issues that we need to discuss, suppo= rting split link model, or eliminating some favorite brand of signaling message (FMA) and riding on PBU/PBA and j= ust with one FMI trigger, and on the aspects around MN applying the flow po= licies by flow mirroring. We have no agreement on those issues yet.

Its just a base draft, for further discussion and resolving those issues. B= ut, hope that is not a stopper for base draft selection.


Sri






On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com>  <http://sfaccinstd@gmail.com> > wrote:
Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicat= e to the network where the flows should be routed or for the LMA to receive= somehow from somewhere some policies, the solution cannot really provide flow mobility since there is no way to = decide which flows are routed where. If we are thinking about a host-based = solution, I have not yet seen a solution as to how the host can indicate to= the MAG and ultimately to the MAG which flows should be routed on each access. If we are relying on modifica= tions of layer 2 protocols, aren't we defining a solution that works only w= ith some technologies (since for other access technologies it is rather unr= ealistic to modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-based solution, can we he= ar of at least one example of a real-life scenario where the LMA would rece= ive such policies, and how such delivery would happen? Also, should there b= e a solution to have policies in the LMA, how does the LMA actually decide to route flows on one access or = the other? E.g., if some flows need to be routed on certain WLAN networks, = but shall not be routed on other WLAN networks, how does the LMA know which= specific WLAN network the host is connected to? Perhaps I missed the ability for the MAG to know e.g. the= WLAN SSID and provide it to the LMA, in which case I would appreciate if s= omebody could highlight to me where that is defined.

I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important.

Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM,  <Basavaraj.Patil@nokia.com <http://Basavaraj.Patil@nokia.com>  <http://Basavaraj.Patil@nokia.com> > wrote:

Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= br> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= br> developed further based on input and feedback from WG members.

-Basavaraj

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

 
 

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

--_000_E5E9FF33C2A27043B3BC96FE5A5160F101B74Anasanexd01enaqual_-- From sgundave@cisco.com Thu Feb 3 14:51:02 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 623523A6B22 for ; Thu, 3 Feb 2011 14:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.135 X-Spam-Level: X-Spam-Status: No, score=-8.135 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vhg-d2biDJBu for ; Thu, 3 Feb 2011 14:50:44 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id CD8A53A6A17 for ; Thu, 3 Feb 2011 14:50:44 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQDAF7ASk2rRN+J/2dsb2JhbACCRZQMQIYJAYczZgJzogebBIJ7AYJcBIR5hm2DM4MBgheDWw Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 03 Feb 2011 22:54:07 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p13Ms7lr015064; Thu, 3 Feb 2011 22:54:07 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Feb 2011 14:54:07 -0800 Received: from 171.70.228.143 ([171.70.228.143]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 Feb 2011 22:54:06 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 03 Feb 2011 14:54:41 -0800 From: Sri Gundavelli To: "Giaretta, Gerardo" , stefano faccin Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLwmpURzmRlysrlUidlexdQorGZJPuBh2AgAAR4ICAAAzJgIAACkaAgADJ5gCAAKKGAP//oT5wgAEpJLk= In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3379589681_87624285" X-OriginalArrivalTime: 03 Feb 2011 22:54:07.0252 (UTC) FILETIME=[433AC540:01CBC3F5] Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 03 Feb 2011 22:51:02 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3379589681_87624285 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Gerardo, Sure, for supporting the specific scenario, the draft is making that assumption. This does come at a cost for the operator having to ensure synchronized policies between the ANDSF server and the PDN GW. But, my question still remains, how in IFOM, a PDN GW can ever authorize and establish the flow policies requested by the UE. It needs the access to sam= e policy that the operator configured on the ANDSF server. Else, its all in the mercy of the UE with no network side validation. There can be all the needed information elements, around UE location, or network attachment in the protocol signaling, directly from the UE in IFOM, but fundamentally the PDN GW needs access to the same policy. I do agree, this assumption is an administrative overhead. Regards Sri=20 On 2/2/11 9:13 PM, "Giaretta, Gerardo" wrote: > Hi Sri, > =20 > There is no implicit assumption of synchronized policies. A basic example= that > shows that there is no assumption is the following: ANDSF policies may be > based also on location of the UE. For example the UE should prefer WLAN o= nly > in a given location. When the UE is attached over WLAN there is no way fo= r the > PDNGW/HA to verify the location of the UE and therefore to verify UE acti= ons > based on policies. > =20 > The assumption on synchronization of policies is only applicable to this = draft > and I think it is a wrong one. > =20 > Cheers > Gerardo > =20 >=20 > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of > Sri Gundavelli > Sent: Wednesday, February 02, 2011 6:50 PM > To: stefano faccin > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > Subject: Re: [netext] Consensus call to adopt I-D: > draft-bernardos-netext-pmipv6-flowmob as WG doc > =20 > Hi Stefano, >=20 > One comment. >=20 > Agree with you there is no ANDSF interface to the network node, but the > assumption of synchronized policies between the ANDSF server and the PDN = GW/HA > is there, implicitly IMO. With out this assumption, I do not know, how th= e HA > can ever validate the flow mobility options received in the BU. If the > operator requires any control on enforcing a flow policy rule, the PDN GW= /HA > needs to have synchronized policies, without which its always the client > decision. I=B9m not sure, operators in 3GPP would like that :) >=20 > No doubt, the lack of MN-AR interface is surely an issue for supporting > complex flow policies. I realize the issues and I agree with you. But, th= e > assumption of synchronized policies can offer some solution with some > configuration requirement on the HA (assuming there are no other issues). > There are also the proposals on flow mirroring on the UE ..., requiring n= o > flow policies. I=B9ve not evaluated this, however. Folks can comment on thi= s. >=20 > It is also to be noted, for some of the scenarios such, there is no flow > policy interface needed. We can identify what scenarios create any > configuration limitations on the HA and which one=B9s do not . As I=B9ve note= d > earlier, this is surely an open issue, that we need to discuss in the WG. >=20 >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 > =20 >=20 >=20 > On 2/2/11 9:08 AM, "stefano faccin" wrote: > Sri, > thanks for the reply. Can you clarify in which system or scenario ANDSF i= s > available to network entities as well? There is no such availability in 3= GPP, > and making such information available would require considerable architec= tural > changes, therefore the applicability of this solution to what seems to be= the > only realistic scenario hinges on 3GPP making considerable architectural > changes. I would therefore not be so hastily concluding that the ANDSF > information is available to the LMA and underestimate what it would reall= y > take to make the solution applicable. >=20 > If we cannot guarantee that there is at least one realistic solution to h= ave > the MNa nd LMA in synch, how do we expect that this solution is applicabl= e at > all? In 3GPP there is no need to have such implicit assumption, be cause = 1) > the MN is provided policies explicitly through the ANDSF, and 2) it is th= e MN > and only the MN that makes IP flow mobility decisions and communicates th= em > explicitly (with well defined signalling) to the LMA, and therefore no ma= gic > is needed. There is no need in 3GPP to have the ANDSF and PDN GW policies > synchronized, since the PDN GW does not use such policies. >=20 > Sri, in the end it is a matter of whether we develop a solution that will= rely > on some unknown magic to be deployed, or a solution that we know can be > deployed in at least one way because there are solutions to what I consid= er > major open issues. >=20 > Cheers, > Stefano >=20 > On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli wrote= : > Hi Stefano, >=20 > Thanks for the discussion. >=20 > As you say, the ANDSF policies are allowing the MN a.) to make the right > network attachment decision and b.) make the access selection on a flow b= asis. > This same policy that is present in the ANDSF server, is available for th= e > network nodes as well. I=B9m not sure, with out this assumption the solutio= n can > work for all currently listed cases. We clearly need the MN and the LMA t= o be > in synch with respect to the configured policy. How, that is done, I gues= s we > will not try to know. I thought even in 3GPP, this is the implied assump= tion > ? But, this is for you to clarify. Not specifically for IFOM where UE and= PDN > GW/HA are negotiating the flow policies, but generally that the PDN GW an= d the > ANDSF policy server will have synchronized policies. The MAG and the LMA = have > the ability to carry this flow policy information in signaling messages a= nd > influence the access selection. The policy is a opaque object, with exten= sible > formats, when carried in the signaling plane, should allow the LMA/MAG to > apply those access policies, while assuming MN is following the same rule= s. > These policies can surely reflect the specific WLAN access/operator speci= fic > rule. I=B9m surely with you, the lack of MN-AR interface is surely an issue= and > I see that. But, we need to understand, what are the limitations with the > approach of out of band policy interfaces and what will be the solution > limitations. If we need to tie the flow movement at the prefix granularit= y and > rely on the natural ND interface in the form of RA PIO option, more like = PDN > offload in MAPCON, or at the granularity of a flow level, is open for > discussion. I want to simplify this draft for sure, we can surely discuss= each > of these issues on the WG draft. >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 >=20 >=20 > On 2/1/11 8:29 PM, "stefano faccin" > wrote: > Sri, > thanks for the reply. >=20 > I'd like to comment on the "the flow policy decisions need not be based o= n the > specific WLAN network". Does it mean, as I believe it does, that the curr= ent > solution would not allow an operator deploying such solution to decide to > route flows over a specific WLAN or not depending on which specific WLAN = the > MN is connected to? E.g. the operator or the entity in control of the > decisions for the routing may want to direct certain traffic always over = WLANs > that the operator deploys, and instead route only some of the traffic ove= r > WLANs of roaming partners or of the MN user home. How does this solution > support that scenario if the LMA is not told specifically which WLAN the = MN is > connected to? From a deployment point of view, I do not believe we can af= ford > to leave out this scenario. Please note that the establishment of a secur= ity > relationship between the MN and the MAG, and a specific MAG identity, can= not > guarantee that the LMA knows which specific WLAN access network the MN is > connected to. Assuming that would severely restrict the deployment scenar= ios. >=20 > As for the MN and the LMA being magically in synch, I am very concerned a= bout > a "glass ball" solution. You mention ANDSF defined by 3GPP as a solution = for > this "out of band" delivery of policy. Fair enough, however there is an i= ssue > with that. ANDSF is designed specific to be a MN-centric solution where > policies are provisioned in the MN and the MN decides which network > technologies and access networks it needs to connect to, under what > conditions, and which IP traffic needs to be routed on such accesses. No = IP > point of attachment in the network (i.e. the PDN GW in 3GPP that is the L= MA in > PMIPv6) is aware under any conditions of such policy. Therefore, even if = in > order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would > unfortunately not provide a solution unless the MN can communicate to the= MAG > and the LMA the decisions the MN has taken based on the ANDSF policies. >=20 > I believe the key point here is that we need to understand how the soluti= on > can be realistically applied to a real scenario, and that we need to ensu= re > that important and realistic deployment scenarios are not excluded by the > solution. >=20 > Cheers, > Stefano >=20 > On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli > wrote: > Hi Stefano: >=20 > These are valid points and some good comments. Let me share my thoughts. >=20 > Carlo=B9s draft is not assuming any new MN-AR interface. Its going with the > assumption there is established policy on the mobile and on the LMA, whic= h > allows the mobile to select the access network at a flow level granularit= y, > without requiring any explicit signaling between the MAG and the MN. To l= arge > part this is all about out of band policy interface, such as ANDSF, towar= ds > the UE, leading to the assumption that magically the MN and the LMA are i= n > sync with respect to flow policies, access selection and they will make t= he > right forwarding decision. Secondly, the flow policy decisions need not b= e > based on the specific WLAN network, but it is implicitly driven by the MA= G =AD > LMA security relation, where the MAG attachment to the WLAN network > transitively allows the LMA to make the flow policy decisions based on th= e MAG > identity. If the WLAN network is not trusted, there is truly no MAG in th= at > network, where the LMA shares a security relation with that node. >=20 > There are still some open issues on this draft that needs to be discussed= in > the WG. On the approaches to allow more a flow aggregate movement, that = is a > discussion point. There are issues that we need to discuss, supporting sp= lit > link model, or eliminating some favorite brand of signaling message (FMA)= and > riding on PBU/PBA and just with one FMI trigger, and on the aspects aroun= d MN > applying the flow policies by flow mirroring. We have no agreement on tho= se > issues yet. >=20 > Its just a base draft, for further discussion and resolving those issues.= But, > hope that is not a stopper for base draft selection. > =20 >=20 > Sri >=20 >=20 >=20 >=20 >=20 >=20 > On 2/1/11 6:39 PM, "stefano faccin" > wrote: > Raj, > thanks for the email. >=20 > I need to apologize in advance if my questions have already been answered > before (though I cannot find a conclusive answer anywhere). >=20 > I think that a protocol that is developed in NETEXT (or other groups) sho= uld > have at least a potential realistic scenario for applicability. >=20 > In terms of applicability, though it is not part of the protocol definiti= on > per se, unless there are solutions in place for either the host to indica= te to > the network where the flows should be routed or for the LMA to receive so= mehow > from somewhere some policies, the solution cannot really provide flow mob= ility > since there is no way to decide which flows are routed where. If we are > thinking about a host-based solution, I have not yet seen a solution as t= o how > the host can indicate to the MAG and ultimately to the MAG which flows sh= ould > be routed on each access. If we are relying on modifications of layer 2 > protocols, aren't we defining a solution that works only with some > technologies (since for other access technologies it is rather unrealisti= c to > modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-ba= sed > solution, can we hear of at least one example of a real-life scenario whe= re > the LMA would receive such policies, and how such delivery would happen? = Also, > should there be a solution to have policies in the LMA, how does the LMA > actually decide to route flows on one access or the other? E.g., if some = flows > need to be routed on certain WLAN networks, but shall not be routed on ot= her > WLAN networks, how does the LMA know which specific WLAN network the host= is > connected to? Perhaps I missed the ability for the MAG to know e.g. the W= LAN > SSID and provide it to the LMA, in which case I would appreciate if someb= ody > could highlight to me where that is defined. >=20 > I think that, though not integral to the protocol specification, understa= nding > what framework the protocol would/needs to fit in is rather important. >=20 > Cheers, > Stefano >=20 >=20 > On Tue, Feb 1, 2011 at 3:47 PM, > > wrote: >=20 > Hello, >=20 > We have discussed the flow mobility solutions for Proxy MIP6 previously a= t > IETFs 78 and 79. > This is a consensus call for adopting this I-D: > draft-bernardos-netext-pmipv6-flowmob-02 > as the working group document. > I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt >=20 > The consensus call will expire on Feb 15th, 2011. Please indicate your > support or concerns in adopting this I-D as the WG baseline document on > the mailing list. >=20 > Please note that this I-D will serve as the baseline in the WG and will b= e > developed further based on input and feedback from WG members. >=20 > -Basavaraj >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > =20 > =20 > =20 >=20 --B_3379589681_87624285 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmi= pv6-flowmob as WG doc Hi Gerardo,

Sure, for supporting the specific scenario, the draft is making that assump= tion. This does come at a cost for the operator having to ensure synchronize= d policies between the ANDSF server and the PDN GW. But, my question still r= emains, how in IFOM, a PDN GW can ever authorize and establish the flow poli= cies requested by the UE. It needs the access to same policy that the operat= or configured on the ANDSF server. Else, its all in the mercy of the UE with= no network side validation. There can be all the needed information element= s, around UE location, or network attachment in the protocol signaling, dire= ctly from the UE in IFOM, but fundamentally the PDN GW needs access to the s= ame policy. I do agree, this assumption is an administrative overhead.


Regards
Sri



On 2/2/11 9:13 PM, "Giaretta, Gerardo" <gerardog@qualcomm.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Hi Sri,
 
There is no implicit assumption of synchronized policies. A basic example t= hat shows that there is no assumption is the following: ANDSF policies may b= e based also on location of the UE. For example the UE should prefer WLAN on= ly in a given location. When the UE is attached over WLAN there is no way fo= r the PDNGW/HA to verify the location of the UE and therefore to verify UE a= ctions based on policies.
 
The assumption on synchronization of policies is only applicable to this dr= aft and I think it is a wrong one.
 
Cheers
Gerardo
 

From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Sri= Gundavelli
Sent: Wednesday, February 02, 2011 6:50 PM
To: stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-n= etext-pmipv6-flowmob as WG doc
Hi Stefano,

One comment.

Agree with you there is no ANDSF interface to the network node, but the ass= umption of synchronized policies between the ANDSF server and the PDN GW/HA = is there, implicitly IMO. With out this assumption, I do not know, how the H= A can ever validate the flow mobility options received in the BU. If the ope= rator requires any control on enforcing a flow policy rule, the PDN GW/HA ne= eds to have synchronized policies, without which its always the client decis= ion. I’m not sure, operators in 3GPP would like that :)

No doubt, the lack of MN-AR interface is surely an issue for supporting com= plex flow policies. I realize the issues and I agree with you. But, the assu= mption of synchronized policies can offer some solution with some configurat= ion requirement on the HA (assuming there are no other issues). There are al= so the proposals on flow mirroring on the UE ..., requiring no flow policies= . I’ve not evaluated this, however. Folks can comment on this.

It is also to be noted, for some of the scenarios such, there is no flow po= licy interface needed. We can identify what scenarios create any configurati= on limitations on the HA and which one’s do not . As I’ve noted = earlier, this is surely an open issue, that we need to discuss in the WG.


Regards
Sri




 


On 2/2/11 9:08 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:
Sri,
thanks for the reply. Can you clarify in which system or scenario ANDSF is = available to network entities as well? There is no such availability in 3GPP= , and making such information available would require considerable architect= ural changes, therefore the applicability of this solution to what seems to = be the only realistic scenario hinges on 3GPP making considerable architectu= ral changes. I would therefore not be so hastily concluding that the ANDSF i= nformation is available to the LMA and underestimate what it would really ta= ke to make the solution applicable.

If we cannot guarantee that there is at least one realistic solution to hav= e the MNa nd LMA in synch, how do we expect that this solution is applicable= at all? In 3GPP there is no need to have such implicit assumption, be cause= 1) the MN is provided policies explicitly through the ANDSF, and 2) it is t= he MN and only the MN that makes IP flow mobility decisions and communicates= them explicitly (with well defined signalling) to the LMA, and therefore no= magic is needed. There is no need in 3GPP to have the ANDSF and PDN GW poli= cies synchronized, since the PDN GW does not use such policies.

Sri, in the end it is a matter of whether we develop a solution that will r= ely on some unknown magic to be deployed, or a solution that we know can be = deployed in at least one way because there are solutions to what I consider = major open issues.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli <sgundave@cisco.com> wrote:
Hi Stefano,

Thanks for the discussion.

As you say, the ANDSF policies are allowing the MN a.) to make the right ne= twork attachment decision and b.) make the access selection on a flow basis.= This same policy that is present in the ANDSF server, is available for the = network nodes as well. I’m not sure, with out this assumption the solu= tion can work for all currently listed cases. We clearly need the MN and the= LMA to be in synch with respect to the configured policy. How, that is done= , I guess we will not try to know.  I thought even in 3GPP, this is the= implied assumption ? But, this is for you to clarify. Not specifically for = IFOM where UE and PDN GW/HA are negotiating the flow policies, but generally= that the PDN GW and the ANDSF policy server will have synchronized policies= . The MAG and the LMA have the ability to carry this flow policy information= in signaling messages and influence the access selection. The policy is a o= paque object, with extensible formats, when carried in the signaling plane, = should allow the LMA/MAG to apply those access policies, while assuming MN i= s following the same rules. These policies can surely reflect the specific W= LAN access/operator specific rule. I’m surely with you, the lack of MN= -AR interface is surely an issue and I see that. But, we need to understand,= what are the limitations with the approach of  out of band policy inte= rfaces and what will be the solution limitations. If we need to tie the flow= movement at the prefix granularity and rely on the natural ND interface in = the form of RA PIO option, more like PDN offload in MAPCON, or at the granul= arity of a flow level, is open for discussion. I want to simplify this draft= for sure, we can surely discuss each of these issues on the WG draft.


Regards
Sri






On 2/1/11 8:29 PM, "stefano faccin" <sfaccinstd@gmail.com <htt= p://sfaccinstd@gmail.com> > wrote:
Sri,
thanks for the reply.

I'd like to comment on the "the flow policy decisions need not be base= d on the specific WLAN network". Does it mean, as I believe it does, th= at the current solution would not allow an operator deploying such solution = to decide to route flows over a specific WLAN or not depending on which spec= ific WLAN the MN is connected to? E.g. the operator or the entity in control= of the decisions for the routing may want to direct certain traffic always = over WLANs that the operator deploys, and instead route only some of the tra= ffic over WLANs of roaming partners or of the MN user home. How does this so= lution support that scenario if the LMA is not told specifically which WLAN = the MN is connected to? From a deployment point of view, I do not believe we= can afford to leave out this scenario. Please note that the establishment o= f a security relationship between the MN and the MAG, and a specific MAG ide= ntity, cannot guarantee that the LMA knows which specific WLAN access networ= k the MN is connected to. Assuming that would severely restrict the deployme= nt scenarios.

As for the MN and the LMA being magically in synch, I am very concerned abo= ut a "glass ball" solution. You mention ANDSF defined by 3GPP as a= solution for this "out of band" delivery of policy. Fair enough, = however there is an issue with that. ANDSF is designed specific to be a MN-c= entric solution where policies are provisioned in the MN and the MN decides = which network technologies and access networks it needs to connect to, under= what conditions, and which IP traffic needs to be routed on such accesses. = No IP point of attachment in the network (i.e. the PDN GW in 3GPP that is th= e LMA in PMIPv6) is aware under any conditions of such policy. Therefore, ev= en if in order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF = would unfortunately not provide a solution unless the MN can communicate to = the MAG and the LMA the decisions the MN has taken based on the ANDSF polici= es.

I believe the key point here is that we need to understand how the solution= can be realistically applied to a real scenario, and that we need to ensure= that important and realistic deployment scenarios are not excluded by the s= olution.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli <sgundave@cisco.com <http://s= gundave@cisco.com> > wrote:
Hi Stefano:

These are valid points and some good comments. Let me share my thoughts.
Carlo’s draft is not assuming any new MN-AR interface. Its going with= the assumption there is established policy on the mobile and on the LMA, wh= ich allows the mobile to select the access network at a flow level granulari= ty, without requiring any explicit signaling between the MAG and the MN. To = large part this is all about out of band policy interface, such as ANDSF, to= wards the UE, leading to the assumption that magically the MN and the LMA ar= e in sync with respect to flow policies, access selection and they will make= the right forwarding decision. Secondly, the flow policy decisions need not= be based on the specific WLAN network, but it is implicitly driven by the M= AG – LMA security relation, where the MAG attachment to the WLAN netwo= rk transitively allows the LMA to make the flow policy decisions based on th= e MAG identity. If the WLAN network is not trusted, there is truly no MAG in= that network, where the LMA shares a security relation with that node.

There are still some open issues on this draft that needs to be discussed i= n the WG.  On the approaches to allow more a flow aggregate movement, t= hat is a discussion point. There are issues that we need to discuss, support= ing split link model, or eliminating some favorite brand of signaling messag= e (FMA) and riding on PBU/PBA and just with one FMI trigger, and on the aspe= cts around MN applying the flow policies by flow mirroring. We have no agree= ment on those issues yet.

Its just a base draft, for further discussion and resolving those issues. B= ut, hope that is not a stopper for base draft selection.


Sri






On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <htt= p://sfaccinstd@gmail.com>  <http://sfaccinstd@gmail.com> > wrote:
Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicate= to the network where the flows should be routed or for the LMA to receive s= omehow from somewhere some policies, the solution cannot really provide flow= mobility since there is no way to decide which flows are routed where. If w= e are thinking about a host-based solution, I have not yet seen a solution a= s to how the host can indicate to the MAG and ultimately to the MAG which fl= ows should be routed on each access. If we are relying on modifications of l= ayer 2 protocols, aren't we defining a solution that works only with some te= chnologies (since for other access technologies it is rather unrealistic to = modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-based= solution, can we hear of at least one example of a real-life scenario where= the LMA would receive such policies, and how such delivery would happen? Al= so, should there be a solution to have policies in the LMA, how does the LMA= actually decide to route flows on one access or the other? E.g., if some fl= ows need to be routed on certain WLAN networks, but shall not be routed on o= ther WLAN networks, how does the LMA know which specific WLAN network the ho= st is connected to? Perhaps I missed the ability for the MAG to know e.g. th= e WLAN SSID and provide it to the LMA, in which case I would appreciate if s= omebody could highlight to me where that is defined.

I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important. <= BR>
Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM,  <Basavaraj.Patil@nokia.com <http://Basavaraj.Patil@nokia.com>  <http://Basavaraj.Patil@nokia.com> > wrote:
Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= BR> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt<= /a>

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= BR> developed further based on input and feedback from WG members.

-Basavaraj

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

--B_3379589681_87624285-- From sgundave@cisco.com Thu Feb 3 14:52:09 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CABA53A6B3B for ; Thu, 3 Feb 2011 14:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.01 X-Spam-Level: X-Spam-Status: No, score=-8.01 tagged_above=-999 required=5 tests=[AWL=-0.875, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFJ6UTy0GaKh for ; Thu, 3 Feb 2011 14:51:50 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 2868A3A6B39 for ; Thu, 3 Feb 2011 14:51:49 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image.jpg, image.png : 722, 9011 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuICABXBSk2rR7H+/2dsb2JhbACCRZQMQIYJAYczZgJzogWbBAKCeQEZgkMEhHmCI4RJgzODAYIXg1s Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 03 Feb 2011 22:55:11 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p13MtAtK027511; Thu, 3 Feb 2011 22:55:10 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Feb 2011 14:55:10 -0800 Received: from 171.70.228.143 ([171.70.228.143]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 Feb 2011 22:55:10 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 03 Feb 2011 14:55:41 -0800 From: Sri Gundavelli To: Stefano Faccin , "Giaretta, Gerardo" , stefano faccin Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLwmpURzmRlysrlUidlexdQorGZJPuBh2AgAAR4ICAAAzJgIAACkaAgADJ5gCAAKKGAP//oT5wgAEesLCAAAq77g== In-Reply-To: <680854867F7FD04BB9B06EB8ACA8D5AC05E1F0A3@XCH02DFW.rim.net> Mime-version: 1.0 Content-type: multipart/related; boundary="B_3379589743_87611006" X-OriginalArrivalTime: 03 Feb 2011 22:55:10.0798 (UTC) FILETIME=[691B1EE0:01CBC3F5] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 03 Feb 2011 22:52:09 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3379589743_87611006 Content-type: multipart/alternative; boundary="B_3379589743_87624380" --B_3379589743_87624380 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Stefano, My point on the synchronized policy assumption still remains, as I=B9ve noted in the other thread. Therefore, if we want to provide a protocol for network based flow mobility to provide an alternative to existing solutions, we need to provide a solution that realistically provides the same functionality. I will probably take a defensive stand on this. As I=B9ve stated before, I do not believe network-based mobility approaches can match client based approaches 1:1, in every aspect. Its simply not possible, specially when we don=B9t have the needed MN-AR interface argument, for carrying Attachment Preferences. But, most of the features that are practical from deployment perspective (unlike some of the complex flow mobility scenarios, complexity in the order of science fiction moves :)), every thing else can be achieved over network-based approaches, with out any MN-AR interface. Hence, my argument to keep the specs simple =20 As as for simplified policies versus what current solutions already provide (e.g. per access network policy and not just per access technology), why should we go ahead with a solution that brings us back in time wrt what we can provide to users and operators? Please note that even today (and not just future releases of 3GPP or future IETF protocols) there are deployment scenarios where the decisions to choose or not whether to route traffic ove= r a certain WLAN is based on the specific WLAN (e.g. SSID) and not just on th= e fact that the MN is connected to WLAN. To large part, in the context of trusted non-3GPP access, basic flow mobility functions can be supported. We can break this down and bring some of the aspects around network ownership, cost parameters and tie the flow policy rules to it. But, I don=B9t think the goal is to support all such features. Regards Sri On 2/3/11 2:22 PM, "Stefano Faccin" wrote: > Hi Sri, > I need to agree with the Gerardo. You are making an assumption that is > incorrect.Synchronizing policies between the MN and the LMA is not an eas= y and > scalable solution. I understand synchronizing policies between a MN and a > policy server that is the only repository for a given MN (i.e. one MN has= its > policy in a single policy server). Assuming that all the LMAs in a networ= k > that the MN can be connected to have synchronized policies with the MN is > clearly not realistic. >=20 > As as for simplified policies versus what current solutions already provi= de > (e.g. per access network policy and not just per access technology), why > should we go ahead with a solution that brings us back in time wrt what w= e can > provide to users and operators? Please note that even today (and not just > future releases of 3GPP or future IETF protocols) there are deployment > scenarios where the decisions to choose or not whether to route traffic o= ver a > certain WLAN is based on the specific WLAN (e.g. SSID) and not just on th= e > fact that the MN is connected to WLAN. > =20 > Therefore, if we want to provide a protocol for network based flow mobili= ty to > provide an alternative to existing solutions, we need to provide a soluti= on > that realistically provides the same functionality. > =20 > Cheers, > =20 > Stefano Faccin Standards ManagerResearch In Motion Corporation > 5000 Riverside Drive > Building 6, Brazos East, Ste. 100Irving, Texas 75039 USA > Office: (972) 910 3451 Internal: 820.63451: (510) 230 8422www.rim.com > E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0= 000/w > ww.rim.com> ; www.blackberry.com > E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0= 000/w > ww.blackberry.com> > > =20 > P Consider the environment before printing. > =20 >=20 > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of > Giaretta, Gerardo > Sent: Wednesday, February 02, 2011 9:14 PM > To: Sri Gundavelli; stefano faccin > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > Subject: Re: [netext] Consensus call to adopt I-D: > draft-bernardos-netext-pmipv6-flowmob as WG doc > =20 > Hi Sri, > =20 > There is no implicit assumption of synchronized policies. A basic example= that > shows that there is no assumption is the following: ANDSF policies may be > based also on location of the UE. For example the UE should prefer WLAN o= nly > in a given location. When the UE is attached over WLAN there is no way fo= r the > PDNGW/HA to verify the location of the UE and therefore to verify UE acti= ons > based on policies. > =20 > The assumption on synchronization of policies is only applicable to this = draft > and I think it is a wrong one. > =20 > Cheers > Gerardo > =20 >=20 > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of > Sri Gundavelli > Sent: Wednesday, February 02, 2011 6:50 PM > To: stefano faccin > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > Subject: Re: [netext] Consensus call to adopt I-D: > draft-bernardos-netext-pmipv6-flowmob as WG doc > =20 > Hi Stefano, >=20 > One comment. >=20 > Agree with you there is no ANDSF interface to the network node, but the > assumption of synchronized policies between the ANDSF server and the PDN = GW/HA > is there, implicitly IMO. With out this assumption, I do not know, how th= e HA > can ever validate the flow mobility options received in the BU. If the > operator requires any control on enforcing a flow policy rule, the PDN GW= /HA > needs to have synchronized policies, without which its always the client > decision. I=B9m not sure, operators in 3GPP would like that :) >=20 > No doubt, the lack of MN-AR interface is surely an issue for supporting > complex flow policies. I realize the issues and I agree with you. But, th= e > assumption of synchronized policies can offer some solution with some > configuration requirement on the HA (assuming there are no other issues). > There are also the proposals on flow mirroring on the UE ..., requiring n= o > flow policies. I=B9ve not evaluated this, however. Folks can comment on thi= s. >=20 > It is also to be noted, for some of the scenarios such, there is no flow > policy interface needed. We can identify what scenarios create any > configuration limitations on the HA and which one=B9s do not . As I=B9ve note= d > earlier, this is surely an open issue, that we need to discuss in the WG. >=20 >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 > =20 >=20 >=20 > On 2/2/11 9:08 AM, "stefano faccin" wrote: > Sri, > thanks for the reply. Can you clarify in which system or scenario ANDSF i= s > available to network entities as well? There is no such availability in 3= GPP, > and making such information available would require considerable architec= tural > changes, therefore the applicability of this solution to what seems to be= the > only realistic scenario hinges on 3GPP making considerable architectural > changes. I would therefore not be so hastily concluding that the ANDSF > information is available to the LMA and underestimate what it would reall= y > take to make the solution applicable. >=20 > If we cannot guarantee that there is at least one realistic solution to h= ave > the MNa nd LMA in synch, how do we expect that this solution is applicabl= e at > all? In 3GPP there is no need to have such implicit assumption, be cause = 1) > the MN is provided policies explicitly through the ANDSF, and 2) it is th= e MN > and only the MN that makes IP flow mobility decisions and communicates th= em > explicitly (with well defined signalling) to the LMA, and therefore no ma= gic > is needed. There is no need in 3GPP to have the ANDSF and PDN GW policies > synchronized, since the PDN GW does not use such policies. >=20 > Sri, in the end it is a matter of whether we develop a solution that will= rely > on some unknown magic to be deployed, or a solution that we know can be > deployed in at least one way because there are solutions to what I consid= er > major open issues. >=20 > Cheers, > Stefano >=20 > On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli wrote= : > Hi Stefano, >=20 > Thanks for the discussion. >=20 > As you say, the ANDSF policies are allowing the MN a.) to make the right > network attachment decision and b.) make the access selection on a flow b= asis. > This same policy that is present in the ANDSF server, is available for th= e > network nodes as well. I=B9m not sure, with out this assumption the solutio= n can > work for all currently listed cases. We clearly need the MN and the LMA t= o be > in synch with respect to the configured policy. How, that is done, I gues= s we > will not try to know. I thought even in 3GPP, this is the implied assump= tion > ? But, this is for you to clarify. Not specifically for IFOM where UE and= PDN > GW/HA are negotiating the flow policies, but generally that the PDN GW an= d the > ANDSF policy server will have synchronized policies. The MAG and the LMA = have > the ability to carry this flow policy information in signaling messages a= nd > influence the access selection. The policy is a opaque object, with exten= sible > formats, when carried in the signaling plane, should allow the LMA/MAG to > apply those access policies, while assuming MN is following the same rule= s. > These policies can surely reflect the specific WLAN access/operator speci= fic > rule. I=B9m surely with you, the lack of MN-AR interface is surely an issue= and > I see that. But, we need to understand, what are the limitations with the > approach of out of band policy interfaces and what will be the solution > limitations. If we need to tie the flow movement at the prefix granularit= y and > rely on the natural ND interface in the form of RA PIO option, more like = PDN > offload in MAPCON, or at the granularity of a flow level, is open for > discussion. I want to simplify this draft for sure, we can surely discuss= each > of these issues on the WG draft. >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 >=20 >=20 > On 2/1/11 8:29 PM, "stefano faccin" > wrote: > Sri, > thanks for the reply. >=20 > I'd like to comment on the "the flow policy decisions need not be based o= n the > specific WLAN network". Does it mean, as I believe it does, that the curr= ent > solution would not allow an operator deploying such solution to decide to > route flows over a specific WLAN or not depending on which specific WLAN = the > MN is connected to? E.g. the operator or the entity in control of the > decisions for the routing may want to direct certain traffic always over = WLANs > that the operator deploys, and instead route only some of the traffic ove= r > WLANs of roaming partners or of the MN user home. How does this solution > support that scenario if the LMA is not told specifically which WLAN the = MN is > connected to? From a deployment point of view, I do not believe we can af= ford > to leave out this scenario. Please note that the establishment of a secur= ity > relationship between the MN and the MAG, and a specific MAG identity, can= not > guarantee that the LMA knows which specific WLAN access network the MN is > connected to. Assuming that would severely restrict the deployment scenar= ios. >=20 > As for the MN and the LMA being magically in synch, I am very concerned a= bout > a "glass ball" solution. You mention ANDSF defined by 3GPP as a solution = for > this "out of band" delivery of policy. Fair enough, however there is an i= ssue > with that. ANDSF is designed specific to be a MN-centric solution where > policies are provisioned in the MN and the MN decides which network > technologies and access networks it needs to connect to, under what > conditions, and which IP traffic needs to be routed on such accesses. No = IP > point of attachment in the network (i.e. the PDN GW in 3GPP that is the L= MA in > PMIPv6) is aware under any conditions of such policy. Therefore, even if = in > order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would > unfortunately not provide a solution unless the MN can communicate to the= MAG > and the LMA the decisions the MN has taken based on the ANDSF policies. >=20 > I believe the key point here is that we need to understand how the soluti= on > can be realistically applied to a real scenario, and that we need to ensu= re > that important and realistic deployment scenarios are not excluded by the > solution. >=20 > Cheers, > Stefano >=20 > On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli > wrote: > Hi Stefano: >=20 > These are valid points and some good comments. Let me share my thoughts. >=20 > Carlo=B9s draft is not assuming any new MN-AR interface. Its going with the > assumption there is established policy on the mobile and on the LMA, whic= h > allows the mobile to select the access network at a flow level granularit= y, > without requiring any explicit signaling between the MAG and the MN. To l= arge > part this is all about out of band policy interface, such as ANDSF, towar= ds > the UE, leading to the assumption that magically the MN and the LMA are i= n > sync with respect to flow policies, access selection and they will make t= he > right forwarding decision. Secondly, the flow policy decisions need not b= e > based on the specific WLAN network, but it is implicitly driven by the MA= G =AD > LMA security relation, where the MAG attachment to the WLAN network > transitively allows the LMA to make the flow policy decisions based on th= e MAG > identity. If the WLAN network is not trusted, there is truly no MAG in th= at > network, where the LMA shares a security relation with that node. >=20 > There are still some open issues on this draft that needs to be discussed= in > the WG. On the approaches to allow more a flow aggregate movement, that = is a > discussion point. There are issues that we need to discuss, supporting sp= lit > link model, or eliminating some favorite brand of signaling message (FMA)= and > riding on PBU/PBA and just with one FMI trigger, and on the aspects aroun= d MN > applying the flow policies by flow mirroring. We have no agreement on tho= se > issues yet. >=20 > Its just a base draft, for further discussion and resolving those issues.= But, > hope that is not a stopper for base draft selection. > =20 >=20 > Sri >=20 >=20 >=20 >=20 >=20 >=20 > On 2/1/11 6:39 PM, "stefano faccin" > wrote: > Raj, > thanks for the email. >=20 > I need to apologize in advance if my questions have already been answered > before (though I cannot find a conclusive answer anywhere). >=20 > I think that a protocol that is developed in NETEXT (or other groups) sho= uld > have at least a potential realistic scenario for applicability. >=20 > In terms of applicability, though it is not part of the protocol definiti= on > per se, unless there are solutions in place for either the host to indica= te to > the network where the flows should be routed or for the LMA to receive so= mehow > from somewhere some policies, the solution cannot really provide flow mob= ility > since there is no way to decide which flows are routed where. If we are > thinking about a host-based solution, I have not yet seen a solution as t= o how > the host can indicate to the MAG and ultimately to the MAG which flows sh= ould > be routed on each access. If we are relying on modifications of layer 2 > protocols, aren't we defining a solution that works only with some > technologies (since for other access technologies it is rather unrealisti= c to > modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-ba= sed > solution, can we hear of at least one example of a real-life scenario whe= re > the LMA would receive such policies, and how such delivery would happen? = Also, > should there be a solution to have policies in the LMA, how does the LMA > actually decide to route flows on one access or the other? E.g., if some = flows > need to be routed on certain WLAN networks, but shall not be routed on ot= her > WLAN networks, how does the LMA know which specific WLAN network the host= is > connected to? Perhaps I missed the ability for the MAG to know e.g. the W= LAN > SSID and provide it to the LMA, in which case I would appreciate if someb= ody > could highlight to me where that is defined. >=20 > I think that, though not integral to the protocol specification, understa= nding > what framework the protocol would/needs to fit in is rather important. >=20 > Cheers, > Stefano >=20 >=20 > On Tue, Feb 1, 2011 at 3:47 PM, > > wrote: >=20 > Hello, >=20 > We have discussed the flow mobility solutions for Proxy MIP6 previously a= t > IETFs 78 and 79. > This is a consensus call for adopting this I-D: > draft-bernardos-netext-pmipv6-flowmob-02 > as the working group document. > I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt >=20 > The consensus call will expire on Feb 15th, 2011. Please indicate your > support or concerns in adopting this I-D as the WG baseline document on > the mailing list. >=20 > Please note that this I-D will serve as the baseline in the WG and will b= e > developed further based on input and feedback from WG members. >=20 > -Basavaraj >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > =20 > =20 > =20 > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-publi= c > information. Any use of this information by anyone other than the intende= d > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from y= our > system. Use, dissemination, distribution, or reproduction of this transmi= ssion > by unintended recipients is not authorized and may be unlawful. --B_3379589743_87624380 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmi= pv6-flowmob as WG doc Hi Stefano,

My point on the synchronized policy assumption still remains, as I’ve= noted in the other thread.

Therefore, if we want to provide a protocol for netwo= rk based flow mobility to provide an alternative to existing solutions, we n= eed to provide a solution that realistically provides the same functionality= .

I will probably take a defensive stand on this. As I’ve stated before= , I do not believe network-based mobility approaches can match client based = approaches 1:1, in every aspect. Its simply not possible, specially when we = don’t have the needed MN-AR interface argument, for carrying Attachmen= t Preferences. But, most of the features that are practical from deployment = perspective (unlike some of the complex flow mobility scenarios, complexity = in the order of science fiction moves :)), every thing else can be achieved = over network-based approaches, with out any MN-AR interface. Hence, my argum= ent to keep the specs simple
 
As as for simplified policies versus what current sol= utions already provide (e.g. per access network policy and not just per acce= ss technology), why should we go ahead with a solution that brings us back i= n time wrt what we can provide to users and operators? Please note that even= today (and not just future releases of 3GPP or future IETF protocols= ) there are deployment scenarios where the decisions to choose or not whethe= r to route traffic over a certain WLAN is based on the specific WLAN (e.g. S= SID) and not just on the fact that the MN is connected to WLAN.

To large part, in the context of trusted non-3GPP access, basic flow mobili= ty functions can be supported. We can break this down and bring some of the = aspects around network ownership, cost parameters and tie the flow policy ru= les to it. But, I don’t think the goal is to support all such features= .



Regards
Sri



On 2/3/11 2:22 PM, "Stefano Faccin" <sfaccin@rim.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Hi Sri,
I need to agree with the Gerardo. You are making an assumption that is inco= rrect.Synchronizing policies between the MN and the LMA is not an easy and s= calable solution. I understand synchronizing policies between a MN and a pol= icy server that is the only repository for a given MN (i.e. one MN has its p= olicy in a single policy server). Assuming that all the LMAs in a network th= at the MN can be connected to have synchronized policies with the MN is clea= rly not realistic.

As as for simplified policies versus what current solutions already provide= (e.g. per access network policy and not just per access technology), why sh= ould we go ahead with a solution that brings us back in time wrt what we can= provide to users and operators? Please note that even today (and not= just future releases of 3GPP or future IETF protocols) there are deployment= scenarios where the decisions to choose or not whether to route traffic ove= r a certain WLAN is based on the specific WLAN (e.g. SSID) and not just on t= he fact that the MN is connected to WLAN.
 
Therefore, if we want to provide a protocol for network based flow mobility= to provide an alternative to existing solutions, we need to provide a solut= ion that realistically provides the same functionality.
 
Cheers,
 
Stefano Faccin Standards ManagerResearch In Motion Corporation
5000 Riverside Drive
Building 6, Brazos East, Ste. 100Irving, Texas 75039 USA
Office: (972) 910 3451  Internal: 820.63451: (510) 230 8422www.rim.com <outbind://28-= 00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB= 000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.rim.com= > ; www.blackberry.com <outbind://28-0000= 0000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB0000= 01B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.blackberry.= com>
<http://www.blackberry.com/>

P Consider the environment before printing.

From: netext-bounces@ietf.org [mailt= o:netext-bounces@ietf.org] On Behalf Of Giaretta, Gerardo
Sent: Wednesday, February 02, 2011 9:14 PM
To: Sri Gundavelli; stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-n= etext-pmipv6-flowmob as WG doc
Hi Sri,
 
There is no implicit assumption of synchronized policies. A basic example t= hat shows that there is no assumption is the following: ANDSF policies may b= e based also on location of the UE. For example the UE should prefer WLAN on= ly in a given location. When the UE is attached over WLAN there is no way fo= r the PDNGW/HA to verify the location of the UE and therefore to verify UE a= ctions based on policies.
 
The assumption on synchronization of policies is only applicable to this dr= aft and I think it is a wrong one.
 
Cheers
Gerardo
 

From: netext-bounces@ietf.org [mailt= o:netext-bounces@ietf.org] On Behalf Of Sri Gundavelli
Sent: Wednesday, February 02, 2011 6:50 PM
To: stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-n= etext-pmipv6-flowmob as WG doc
Hi Stefano,

One comment.

Agree with you there is no ANDSF interface to the network node, but the ass= umption of synchronized policies between the ANDSF server and the PDN GW/HA = is there, implicitly IMO. With out this assumption, I do not know, how the H= A can ever validate the flow mobility options received in the BU. If the ope= rator requires any control on enforcing a flow policy rule, the PDN GW/HA ne= eds to have synchronized policies, without which its always the client decis= ion. I’m not sure, operators in 3GPP would like that :)

No doubt, the lack of MN-AR interface is surely an issue for supporting com= plex flow policies. I realize the issues and I agree with you. But, the assu= mption of synchronized policies can offer some solution with some configurat= ion requirement on the HA (assuming there are no other issues). There are al= so the proposals on flow mirroring on the UE ..., requiring no flow policies= . I’ve not evaluated this, however. Folks can comment on this.

It is also to be noted, for some of the scenarios such, there is no flow po= licy interface needed. We can identify what scenarios create any configurati= on limitations on the HA and which one’s do not . As I’ve noted = earlier, this is surely an open issue, that we need to discuss in the WG.


Regards
Sri




 


On 2/2/11 9:08 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:
Sri,
thanks for the reply. Can you clarify in which system or scenario ANDSF is = available to network entities as well? There is no such availability in 3GPP= , and making such information available would require considerable architect= ural changes, therefore the applicability of this solution to what seems to = be the only realistic scenario hinges on 3GPP making considerable architectu= ral changes. I would therefore not be so hastily concluding that the ANDSF i= nformation is available to the LMA and underestimate what it would really ta= ke to make the solution applicable.

If we cannot guarantee that there is at least one realistic solution to hav= e the MNa nd LMA in synch, how do we expect that this solution is applicable= at all? In 3GPP there is no need to have such implicit assumption, be cause= 1) the MN is provided policies explicitly through the ANDSF, and 2) it is t= he MN and only the MN that makes IP flow mobility decisions and communicates= them explicitly (with well defined signalling) to the LMA, and therefore no= magic is needed. There is no need in 3GPP to have the ANDSF and PDN GW poli= cies synchronized, since the PDN GW does not use such policies.

Sri, in the end it is a matter of whether we develop a solution that will r= ely on some unknown magic to be deployed, or a solution that we know can be = deployed in at least one way because there are solutions to what I consider = major open issues.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli <sgundave@cisco.com> wrote:
Hi Stefano,

Thanks for the discussion.

As you say, the ANDSF policies are allowing the MN a.) to make the right ne= twork attachment decision and b.) make the access selection on a flow basis.= This same policy that is present in the ANDSF server, is available for the = network nodes as well. I’m not sure, with out this assumption the solu= tion can work for all currently listed cases. We clearly need the MN and the= LMA to be in synch with respect to the configured policy. How, that is done= , I guess we will not try to know.  I thought even in 3GPP, this is the= implied assumption ? But, this is for you to clarify. Not specifically for = IFOM where UE and PDN GW/HA are negotiating the flow policies, but generally= that the PDN GW and the ANDSF policy server will have synchronized policies= . The MAG and the LMA have the ability to carry this flow policy information= in signaling messages and influence the access selection. The policy is a o= paque object, with extensible formats, when carried in the signaling plane, = should allow the LMA/MAG to apply those access policies, while assuming MN i= s following the same rules. These policies can surely reflect the specific W= LAN access/operator specific rule. I’m surely with you, the lack of MN= -AR interface is surely an issue and I see that. But, we need to understand,= what are the limitations with the approach of  out of band policy inte= rfaces and what will be the solution limitations. If we need to tie the flow= movement at the prefix granularity and rely on the natural ND interface in = the form of RA PIO option, more like PDN offload in MAPCON, or at the granul= arity of a flow level, is open for discussion. I want to simplify this draft= for sure, we can surely discuss each of these issues on the WG draft.


Regards
Sri






On 2/1/11 8:29 PM, "stefano faccin" <sfaccinstd@gmail.com <htt= p://sfaccinstd@gmail.com> > wrote:
Sri,
thanks for the reply.

I'd like to comment on the "the flow policy decisions n= eed not be based on the specific WLAN network". Does it mean, as I beli= eve it does, that the current solution would not allow an operator deploying= such solution to decide to route flows over a specific WLAN or not dependin= g on which specific WLAN the MN is connected to? E.g. the operator or the en= tity in control of the decisions for the routing may want to direct certain = traffic always over WLANs that the operator deploys, and instead route only = some of the traffic over WLANs of roaming partners or of the MN user home. H= ow does this solution support that scenario if the LMA is not told specifica= lly which WLAN the MN is connected to? From a deployment point of view, I do= not believe we can afford to leave out this scenario. Please note that the = establishment of a security relationship between the MN and the MAG, and a s= pecific MAG identity, cannot guarantee that the LMA knows which specific WLA= N access network the MN is connected to. Assuming that would severely restri= ct the deployment scenarios.

As for the MN and the LMA being magically in synch, I am very concerned abo= ut a "glass ball" solution. You mention ANDSF defined by 3GPP as a= solution for this "out of band" delivery of policy. Fair enough, = however there is an issue with that. ANDSF is designed specific to be a MN-c= entric solution where policies are provisioned in the MN and the MN decides = which network technologies and access networks it needs to connect to, under= what conditions, and which IP traffic needs to be routed on such accesses. = No IP point of attachment in the network (i.e. the PDN GW in 3GPP that is th= e LMA in PMIPv6) is aware under any conditions of such policy. Therefore, ev= en if in order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF = would unfortunately not provide a solution unless the MN can communicate to = the MAG and the LMA the decisions the MN has taken based on the ANDSF polici= es.

I believe the key point here is that we need to understand how the solution= can be realistically applied to a real scenario, and that we need to ensure= that important and realistic deployment scenarios are not excluded by the s= olution.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli <sgundave@cisco.com <http://s= gundave@cisco.com> > wrote:
Hi Stefano:

These are valid points and some good comments. Let me share my thoughts.
Carlo’s draft is not assuming any new MN-AR interface. Its going with= the assumption there is established policy on the mobile and on the LMA, wh= ich allows the mobile to select the access network at a flow level granulari= ty, without requiring any explicit signaling between the MAG and the MN. To = large part this is all about out of band policy interface, such as ANDSF, to= wards the UE, leading to the assumption that magically the MN and the LMA ar= e in sync with respect to flow policies, access selection and they will make= the right forwarding decision. Secondly, the flow policy decisions need not= be based on the specific WLAN network, but it is implicitly driven by the M= AG – LMA security relation, where the MAG attachment to the WLAN netwo= rk transitively allows the LMA to make the flow policy decisions based on th= e MAG identity. If the WLAN network is not trusted, there is truly no MAG in= that network, where the LMA shares a security relation with that node.

There are still some open issues on this draft that needs to be discussed i= n the WG.  On the approaches to allow more a flow aggregate movement, t= hat is a discussion point. There are issues that we need to discuss, support= ing split link model, or eliminating some favorite brand of signaling messag= e (FMA) and riding on PBU/PBA and just with one FMI trigger, and on the aspe= cts around MN applying the flow policies by flow mirroring. We have no agree= ment on those issues yet.

Its just a base draft, for further discussion and resolving those issues. B= ut, hope that is not a stopper for base draft selection.


Sri






On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <htt= p://sfaccinstd@gmail.com>  <http://sfaccinstd@gmail.com> > wrote:
Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicate= to the network where the flows should be routed or for the LMA to receive s= omehow from somewhere some policies, the solution cannot really provide flow= mobility since there is no way to decide which flows are routed where. If w= e are thinking about a host-based solution, I have not yet seen a solution a= s to how the host can indicate to the MAG and ultimately to the MAG which fl= ows should be routed on each access. If we are relying on modifications of l= ayer 2 protocols, aren't we defining a solution that works only with some te= chnologies (since for other access technologies it is rather unrealistic to = modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-based= solution, can we hear of at least one example of a real-life scenario where= the LMA would receive such policies, and how such delivery would happen? Al= so, should there be a solution to have policies in the LMA, how does the LMA= actually decide to route flows on one access or the other? E.g., if some fl= ows need to be routed on certain WLAN networks, but shall not be routed on o= ther WLAN networks, how does the LMA know which specific WLAN network the ho= st is connected to? Perhaps I missed the ability for the MAG to know e.g. th= e WLAN SSID and provide it to the LMA, in which case I would appreciate if s= omebody could highlight to me where that is defined.

I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important. <= BR>
Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM,  <Basavaraj.Patil@nokia.com <http://Basavaraj.Patil@nokia.com>  <http://Basavaraj.Patil@nokia.com> > wrote:
Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= BR> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt<= /a>

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= BR> developed further based on input and feedback from WG members.

-Basavaraj

_______________________________________________
netext mailing list
netext@ietf.org <http://netext@ietf.org>  <http://netext@ietf.org>
https://www.ietf.org= /mailman/listinfo/netext
  
 
------------------------------------------------------------= ---------
This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor-= client or other applicable privileges), or constitute non-public information= . Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use, = dissemination, distribution, or reproduction of this transmission by uninten= ded recipients is not authorized and may be unlawful.
--B_3379589743_87624380-- --B_3379589743_87611006 Content-Type: image/jpeg; name="image.jpg" Content-ID: <3379589742_87628676> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8l JCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIo Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAAR CAAKAA4DASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDSu9NvV0vVpbjQL2KfU7xR5T6qqmRclsrn hecDFbGl6hqL69Noem63ZRQ6faops5Y2mmiYBQdz8BuSR1qD4pxpLdeHo5UV0N2cqwyD93tX exW0ELtJFBGjv95lQAt9T3oA/9k= --B_3379589743_87611006 Content-Type: image/png; name="image.png" Content-ID: <3379589742_87653820> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAIoAAAA+CAIAAAB7vhRQAAAAAXNSR0IArs4c6QAAAAlwSFlz AAAOxAAADsQBlSsOGwAAIthJREFUeF7tfAeYHdWV5q1b8eXXudXKoAyIIH1IgESwMTKDSDZe bNKsZa8/xh8MNgxj1mYxLGZtgseDDcwABsb2YH9ggglDMAiEyCIMEkkSCOWW1Orw8qt0b+1/ ql4/tbJEN9t8OxSPp3rVFc+555z//OfcUtjwLZyxAB/8I8ObUMLfGmNCYYES/Yq+63/ETyz1 LdH6Hvbh4RXCwxX8I2vrOH3tSNqK1W2X7j/78Ill4JWj5x2epaaeSPZ1qdPPUKpDs9TUs93J drhcXflDc8X/T8+CAQ65QWef7dJ/DbV+mf4hqjO2beNnexP7evbhtJ6d7xGOLc30pKpLJjh5 nMEtsBw1kIH0hfRZUGXS7fejkUMV0elxVfyQpBts9wZ3zaE9etAiGPTtbIsciqIFwXg1Mbtp kukFYkj8mxJIJv1AQtt24FUDv2rbObfQy7xe6Zajm4dawrj0OXRyw68euBQasByxm9RzmN5w ZHysXvZ2Np4IBezPgt0FziMVnFuRipRcVVTF80XOlJ1Bpada6HKKBSagGjjW2ngYkmGxP3e5 h32H2dlCfpFrCWOOYgTsEKO1mZmKH4TOTYm+EZbqPyHpaAtW9rBPwBQ1YDzA3gHgGcdvEQRC qjLgMlClbFStsWa2XUvEGPdEFffgq5zJz5Ny9ns4DtGgqJ0GFiOZyZgD7xJ6mIRkp6cnZ3wd GovA9iAWIHboxYdiAtK1VELpS5iKpsSEwt1wi8bzOlsjc+9UOrtxB3VXO4gLD+Ghw2o9oavC Hfj0D9lDo9QPNVpMH0Kt+5pP+bBwaQFXuEwF3GO8wgKLC2jLNgwWuDGcXdU8FQZIMc5PGNaI RNat5l0W+NGVDTJqstPo+vQP7pTEFW4kkBnZfKTQMEnAV/jvtsM+5c3XDxtu9URZYaSeIGhX E1P0BtUVUuHkmsLH/bQfWA9XpMG5w3mF+xlViWvcF76tsWygWK6iicDAh3ELu5k8meXpXr+U IzkbiFdhwqzhJAFpJfSoFMLwk/TCSUHQN6kpUlWo1iH2jcOnnn43su2BJBsXbxwDD+d6gabC fsIIM7gPsxVeIbGKRilMRfV9WRIycPA//Qefx6AxSL3ienHDsiXbKMsMcI90QzKHa+y3EODw SAF0y+H2yHhgaBBjDaX32xp8Nv40WA+9n1BosMa60/EDfD0g3DGZ8Qfb8ELMh3qG4FqQshuo NqEJdxzQhuQbmjsc3/cRegLmqTBSSBF64tyHm1OCSlJ9Nd/TY4uqChjJkH9BC+CYYNyBp1Rt GFWAw30xUPCRkgaqB9oibipy24NZhlU90cX7zadZs2anx4wra1wEQ6QeISFftQwHJbyRrl9o G1ued1qHLXPkqHTJJf4AyStCCkVVgRrcGN/Iq1vsfCEIDENTfYGI5UFRAVd9U2B3qZYroq9Q 6S3wrm73veV9FQCbmslggJnYVVFsYMTBaKV+7LCqZ8ATYLCNt1IzzI4OV/dcT+j6oK1HQKaA 0KriBBwDPuspXVOP8A6dAyvqczyLKSaoPWgoCuTwcnBkUmM2l+vL+T78TSXlQTVkPdAwTDGk alVV182UZLphGlXbXdvtvfpm5ePldsmDyQB7AhpWB6a6g9HT8MWe7UeIxdhIJd6hpmMe/AYH 6Br0wAkQtxURI96Ae8DWUs1PODiebMhJ3ZXCkkEyCDRIWUodbiwI9EDRmQBE0asiKApfKpoC G0A2S7icQADpDw7LF7YD8qFUKuZ5UMlkxWEHJVoam/K91VK5CtRJHhPLYOMOneNzpJ7RVqZN TZquj2GKYABRcNFPXRMHF3lBCH27TzjoMbjDuE0SQcZEcEKEyEqVJlMxlitSqJrFD5jabCSQ gSIrtSBvsgYcgDPjULg7rGOroRY1v1faPiwa8JwjRgUCvo3DlkhfgiuGYZIqQ3ARuKJcqI4e bY4+INFbKG/tiTBBPNTPYIHccKonKihEfiCl8AOtxgbgYMQLxdAgD8arhi9U6MV3VaEHXpwM S0V8hyGE3xwUgIbwLuHpdQQRgW0QvYqggi8SO4Vw7CVjbuClmt2JByX0uOv7psI5Zy6cFwcg QKzDChcC+ADy17ijyB7XJkRNtAQCIWmcSV1wrGnwb67nwbp0AyRUoPksnmQ9hUos5s6c0dy9 2d7SjcdKhuigPy59Wgc3aA//aS/cH05rxycUtYHFFV8Knfu6qgeq5SvIUDyOtF94ug8MnILi yEoge8QDaIf8Hwa3RtEBnBoxOIFKPo1clMI0IQIV5J3p+yMVpsazRT21STEKwquqVO7TVaFx MAdCVel0+EAd+AluSbU8FhPc8EjthkcFKD1wLGHrim0EXkwNDEjOR/YMolCtYucYCxzJ8uUz Tkq0QjWspCiDhW3D7NxqGV2Irdu4OUrPxMD7g/lHFAiEJjFylbSjxzyzymI+h7tgtpn3NN/T hVB9T3U9zXORXKq+JRwdQV1xFcVD+AZdI7jucoOrCDMSwVyyraMPVEaNM1y/xJGH1vJ/KBXA TYXwWYDBrsPwYLalwO/yq74BuEAWFLIE8Lak0uiDhf5FPoXxIaFr7EjUkRRBIq1WpbFqjT0k zm04rYd8M54vhKAZNW4oOp5cwsErAnIXGtM8riNmMAPS9aRflkKr6pqrKRUDOhS26dsxz447 +Pa49FWiviEWTxGu6vlGVcR9G5ahStf1PSeTbGZ+UlbjikyhxsAk4K8bSA80HOAD0aZS00AH BEDjvkdWqbrIh8APMFWDqYa8QY3TIe3U2AJKU8MclaIY94uFypSpMQMYe7tM6FM6mV3HnjBM 7t8y8JD9PRxjZHK8oVVJaJTBBxY4A6l1uvl8YPeygs2KCVMkY7aluczVbGFrgYEYA0emBDrk hKFb1dQi1GUqqZhiqm5cF5bhW7qIm25Mh3SrmUbnoMMbzWSFaDfdZLxk6GVVRX5FsYch52S+ DACqwTKIQmB3o0JkIPIjlCkYJwQa4P52LGiQI4U/hFtEhFQQmngAbWcakytXy3x+CJzbbtVw ySWXnHvuucuWLbvyyis3b968V11FKom+ETCj/esr9cN1Xfc87/jjj7/22muF5137s58tfO45 uK1TUpNbhaa5wtWVmMs3id5JX/nKOddcVu3deufPfsRWvP+tL83u9HuThx1+0FFz0uMPhC8K wDyHIAkykqZR2fTxsof+zV2zrNkSik+igWB9jsCD8CBEbOv0WY026wJe84HoRIoJi7wnRC8V DArHAVz2pes7rreqVFleZFqCIfkC6PbhvuC5iELYUVxECwmDaa7PmerD0MkejWzmwSe8d5ZW 9iq0ve6w3fXqwh05cuSGDRuig2+//fYLL7xwdyci/xsqIzoWgEgigMOlAzgRbagIsYv8edGi Rccddxz2f/fdd08+dX7v2nXfaj4sWXA0wSqQh+0lJh1w5ZN/yh7QhH1eeeTeRy757twJDelj jpn1kztNI7u7mym889Qj/7igI+GbQGUE2zSHJRSNV7zubIeceEhDNegBVgMhEAYScNXEe4Ll ZICCBOXBw6LOwPLSX1u0t/ZWK4WgDHSQYm5UaoiiDT1tffzBh4XqUeGKgScxZmRgJha/pS5c VNir9Pe6w65jz4QJE3Ck4xAuPO200/ZwloGGgnUoA9/QDQ1eKXepG/zJNMEYMtfxJk6YOHnS BHCKloockGhI7gc5Zp/ygwXQjY0kL2CZTEvLyLEl3z/2ssugm4rwkTaWA4YPUhhHSlfKcohg Y9kW3UggaxeSu4HuKDGQXhwkmV1pa0xRsMAVgIwlyn40rNCIQBgQJ2BVIcuBKMqgLJSCqdlT WpMzxzbMmtg4MqOVy6RtSrAoSwrNtT/ehAEozD/DqhKNT8L+pOohWbZTDyQbGUEk30j0kSh3 ucyePfsPf/jDzTfffMcdd8BfYZ9Jkyb95je/ufXWW2+77bYzzjhj5yA00PsZJjJ2ZCe8mSWE 42JEAgP1+bmDTjnuhL/7ZgkZkabi6Tdt3NKzsThu9ldYehJaOpBn6lxJKLALFuPM5MBnPEH3 6L/86P0lpxRoBhg0Qm4YzcB1fgWxJdVgSkgf8iMyvErx3wdmxpBA6FJNRdNBgRKoJmihigpz +jKB0Z6MHz65beqkNLIk4YZZrI6UGfKJKGtKlQNVEMGNcwVSU6TnMcM0C7khCDx4JAS97ZZI MdFioHTV77UG7qRpGjgsbDn77LPPO++86E8IVIlEAkq66KKLoi3z589/++23161bVz82Cjx1 xVNXIIjgwBtjNRgeYJPquU4P87932/XYBzaR0Hi5u/D23XePMTZZo1sYa3Q4s+CNyptfeuwP aQvjGDCaiqJm38auF1/rW782kY2XNLNBagm7xPXNuZjVUI7HzSY37sVk0VOa/HJb0vogxpSy lq3qNpQUVxJWscLUWNnwdIyIKugcoSRcUbGkV0ynSoc3j2hLO++95+Rd7qLcITQL+yHN8TQJ t2YGvNJgsRxXBQxXseJVuOgqPbQK2Bj6dpgTlkho9QE6bty4fD7vum61Gu7dbxUDRb0nYL1D nK8fFl0Gy5w5c+obFy5ciPW5c+fWt7zzzju5XA66TKfTqVQqmUxGutm2UAWOJZAwuj4GpC3F Srbm76+/vnXMKOG7CYWw7FO33LVy2ZKxIxvdCkVancHI8izoefa6f1zyq58sv/nKVb/6nx/8 85Vv/flud8P77UY1w6oqnQnQwRRmCsEMGVRGr8TMXNlk6P4wp33VaZjRR56oL+EmY46le8W+ WLkczyUwImzdaxhlN4+WBnPVzbrWKxxghc0dCeewqUaGx5Uyg2eErbsurMTlQQz9Pp7EcwW+ w0gXaDXx+KYuWCF+CoSGY489FoO+Pu6jaB2LxW666aYHH3zwlltuwfpAqxgooR2tZzvx7eZH HQ7g7I899hi0tWXLlieeeAK7P/7442vWrMFtwWgQ/wuFwr333nvggQdCMbAtgMBot9pC0TZo DCyffFDQ7RemHTj3lEu/g3IPfpoKy6/e+O//++eHTWowdQr1OKqiaCkFoTirptvMVFzzqokA 7t7xrSAh/JhbQRZKgV5Nu0q8RyDB8SiRSsIdFvq4Vu7155zw7U9eNzZteauD61rVBYODQJVv yoh8YSxT8pVKZvp3M+MnrH70iga9YCpBoZKwjfZ4blU2npk2ofn1FR/mcn4CBJHoyeWDRMIz YJEcdgluuyHQSoKXN2+NdedqTuiCCy4oFouLFy+GAqAGGEqkCQgNIeDQQw+1bZtUvSsvRRt3 qQIYAc4YhaLe3t6mJkJQ9YX4qtAS68a7B6UOxNZQ3qmnnoqdX3755aOPPhor0N8V37jA+evb qCav93v++ZGHDp5/fCGoJDxTNdSfnblgyV/uOWPGxI50Z/vJ3zrk8ju3IoEFBPCdJX+5N2Px JDyG43dvXP3BS/e1F3qaglLJ8h0lqYlMsSLTR88YP+uYl//XT6af9VUj/Xyx7cBEdsS4Gdcr pTVaKub16B8+d1mu9PERx/46M+O0/IcfaIl1nyy86oDjb0uMP6n02vc+WHhnE+oLjceMPnFB 570XNZzw3arrP3rfnbNPvPjIs35Y6vn4X2+4elP3m9847+pXX/9d58fvn3POL99a+uC6zldf eNl8+XX1xUULm9qypmn97ne/++lPf3r55ZffcMMNn3zyCXz+hx9+WA8QkWIiSe6ch+zJue3O 4iLdnHDCCRgCOCOW9evXYyN8XfQTC1IlGE2kSFwYS7lcBo4YqEg4Hl3T04GV4tYWN/e1y34A 3TghSwrdPPfHp/7jL7+fbna0N8UAq4SmIoVuQwLjVZmoHnnWeZPnnz/yb84de+aCGRdd+zfX 3r3V7OjjTdJooEIA/IePdLaYPOLY9JxTpl1xV3r838Wbz40Zh6DMU8h3Lbn9HN+0EtNOGTfl v8cPmvv6Lcd0vnd7YswpxULQu3zh+rVvvfPSbxMNqoyxiuUnRx+/SfG9bCbPqvNO/f7EE753 yYJZD/715n+4/r687Y8Ye6QWz6LY0zhqrpYcnSuZi1+177jt1s7ujZMnT8HDwGK++c1vfv/7 34carr76aviPMWPGQHRQSSQNiCuS5M6jfO+xZ+djopg0b968+p9GjRrV0dGBGFPf0tbWdtBB B0E9wA5nnnkmQAT2uf/++weeDXEUi6mpfTI/8uBpZ//wQoAFz7PhvsrrCndcedME1pYwAyvm oXsmRN2oNIBh1oQWp/zRd8pS5hl6A5hvtPBMu6PFcoBdqgGA35JJbl21lBV6R8w/3+9cGp84 L94wS65eCdY1t+lD1tnj51ZypzvR0rJl49LCx8tXvPGIw7oVUZGsV7ELdhFZglJBkNVitm30 BAkHVIWTz04ZtfI/n1j60ab/WPgo4mZTi1IpF+ySU0AEEjyRbHn6GYo6X5p3wrL/XIqVp556 Kh6PT548GYEAP//85z9/9NFHSCujUbtXemW/Obco5cTZx44di2/YxIoVK6677rrOzs6pU6di S6lU6uvru+qqq3BnEydOhG/FMOnq6gJMqOumPlKASU3V/JB1XXzlFU0jWtELnQDKZcojt99T Wd0VY2oyGVNiPgqXUXW4rGkO131gaSOua3GD63HGE4B5ne/yYpcKrg68CogWsJzg4PxqYfOa w78yb91jv060x9rHN9tbl6LFIBMXforlWNrPWqs7l7ccMKX5qIOnzV9gsGQllgaCzCTTHdlp nqubpsoKWjyZnTLrghEjTner0worlh4ye+bXvnzet8+6xS/1yl6eSKgHHzF35qy5B0467LXX tq5cRff51LNPzvvqScfOnXvWWWfBMpB9A9lGXAnG8fLly7EC5LZLixk4gveknl0eXM+NAKBh EFDAUUcdhZiPkyIBymaz7e3tuDAuj4j34x//+IEHHsCQQST75S9/GV0YRgYUhxWPCVPVenq7 jxs5e/rZJ/fYZQd2oirvvrj44d/8FrpJK4lsOmNTxT9MMZC9BgJsqKmUtix51l72vL76VfXV h1645m8X/uryRGltIy/rYFXIm2sYFvFEYuVLi9gnL/nFNyufPCr7Him6a7n/hsx3gSYz3bfH VlZobz5eevP+w8++qjE1RikuzijehvWLY8m+KV/+uiurSECLq97a+swVo0YHPfm3mrPjVr/5 l+L7//L3V19+4kktN143R69WH/njvx4/98QfXn7PrTf+/JZbHgjrV+kf/cOljltF9vfGG29g vD700EN4/Oeff/7EE0/8+te/juGL7x0i+s5eClt2hAYRKhsIDXp6epqbm3c4uJ7BDNyOkQL1 YAvs6cUXX2xsbIRW4OKifXCLuCestLS0ANRNnTLV4Uo1l7vizPNu/OOf0iNSwDQxeDCVXXHo 8SuXLZtgzBLuu0d9mTU2+ZVNW1pPv/jIy35dCWQcBOTWj6+YPXF8BmQKM5PMSmttaCSE/nxW VlFBQx+BAWYNjQOb7E0dY+MTJigAyEBLqay+vttrzqRjmlLOF7knsxljfc6l3ilTR3xpbNMK KP9t9VWdNbQhX4kVS23ZcUcEo8eNGTdh9dNP+92Luyt9z77FPiqw0WNYm2n2BtbmnurjT7o9 pagTOR6yCvtEuNUx8C51g43bWc8Oe0dObMdkJTwTNkZhPyLWsAJ/et99990ZLtAKgBlsCx7v 1XB58sknr7nmmugmIuwABxTOVgsuvOonqZZ4gN4k4UM3z/zT799ZtqQ51l4RjmUAOVSRigeg qsGWIO8BTEaJLmmMSLJRjfrYDpZJQw16V9HvdrUcHKOCD4KsCHCY5G1ZbcKYrK5a7UmtIROD 7Y1psgxe8AKU5rjerBe4bGrVW8arrR2ydQyqgDyjqa3tjAakx3wH8xrySDvNwF/5/MPFrkUG z3e0xKcfmjh4mtbYmGbxRE+X+GCZki9FbW0GSNJ91E0kit0pJtq+nfUQVxQu8JKwRMQuhA3Y JkIL4lvtgDD2gMl++OGHB0I74EXkQPWLwVBgLplMJmJIK5VKhFVwTqSosC1A/kqAZmque4p0 XMQczrXeTZtPPXhmk6eaepoXrAmZLXPmsVhQLazrbv3ad+Zc+lsknEhhVLf04M8vb08GpvT8 wLLVpK76xc2rty5/O6N5BuoC0A9IHcn1ZG7q9HY0gQhWRo2Oghh1doBfhixR3AE/SLRtWGkj n4jqAkSiSir3oNMObQ/CMHNVTzPigeJlFAdO2U8k3umyXl/lbtiiLH+/vHK1ADVIsiZ2G54N KerQdFHtQj1021IioqxcuTJaj6xkhwXbH330UUCy+vbzzz//4osvBlIAkQoG4cYbb6z/qW6U dZcIjzxz5kyU16AuI6x0+YjyjJ9+xunPPvJoFnWYAKVKeXIzP+OkJtfOeT2lscd89ZjrnvQk s9FfoCmGhwozckFwXgbqAzT9I8i998Bti3/7i7Y4GhDQpqHagTZiUmXC1IRQ4HeIXkG3GjVE oREIoAktOCCow1776AnBMAUijoInNutIVtFT4NpqApexHbB4fialVCt9+U1+6sEl+r2Lentt aidFGtbfUQNelmrtdbEOnhfdbb3nvffeQ9iArDHksURmCFVFJFKE2feMC+vZK8HnfrwX6eyu u+5asGCBg9ovknwfHWM6fN3d/3bPd769AGVGjSlVXIqJi6am5s1q7c11qV6p4mS/8/RaxlO4 gSoGuIJ+DrR84MZQmoPrY+iYEl1v3vnd+RmlZKGsoXBHGplGnkqDHi0rHNU2dG7gQmCqHfTd EIEJSyIvS2U3PA1WoEEk26iwGS4VSVFj9aQjuOchkpXjQamMaxWsjj8tk0+v2KQoTeSlyW6g mGpYZajVTfu7RAeroN2qB0wR3BfC+86mE2154YUXIpZ6v5aoIATQ8sorr4Derh/712eeOeec b/V09/T3iNGsrF/NbxqnWbbmgKdcv6Y8/Rs/+NKlNyHFpmaz/gkDEcePb5TVVj1z5+M3/ag9 IQ3pUREUNuamBNqq0UtFHVGWRCeQgokj0Ca0r1OhFW3yYUEP56BWQ7UY6BW063Cpc4E+RSpK U+sPlYKAN6pcV/qsUfcuLT+zYiPjiHugjKAbKnyE56g/ECh03ONgvdyeitbTp09HugvcjJrC QEYPtwC68xe/+EVEFuzXUudukaldfullM2bOqLru66+/dt11/6d761aiOjCqkUVLFRbw+79t T26WOQ3NNiVDptcV5ZTj5h987MnZtjEoJWH8U3CFQUNhQm54/9XXHrpHK3VlkZgi+aSeNNgh XJbLVJe601CLkEZoRqH5hX+l6BwW2cLm26jPEBaEPyFOGqizRlP4EaE0VuKihDvsMttuXbT5 7S0guUP5R1oJvzG2+gn/qEvsM7OeutCBlevOLdqIxwDaxgoqDhGdt+8Ljo3AXkR7t7a2wllF Z7NUtNVIZhmq7XgBnzxaufFL6dQGc2tS2mYhBipfFD1cT0tyoxFhwlKQ4viOqrhaTPVB9FQ1 5sdVtHNgRJOQMewD1ZMK2jYdKIZLdIaaauDBmKgHETMLSC31MR92LUjM/DJRoGZalfw5tgBN SLRjQ1ueGbhcMzay5hueXr2aGIVIKaSc2hQT8NaRTrazpH0Xz4577rYNMUJx2B35HVijHZZI xDCpvULDHS6I0UeSC102QFKpXI6qHXA0VMDEwIVZcBPczdwpqUOTLvcMYTLHLVgq8lRmIV5w jeYOeI4mweej3uMrvp3Ah8uYTsM/RCLRKKKCBbXUUhMHSqNgFKi8GfXcADsQwUCSDGNjBN5g jGFPPOKNROGWurDJ0+G+0HmCmamSW6tyyqKPAQvgvgwUW8Nz4BqYCUTqrdlLZDyDXnarnj3L vU597u8NRBqlZfv7h0+oEbbkX1AIFd8Ynx6ZopmFQeAkwcVxboOhpuY3TP2BP0OER20aokSh E3CZOtSonR1yrk0oDZEYNRBCC4C8YeCGUqhmjvYb2nFgX1RtKhXabRBLaGTi7CgQoaSAO9Ax prioAGmLVPq1TnfJRqQ5uKhHo6HmxFCKGzAxdSh0A9nuN+e2v/r4NPsHTloLWhujgEfN52Hv X1hLpr4NiL023CF9GAT1SpMxh/ImkWMc1z7hBsqAqameWgFqT0wH7HLaHTWbUgsp4TuGVkgX GB1pEGVCMClNL0tjyXJyxeGJqLf3M10+l+phTmNcTxqqcF2yFgx/ShbDcBItxDhEGqhJPPRR tclq0Xr9U1ujM0TaCw/ejVAx0xRXJI9I14QloU0XU1DRJEzsMo8n31tXWVFEuAV2qKGG/4Lq Ye1JNaa6od9AdzqaLWha2mcqCDo58jD0g8LOwuhIU63IdNBaj0urwkxWldSTb28Jx0RUZaZb +kxv6/NoPYiHk9tT8cCl8Rm2n5GtgEUboilnu1dzNIuHSGFUMAAQwDPZmM5jWGVulszWB1/b sryMGIM/omJO0/2HYg7Pnkbd51E9lspGpDCp2oagPLAzJLLIi4Vpyf43GO+32RHAI0LB9QMt noIz09PNS9fbr3ycD0+F8QP/9v/i5TufR/XENK0xoWnCQcZBegnn54KWq01Tp7ewRO2A+/DZ jesByhrwGZhAApeHs+AolGmaZRVtv3lEx5othftfWdtFExl1pmtoBKYes5qqPkN88HlUT3NS bUxgZrTqCY8SFHr/HmgwmuVObTlIt8IZBXv9EK+w42Q6aubEpDbCz9SESA6M3jyBJQSJ4QxT miCEpnaUbm0/iDV3vPJ+5x1PdXZiAiQQgRrH/Iloqnyolv4JJfttoft0wGeo+X24PooUrop3 2eAfglOwFhwkTplk/Y8jUlUPbZmUH9IMjoi/IcQcvVxg7wuxcEBp1Ly5484wPw0MOSZUQTFq 2N4JIhA6ozQV/W0o2pTjeM9OLF7Umx/+yPvTErSbQyMRP0K4IZLaPt3H3u90T3sMr3ow4Zfm tuE5Q+4QFRZ6v9cPDmv8b1PNzlzJMjC/wKf5GSGpFQIq6h/Z90f2qId6Z0GG7dUhpRBOHg1n FRGYVgi7SdVMpnwttryr+tLyvufWlqm3g6ZoDZbf3Pfbru+5H4/6Kc6+50MigVMUpv2QSSgW CDHGrjmxfXqjV3YEKnSkHnRab+MYIvZx7wsN7ZChJG3Wx3nt0MAHhw1DpDwWhTcYKOgZaujW rVhFUzeUtcffLby+BjVYcmJgb3CCWqPt3q88lHvs06MO5QUHnAtPDgGGAAhvhkJRi2azYWbU P51/gOl2YtYvKmIh/4XcEEA2OpLKnbu5n+3MJFKjRTMUIo9U90Y0KnSwAGin51rALa6iO8A0 Y0m7ai9b37ukq7hso7MW0+dIL8hv/BhoHsyG+IyksMfTDqd6UEvB5UOPjrFrYaaHIpzpTea1 Z01XeteB90eiDhqSwvu2F+aCAcP+FMe38fgDifxI2VFdAKQYAj0B8tCWAAKiCEYgA3K3XKb1 VN28p27I2R+u71m9tbwRE7BCeYVnxz7Ru1eiK/6Xc241QYbCQzEGz+8fPSZz5swDZK4rbBbp b9uKvFOIssMpCdgzfBsBRaSQ8yfJh6/tILlGTg1/V3y814o8WFgbQPSXCtJMcPA9Za/L0fpc pTufhwvDZJV+Ugi0JyIizu/0GyPOhgkNOM8+Nd8MrY0Np/VQGQE1mfBdkf20vEhREIBDq72F Y9foaHtfVauGRd6r7uFCnUQGSm/co76J6N0U9IGJbHvlAM2BDKdqI/5jwjFKqVToxFyV/rYB GhAYDUMzZWe/9De86kG8wTsd0BZDEYjIf4A3VEprXPIu4Wu9PNnvgequaNtK/cC6A4xkQtoj o8MXiG56HxL4NUzLA69G7zUIVenR/AjaGcU6HIHEK+oerpdB90u8g915eNWDwU2tLQNielQf hsevF6IG2g+Jr//NuRHii+4/Guh1UBdtDDtwavXQunpCpaKQjf7mmm2EnEQIOcLXwVANIzST 8AbIc9Yx4GBl/cXxX0jgCwl8IYEvJBBJ4P8CkLsiseCTLsQAAAAASUVORK5CYII= --B_3379589743_87611006-- From gerardog@qualcomm.com Thu Feb 3 14:56:59 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29D1B3A6B37 for ; Thu, 3 Feb 2011 14:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iszNyNod+Wvx for ; Thu, 3 Feb 2011 14:56:42 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 5F38D3A6B25 for ; Thu, 3 Feb 2011 14:56:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1296774006; x=1328310006; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:mime-version; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20Sri=20Gundavelli=20,=20stefano =20faccin=20|CC:=20"netext@ietf.org "=20,=20"Basavaraj.Patil@nokia.com"=0D =0A=09|Subject:=20RE:=20[netex t]=20Consensus=20call=20to=20adopt=20I-D:=0D=0A=20draft-b ernardos-netext-pmipv6-flowmob=20as=20WG=20doc |Thread-Topic:=20[netext]=20Consensus=20call=20to=20adopt =20I-D:=0D=0A=20draft-bernardos-netext-pmipv6-flowmob=20a s=20WG=20doc|Thread-Index:=20AQHLwmpURzmRlysrlUidlexdQorG ZJPuBh2AgAAR4ICAAAzJgIAACkaAgADJ5gCAAKKGAP//oT5wgAEpJLmAA AFP8A=3D=3D|Date:=20Thu,=203=20Feb=202011=2023:00:05=20+0 000|Message-ID:=20|References:=20 =0D=0A=20|In-Reply-To: =20|Accept-Language:=20 en-US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|x-originating-ip:=20[172.30.48.1] |Content-Type:=20multipart/alternative=3B=0D=0A=09boundar y=3D"_000_E5E9FF33C2A27043B3BC96FE5A5160F101B7DEnasanexd0 1enaqual_"|MIME-Version:=201.0; bh=1p9fxo+IMmgw+tpjm3MfDlTnD07qm2E3hXHvVH+eKIk=; b=Z/5SiTgrNMJtujRbUhQvv0XQx9w06EyF80kQLM5UirwdpzkDx1pQKN5J dGeRJi/3gaUGYojjHX1AhyQed2kJHyuHr6G7wuRB++XRObKSdFiZEwXHS z1133vsRkwC1ramQ3JO9Fqu8ez/pX3/3kdkbaJy0sIiRp8Q6mKW8+3i0x s=; X-IronPort-AV: E=McAfee;i="5400,1158,6245"; a="72908992" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 03 Feb 2011 15:00:05 -0800 X-IronPort-AV: E=Sophos;i="4.60,418,1291622400"; d="scan'208,217";a="47334180" Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 03 Feb 2011 15:00:05 -0800 Received: from NASANEXD01E.na.qualcomm.com ([fe80::6555:8c37:4ee3:efc4]) by nasanexhc05.na.qualcomm.com ([::1]) with mapi id 14.01.0218.012; Thu, 3 Feb 2011 15:00:05 -0800 From: "Giaretta, Gerardo" To: Sri Gundavelli , stefano faccin Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLwmpURzmRlysrlUidlexdQorGZJPuBh2AgAAR4ICAAAzJgIAACkaAgADJ5gCAAKKGAP//oT5wgAEpJLmAAAFP8A== Date: Thu, 3 Feb 2011 23:00:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.48.1] Content-Type: multipart/alternative; boundary="_000_E5E9FF33C2A27043B3BC96FE5A5160F101B7DEnasanexd01enaqual_" MIME-Version: 1.0 Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 03 Feb 2011 22:56:59 -0000 --_000_E5E9FF33C2A27043B3BC96FE5A5160F101B7DEnasanexd01enaqual_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sri, Conformance tests can be used to make sure the UE behaves accordingly. So n= o need for the PDN GW to perform any validation. Cheers Gerardo From: Sri Gundavelli [mailto:sgundave@cisco.com] Sent: Thursday, February 03, 2011 2:55 PM To: Giaretta, Gerardo; stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-p= mipv6-flowmob as WG doc Hi Gerardo, Sure, for supporting the specific scenario, the draft is making that assump= tion. This does come at a cost for the operator having to ensure synchroniz= ed policies between the ANDSF server and the PDN GW. But, my question still= remains, how in IFOM, a PDN GW can ever authorize and establish the flow p= olicies requested by the UE. It needs the access to same policy that the op= erator configured on the ANDSF server. Else, its all in the mercy of the UE= with no network side validation. There can be all the needed information e= lements, around UE location, or network attachment in the protocol signalin= g, directly from the UE in IFOM, but fundamentally the PDN GW needs access = to the same policy. I do agree, this assumption is an administrative overhe= ad. Regards Sri On 2/2/11 9:13 PM, "Giaretta, Gerardo" wrote: Hi Sri, There is no implicit assumption of synchronized policies. A basic example t= hat shows that there is no assumption is the following: ANDSF policies may = be based also on location of the UE. For example the UE should prefer WLAN = only in a given location. When the UE is attached over WLAN there is no way= for the PDNGW/HA to verify the location of the UE and therefore to verify = UE actions based on policies. The assumption on synchronization of policies is only applicable to this dr= aft and I think it is a wrong one. Cheers Gerardo From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of= Sri Gundavelli Sent: Wednesday, February 02, 2011 6:50 PM To: stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-p= mipv6-flowmob as WG doc Hi Stefano, One comment. Agree with you there is no ANDSF interface to the network node, but the ass= umption of synchronized policies between the ANDSF server and the PDN GW/HA= is there, implicitly IMO. With out this assumption, I do not know, how the= HA can ever validate the flow mobility options received in the BU. If the = operator requires any control on enforcing a flow policy rule, the PDN GW/H= A needs to have synchronized policies, without which its always the client = decision. I'm not sure, operators in 3GPP would like that :) No doubt, the lack of MN-AR interface is surely an issue for supporting com= plex flow policies. I realize the issues and I agree with you. But, the ass= umption of synchronized policies can offer some solution with some configur= ation requirement on the HA (assuming there are no other issues). There are= also the proposals on flow mirroring on the UE ..., requiring no flow poli= cies. I've not evaluated this, however. Folks can comment on this. It is also to be noted, for some of the scenarios such, there is no flow po= licy interface needed. We can identify what scenarios create any configurat= ion limitations on the HA and which one's do not . As I've noted earlier, t= his is surely an open issue, that we need to discuss in the WG. Regards Sri On 2/2/11 9:08 AM, "stefano faccin" wrote: Sri, thanks for the reply. Can you clarify in which system or scenario ANDSF is = available to network entities as well? There is no such availability in 3GP= P, and making such information available would require considerable archite= ctural changes, therefore the applicability of this solution to what seems = to be the only realistic scenario hinges on 3GPP making considerable archit= ectural changes. I would therefore not be so hastily concluding that the AN= DSF information is available to the LMA and underestimate what it would rea= lly take to make the solution applicable. If we cannot guarantee that there is at least one realistic solution to hav= e the MNa nd LMA in synch, how do we expect that this solution is applicabl= e at all? In 3GPP there is no need to have such implicit assumption, be cau= se 1) the MN is provided policies explicitly through the ANDSF, and 2) it i= s the MN and only the MN that makes IP flow mobility decisions and communic= ates them explicitly (with well defined signalling) to the LMA, and therefo= re no magic is needed. There is no need in 3GPP to have the ANDSF and PDN G= W policies synchronized, since the PDN GW does not use such policies. Sri, in the end it is a matter of whether we develop a solution that will r= ely on some unknown magic to be deployed, or a solution that we know can be= deployed in at least one way because there are solutions to what I conside= r major open issues. Cheers, Stefano On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli wrote: Hi Stefano, Thanks for the discussion. As you say, the ANDSF policies are allowing the MN a.) to make the right ne= twork attachment decision and b.) make the access selection on a flow basis= . This same policy that is present in the ANDSF server, is available for th= e network nodes as well. I'm not sure, with out this assumption the solutio= n can work for all currently listed cases. We clearly need the MN and the L= MA to be in synch with respect to the configured policy. How, that is done,= I guess we will not try to know. I thought even in 3GPP, this is the impl= ied assumption ? But, this is for you to clarify. Not specifically for IFOM= where UE and PDN GW/HA are negotiating the flow policies, but generally th= at the PDN GW and the ANDSF policy server will have synchronized policies. = The MAG and the LMA have the ability to carry this flow policy information = in signaling messages and influence the access selection. The policy is a o= paque object, with extensible formats, when carried in the signaling plane,= should allow the LMA/MAG to apply those access policies, while assuming MN= is following the same rules. These policies can surely reflect the specifi= c WLAN access/operator specific rule. I'm surely with you, the lack of MN-A= R interface is surely an issue and I see that. But, we need to understand, = what are the limitations with the approach of out of band policy interface= s and what will be the solution limitations. If we need to tie the flow mov= ement at the prefix granularity and rely on the natural ND interface in the= form of RA PIO option, more like PDN offload in MAPCON, or at the granular= ity of a flow level, is open for discussion. I want to simplify this draft = for sure, we can surely discuss each of these issues on the WG draft. Regards Sri On 2/1/11 8:29 PM, "stefano faccin" > wrote: Sri, thanks for the reply. I'd like to comment on the "the flow policy decisions need not be based on = the specific WLAN network". Does it mean, as I believe it does, that the cu= rrent solution would not allow an operator deploying such solution to decid= e to route flows over a specific WLAN or not depending on which specific WL= AN the MN is connected to? E.g. the operator or the entity in control of th= e decisions for the routing may want to direct certain traffic always over = WLANs that the operator deploys, and instead route only some of the traffic= over WLANs of roaming partners or of the MN user home. How does this solut= ion support that scenario if the LMA is not told specifically which WLAN th= e MN is connected to? From a deployment point of view, I do not believe we = can afford to leave out this scenario. Please note that the establishment o= f a security relationship between the MN and the MAG, and a specific MAG id= entity, cannot guarantee that the LMA knows which specific WLAN access netw= ork the MN is connected to. Assuming that would severely restrict the deplo= yment scenarios. As for the MN and the LMA being magically in synch, I am very concerned abo= ut a "glass ball" solution. You mention ANDSF defined by 3GPP as a solution= for this "out of band" delivery of policy. Fair enough, however there is a= n issue with that. ANDSF is designed specific to be a MN-centric solution w= here policies are provisioned in the MN and the MN decides which network te= chnologies and access networks it needs to connect to, under what condition= s, and which IP traffic needs to be routed on such accesses. No IP point of= attachment in the network (i.e. the PDN GW in 3GPP that is the LMA in PMIP= v6) is aware under any conditions of such policy. Therefore, even if in ord= er to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would unfor= tunately not provide a solution unless the MN can communicate to the MAG an= d the LMA the decisions the MN has taken based on the ANDSF policies. I believe the key point here is that we need to understand how the solution= can be realistically applied to a real scenario, and that we need to ensur= e that important and realistic deployment scenarios are not excluded by the= solution. Cheers, Stefano On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli > wrote: Hi Stefano: These are valid points and some good comments. Let me share my thoughts. Carlo's draft is not assuming any new MN-AR interface. Its going with the a= ssumption there is established policy on the mobile and on the LMA, which a= llows the mobile to select the access network at a flow level granularity, = without requiring any explicit signaling between the MAG and the MN. To lar= ge part this is all about out of band policy interface, such as ANDSF, towa= rds the UE, leading to the assumption that magically the MN and the LMA are= in sync with respect to flow policies, access selection and they will make= the right forwarding decision. Secondly, the flow policy decisions need no= t be based on the specific WLAN network, but it is implicitly driven by the= MAG - LMA security relation, where the MAG attachment to the WLAN network = transitively allows the LMA to make the flow policy decisions based on the = MAG identity. If the WLAN network is not trusted, there is truly no MAG in = that network, where the LMA shares a security relation with that node. There are still some open issues on this draft that needs to be discussed i= n the WG. On the approaches to allow more a flow aggregate movement, that = is a discussion point. There are issues that we need to discuss, supporting= split link model, or eliminating some favorite brand of signaling message = (FMA) and riding on PBU/PBA and just with one FMI trigger, and on the aspec= ts around MN applying the flow policies by flow mirroring. We have no agree= ment on those issues yet. Its just a base draft, for further discussion and resolving those issues. B= ut, hope that is not a stopper for base draft selection. Sri On 2/1/11 6:39 PM, "stefano faccin" > wrote: Raj, thanks for the email. I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere). I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability. In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicat= e to the network where the flows should be routed or for the LMA to receive= somehow from somewhere some policies, the solution cannot really provide f= low mobility since there is no way to decide which flows are routed where. = If we are thinking about a host-based solution, I have not yet seen a solut= ion as to how the host can indicate to the MAG and ultimately to the MAG wh= ich flows should be routed on each access. If we are relying on modificatio= ns of layer 2 protocols, aren't we defining a solution that works only with= some technologies (since for other access technologies it is rather unreal= istic to modify L2 for IP flow mobility purposes)? If we are thinking of an= LMA-based solution, can we hear of at least one example of a real-life sce= nario where the LMA would receive such policies, and how such delivery woul= d happen? Also, should there be a solution to have policies in the LMA, how= does the LMA actually decide to route flows on one access or the other? E.= g., if some flows need to be routed on certain WLAN networks, but shall not= be routed on other WLAN networks, how does the LMA know which specific WLA= N network the host is connected to? Perhaps I missed the ability for the MA= G to know e.g. the WLAN SSID and provide it to the LMA, in which case I wou= ld appreciate if somebody could highlight to me where that is defined. I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important. Cheers, Stefano On Tue, Feb 1, 2011 at 3:47 PM, > wrote: Hello, We have discussed the flow mobility solutions for Proxy MIP6 previously at IETFs 78 and 79. This is a consensus call for adopting this I-D: draft-bernardos-netext-pmipv6-flowmob-02 as the working group document. I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt The consensus call will expire on Feb 15th, 2011. Please indicate your support or concerns in adopting this I-D as the WG baseline document on the mailing list. Please note that this I-D will serve as the baseline in the WG and will be developed further based on input and feedback from WG members. -Basavaraj _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext --_000_E5E9FF33C2A27043B3BC96FE5A5160F101B7DEnasanexd01enaqual_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmi= pv6-flowmob as WG doc

Hi Sri,

 

Conformance tests can be used to make sure the UE behaves ac= cordingly. So no need for the PDN GW to perform any validation.<= /span>

 

Cheers

Gerardo

 

From: Sri Gund= avelli [mailto:sgundave@cisco.com]
Sent: Thursday, February 03, 2011 2:55 PM
To: Giaretta, Gerardo; stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-n= etext-pmipv6-flowmob as WG doc

 

Hi Gerardo,

Sure, for supporting the specific scenario, the draft is making that assump= tion. This does come at a cost for the operator having to ensure synchroniz= ed policies between the ANDSF server and the PDN GW. But, my question still= remains, how in IFOM, a PDN GW can ever authorize and establish the flow policies requested by the UE. It= needs the access to same policy that the operator configured on the ANDSF = server. Else, its all in the mercy of the UE with no network side validatio= n. There can be all the needed information elements, around UE location, or network attachment in the protocol signal= ing, directly from the UE in IFOM, but fundamentally the PDN GW needs acces= s to the same policy. I do agree, this assumption is an administrative over= head.


Regards
Sri



On 2/2/11 9:13 PM, "Giaretta, Gerardo" <gerardog@qualcomm.com> wrote:

Hi Sri,
 
There is no implicit assumption of synchronized policies. A basic example t= hat shows that there is no assumption is the following: ANDSF policies may = be based also on location of the UE. For example the UE should prefer WLAN = only in a given location. When the UE is attached over WLAN there is no way for the PDNGW/HA to verify the lo= cation of the UE and therefore to verify UE actions based on policies.
 
The assumption on synchronization of policies is only applicable to this dr= aft and I think it is a wrong one.
 
Cheers
Gerardo
 

From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Sri Gundavelli
Sent: Wednesday, February 02, 2011 6:50 PM
To: stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-n= etext-pmipv6-flowmob as WG doc

Hi Stefano,

One comment.

Agree with you there is no ANDSF interface to the network node, but the ass= umption of synchronized policies between the ANDSF server and the PDN GW/HA= is there, implicitly IMO. With out this assumption, I do not know, how the= HA can ever validate the flow mobility options received in the BU. If the operator requires any control on enforc= ing a flow policy rule, the PDN GW/HA needs to have synchronized policies, = without which its always the client decision. I’m not sure, operators= in 3GPP would like that :)

No doubt, the lack of MN-AR interface is surely an issue for supporting com= plex flow policies. I realize the issues and I agree with you. But, the ass= umption of synchronized policies can offer some solution with some configur= ation requirement on the HA (assuming there are no other issues). There are also the proposals on flow mirroring= on the UE ..., requiring no flow policies. I’ve not evaluated this, = however. Folks can comment on this.

It is also to be noted, for some of the scenarios such, there is no flow po= licy interface needed. We can identify what scenarios create any configurat= ion limitations on the HA and which one’s do not . As I’ve note= d earlier, this is surely an open issue, that we need to discuss in the WG.



Regards
Sri




 


On 2/2/11 9:08 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:
Sri,
thanks for the reply. Can you clarify in which system or scenario ANDSF is = available to network entities as well? There is no such availability in 3GP= P, and making such information available would require considerable archite= ctural changes, therefore the applicability of this solution to what seems to be the only realistic scenario hinges on= 3GPP making considerable architectural changes. I would therefore not be s= o hastily concluding that the ANDSF information is available to the LMA and= underestimate what it would really take to make the solution applicable.

If we cannot guarantee that there is at least one realistic solution to hav= e the MNa nd LMA in synch, how do we expect that this solution is applicabl= e at all? In 3GPP there is no need to have such implicit assumption, be cau= se 1) the MN is provided policies explicitly through the ANDSF, and 2) it is the MN and only the MN that mak= es IP flow mobility decisions and communicates them explicitly (with well d= efined signalling) to the LMA, and therefore no magic is needed. There is n= o need in 3GPP to have the ANDSF and PDN GW policies synchronized, since the PDN GW does not use such polic= ies.

Sri, in the end it is a matter of whether we develop a solution that will r= ely on some unknown magic to be deployed, or a solution that we know can be= deployed in at least one way because there are solutions to what I conside= r major open issues.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli <sgundave@cisco.com> wrote:
Hi Stefano,

Thanks for the discussion.

As you say, the ANDSF policies are allowing the MN a.) to make the right ne= twork attachment decision and b.) make the access selection on a flow basis= . This same policy that is present in the ANDSF server, is available for th= e network nodes as well. I’m not sure, with out this assumption the solution can work for all currently lis= ted cases. We clearly need the MN and the LMA to be in synch with respect t= o the configured policy. How, that is done, I guess we will not try to know= .  I thought even in 3GPP, this is the implied assumption ? But, this is for you to clarify. Not specifica= lly for IFOM where UE and PDN GW/HA are negotiating the flow policies, but = generally that the PDN GW and the ANDSF policy server will have synchronize= d policies. The MAG and the LMA have the ability to carry this flow policy information in signaling messag= es and influence the access selection. The policy is a opaque object, with = extensible formats, when carried in the signaling plane, should allow the L= MA/MAG to apply those access policies, while assuming MN is following the same rules. These policies can surely r= eflect the specific WLAN access/operator specific rule. I’m surely wi= th you, the lack of MN-AR interface is surely an issue and I see that. But,= we need to understand, what are the limitations with the approach of  out of band policy interfaces and what will be = the solution limitations. If we need to tie the flow movement at the prefix= granularity and rely on the natural ND interface in the form of RA PIO opt= ion, more like PDN offload in MAPCON, or at the granularity of a flow level, is open for discussion. I want to s= implify this draft for sure, we can surely discuss each of these issues on = the WG draft.


Regards
Sri






On 2/1/11 8:29 PM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com> > wrote:
Sri,
thanks for the reply.

I'd like to comment on the "the flow policy decisions need not be base= d on the specific WLAN network". Does it mean, as I believe it does, t= hat the current solution would not allow an operator deploying such solutio= n to decide to route flows over a specific WLAN or not depending on which specific WLAN the MN is connected to? E.g. = the operator or the entity in control of the decisions for the routing may = want to direct certain traffic always over WLANs that the operator deploys,= and instead route only some of the traffic over WLANs of roaming partners or of the MN user home. How doe= s this solution support that scenario if the LMA is not told specifically w= hich WLAN the MN is connected to? From a deployment point of view, I do not= believe we can afford to leave out this scenario. Please note that the establishment of a security relati= onship between the MN and the MAG, and a specific MAG identity, cannot guar= antee that the LMA knows which specific WLAN access network the MN is conne= cted to. Assuming that would severely restrict the deployment scenarios.

As for the MN and the LMA being magically in synch, I am very concerned abo= ut a "glass ball" solution. You mention ANDSF defined by 3GPP as = a solution for this "out of band" delivery of policy. Fair enough= , however there is an issue with that. ANDSF is designed specific to be a MN-centric solution where policies are provisioned in the= MN and the MN decides which network technologies and access networks it ne= eds to connect to, under what conditions, and which IP traffic needs to be = routed on such accesses. No IP point of attachment in the network (i.e. the PDN GW in 3GPP that is the LMA in P= MIPv6) is aware under any conditions of such policy. Therefore, even if in = order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would un= fortunately not provide a solution unless the MN can communicate to the MAG and the LMA the decisions the MN = has taken based on the ANDSF policies.

I believe the key point here is that we need to understand how the solution= can be realistically applied to a real scenario, and that we need to ensur= e that important and realistic deployment scenarios are not excluded by the= solution.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli <sgundave@cisco.com <htt= p://sgundave@cisco.com> > wrote:
Hi Stefano:

These are valid points and some good comments. Let me share my thoughts.
Carlo’s draft is not assuming any new MN-AR interface. Its going with= the assumption there is established policy on the mobile and on the LMA, w= hich allows the mobile to select the access network at a flow level granula= rity, without requiring any explicit signaling between the MAG and the MN. To large part this is all about out of band po= licy interface, such as ANDSF, towards the UE, leading to the assumption th= at magically the MN and the LMA are in sync with respect to flow policies, = access selection and they will make the right forwarding decision. Secondly, the flow policy decisions need no= t be based on the specific WLAN network, but it is implicitly driven by the= MAG – LMA security relation, where the MAG attachment to the WLAN ne= twork transitively allows the LMA to make the flow policy decisions based on the MAG identity. If the WLAN network i= s not trusted, there is truly no MAG in that network, where the LMA shares = a security relation with that node.

There are still some open issues on this draft that needs to be discussed i= n the WG.  On the approaches to allow more a flow aggregate movement, = that is a discussion point. There are issues that we need to discuss, suppo= rting split link model, or eliminating some favorite brand of signaling message (FMA) and riding on PBU/PBA and j= ust with one FMI trigger, and on the aspects around MN applying the flow po= licies by flow mirroring. We have no agreement on those issues yet.

Its just a base draft, for further discussion and resolving those issues. B= ut, hope that is not a stopper for base draft selection.


Sri






On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com>  <http://sfaccinstd@gmail.com> > wrote:
Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicat= e to the network where the flows should be routed or for the LMA to receive= somehow from somewhere some policies, the solution cannot really provide flow mobility since there is no way to = decide which flows are routed where. If we are thinking about a host-based = solution, I have not yet seen a solution as to how the host can indicate to= the MAG and ultimately to the MAG which flows should be routed on each access. If we are relying on modifica= tions of layer 2 protocols, aren't we defining a solution that works only w= ith some technologies (since for other access technologies it is rather unr= ealistic to modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-based solution, can we he= ar of at least one example of a real-life scenario where the LMA would rece= ive such policies, and how such delivery would happen? Also, should there b= e a solution to have policies in the LMA, how does the LMA actually decide to route flows on one access or = the other? E.g., if some flows need to be routed on certain WLAN networks, = but shall not be routed on other WLAN networks, how does the LMA know which= specific WLAN network the host is connected to? Perhaps I missed the ability for the MAG to know e.g. the= WLAN SSID and provide it to the LMA, in which case I would appreciate if s= omebody could highlight to me where that is defined.

I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important.

Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM,  <Basavaraj.Patil@nokia.com <http://Basavaraj.Patil@nokia.com>  <http://Basavaraj.Patil@nokia.com> > wrote:

Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= br> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= br> developed further based on input and feedback from WG members.

-Basavaraj

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

 
 

--_000_E5E9FF33C2A27043B3BC96FE5A5160F101B7DEnasanexd01enaqual_-- From sfaccin@rim.com Thu Feb 3 14:58:33 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 454303A6B37 for ; Thu, 3 Feb 2011 14:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.634 X-Spam-Level: X-Spam-Status: No, score=-4.634 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrdwWMHx9Ruz for ; Thu, 3 Feb 2011 14:58:12 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id EBA1A3A6B25 for ; Thu, 3 Feb 2011 14:58:11 -0800 (PST) X-AuditID: 0a666446-b7ba6ae0000051d3-10-4d4b33cd9c11 Received: from XCH138CNC.rim.net ( [10.65.20.127]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 46.CA.20947.DC33B4D4; Thu, 3 Feb 2011 18:01:33 -0500 (EST) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH138CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Feb 2011 18:01:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CBC3F6.4B63BD0B" Date: Thu, 3 Feb 2011 17:01:30 -0600 Message-ID: <680854867F7FD04BB9B06EB8ACA8D5AC05E1F0CB@XCH02DFW.rim.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLwmpURzmRlysrlUidlexdQorGZJPuBh2AgAAR4ICAAAzJgIAACkaAgADJ5gCAAKKGAP//oT5wgAEesLCAAAq77oAAADZg References: <680854867F7FD04BB9B06EB8ACA8D5AC05E1F0A3@XCH02DFW.rim.net> From: "Stefano Faccin" To: "Sri Gundavelli" , "Giaretta, Gerardo" , "stefano faccin" X-OriginalArrivalTime: 03 Feb 2011 23:01:33.0670 (UTC) FILETIME=[4D50C060:01CBC3F6] X-Brightmail-Tracker: AAAABgAAAZEXVB72F1QozBdUKM0XVCjOF1TWuQ== Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 03 Feb 2011 22:58:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC3F6.4B63BD0B Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CBC3F6.4B63BD0B" ------_=_NextPart_002_01CBC3F6.4B63BD0B Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Sri, I am glad to hear that you also think that the network-based flow mobility solution cannot intrinsically provide all the features of the client-based approach. I am also glad that you hear that access selection solutions in place today are sci-fi. Why do you believe that an operator that wants e.g. to move the voice traffic and video streaming to the WLAN APs it deploys (because it can offload them and can control QoS) may not want to move the same flows to a WLAN in a hotel where the user will get an awful user experience? Another example: policies may be configured by an enterprise in the device so that the enterprise will allow the MN to direct some traffic on certain WLAN APs (e.g. the one the enterprise deploys) but not on other WLAN APs. I think the per-access network scenarios are indeed more than realistic. Perhaps we're trying to oversimplify the scenarios just to fit the solution in them? Stefano Faccin Standards Manager Research In Motion Corporation 5000 Riverside Drive Building 6, Brazos East, Ste. 100 Irving, Texas 75039 USA Office: (972) 910 3451 Internal: 820.63451 : (510) 230 8422 www.rim.com ; www.blackberry.com P Consider the environment before printing. From: Sri Gundavelli [mailto:sgundave@cisco.com] Sent: Thursday, February 03, 2011 2:56 PM To: Stefano Faccin; Giaretta, Gerardo; stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Hi Stefano, My point on the synchronized policy assumption still remains, as I've noted in the other thread. Therefore, if we want to provide a protocol for network based flow mobility to provide an alternative to existing solutions, we need to provide a solution that realistically provides the same functionality. I will probably take a defensive stand on this. As I've stated before, I do not believe network-based mobility approaches can match client based approaches 1:1, in every aspect. Its simply not possible, specially when we don't have the needed MN-AR interface argument, for carrying Attachment Preferences. But, most of the features that are practical from deployment perspective (unlike some of the complex flow mobility scenarios, complexity in the order of science fiction moves :)), every thing else can be achieved over network-based approaches, with out any MN-AR interface. Hence, my argument to keep the specs simple As as for simplified policies versus what current solutions already provide (e.g. per access network policy and not just per access technology), why should we go ahead with a solution that brings us back in time wrt what we can provide to users and operators? Please note that even today (and not just future releases of 3GPP or future IETF protocols) there are deployment scenarios where the decisions to choose or not whether to route traffic over a certain WLAN is based on the specific WLAN (e.g. SSID) and not just on the fact that the MN is connected to WLAN. To large part, in the context of trusted non-3GPP access, basic flow mobility functions can be supported. We can break this down and bring some of the aspects around network ownership, cost parameters and tie the flow policy rules to it. But, I don't think the goal is to support all such features. Regards Sri On 2/3/11 2:22 PM, "Stefano Faccin" wrote: Hi Sri, I need to agree with the Gerardo. You are making an assumption that is incorrect.Synchronizing policies between the MN and the LMA is not an easy and scalable solution. I understand synchronizing policies between a MN and a policy server that is the only repository for a given MN (i.e. one MN has its policy in a single policy server). Assuming that all the LMAs in a network that the MN can be connected to have synchronized policies with the MN is clearly not realistic. As as for simplified policies versus what current solutions already provide (e.g. per access network policy and not just per access technology), why should we go ahead with a solution that brings us back in time wrt what we can provide to users and operators? Please note that even today (and not just future releases of 3GPP or future IETF protocols) there are deployment scenarios where the decisions to choose or not whether to route traffic over a certain WLAN is based on the specific WLAN (e.g. SSID) and not just on the fact that the MN is connected to WLAN. Therefore, if we want to provide a protocol for network based flow mobility to provide an alternative to existing solutions, we need to provide a solution that realistically provides the same functionality. Cheers, Stefano Faccin Standards ManagerResearch In Motion Corporation 5000 Riverside Drive Building 6, Brazos East, Ste. 100Irving, Texas 75039 USA Office: (972) 910 3451 Internal: 820.63451: (510) 230 8422www.rim.com ; www.blackberry.com P Consider the environment before printing. From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Giaretta, Gerardo Sent: Wednesday, February 02, 2011 9:14 PM To: Sri Gundavelli; stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Hi Sri, There is no implicit assumption of synchronized policies. A basic example that shows that there is no assumption is the following: ANDSF policies may be based also on location of the UE. For example the UE should prefer WLAN only in a given location. When the UE is attached over WLAN there is no way for the PDNGW/HA to verify the location of the UE and therefore to verify UE actions based on policies. The assumption on synchronization of policies is only applicable to this draft and I think it is a wrong one. Cheers Gerardo From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Sri Gundavelli Sent: Wednesday, February 02, 2011 6:50 PM To: stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Hi Stefano, One comment. Agree with you there is no ANDSF interface to the network node, but the assumption of synchronized policies between the ANDSF server and the PDN GW/HA is there, implicitly IMO. With out this assumption, I do not know, how the HA can ever validate the flow mobility options received in the BU. If the operator requires any control on enforcing a flow policy rule, the PDN GW/HA needs to have synchronized policies, without which its always the client decision. I'm not sure, operators in 3GPP would like that :) No doubt, the lack of MN-AR interface is surely an issue for supporting complex flow policies. I realize the issues and I agree with you. But, the assumption of synchronized policies can offer some solution with some configuration requirement on the HA (assuming there are no other issues). There are also the proposals on flow mirroring on the UE ..., requiring no flow policies. I've not evaluated this, however. Folks can comment on this. It is also to be noted, for some of the scenarios such, there is no flow policy interface needed. We can identify what scenarios create any configuration limitations on the HA and which one's do not . As I've noted earlier, this is surely an open issue, that we need to discuss in the WG. Regards Sri On 2/2/11 9:08 AM, "stefano faccin" wrote: Sri, thanks for the reply. Can you clarify in which system or scenario ANDSF is available to network entities as well? There is no such availability in 3GPP, and making such information available would require considerable architectural changes, therefore the applicability of this solution to what seems to be the only realistic scenario hinges on 3GPP making considerable architectural changes. I would therefore not be so hastily concluding that the ANDSF information is available to the LMA and underestimate what it would really take to make the solution applicable. If we cannot guarantee that there is at least one realistic solution to have the MNa nd LMA in synch, how do we expect that this solution is applicable at all? In 3GPP there is no need to have such implicit assumption, be cause 1) the MN is provided policies explicitly through the ANDSF, and 2) it is the MN and only the MN that makes IP flow mobility decisions and communicates them explicitly (with well defined signalling) to the LMA, and therefore no magic is needed. There is no need in 3GPP to have the ANDSF and PDN GW policies synchronized, since the PDN GW does not use such policies. Sri, in the end it is a matter of whether we develop a solution that will rely on some unknown magic to be deployed, or a solution that we know can be deployed in at least one way because there are solutions to what I consider major open issues. Cheers, Stefano On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli wrote: Hi Stefano, Thanks for the discussion. As you say, the ANDSF policies are allowing the MN a.) to make the right network attachment decision and b.) make the access selection on a flow basis. This same policy that is present in the ANDSF server, is available for the network nodes as well. I'm not sure, with out this assumption the solution can work for all currently listed cases. We clearly need the MN and the LMA to be in synch with respect to the configured policy. How, that is done, I guess we will not try to know. I thought even in 3GPP, this is the implied assumption ? But, this is for you to clarify. Not specifically for IFOM where UE and PDN GW/HA are negotiating the flow policies, but generally that the PDN GW and the ANDSF policy server will have synchronized policies. The MAG and the LMA have the ability to carry this flow policy information in signaling messages and influence the access selection. The policy is a opaque object, with extensible formats, when carried in the signaling plane, should allow the LMA/MAG to apply those access policies, while assuming MN is following the same rules. These policies can surely reflect the specific WLAN access/operator specific rule. I'm surely with you, the lack of MN-AR interface is surely an issue and I see that. But, we need to understand, what are the limitations with the approach of out of band policy interfaces and what will be the solution limitations. If we need to tie the flow movement at the prefix granularity and rely on the natural ND interface in the form of RA PIO option, more like PDN offload in MAPCON, or at the granularity of a flow level, is open for discussion. I want to simplify this draft for sure, we can surely discuss each of these issues on the WG draft. Regards Sri On 2/1/11 8:29 PM, "stefano faccin" > wrote: Sri, thanks for the reply. I'd like to comment on the "the flow policy decisions need not be based on the specific WLAN network". Does it mean, as I believe it does, that the current solution would not allow an operator deploying such solution to decide to route flows over a specific WLAN or not depending on which specific WLAN the MN is connected to? E.g. the operator or the entity in control of the decisions for the routing may want to direct certain traffic always over WLANs that the operator deploys, and instead route only some of the traffic over WLANs of roaming partners or of the MN user home. How does this solution support that scenario if the LMA is not told specifically which WLAN the MN is connected to? From a deployment point of view, I do not believe we can afford to leave out this scenario. Please note that the establishment of a security relationship between the MN and the MAG, and a specific MAG identity, cannot guarantee that the LMA knows which specific WLAN access network the MN is connected to. Assuming that would severely restrict the deployment scenarios. As for the MN and the LMA being magically in synch, I am very concerned about a "glass ball" solution. You mention ANDSF defined by 3GPP as a solution for this "out of band" delivery of policy. Fair enough, however there is an issue with that. ANDSF is designed specific to be a MN-centric solution where policies are provisioned in the MN and the MN decides which network technologies and access networks it needs to connect to, under what conditions, and which IP traffic needs to be routed on such accesses. No IP point of attachment in the network (i.e. the PDN GW in 3GPP that is the LMA in PMIPv6) is aware under any conditions of such policy. Therefore, even if in order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would unfortunately not provide a solution unless the MN can communicate to the MAG and the LMA the decisions the MN has taken based on the ANDSF policies. I believe the key point here is that we need to understand how the solution can be realistically applied to a real scenario, and that we need to ensure that important and realistic deployment scenarios are not excluded by the solution. Cheers, Stefano On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli > wrote: Hi Stefano: These are valid points and some good comments. Let me share my thoughts. Carlo's draft is not assuming any new MN-AR interface. Its going with the assumption there is established policy on the mobile and on the LMA, which allows the mobile to select the access network at a flow level granularity, without requiring any explicit signaling between the MAG and the MN. To large part this is all about out of band policy interface, such as ANDSF, towards the UE, leading to the assumption that magically the MN and the LMA are in sync with respect to flow policies, access selection and they will make the right forwarding decision. Secondly, the flow policy decisions need not be based on the specific WLAN network, but it is implicitly driven by the MAG - LMA security relation, where the MAG attachment to the WLAN network transitively allows the LMA to make the flow policy decisions based on the MAG identity. If the WLAN network is not trusted, there is truly no MAG in that network, where the LMA shares a security relation with that node. There are still some open issues on this draft that needs to be discussed in the WG. On the approaches to allow more a flow aggregate movement, that is a discussion point. There are issues that we need to discuss, supporting split link model, or eliminating some favorite brand of signaling message (FMA) and riding on PBU/PBA and just with one FMI trigger, and on the aspects around MN applying the flow policies by flow mirroring. We have no agreement on those issues yet. Its just a base draft, for further discussion and resolving those issues. But, hope that is not a stopper for base draft selection. Sri On 2/1/11 6:39 PM, "stefano faccin" > wrote: Raj, thanks for the email. I need to apologize in advance if my questions have already been answered before (though I cannot find a conclusive answer anywhere). I think that a protocol that is developed in NETEXT (or other groups) should have at least a potential realistic scenario for applicability. In terms of applicability, though it is not part of the protocol definition per se, unless there are solutions in place for either the host to indicate to the network where the flows should be routed or for the LMA to receive somehow from somewhere some policies, the solution cannot really provide flow mobility since there is no way to decide which flows are routed where. If we are thinking about a host-based solution, I have not yet seen a solution as to how the host can indicate to the MAG and ultimately to the MAG which flows should be routed on each access. If we are relying on modifications of layer 2 protocols, aren't we defining a solution that works only with some technologies (since for other access technologies it is rather unrealistic to modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-based solution, can we hear of at least one example of a real-life scenario where the LMA would receive such policies, and how such delivery would happen? Also, should there be a solution to have policies in the LMA, how does the LMA actually decide to route flows on one access or the other? E.g., if some flows need to be routed on certain WLAN networks, but shall not be routed on other WLAN networks, how does the LMA know which specific WLAN network the host is connected to? Perhaps I missed the ability for the MAG to know e.g. the WLAN SSID and provide it to the LMA, in which case I would appreciate if somebody could highlight to me where that is defined. I think that, though not integral to the protocol specification, understanding what framework the protocol would/needs to fit in is rather important. Cheers, Stefano On Tue, Feb 1, 2011 at 3:47 PM, > wrote: Hello, We have discussed the flow mobility solutions for Proxy MIP6 previously at IETFs 78 and 79. This is a consensus call for adopting this I-D: draft-bernardos-netext-pmipv6-flowmob-02 as the working group document. I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt The consensus call will expire on Feb 15th, 2011. Please indicate your support or concerns in adopting this I-D as the WG baseline document on the mailing list. Please note that this I-D will serve as the baseline in the WG and will be developed further based on input and feedback from WG members. -Basavaraj _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_002_01CBC3F6.4B63BD0B Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable Re: [netext] Consensus call to adopt I-D: draft-b= ernardos-netext-pmipv6-flowmob as WG doc

Sri,

I am glad to hear that you also thi= nk that the network-based flow mobility solution cannot intrinsically provid= e all the features of the client-based approach.

 

I am also glad that you hear that access selection solutions in place today= are sci-fi. Why do you believe that an operator that wants e.g. to move the= voice traffic and video streaming to the WLAN APs it deploys (because it ca= n offload them and can control QoS) may not want to move the same flows to a= WLAN in a hotel where the user will get an awful user experience? Another e= xample: policies may be configured by an enterprise in the device so that th= e enterprise will allow the MN to direct some traffic on certain WLAN APs (e= .g. the one the enterprise deploys) but not on other WLAN APs. I think the p= er-access network scenarios are indeed more than realistic. Perhaps we’= ;re trying to oversimplify the scenarios just to fit the solution in them?

 

<= div>

Stefano Faccin

 <= /o:p>

Standards Manager

Research In Motion Corporation<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:blac= k'>
5000 Riverside Drive
Building 6, Brazos East, Ste. 100

Irving, Texas 75039 USA
= Office: (972) 910 3451 

= Internal: 820.63451

3DUntitled-1: (510) 230 8422

www.rim.com; ww= w.blackberry.com

3D"cid:image004.png@01CB49=

 

P Consi= der the environment before printing.

 

From: Sri Gundavelli [mailto:sgundave@cisco.com]
Sent:= Thursday, February 03, 2011 2:56 PM
To: Stefano Faccin; Giaretta,= Gerardo; stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@noki= a.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-ber= nardos-netext-pmipv6-flowmob as WG doc

 

Hi Stefano,

My point on the synchronized policy assumption stil= l remains, as I’ve noted in the other thread.

Therefore, if we want to provide a protocol for network based f= low mobility to provide an alternative to existing solutions, we need to pro= vide a solution that realistically provides the same functionality.

I will probably take a defensive stand on this. As I’ve stated= before, I do not believe network-based mobility approaches can match client= based approaches 1:1, in every aspect. Its simply not possible, specially w= hen we don’t have the needed MN-AR interface argument, for carrying At= tachment Preferences. But, most of the features that are practical from depl= oyment perspective (unlike some of the complex flow mobility scenarios, comp= lexity in the order of science fiction moves :)), every thing else can be ac= hieved over network-based approaches, with out any MN-AR interface. Hence, m= y argument to keep the specs simple
 
As as for simplified policies versus what current solutions already prov= ide (e.g. per access network policy and not just per access technology), why= should we go ahead with a solution that brings us back in time wrt what we= can provide to users and operators? Please note that even today (and= not just future releases of 3GPP or future IETF protocols) there are deploy= ment scenarios where the decisions to choose or not whether to route traffic= over a certain WLAN is based on the specific WLAN (e.g. SSID) and not just= on the fact that the MN is connected to WLAN.

To large part,= in the context of trusted non-3GPP access, basic flow mobility functions ca= n be supported. We can break this down and bring some of the aspects around= network ownership, cost parameters and tie the flow policy rules to it. But= , I don’t think the goal is to support all such features.


<= br>Regards
Sri



On 2/3/11 2:22 PM, "Stefano Faccin&quo= t; <sfaccin@rim.com> wrote:

Hi Sri,
I need to agree with the Ge= rardo. You are making an assumption that is incorrect.Synchronizing policies= between the MN and the LMA is not an easy and scalable solution. I understa= nd synchronizing policies between a MN and a policy server that is the only= repository for a given MN (i.e. one MN has its policy in a single policy se= rver). Assuming that all the LMAs in a network that the MN can be connected= to have synchronized policies with the MN is clearly not realistic.

= As as for simplified policies versus what current solutions already provide= (e.g. per access network policy and not just per access technology), why sh= ould we go ahead with a solution that brings us back in time wrt what we can= provide to users and operators? Please note that even today (and not= just future releases of 3GPP or future IETF protocols) there are deployment= scenarios where the decisions to choose or not whether to route traffic ove= r a certain WLAN is based on the specific WLAN (e.g. SSID) and not just on t= he fact that the MN is connected to WLAN.
 
Therefore, if we wan= t to provide a protocol for network based flow mobility to provide an altern= ative to existing solutions, we need to provide a solution that realisticall= y provides the same functionality.
 
Cheers,
 
Stefan= o Faccin Standards ManagerResearch In Motion Corporation
5000 River= side Drive
Building 6, Brazos East, Ste. 100Irving, Texas 75039 USA
= Office: (972) 910 3451  Internal: 820.63451:= (510) 230 8422www.rim.com <outbind://28-00= 000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB00= 0001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.rim.com&g= t; ; www.blackberry.com <outbind://2= 8-00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259= AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.black= berry.com>
<http://www.bl= ackberry.com/>

P Consider the e= nvironment before printing.


From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Giar= etta, Gerardo
Sent: Wednesday, February 02, 2011 9:14 PM
To:= Sri Gundavelli; stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil= @nokia.com
Subject: Re: [netext] Consensus call to adopt I-D:= draft-bernardos-netext-pmipv6-flowmob as WG doc

Hi Sr= i,
 
There is no implicit assumption of synchronized policies. A= basic example that shows that there is no assumption is the following: ANDS= F policies may be based also on location of the UE. For example the UE shoul= d prefer WLAN only in a given location. When the UE is attached over WLAN th= ere is no way for the PDNGW/HA to verify the location of the UE and therefor= e to verify UE actions based on policies.
 
The assumption on syn= chronization of policies is only applicable to this draft and I think it is= a wrong one.
 
Cheers
Gerardo
 

From:<= /b> netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf= Of Sri Gundavelli
Sent: Wednesday, February 02, 2011 6:50 PM<= br>To: stefano faccin
Cc: netex= t@ietf.org; Basavaraj.Patil@nokia.= com
Subject: Re: [netext] Consensus call to adopt I-D: draft-b= ernardos-netext-pmipv6-flowmob as WG doc

Hi Stefano,

One commen= t.

Agree with you there is no ANDSF interface to the network node, bu= t the assumption of synchronized policies between the ANDSF server and the P= DN GW/HA is there, implicitly IMO. With out this assumption, I do not know,= how the HA can ever validate the flow mobility options received in the BU.= If the operator requires any control on enforcing a flow policy rule, the P= DN GW/HA needs to have synchronized policies, without which its always the c= lient decision. I’m not sure, operators in 3GPP would like that :)
No doubt, the lack of MN-AR interface is surely an issue for supporting= complex flow policies. I realize the issues and I agree with you. But, the= assumption of synchronized policies can offer some solution with some confi= guration requirement on the HA (assuming there are no other issues). There a= re also the proposals on flow mirroring on the UE ..., requiring no flow pol= icies. I’ve not evaluated this, however. Folks can comment on this.
It is also to be noted, for some of the scenarios such, there is no flo= w policy interface needed. We can identify what scenarios create any configu= ration limitations on the HA and which one’s do not . As I’ve no= ted earlier, this is surely an open issue, that we need to discuss in the WG= .



Regards
Sri




 


On 2/2= /11 9:08 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:
Sri,
thanks for the reply. Can yo= u clarify in which system or scenario ANDSF is available to network entities= as well? There is no such availability in 3GPP, and making such information= available would require considerable architectural changes, therefore the a= pplicability of this solution to what seems to be the only realistic scenari= o hinges on 3GPP making considerable architectural changes. I would therefor= e not be so hastily concluding that the ANDSF information is available to th= e LMA and underestimate what it would really take to make the solution appli= cable.

If we cannot guarantee that there is at least one realistic so= lution to have the MNa nd LMA in synch, how do we expect that this solution= is applicable at all? In 3GPP there is no need to have such implicit assump= tion, be cause 1) the MN is provided policies explicitly through the ANDSF,= and 2) it is the MN and only the MN that makes IP flow mobility decisions a= nd communicates them explicitly (with well defined signalling) to the LMA, a= nd therefore no magic is needed. There is no need in 3GPP to have the ANDSF= and PDN GW policies synchronized, since the PDN GW does not use such polici= es.

Sri, in the end it is a matter of whether we develop a solution= that will rely on some unknown magic to be deployed, or a solution that we= know can be deployed in at least one way because there are solutions to wha= t I consider major open issues.

Cheers,
Stefano

On Tue, Feb= 1, 2011 at 9:06 PM, Sri Gundavelli <sgund= ave@cisco.com> wrote:
Hi Stefano,

Thanks for the discussion= .

As you say, the ANDSF policies are allowing the MN a.) to make the= right network attachment decision and b.) make the access selection on a fl= ow basis. This same policy that is present in the ANDSF server, is available= for the network nodes as well. I’m not sure, with out this assumption= the solution can work for all currently listed cases. We clearly need the M= N and the LMA to be in synch with respect to the configured policy. How, tha= t is done, I guess we will not try to know.  I thought even in 3GPP, th= is is the implied assumption ? But, this is for you to clarify. Not specific= ally for IFOM where UE and PDN GW/HA are negotiating the flow policies, but= generally that the PDN GW and the ANDSF policy server will have synchronize= d policies. The MAG and the LMA have the ability to carry this flow policy i= nformation in signaling messages and influence the access selection. The pol= icy is a opaque object, with extensible formats, when carried in the signali= ng plane, should allow the LMA/MAG to apply those access policies, while ass= uming MN is following the same rules. These policies can surely reflect the= specific WLAN access/operator specific rule. I’m surely with you, the= lack of MN-AR interface is surely an issue and I see that. But, we need to= understand, what are the limitations with the approach of  out of band= policy interfaces and what will be the solution limitations. If we need to= tie the flow movement at the prefix granularity and rely on the natural ND= interface in the form of RA PIO option, more like PDN offload in MAPCON, or= at the granularity of a flow level, is open for discussion. I want to simpl= ify this draft for sure, we can surely discuss each of these issues on the W= G draft.


Regards
Sri






On 2/1/11 8:29= PM, "stefano faccin" <sfaccin= std@gmail.com <http://sfaccin= std@gmail.com> > wrote:
Sri,
thanks for the reply.

I'd l= ike to comment on the "the flow policy decisions need not be based on th= e specific WLAN network". Does it mean, as I believe it does, that the= current solution would not allow an operator deploying such solution to dec= ide to route flows over a specific WLAN or not depending on which specific W= LAN the MN is connected to? E.g. the operator or the entity in control of th= e decisions for the routing may want to direct certain traffic always over W= LANs that the operator deploys, and instead route only some of the traffic o= ver WLANs of roaming partners or of the MN user home. How does this solution= support that scenario if the LMA is not told specifically which WLAN the MN= is connected to? From a deployment point of view, I do not believe we can a= fford to leave out this scenario. Please note that the establishment of a se= curity relationship between the MN and the MAG, and a specific MAG identity,= cannot guarantee that the LMA knows which specific WLAN access network the= MN is connected to. Assuming that would severely restrict the deployment sc= enarios.

As for the MN and the LMA being magically in synch, I am very c= oncerned about a "glass ball" solution. You mention ANDSF defined= by 3GPP as a solution for this "out of band" delivery of policy.= Fair enough, however there is an issue with that. ANDSF is designed specifi= c to be a MN-centric solution where policies are provisioned in the MN and t= he MN decides which network technologies and access networks it needs to con= nect to, under what conditions, and which IP traffic needs to be routed on s= uch accesses. No IP point of attachment in the network (i.e. the PDN GW in 3= GPP that is the LMA in PMIPv6) is aware under any conditions of such policy.= Therefore, even if in order to apply this solution to 3GPP we wanted to use= ANDSF, ANDSF would unfortunately not provide a solution unless the MN can c= ommunicate to the MAG and the LMA the decisions the MN has taken based on th= e ANDSF policies.

I believe the key point here is that we need to und= erstand how the solution can be realistically applied to a real scenario, an= d that we need to ensure that important and realistic deployment scenarios a= re not excluded by the solution.

Cheers,
Stefano

On Tue, Feb= 1, 2011 at 7:43 PM, Sri Gundavelli <sgund= ave@cisco.com <http://sgundave@= cisco.com> > wrote:
Hi Stefano:

These are valid points a= nd some good comments. Let me share my thoughts.

Carlo’s draft= is not assuming any new MN-AR interface. Its going with the assumption ther= e is established policy on the mobile and on the LMA, which allows the mobil= e to select the access network at a flow level granularity, without requirin= g any explicit signaling between the MAG and the MN. To large part this is a= ll about out of band policy interface, such as ANDSF, towards the UE, leadin= g to the assumption that magically the MN and the LMA are in sync with respe= ct to flow policies, access selection and they will make the right forwardin= g decision. Secondly, the flow policy decisions need not be based on the spe= cific WLAN network, but it is implicitly driven by the MAG – LMA secur= ity relation, where the MAG attachment to the WLAN network transitively allo= ws the LMA to make the flow policy decisions based on the MAG identity. If t= he WLAN network is not trusted, there is truly no MAG in that network, where= the LMA shares a security relation with that node.

There are still s= ome open issues on this draft that needs to be discussed in the WG.  On= the approaches to allow more a flow aggregate movement, that is a discussio= n point. There are issues that we need to discuss, supporting split link mod= el, or eliminating some favorite brand of signaling message (FMA) and riding= on PBU/PBA and just with one FMI trigger, and on the aspects around MN appl= ying the flow policies by flow mirroring. We have no agreement on those issu= es yet.

Its just a base draft, for further discussion and resolving t= hose issues. But, hope that is not a stopper for base draft selection.


Sri






On= 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <ht= tp://sfaccinstd@gmail.com>  <http://sfaccinstd@gmail.com> > wrote:
Raj,
thanks fo= r the email.

I need to apologize in advance if my questions have alre= ady been answered before (though I cannot find a conclusive answer anywhere)= .

I think that a protocol that is developed in NETEXT (or other group= s) should have at least a potential realistic scenario for applicability.
In terms of applicability, though it is not part of the protocol defini= tion per se, unless there are solutions in place for either the host to indi= cate to the network where the flows should be routed or for the LMA to recei= ve somehow from somewhere some policies, the solution cannot really provide= flow mobility since there is no way to decide which flows are routed where.= If we are thinking about a host-based solution, I have not yet seen a solut= ion as to how the host can indicate to the MAG and ultimately to the MAG whi= ch flows should be routed on each access. If we are relying on modifications= of layer 2 protocols, aren't we defining a solution that works only with so= me technologies (since for other access technologies it is rather unrealisti= c to modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-= based solution, can we hear of at least one example of a real-life scenario= where the LMA would receive such policies, and how such delivery would happ= en? Also, should there be a solution to have policies in the LMA, how does t= he LMA actually decide to route flows on one access or the other? E.g., if s= ome flows need to be routed on certain WLAN networks, but shall not be route= d on other WLAN networks, how does the LMA know which specific WLAN network= the host is connected to? Perhaps I missed the ability for the MAG to know= e.g. the WLAN SSID and provide it to the LMA, in which case I would appreci= ate if somebody could highlight to me where that is defined.

I think= that, though not integral to the protocol specification, understanding what= framework the protocol would/needs to fit in is rather important.

C= heers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM,  <Basavaraj.Patil@nokia.com <http://Basavaraj.Patil@nokia.com&g= t;  <http://Basavaraj.P= atil@nokia.com> > wrote:

Hello,

We have discussed th= e flow mobility solutions for Proxy MIP6 previously at
IETFs 78 and 79.This is a consensus call for adopting this I-D:
draft-bernardos-netext-= pmipv6-flowmob-02
as the working group document.
I-D: http://www.i= etf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt

The conse= nsus call will expire on Feb 15th, 2011. Please indicate your
support or= concerns in adopting this I-D as the WG baseline document on
the mailing= list.

Please note that this I-D will serve as the baseline in the WG= and will be
developed further based on input and feedback from WG member= s.

-Basavaraj

_______________________________________________<= br>netext mailing list
netext@ietf.org &l= t;http://netext@ietf.org>  &l= t;http://netext@ietf.org>
https://www.ietf.org/ma= ilman/listinfo/netext

 
 
------------------------= ---------------------------------------------
This transmission (includi= ng any attachments) may contain confidential information, privileged materia= l (including material protected by the solicitor-client or other applicable= privileges), or constitute non-public information. Any use of this informat= ion by anyone other than the intended recipient is prohibited. If you have r= eceived this transmission in error, please immediately reply to the sender a= nd delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not auth= orized and may be unlawful.

---------------------= ------------------------------------------------
=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_002_01CBC3F6.4B63BD0B-- ------_=_NextPart_001_01CBC3F6.4B63BD0B Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAKAA4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDSu9Nv V0vVpbjQL2KfU7xR5T6qqmRclsrnhecDFbGl6hqL69Noem63ZRQ6faops5Y2mmiYBQdz8BuSR1qD 4pxpLdeHo5UV0N2cqwyD93tXexW0ELtJFBGjv95lQAt9T3oA/9k= ------_=_NextPart_001_01CBC3F6.4B63BD0B Content-Type: image/png; name="image002.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.png Content-Location: image002.png iVBORw0KGgoAAAANSUhEUgAAAIoAAAA+CAIAAAB7vhRQAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAIthJREFUeF7tfAeYHdWV5q1b8eXXudXKoAyIIH1IgESwMTKDSDZebNKsZa8/ xh8MNgxj1mYxLGZtgseDDcwABsb2YH9ggglDMAiEyCIMEkkSCOWW1Orw8qt0b+1/ql4/tbJEN9t8 OxSPp3rVFc+555z//OfcUtjwLZyxAB/8I8ObUMLfGmNCYYES/Yq+63/ETyz1LdH6Hvbh4RXCwxX8 I2vrOH3tSNqK1W2X7j/78Ill4JWj5x2epaaeSPZ1qdPPUKpDs9TUs93JdrhcXflDc8X/T8+CAQ65 QWef7dJ/DbV+mf4hqjO2beNnexP7evbhtJ6d7xGOLc30pKpLJjh5nMEtsBw1kIH0hfRZUGXS7fej kUMV0elxVfyQpBts9wZ3zaE9etAiGPTtbIsciqIFwXg1MbtpkukFYkj8mxJIJv1AQtt24FUDv2rb ObfQy7xe6Zajm4dawrj0OXRyw68euBQasByxm9RzmN5wZHysXvZ2Np4IBezPgt0FziMVnFuRipRc VVTF80XOlJ1Bpada6HKKBSagGjjW2ngYkmGxP3e5h32H2dlCfpFrCWOOYgTsEKO1mZmKH4TOTYm+ EZbqPyHpaAtW9rBPwBQ1YDzA3gHgGcdvEQRCqjLgMlClbFStsWa2XUvEGPdEFffgq5zJz5Ny9ns4 DtGgqJ0GFiOZyZgD7xJ6mIRkp6cnZ3wdGovA9iAWIHboxYdiAtK1VELpS5iKpsSEwt1wi8bzOlsj c+9UOrtxB3VXO4gLD+Ghw2o9oavCHfj0D9lDo9QPNVpMH0Kt+5pP+bBwaQFXuEwF3GO8wgKLC2jL NgwWuDGcXdU8FQZIMc5PGNaIRNat5l0W+NGVDTJqstPo+vQP7pTEFW4kkBnZfKTQMEnAV/jvtsM+ 5c3XDxtu9URZYaSeIGhXE1P0BtUVUuHkmsLH/bQfWA9XpMG5w3mF+xlViWvcF76tsWygWK6iicDA h3ELu5k8meXpXr+UIzkbiFdhwqzhJAFpJfSoFMLwk/TCSUHQN6kpUlWo1iH2jcOnnn43su2BJBsX bxwDD+d6gabCfsIIM7gPsxVeIbGKRilMRfV9WRIycPA//Qefx6AxSL3ienHDsiXbKMsMcI90QzKH a+y3EODwSAF0y+H2yHhgaBBjDaX32xp8Nv40WA+9n1BosMa60/EDfD0g3DGZ8Qfb8ELMh3qG4FqQ shuoNqEJdxzQhuQbmjsc3/cRegLmqTBSSBF64tyHm1OCSlJ9Nd/TY4uqChjJkH9BC+CYYNyBp1Rt GFWAw30xUPCRkgaqB9oibipy24NZhlU90cX7zadZs2anx4wra1wEQ6QeISFftQwHJbyRrl9oG1ue d1qHLXPkqHTJJf4AyStCCkVVgRrcGN/Iq1vsfCEIDENTfYGI5UFRAVd9U2B3qZYroq9Q6S3wrm73 veV9FQCbmslggJnYVVFsYMTBaKV+7LCqZ8ATYLCNt1IzzI4OV/dcT+j6oK1HQKaA0KriBBwDPusp XVOP8A6dAyvqczyLKSaoPWgoCuTwcnBkUmM2l+vL+T78TSXlQTVkPdAwTDGkalVV182UZLphGlXb Xdvtvfpm5ePldsmDyQB7AhpWB6a6g9HT8MWe7UeIxdhIJd6hpmMe/AYH6Br0wAkQtxURI96Ae8DW Us1PODiebMhJ3ZXCkkEyCDRIWUodbiwI9EDRmQBE0asiKApfKpoCG0A2S7icQADpDw7LF7YD8qFU KuZ5UMlkxWEHJVoam/K91VK5CtRJHhPLYOMOneNzpJ7RVqZNTZquj2GKYABRcNFPXRMHF3lBCH27 TzjoMbjDuE0SQcZEcEKEyEqVJlMxlitSqJrFD5jabCSQgSIrtSBvsgYcgDPjULg7rGOroRY1v1fa Piwa8JwjRgUCvo3DlkhfgiuGYZIqQ3ARuKJcqI4ebY4+INFbKG/tiTBBPNTPYIHccKonKihEfiCl 8AOtxgbgYMQLxdAgD8arhi9U6MV3VaEHXpwMS0V8hyGE3xwUgIbwLuHpdQQRgW0QvYqggi8SO4Vw 7CVjbuClmt2JByX0uOv7psI5Zy6cFwcgQKzDChcC+ADy17ijyB7XJkRNtAQCIWmcSV1wrGnwb67n wbp0AyRUoPksnmQ9hUos5s6c0dy92d7SjcdKhuigPy59Wgc3aA//aS/cH05rxycUtYHFFV8Knfu6 qgeq5SvIUDyOtF94ug8MnILiyEoge8QDaIf8Hwa3RtEBnBoxOIFKPo1clMI0IQIV5J3p+yMVpsaz RT21STEKwquqVO7TVaFxMAdCVel0+EAd+AluSbU8FhPc8EjthkcFKD1wLGHrim0EXkwNDEjOR/YM olCtYucYCxzJ8uUzTkq0QjWspCiDhW3D7NxqGV2Irdu4OUrPxMD7g/lHFAiEJjFylbSjxzyzymI+ h7tgtpn3NN/ThVB9T3U9zXORXKq+JRwdQV1xFcVD+AZdI7jucoOrCDMSwVyyraMPVEaNM1y/xJGH 1vJ/KBXATYXwWYDBrsPwYLalwO/yq74BuEAWFLIE8Lak0uiDhf5FPoXxIaFr7EjUkRRBIq1WpbFq jT0kzm04rYd8M54vhKAZNW4oOp5cwsErAnIXGtM8riNmMAPS9aRflkKr6pqrKRUDOhS26dsxz447 +Pa49FWiviEWTxGu6vlGVcR9G5ahStf1PSeTbGZ+UlbjikyhxsAk4K8bSA80HOAD0aZS00AHBEDj vkdWqbrIh8APMFWDqYa8QY3TIe3U2AJKU8MclaIY94uFypSpMQMYe7tM6FM6mV3HnjBM7t8y8JD9 PRxjZHK8oVVJaJTBBxY4A6l1uvl8YPeygs2KCVMkY7aluczVbGFrgYEYA0emBDrkhKFb1dQi1GUq qZhiqm5cF5bhW7qIm25Mh3SrmUbnoMMbzWSFaDfdZLxk6GVVRX5FsYch52S+DACqwTKIQmB3o0Jk IPIjlCkYJwQa4P52LGiQI4U/hFtEhFQQmngAbWcakytXy3x+CJzbbtVwySWXnHvuucuWLbvyyis3 b968V11FKom+ETCj/esr9cN1Xfc87/jjj7/22muF5137s58tfO45uK1TUpNbhaa5wtWVmMs3id5J X/nKOddcVu3deufPfsRWvP+tL83u9HuThx1+0FFz0uMPhC8KwDyHIAkykqZR2fTxsof+zV2zrNkS ik+igWB9jsCD8CBEbOv0WY026wJe84HoRIoJi7wnRC8VDArHAVz2pes7rreqVFleZFqCIfkC6Pbh vuC5iELYUVxECwmDaa7PmerD0MkejWzmwSe8d5ZW9iq0ve6w3fXqwh05cuSGDRuig2+//fYLL7xw dyci/xsqIzoWgEgigMOlAzgRbagIsYv8edGiRccddxz2f/fdd08+dX7v2nXfaj4sWXA0wSqQh+0l Jh1w5ZN/yh7QhH1eeeTeRy757twJDeljjpn1kztNI7u7mym889Qj/7igI+GbQGUE2zSHJRSNV7zu bIeceEhDNegBVgMhEAYScNXEe4LlZICCBOXBw6LOwPLSX1u0t/ZWK4WgDHSQYm5UaoiiDT1tffzB h4XqUeGKgScxZmRgJha/pS5cVNir9Pe6w65jz4QJE3Ck4xAuPO200/ZwloGGgnUoA9/QDQ1eKXep G/zJNMEYMtfxJk6YOHnSBHCKloockGhI7gc5Zp/ygwXQjY0kL2CZTEvLyLEl3z/2ssugm4rwkTaW A4YPUhhHSlfKcohgY9kW3UggaxeSu4HuKDGQXhwkmV1pa0xRsMAVgIwlyn40rNCIQBgQJ2BVIcuB KMqgLJSCqdlTWpMzxzbMmtg4MqOVy6RtSrAoSwrNtT/ehAEozD/DqhKNT8L+pOohWbZTDyQbGUEk 30j0kSh3ucyePfsPf/jDzTfffMcdd8BfYZ9Jkyb95je/ufXWW2+77bYzzjhj5yA00PsZJjJ2ZCe8 mSWE42JEAgP1+bmDTjnuhL/7ZgkZkabi6Tdt3NKzsThu9ldYehJaOpBn6lxJKLALFuPM5MBnPEH3 6L/86P0lpxRoBhg0Qm4YzcB1fgWxJdVgSkgf8iMyvErx3wdmxpBA6FJNRdNBgRKoJmihigpz+jKB 0Z6MHz65beqkNLIk4YZZrI6UGfKJKGtKlQNVEMGNcwVSU6TnMcM0C7khCDx4JAS97ZZIMdFioHTV 77UG7qRpGjgsbDn77LPPO++86E8IVIlEAkq66KKLoi3z589/++23161bVz82Cjx1xVNXIIjgwBtj NRgeYJPquU4P87932/XYBzaR0Hi5u/D23XePMTZZo1sYa3Q4s+CNyptfeuwPaQvjGDCaiqJm38au F1/rW782kY2XNLNBagm7xPXNuZjVUI7HzSY37sVk0VOa/HJb0vogxpSylq3qNpQUVxJWscLUWNnw dIyIKugcoSRcUbGkV0ynSoc3j2hLO++95+Rd7qLcITQL+yHN8TQJt2YGvNJgsRxXBQxXseJVuOgq PbQK2Bj6dpgTlkho9QE6bty4fD7vum61Gu7dbxUDRb0nYL1DnK8fFl0Gy5w5c+obFy5ciPW5c+fW t7zzzju5XA66TKfTqVQqmUxGutm2UAWOJZAwuj4GpC3FSrbm76+/vnXMKOG7CYWw7FO33LVy2ZKx IxvdCkVancHI8izoefa6f1zyq58sv/nKVb/6nx/885Vv/flud8P77UY1w6oqnQnQwRRmCsEMGVRG r8TMXNlk6P4wp33VaZjRR56oL+EmY46le8W+WLkczyUwImzdaxhlN4+WBnPVzbrWKxxghc0dCeew qUaGx5Uyg2eErbsurMTlQQz9Pp7EcwW+w0gXaDXx+KYuWCF+CoSGY489FoO+Pu6jaB2LxW666aYH H3zwlltuwfpAqxgooR2tZzvx7eZHHQ7g7I899hi0tWXLlieeeAK7P/7442vWrMFtwWgQ/wuFwr33 3nvggQdCMbAtgMBot9pC0TZoDCyffFDQ7RemHTj3lEu/g3IPfpoKy6/e+O//++eHTWowdQr1OKqi aCkFoTirptvMVFzzqokA7t7xrSAh/JhbQRZKgV5Nu0q8RyDB8SiRSsIdFvq4Vu7155zw7U9eNzZt eauD61rVBYODQJVvyoh8YSxT8pVKZvp3M+MnrH70iga9YCpBoZKwjfZ4blU2npk2ofn1FR/mcn4C BJHoyeWDRMIzYJEcdgluuyHQSoKXN2+NdedqTuiCCy4oFouLFy+GAqAGGEqkCQgNIeDQQw+1bZtU vSsvRRt3qQIYAc4YhaLe3t6mJkJQ9YX4qtAS68a7B6UOxNZQ3qmnnoqdX3755aOPPhor0N8V37jA +evbqCav93v++ZGHDp5/fCGoJDxTNdSfnblgyV/uOWPGxI50Z/vJ3zrk8ju3IoEFBPCdJX+5N2Px JDyG43dvXP3BS/e1F3qaglLJ8h0lqYlMsSLTR88YP+uYl//XT6af9VUj/Xyx7cBEdsS4GdcrpTVa Kub16B8+d1mu9PERx/46M+O0/IcfaIl1nyy86oDjb0uMP6n02vc+WHhnE+oLjceMPnFB570XNZzw 3arrP3rfnbNPvPjIs35Y6vn4X2+4elP3m9847+pXX/9d58fvn3POL99a+uC6zldfeNl8+XX1xUUL m9qypmn97ne/++lPf3r55ZffcMMNn3zyCXz+hx9+WA8QkWIiSe6ch+zJue3O4iLdnHDCCRgCOCOW 9evXYyN8XfQTC1IlGE2kSFwYS7lcBo4YqEg4Hl3T04GV4tYWN/e1y34A3TghSwrdPPfHp/7jL7+f bna0N8UAq4SmIoVuQwLjVZmoHnnWeZPnnz/yb84de+aCGRdd+zfX3r3V7OjjTdJooEIA/IePdLaY POLY9JxTpl1xV3r838Wbz40Zh6DMU8h3Lbn9HN+0EtNOGTflv8cPmvv6Lcd0vnd7YswpxULQu3zh +rVvvfPSbxMNqoyxiuUnRx+/SfG9bCbPqvNO/f7EE753yYJZD/715n+4/r687Y8Ye6QWz6LY0zhq rpYcnSuZi1+177jt1s7ujZMnT8HDwGK++c1vfv/734carr76aviPMWPGQHRQSSQNiCuS5M6jfO+x Z+djopg0b968+p9GjRrV0dGBGFPf0tbWdtBBB0E9wA5nnnkmQAT2uf/++weeDXEUi6mpfTI/8uBp Z//wQoAFz7PhvsrrCndcedME1pYwAyvmoXsmRN2oNIBh1oQWp/zRd8pS5hl6A5hvtPBMu6PFcoBd qgGA35JJbl21lBV6R8w/3+9cGp84L94wS65eCdY1t+lD1tnj51ZypzvR0rJl49LCx8tXvPGIw7oV UZGsV7ELdhFZglJBkNVitm30BAkHVIWTz04ZtfI/n1j60ab/WPgo4mZTi1IpF+ySU0AEEjyRbHn6 GYo6X5p3wrL/XIqVp556Kh6PT548GYEAP//85z9/9NFHSCujUbtXemW/Obco5cTZx44di2/YxIoV K6677rrOzs6pU6diS6lU6uvru+qqq3BnEydOhG/FMOnq6gJMqOumPlKASU3V/JB1XXzlFU0jWtEL nQDKZcojt99TWd0VY2oyGVNiPgqXUXW4rGkO131gaSOua3GD63HGE4B5ne/yYpcKrg68CogWsJzg 4PxqYfOaw78yb91jv060x9rHN9tbl6LFIBMXforlWNrPWqs7l7ccMKX5qIOnzV9gsGQllgaCzCTT HdlpnqubpsoKWjyZnTLrghEjTner0worlh4ye+bXvnzet8+6xS/1yl6eSKgHHzF35qy5B0467LXX tq5cRff51LNPzvvqScfOnXvWWWfBMpB9A9lGXAnG8fLly7EC5LZLixk4gveknl0eXM+NAKBhEFDA UUcdhZiPkyIBymaz7e3tuDAuj4j34x//+IEHHsCQQST75S9/GV0YRgYUhxWPCVPVenq7jxs5e/rZ J/fYZQd2oirvvrj44d/8FrpJK4lsOmNTxT9MMZC9BgJsqKmUtix51l72vL76VfXVh1645m8X/ury RGltIy/rYFXIm2sYFvFEYuVLi9gnL/nFNyufPCr7Him6a7n/hsx3gSYz3bfHVlZobz5eevP+w8++ qjE1RikuzijehvWLY8m+KV/+uiurSECLq97a+swVo0YHPfm3mrPjVr/5l+L7//L3V19+4kktN143 R69WH/njvx4/98QfXn7PrTf+/JZbHgjrV+kf/cOljltF9vfGG29gvD700EN4/Oeff/7EE0/8+te/ juGL7x0i+s5eClt2hAYRKhsIDXp6epqbm3c4uJ7BDNyOkQL1YAvs6cUXX2xsbIRW4OKifXCLuCes tLS0ANRNnTLV4Uo1l7vizPNu/OOf0iNSwDQxeDCVXXHo8SuXLZtgzBLuu0d9mTU2+ZVNW1pPv/jI y35dCWQcBOTWj6+YPXF8BmQKM5PMSmttaCSE/nxWVlFBQx+BAWYNjQOb7E0dY+MTJigAyEBLqay+ vttrzqRjmlLOF7knsxljfc6l3ilTR3xpbNMKKP9t9VWdNbQhX4kVS23ZcUcEo8eNGTdh9dNP+92L uyt9z77FPiqw0WNYm2n2BtbmnurjT7o9pagTOR6yCvtEuNUx8C51g43bWc8Oe0dObMdkJTwTNkZh PyLWsAJ/et99990ZLtAKgBlsCx7v1XB58sknr7nmmugmIuwABxTOVgsuvOonqZZ4gN4k4UM3z/zT 799ZtqQ51l4RjmUAOVSRigegqsGWIO8BTEaJLmmMSLJRjfrYDpZJQw16V9HvdrUcHKOCD4KsCHCY 5G1ZbcKYrK5a7UmtIROD7Y1psgxe8AKU5rjerBe4bGrVW8arrR2ydQyqgDyjqa3tjAakx3wH8xry SDvNwF/5/MPFrkUGz3e0xKcfmjh4mtbYmGbxRE+X+GCZki9FbW0GSNJ91E0kit0pJtq+nfUQVxQu 8JKwRMQuhA3YJkIL4lvtgDD2gMl++OGHB0I74EXkQPWLwVBgLplMJmJIK5VKhFVwTqSosC1A/kqA Zmque4p0XMQczrXeTZtPPXhmk6eaepoXrAmZLXPmsVhQLazrbv3ad+Zc+lsknEhhVLf04M8vb08G pvT8wLLVpK76xc2rty5/O6N5BuoC0A9IHcn1ZG7q9HY0gQhWRo2Oghh1doBfhixR3AE/SLRtWGkj n4jqAkSiSir3oNMObQ/CMHNVTzPigeJlFAdO2U8k3umyXl/lbtiiLH+/vHK1ADVIsiZ2G54NKerQ dFHtQj1021IioqxcuTJaj6xkhwXbH330UUCy+vbzzz//4osvBlIAkQoG4cYbb6z/qW6UdZcIjzxz 5kyU16AuI6x0+YjyjJ9+xunPPvJoFnWYAKVKeXIzP+OkJtfOeT2lscd89ZjrnvQks9FfoCmGhwoz ckFwXgbqAzT9I8i998Bti3/7i7Y4GhDQpqHagTZiUmXC1IRQ4HeIXkG3GjVEoREIoAktOCCow177 6AnBMAUijoInNutIVtFT4NpqApexHbB4fialVCt9+U1+6sEl+r2LenttaidFGtbfUQNelmrtdbEO nhfdbb3nvffeQ9iArDHksURmCFVFJFKE2feMC+vZK8HnfrwX6eyuu+5asGCBg9ovknwfHWM6fN3d /3bPd769AGVGjSlVXIqJi6am5s1q7c11qV6p4mS/8/RaxlO4gSoGuIJ+DrR84MZQmoPrY+iYEl1v 3vnd+RmlZKGsoXBHGplGnkqDHi0rHNU2dG7gQmCqHfTdEIEJSyIvS2U3PA1WoEEk26iwGS4VSVFj 9aQjuOchkpXjQamMaxWsjj8tk0+v2KQoTeSlyW6gmGpYZajVTfu7RAeroN2qB0wR3BfC+86mE215 4YUXIpZ6v5aoIATQ8sorr4Derh/712eeOeecb/V09/T3iNGsrF/NbxqnWbbmgKdcv6Y8/Rs/+NKl NyHFpmaz/gkDEcePb5TVVj1z5+M3/ag9IQ3pUREUNuamBNqq0UtFHVGWRCeQgokj0Ca0r1OhFW3y YUEP56BWQ7UY6BW063Cpc4E+RSpKU+sPlYKAN6pcV/qsUfcuLT+zYiPjiHugjKAbKnyE56g/ECh0 3ONgvdyeitbTp09HugvcjJrCQEYPtwC68xe/+EVEFuzXUudukaldfullM2bOqLru66+/dt11/6d7 61aiOjCqkUVLFRbw+79tT26WOQ3NNiVDptcV5ZTj5h987MnZtjEoJWH8U3CFQUNhQm54/9XXHrpH K3VlkZgi+aSeNNghXJbLVJe601CLkEZoRqH5hX+l6BwW2cLm26jPEBaEPyFOGqizRlP4EaE0VuKi hDvsMttuXbT57S0guUP5R1oJvzG2+gn/qEvsM7OeutCBlevOLdqIxwDaxgoqDhGdt+8Ljo3AXkR7 t7a2wllFZ7NUtNVIZhmq7XgBnzxaufFL6dQGc2tS2mYhBipfFD1cT0tyoxFhwlKQ4viOqrhaTPVB 9FQ15sdVtHNgRJOQMewD1ZMK2jYdKIZLdIaaauDBmKgHETMLSC31MR92LUjM/DJRoGZalfw5tgBN SLRjQ1ueGbhcMzay5hueXr2aGIVIKaSc2hQT8NaRTrazpH0Xz4577rYNMUJx2B35HVijHZZIxDCp vULDHS6I0UeSC102QFKpXI6qHXA0VMDEwIVZcBPczdwpqUOTLvcMYTLHLVgq8lRmIV5wjeYOeI4m weej3uMrvp3Ah8uYTsM/RCLRKKKCBbXUUhMHSqNgFKi8GfXcADsQwUCSDGNjBN5gjGFPPOKNROGW urDJ0+G+0HmCmamSW6tyyqKPAQvgvgwUW8Nz4BqYCUTqrdlLZDyDXnarnj3LvU597u8NRBqlZfv7 h0+oEbbkX1AIFd8Ynx6ZopmFQeAkwcVxboOhpuY3TP2BP0OER20aokShE3CZOtSonR1yrk0oDZEY NRBCC4C8YeCGUqhmjvYb2nFgX1RtKhXabRBLaGTi7CgQoaSAO9AxprioAGmLVPq1TnfJRqQ5uKhH o6HmxFCKGzAxdSh0A9nuN+e2v/r4NPsHTloLWhujgEfN52HvX1hLpr4NiL023CF9GAT1SpMxh/Im kWMc1z7hBsqAqameWgFqT0wH7HLaHTWbUgsp4TuGVkgXGB1pEGVCMClNL0tjyXJyxeGJqLf3M10+ l+phTmNcTxqqcF2yFgx/ShbDcBItxDhEGqhJPPRRtclq0Xr9U1ujM0TaCw/ejVAx0xRXJI9I14Ql oU0XU1DRJEzsMo8n31tXWVFEuAV2qKGG/4LqYe1JNaa6od9AdzqaLWha2mcqCDo58jD0g8LOwuhI U63IdNBaj0urwkxWldSTb28Jx0RUZaZb+kxv6/NoPYiHk9tT8cCl8Rm2n5GtgEUboilnu1dzNIuH SGFUMAAQwDPZmM5jWGVulszWB1/bsryMGIM/omJO0/2HYg7Pnkbd51E9lspGpDCp2oagPLAzJLLI i4Vpyf43GO+32RHAI0LB9QMtnoIz09PNS9fbr3ycD0+F8QP/9v/i5TufR/XENK0xoWnCQcZBegnn 54KWq01Tp7ewRO2A+/DZjesByhrwGZhAApeHs+AolGmaZRVtv3lEx5othftfWdtFExl1pmtoBKYe s5qqPkN88HlUT3NSbUxgZrTqCY8SFHr/HmgwmuVObTlIt8IZBXv9EK+w42Q6aubEpDbCz9SESA6M 3jyBJQSJ4QxTmiCEpnaUbm0/iDV3vPJ+5x1PdXZiAiQQgRrH/Iloqnyolv4JJfttoft0wGeo+X24 PooUrop32eAfglOwFhwkTplk/Y8jUlUPbZmUH9IMjoi/IcQcvVxg7wuxcEBp1Ly5484wPw0MOSZU QTFq2N4JIhA6ozQV/W0o2pTjeM9OLF7Umx/+yPvTErSbQyMRP0K4IZLaPt3H3u90T3sMr3ow4Zfm tuE5Q+4QFRZ6v9cPDmv8b1PNzlzJMjC/wKf5GSGpFQIq6h/Z90f2qId6Z0GG7dUhpRBOHg1nFRGY Vgi7SdVMpnwttryr+tLyvufWlqm3g6ZoDZbf3Pfbru+5H4/6Kc6+50MigVMUpv2QSSgWCDHGrjmx fXqjV3YEKnSkHnRab+MYIvZx7wsN7ZChJG3Wx3nt0MAHhw1DpDwWhTcYKOgZaujWrVhFUzeUtcff Lby+BjVYcmJgb3CCWqPt3q88lHvs06MO5QUHnAtPDgGGAAhvhkJRi2azYWbUP51/gOl2YtYvKmIh /4XcEEA2OpLKnbu5n+3MJFKjRTMUIo9U90Y0KnSwAGin51rALa6iO8A0Y0m7ai9b37ukq7hso7MW 0+dIL8hv/BhoHsyG+IyksMfTDqd6UEvB5UOPjrFrYaaHIpzpTea1Z01XeteB90eiDhqSwvu2F+aC AcP+FMe38fgDifxI2VFdAKQYAj0B8tCWAAKiCEYgA3K3XKb1VN28p27I2R+u71m9tbwRE7BCeYVn xz7Ru1eiK/6Xc241QYbCQzEGz+8fPSZz5swDZK4rbBbpb9uKvFOIssMpCdgzfBsBRaSQ8yfJh6/t ILlGTg1/V3y814o8WFgbQPSXCtJMcPA9Za/L0fpcpTufhwvDZJV+Ugi0JyIizu/0GyPOhgkNOM8+ Nd8MrY0Np/VQGQE1mfBdkf20vEhREIBDq72FY9foaHtfVauGRd6r7uFCnUQGSm/co76J6N0U9IGJ bHvlAM2BDKdqI/5jwjFKqVToxFyV/rYBGhAYDUMzZWe/9De86kG8wTsd0BZDEYjIf4A3VEprXPIu 4Wu9PNnvgequaNtK/cC6A4xkQtojo8MXiG56HxL4NUzLA69G7zUIVenR/AjaGcU6HIHEK+oerpdB 90u8g915eNWDwU2tLQNielQfhsevF6IG2g+Jr//NuRHii+4/Guh1UBdtDDtwavXQunpCpaKQjf7m mm2EnEQIOcLXwVANIzST8AbIc9Yx4GBl/cXxX0jgCwl8IYEvJBBJ4P8CkLsiseCTLsQAAAAASUVO RK5CYII= ------_=_NextPart_001_01CBC3F6.4B63BD0B-- From cjbc@it.uc3m.es Thu Feb 3 15:04:54 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B2C13A6B3B for ; Thu, 3 Feb 2011 15:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.056 X-Spam-Level: X-Spam-Status: No, score=-4.056 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdC2VIg3QiXk for ; Thu, 3 Feb 2011 15:04:52 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 0B2833A6B29 for ; Thu, 3 Feb 2011 15:04:50 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.3] (213.37.82.169.static.user.ono.com [213.37.82.169]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 92D1A98DC51; Fri, 4 Feb 2011 00:08:12 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Julien Laganier In-Reply-To: References: <1296689037.3593.20.camel@acorde.it.uc3m.es> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-MV+VGoGeiJU1NuVvox6O" Organization: Universidad Carlos III de Madrid Date: Fri, 04 Feb 2011 00:09:15 +0100 Message-ID: <1296774555.4238.46.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17934.002 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 03 Feb 2011 23:04:54 -0000 --=-MV+VGoGeiJU1NuVvox6O Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Julien, Please, see inline below. On Thu, 2011-02-03 at 10:52 -0800, Julien Laganier wrote: > Hi Sri, >=20 > Please see inline: >=20 > On Wed, Feb 2, 2011 at 4:13 PM, Sri Gundavelli (sgundave) > wrote: > > > > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behal= f Of Julien Laganier > > Sent: Wednesday, February 02, 2011 3:45 PM > > To: cjbc@it.uc3m.es > > > > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > > Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-nete= xt-pmipv6-flowmob as WG doc > > > > > > 1. there is no need to support multiple addressing models. All scenario= s can be supported by a single addressing model in which each PMIPv6 sessio= n maps to a set of prefixes that are equally accessible through the set of = physical interfaces attached to that PMIPv6 session. This allows all scenar= ios, including one in which two prefix sets are available through different= physical interfaces set. I understand that the WG has been divided on that= question but that does not constitute a mandate to include everyone's wish= list in a standard specification. Thus unless someone can come up with a = rebuttal of my argument on why single addressing model (prefix-set per inte= rface-set) satisfies all scenarios, e.g., by pointing out a scenario in whi= ch it does not, that should be the only addressing model supported in that = spec. > > > > > > > > [Sri] I guess, this goes back to our last discussion in this list. We a= llow the hosting of multiple prefixes on an IPv6 link and the base RFC-5213= allows the same. You agreed and your comments on to take the approach of s= ession management, as supposed to addressing models. Now, we allow the abil= ity to move a full/partial set of prefixes to a different interface, and op= tionally allow the sharing of prefixes across links. This is one issue to d= iscuss the shared link approach and see how to capture the final text. The = text can be updated once we decide the scenarios that we support. This also= probably ties to the policy interface to MN. Lets take this as an open iss= ue. >=20 > Adopting a solution draft before we have decided what scenarios we > want to support with solution sounds a bit like putting the cart > before the horse. >=20 > In the addressing model I outlined: at PMIPv6 session creation a set > of prefixes is assigned the mobile node's session. Then physical > interfaces can attach to / detach from this session. A single mobile > node can also have multiple sessions (say 2) in parallel, associated > with distinct set of prefixes, which results in the ability for the > prefixes set to move across interfaces fully or partially as the > interfaces are attached to / detached from the session. So all > scenarios are supported in this simple addressing model which also has > a minimal deviation from the basic 5213 model. >=20 > If you think this model places unreasonable limitations on what > scenarios can be supported, please explain how and why. >=20 > From my perspective the way forward is to revise the individual draft > submission to document this addressing model only, after which we know > what we are asked to adopt as a WG item. I fail to see here how current draft deviates from your proposal. I think it does this. Prefix models are just a way of presenting potential use case deployments and the solution adapts to all scenarios presented in the draft. >=20 > > 2. there is no need to convey traffic selectors between the MAG and the= LMA. The LMA forwards downlink packets as per the network-based policy, an= d the uplink packets to the Internet. The MAG forwards downlink packets to = the MN, and uplink packets to the LMA. End of the story. As above, unless s= omeone comes up with a rebuttal of why that is not sufficient to address th= e scenario we're concerned with (network-based flow mobility), the traffic = selectors shall be removed from the specification. > > > > [Sri] I tend to agree. The MAG does not have ability to convey flow lev= el info over ND interface. At the end of the day, the MAG is hosting a set = of prefixes on a link and that=E2=80=99s all. So, the traffic selectors are= not needed from the mobility perspective, but if we look at this as exchan= ge of policy, we can allow them optionally. But, I=E2=80=99m fine to get r= id of this entirely, but allowing this exchange is not undesirable either. > > >=20 > As you rightfully note, "the traffic selectors are not needed from the > mobility perspective." Thus, since PMIPv6 is not a policy exchange > protocol (or did it stand for Policy and Mobility for IPv6 ;-) they > are undesirable, should not be allowed optionally, and should be > getting rid of entirely :-) You are right in that TS are not required from the mobility perspective. They are optional in the draft and not even considered as the default case. They were included because some people expressed in the mailing lists that were required for some scenarios. Therefore, I'm fine removing them if there is consensus for doing so. Carlos >=20 > Best, >=20 > --julien --=20 Carlos Jes=C3=BAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-MV+VGoGeiJU1NuVvox6O Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1LNZsACgkQNdy6TdFwT2ffPQCg49oYK2UP/ApeXV0wgrXexy6A AJ0AoIZZ6JRWaop5e4g/3WjbYfPEY0y6 =YRij -----END PGP SIGNATURE----- --=-MV+VGoGeiJU1NuVvox6O-- From cjbc@it.uc3m.es Thu Feb 3 15:04:54 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E3913A6B29 for ; Thu, 3 Feb 2011 15:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.056 X-Spam-Level: X-Spam-Status: No, score=-4.056 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvxhEHxfyuxH for ; Thu, 3 Feb 2011 15:04:53 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 031E33A6B37 for ; Thu, 3 Feb 2011 15:04:53 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.3] (213.37.82.169.static.user.ono.com [213.37.82.169]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 9C4FF7101B8; Fri, 4 Feb 2011 00:08:14 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Behcet Sarikaya In-Reply-To: <510561.49948.qm@web111403.mail.gq1.yahoo.com> References: <680854867F7FD04BB9B06EB8ACA8D5AC0465FAB1@XCH02DFW.rim.net> <843DA8228A1BA74CA31FB4E111A5C4620179629E@ftrdmel0.rd.francetelecom.fr> <510561.49948.qm@web111403.mail.gq1.yahoo.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-vwUA3hfDt3BRbf7kz+D5" Organization: Universidad Carlos III de Madrid Date: Fri, 04 Feb 2011 00:09:17 +0100 Message-ID: <1296774557.4238.47.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17934.002 Cc: netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 03 Feb 2011 23:04:54 -0000 --=-vwUA3hfDt3BRbf7kz+D5 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Behcet, On Thu, 2011-02-03 at 08:19 -0800, Behcet Sarikaya wrote: > Hi Pierrick, >=20 >=20 > >Hello, > >=20 > >This is an interesting discussion, thanks for bringing the ANDSF issues = on the=20 > >table. Effectively, mobility control, i.e. access selection, is a key po= int for=20 >=20 > >an operator. From an operator point of view, criteria for selection is n= ot only=20 >=20 > >RAT type or SSID; we can imagine plenty of other criteria. Different mob= ility=20 > >control models can be envisaged such as Network controlled or terminal= =20 > >controlled and so on... For sure, in PMIP context, policies synchronizat= ion can=20 >=20 > >be an issue and how decision made on the terminal can interact with netw= ork=20 > >managed mobility should be discussed. But, I don't think draft-bernardos= should=20 >=20 > >go in this space. I think, we should clearly distinguish mobility functi= ons.=20 > >IMHO, draft-bernardos should not be expected to deal with selection mana= gement,=20 >=20 > >or mobility triggers,=20 >=20 > + 1 >=20 > > but only on the handover execution. In other words, the=20 > >draft should assume that handover decision has been made (how decision i= s made=20 > >is out of scope) and, then, only focus on mechanism allowing the LMA to = transfer=20 > > > >flow(s). Although related, mobility decision management, e.g. policy bas= ed,=20 > >should be discussed in a separated thread. >=20 > Why do you say flow mobility should be tied only to handover? > Handovers may happen in the same technology not necessarily requiring any= flow=20 > mobility. > If it is an inter technology handover then flow mobility may be required. >=20 > draft-bernardos makes it as if flow =3D prefix. Why? Maybe because of wha= t you=20 > said above. In fact flow >=3D prefix. And flow mobility >=3D handover. Fl= ow mobility=20 > may not necessarily be tied to handover. There are all sorts of cases.= =20 >=20 Why do you say we make it as if flow =3D prefix? In my understanding we consider any granularity of flow mobility. Thanks, Carlos >=20 > Flow mobility's basic assumption is availability of simultaneously active= =20 > interfaces. Defining an abstract flow mobility protocol would fit to all = those=20 > cases, IMHO. >=20 > Regards, >=20 > Behcet >=20 >=20 > =20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-vwUA3hfDt3BRbf7kz+D5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1LNZ0ACgkQNdy6TdFwT2fEZgCeN4rOkt786r2fN/nijMepjdCC dwYAoJmkFWbwBCmNcRAmKZyY7Mw1Gr55 =7CIJ -----END PGP SIGNATURE----- --=-vwUA3hfDt3BRbf7kz+D5-- From cjbc@it.uc3m.es Thu Feb 3 15:04:58 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25FAE3A6B43 for ; Thu, 3 Feb 2011 15:04:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.056 X-Spam-Level: X-Spam-Status: No, score=-4.056 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bn5fYiMkVvRh for ; Thu, 3 Feb 2011 15:04:56 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 117AF3A6B37 for ; Thu, 3 Feb 2011 15:04:55 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.3] (213.37.82.169.static.user.ono.com [213.37.82.169]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id EECBA7101B8; Fri, 4 Feb 2011 00:08:16 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: pierrick.seite@orange-ftgroup.com In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C4620179629E@ftrdmel0.rd.francetelecom.fr> References: <680854867F7FD04BB9B06EB8ACA8D5AC0465FAB1@XCH02DFW.rim.net> <843DA8228A1BA74CA31FB4E111A5C4620179629E@ftrdmel0.rd.francetelecom.fr> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Dp/7EQX2Dk90CFdHEa4B" Organization: Universidad Carlos III de Madrid Date: Fri, 04 Feb 2011 00:09:19 +0100 Message-ID: <1296774559.4238.48.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17934.002 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com, sfaccinstd@gmail.com Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 03 Feb 2011 23:04:58 -0000 --=-Dp/7EQX2Dk90CFdHEa4B Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable +1 On Thu, 2011-02-03 at 16:35 +0100, pierrick.seite@orange-ftgroup.com wrote: > Hello, >=20 > =20 >=20 > This is an interesting discussion, thanks for bringing the ANDSF issues o= n the table. Effectively, mobility control, i.e. access selection, is a key= point for an operator. From an operator point of view, criteria for select= ion is not only RAT type or SSID; we can imagine plenty of other criteria. = Different mobility control models can be envisaged such as Network controll= ed or terminal controlled and so on... For sure, in PMIP context, policies = synchronization can be an issue and how decision made on the terminal can i= nteract with network managed mobility should be discussed. But, I don't thi= nk draft-bernardos should go in this space. I think, we should clearly dist= inguish mobility functions. IMHO, draft-bernardos should not be expected to= deal with selection management, or mobility triggers, but only on the hand= over execution. In other words, the draft should assume that handover decis= ion has been made (how decision is made is out of scope) and, then, only fo= cus on mechanism allowing the LMA to transfer flow(s). Although related, mo= bility decision management, e.g. policy based, should be discussed in a sep= arated thread. >=20 > =20 >=20 > BR, >=20 > Pierrick >=20 > =20 >=20 >=20 >=20 > ________________________________ >=20 > De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part = de Stefano Faccin > Envoy=E9 : jeudi 3 f=E9vrier 2011 08:05 > =C0 : gerardog@qualcomm.com; sgundave@cisco.com; sfaccinstd@gmail.com > Cc : netext@ietf.org; Basavaraj.Patil@nokia.com > Objet : Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-p= mipv6-flowmob as WG doc >=20 > =20 >=20 > Hello Sri, > >From a point of view of applicability of the solution, I must agree with= Gerardo that assuming synchronization of policies is an issue of this solu= tion since it comes with a set of restrictions on how the solution can be a= pplied. > Cheers, > Stefano >=20 > Stefano=20 > Stefano M. Faccin=20 >=20 > Standards Manager=20 > Research In Motion=20 > 122 West John Carpenter Parkway=20 > Irving, TX 75039=20 > Internal: 820 63451=20 > Desk: +1 972 910 3451=20 > BlackBerry: +1 510 230 8422=20 > sfaccin@rim.com=20 > Time zone: PST (GMT -8) > =20 >=20 > From: Giaretta, Gerardo [mailto:gerardog@qualcomm.com]=20 > Sent: Wednesday, February 02, 2011 11:13 PM > To: Sri Gundavelli ; stefano faccin =20 > Cc: netext@ietf.org ; Basavaraj.Patil@nokia.com =20 > Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext= -pmipv6-flowmob as WG doc=20 > =20 >=20 > Hi Sri, >=20 > =20 >=20 > There is no implicit assumption of synchronized policies. A basic example= that shows that there is no assumption is the following: ANDSF policies ma= y be based also on location of the UE. For example the UE should prefer WLA= N only in a given location. When the UE is attached over WLAN there is no w= ay for the PDNGW/HA to verify the location of the UE and therefore to verif= y UE actions based on policies. >=20 > =20 >=20 > The assumption on synchronization of policies is only applicable to this = draft and I think it is a wrong one.=20 >=20 > =20 >=20 > Cheers >=20 > Gerardo >=20 > =20 >=20 > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of Sri Gundavelli > Sent: Wednesday, February 02, 2011 6:50 PM > To: stefano faccin > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext= -pmipv6-flowmob as WG doc >=20 > =20 >=20 > Hi Stefano, >=20 > One comment. >=20 > Agree with you there is no ANDSF interface to the network node, but the a= ssumption of synchronized policies between the ANDSF server and the PDN GW/= HA is there, implicitly IMO. With out this assumption, I do not know, how t= he HA can ever validate the flow mobility options received in the BU. If th= e operator requires any control on enforcing a flow policy rule, the PDN GW= /HA needs to have synchronized policies, without which its always the clien= t decision. I'm not sure, operators in 3GPP would like that :)=20 >=20 > No doubt, the lack of MN-AR interface is surely an issue for supporting c= omplex flow policies. I realize the issues and I agree with you. But, the a= ssumption of synchronized policies can offer some solution with some config= uration requirement on the HA (assuming there are no other issues). There a= re also the proposals on flow mirroring on the UE ..., requiring no flow po= licies. I've not evaluated this, however. Folks can comment on this. >=20 > It is also to be noted, for some of the scenarios such, there is no flow = policy interface needed. We can identify what scenarios create any configur= ation limitations on the HA and which one's do not . As I've noted earlier,= this is surely an open issue, that we need to discuss in the WG.=20 >=20 >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 > =20 >=20 >=20 > On 2/2/11 9:08 AM, "stefano faccin" wrote: >=20 > Sri, > thanks for the reply. Can you clarify in which system or scenario ANDSF i= s available to network entities as well? There is no such availability in 3= GPP, and making such information available would require considerable archi= tectural changes, therefore the applicability of this solution to what seem= s to be the only realistic scenario hinges on 3GPP making considerable arch= itectural changes. I would therefore not be so hastily concluding that the = ANDSF information is available to the LMA and underestimate what it would r= eally take to make the solution applicable. >=20 > If we cannot guarantee that there is at least one realistic solution to h= ave the MNa nd LMA in synch, how do we expect that this solution is applica= ble at all? In 3GPP there is no need to have such implicit assumption, be c= ause 1) the MN is provided policies explicitly through the ANDSF, and 2) it= is the MN and only the MN that makes IP flow mobility decisions and commun= icates them explicitly (with well defined signalling) to the LMA, and there= fore no magic is needed. There is no need in 3GPP to have the ANDSF and PDN= GW policies synchronized, since the PDN GW does not use such policies.=20 >=20 > Sri, in the end it is a matter of whether we develop a solution that will= rely on some unknown magic to be deployed, or a solution that we know can = be deployed in at least one way because there are solutions to what I consi= der major open issues. >=20 > Cheers, > Stefano >=20 > On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli wrote= : >=20 > Hi Stefano, >=20 > Thanks for the discussion. >=20 > As you say, the ANDSF policies are allowing the MN a.) to make the right = network attachment decision and b.) make the access selection on a flow bas= is. This same policy that is present in the ANDSF server, is available for = the network nodes as well. I'm not sure, with out this assumption the solut= ion can work for all currently listed cases. We clearly need the MN and the= LMA to be in synch with respect to the configured policy. How, that is don= e, I guess we will not try to know. I thought even in 3GPP, this is the im= plied assumption ? But, this is for you to clarify. Not specifically for IF= OM where UE and PDN GW/HA are negotiating the flow policies, but generally = that the PDN GW and the ANDSF policy server will have synchronized policies= . The MAG and the LMA have the ability to carry this flow policy informatio= n in signaling messages and influence the access selection. The policy is a= opaque object, with extensible formats, when carried in the signaling plan= e, should allow the LMA/MAG to apply those access policies, while assuming = MN is following the same rules. These policies can surely reflect the speci= fic WLAN access/operator specific rule. I'm surely with you, the lack of MN= -AR interface is surely an issue and I see that. But, we need to understand= , what are the limitations with the approach of out of band policy interfa= ces and what will be the solution limitations. If we need to tie the flow m= ovement at the prefix granularity and rely on the natural ND interface in t= he form of RA PIO option, more like PDN offload in MAPCON, or at the granul= arity of a flow level, is open for discussion. I want to simplify this draf= t for sure, we can surely discuss each of these issues on the WG draft. >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 >=20 >=20 > On 2/1/11 8:29 PM, "stefano faccin" > wrote: >=20 > Sri, > thanks for the reply. >=20 > I'd like to comment on the "the flow policy decisions need not be based o= n the specific WLAN network". Does it mean, as I believe it does, that the = current solution would not allow an operator deploying such solution to dec= ide to route flows over a specific WLAN or not depending on which specific = WLAN the MN is connected to? E.g. the operator or the entity in control of = the decisions for the routing may want to direct certain traffic always ove= r WLANs that the operator deploys, and instead route only some of the traff= ic over WLANs of roaming partners or of the MN user home. How does this sol= ution support that scenario if the LMA is not told specifically which WLAN = the MN is connected to? From a deployment point of view, I do not believe w= e can afford to leave out this scenario. Please note that the establishment= of a security relationship between the MN and the MAG, and a specific MAG = identity, cannot guarantee that the LMA knows which specific WLAN access ne= twork the MN is connected to. Assuming that would severely restrict the dep= loyment scenarios. >=20 > As for the MN and the LMA being magically in synch, I am very concerned a= bout a "glass ball" solution. You mention ANDSF defined by 3GPP as a soluti= on for this "out of band" delivery of policy. Fair enough, however there is= an issue with that. ANDSF is designed specific to be a MN-centric solution= where policies are provisioned in the MN and the MN decides which network = technologies and access networks it needs to connect to, under what conditi= ons, and which IP traffic needs to be routed on such accesses. No IP point = of attachment in the network (i.e. the PDN GW in 3GPP that is the LMA in PM= IPv6) is aware under any conditions of such policy. Therefore, even if in o= rder to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would unf= ortunately not provide a solution unless the MN can communicate to the MAG = and the LMA the decisions the MN has taken based on the ANDSF policies. >=20 > I believe the key point here is that we need to understand how the soluti= on can be realistically applied to a real scenario, and that we need to ens= ure that important and realistic deployment scenarios are not excluded by t= he solution. >=20 > Cheers, > Stefano >=20 > On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli > wrote: >=20 > Hi Stefano: >=20 > These are valid points and some good comments. Let me share my thoughts. >=20 > Carlo's draft is not assuming any new MN-AR interface. Its going with the= assumption there is established policy on the mobile and on the LMA, which= allows the mobile to select the access network at a flow level granularity= , without requiring any explicit signaling between the MAG and the MN. To l= arge part this is all about out of band policy interface, such as ANDSF, to= wards the UE, leading to the assumption that magically the MN and the LMA a= re in sync with respect to flow policies, access selection and they will ma= ke the right forwarding decision. Secondly, the flow policy decisions need = not be based on the specific WLAN network, but it is implicitly driven by t= he MAG - LMA security relation, where the MAG attachment to the WLAN networ= k transitively allows the LMA to make the flow policy decisions based on th= e MAG identity. If the WLAN network is not trusted, there is truly no MAG i= n that network, where the LMA shares a security relation with that node. >=20 > There are still some open issues on this draft that needs to be discussed= in the WG. On the approaches to allow more a flow aggregate movement, tha= t is a discussion point. There are issues that we need to discuss, supporti= ng split link model, or eliminating some favorite brand of signaling messag= e (FMA) and riding on PBU/PBA and just with one FMI trigger, and on the asp= ects around MN applying the flow policies by flow mirroring. We have no agr= eement on those issues yet. >=20 > Its just a base draft, for further discussion and resolving those issues.= But, hope that is not a stopper for base draft selection. > =20 >=20 > Sri >=20 >=20 >=20 >=20 >=20 >=20 > On 2/1/11 6:39 PM, "stefano faccin" > wrote: >=20 > Raj, > thanks for the email. >=20 > I need to apologize in advance if my questions have already been answered= before (though I cannot find a conclusive answer anywhere). >=20 > I think that a protocol that is developed in NETEXT (or other groups) sho= uld have at least a potential realistic scenario for applicability. >=20 > In terms of applicability, though it is not part of the protocol definiti= on per se, unless there are solutions in place for either the host to indic= ate to the network where the flows should be routed or for the LMA to recei= ve somehow from somewhere some policies, the solution cannot really provide= flow mobility since there is no way to decide which flows are routed where= . If we are thinking about a host-based solution, I have not yet seen a sol= ution as to how the host can indicate to the MAG and ultimately to the MAG = which flows should be routed on each access. If we are relying on modificat= ions of layer 2 protocols, aren't we defining a solution that works only wi= th some technologies (since for other access technologies it is rather unre= alistic to modify L2 for IP flow mobility purposes)? If we are thinking of = an LMA-based solution, can we hear of at least one example of a real-life s= cenario where the LMA would receive such policies, and how such delivery wo= uld happen? Also, should there be a solution to have policies in the LMA, h= ow does the LMA actually decide to route flows on one access or the other? = E.g., if some flows need to be routed on certain WLAN networks, but shall n= ot be routed on other WLAN networks, how does the LMA know which specific W= LAN network the host is connected to? Perhaps I missed the ability for the = MAG to know e.g. the WLAN SSID and provide it to the LMA, in which case I w= ould appreciate if somebody could highlight to me where that is defined. >=20 > I think that, though not integral to the protocol specification, understa= nding what framework the protocol would/needs to fit in is rather important= .=20 >=20 > Cheers, > Stefano >=20 >=20 > On Tue, Feb 1, 2011 at 3:47 PM, > wrote: >=20 >=20 > Hello, >=20 > We have discussed the flow mobility solutions for Proxy MIP6 previously a= t > IETFs 78 and 79. > This is a consensus call for adopting this I-D: > draft-bernardos-netext-pmipv6-flowmob-02 > as the working group document. > I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt >=20 > The consensus call will expire on Feb 15th, 2011. Please indicate your > support or concerns in adopting this I-D as the WG baseline document on > the mailing list. >=20 > Please note that this I-D will serve as the baseline in the WG and will b= e > developed further based on input and feedback from WG members. >=20 > -Basavaraj >=20 > _______________________________________________ > netext mailing list > netext@ietf.org =20 > https://www.ietf.org/mailman/listinfo/netext >=20 > =20 >=20 >=20 >=20 >=20 >=20 > ---------------------------------------------------------------------=20 > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful.=20 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-Dp/7EQX2Dk90CFdHEa4B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1LNZ8ACgkQNdy6TdFwT2eAdwCgnZkaMuWrO40Gf9MnGgimY9kF y3cAnArrepzgnhiR0mB7VWZYyK46ej8p =/cQz -----END PGP SIGNATURE----- --=-Dp/7EQX2Dk90CFdHEa4B-- From sgundave@cisco.com Thu Feb 3 15:22:04 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEBB53A6AAE for ; Thu, 3 Feb 2011 15:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.913 X-Spam-Level: X-Spam-Status: No, score=-7.913 tagged_above=-999 required=5 tests=[AWL=-0.778, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Rs8Xc4bg3qc for ; Thu, 3 Feb 2011 15:21:40 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id C8B4A3A6A17 for ; Thu, 3 Feb 2011 15:21:40 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image.jpg, image.png, image.jpg, image.png : 722, 9011, 722, 9011 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuICAKPHSk2rR7H+/2dsb2JhbACCRZQMQIYJAYczZgJzogabAQKCeQEZgkMEhHmCI4RJgzODAYIXg1s Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 03 Feb 2011 23:25:03 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p13NP38Q023488; Thu, 3 Feb 2011 23:25:03 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Feb 2011 15:25:03 -0800 Received: from 171.70.228.143 ([171.70.228.143]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 Feb 2011 23:25:02 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 03 Feb 2011 15:25:34 -0800 From: Sri Gundavelli To: Stefano Faccin , "Giaretta, Gerardo" , stefano faccin Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLwmpURzmRlysrlUidlexdQorGZJPuBh2AgAAR4ICAAAzJgIAACkaAgADJ5gCAAKKGAP//oT5wgAEesLCAAAq77oAAADZggAAIIw8= In-Reply-To: <680854867F7FD04BB9B06EB8ACA8D5AC05E1F0CB@XCH02DFW.rim.net> Mime-version: 1.0 Content-type: multipart/related; boundary="B_3379591535_87756494" X-OriginalArrivalTime: 03 Feb 2011 23:25:03.0146 (UTC) FILETIME=[956DB8A0:01CBC3F9] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 03 Feb 2011 23:22:04 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3379591535_87756494 Content-type: multipart/alternative; boundary="B_3379591535_87738216" --B_3379591535_87738216 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Stefano, Sure. Closing the discussion, client-based vs network-based discussion. If there is wide-spread adoption of DSMIPv6 stack on all the operating systems= , we would not have needed any specification work. So, the model of client based model is fine, if we can solve the adoption issue. We need classification of the traffic based on some very high level parameters, to most part, the base information elements around access technology is sufficient. I=B9ve this set of Internet flows, which should break off when WLAN access is available. If any operator requires more complex policies, sure, they have the IFOM option and I agree with you, it can offer the solution. But, the goal of the spec is to support base set of features. Regards Sri On 2/3/11 3:01 PM, "Stefano Faccin" wrote: > Sri, > I am glad to hear that you also think that the network-based flow mobilit= y > solution cannot intrinsically provide all the features of the client-base= d > approach.=20 > =20 > I am also glad that you hear that access selection solutions in place tod= ay > are sci-fi. Why do you believe that an operator that wants e.g. to move t= he > voice traffic and video streaming to the WLAN APs it deploys (because it = can > offload them and can control QoS) may not want to move the same flows to = a > WLAN in a hotel where the user will get an awful user experience? Another > example: policies may be configured by an enterprise in the device so tha= t the > enterprise will allow the MN to direct some traffic on certain WLAN APs (= e.g. > the one the enterprise deploys) but not on other WLAN APs. I think the > per-access network scenarios are indeed more than realistic. Perhaps we=B9r= e > trying to oversimplify the scenarios just to fit the solution in them? > =20 > Stefano Faccin Standards ManagerResearch In Motion Corporation > 5000 Riverside Drive > Building 6, Brazos East, Ste. 100Irving, Texas 75039 USA > Office: (972) 910 3451 Internal: 820.63451: (510) 230 8422www.rim.com > E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0= 000/w > ww.rim.com> ; www.blackberry.com > E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0= 000/w > ww.blackberry.com> > > =20 > P Consider the environment before printing. > =20 >=20 > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Thursday, February 03, 2011 2:56 PM > To: Stefano Faccin; Giaretta, Gerardo; stefano faccin > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > Subject: Re: [netext] Consensus call to adopt I-D: > draft-bernardos-netext-pmipv6-flowmob as WG doc > =20 > Hi Stefano, >=20 > My point on the synchronized policy assumption still remains, as I=B9ve not= ed in > the other thread. >=20 > Therefore, if we want to provide a protocol for network based flow mobili= ty to > provide an alternative to existing solutions, we need to provide a soluti= on > that realistically provides the same functionality. >=20 > I will probably take a defensive stand on this. As I=B9ve stated before, I = do > not believe network-based mobility approaches can match client based > approaches 1:1, in every aspect. Its simply not possible, specially when = we > don=B9t have the needed MN-AR interface argument, for carrying Attachment > Preferences. But, most of the features that are practical from deployment > perspective (unlike some of the complex flow mobility scenarios, complexi= ty in > the order of science fiction moves :)), every thing else can be achieved = over > network-based approaches, with out any MN-AR interface. Hence, my argumen= t to > keep the specs simple > =20 > As as for simplified policies versus what current solutions already provi= de > (e.g. per access network policy and not just per access technology), why > should we go ahead with a solution that brings us back in time wrt what w= e can > provide to users and operators? Please note that even today (and not just > future releases of 3GPP or future IETF protocols) there are deployment > scenarios where the decisions to choose or not whether to route traffic o= ver a > certain WLAN is based on the specific WLAN (e.g. SSID) and not just on th= e > fact that the MN is connected to WLAN. >=20 > To large part, in the context of trusted non-3GPP access, basic flow mobi= lity > functions can be supported. We can break this down and bring some of the > aspects around network ownership, cost parameters and tie the flow policy > rules to it. But, I don=B9t think the goal is to support all such features. >=20 >=20 >=20 > Regards > Sri >=20 >=20 >=20 > On 2/3/11 2:22 PM, "Stefano Faccin" wrote: > Hi Sri, > I need to agree with the Gerardo. You are making an assumption that is > incorrect.Synchronizing policies between the MN and the LMA is not an eas= y and > scalable solution. I understand synchronizing policies between a MN and a > policy server that is the only repository for a given MN (i.e. one MN has= its > policy in a single policy server). Assuming that all the LMAs in a networ= k > that the MN can be connected to have synchronized policies with the MN is > clearly not realistic. >=20 > As as for simplified policies versus what current solutions already provi= de > (e.g. per access network policy and not just per access technology), why > should we go ahead with a solution that brings us back in time wrt what w= e can > provide to users and operators? Please note that even today (and not just > future releases of 3GPP or future IETF protocols) there are deployment > scenarios where the decisions to choose or not whether to route traffic o= ver a > certain WLAN is based on the specific WLAN (e.g. SSID) and not just on th= e > fact that the MN is connected to WLAN. > =20 > Therefore, if we want to provide a protocol for network based flow mobili= ty to > provide an alternative to existing solutions, we need to provide a soluti= on > that realistically provides the same functionality. > =20 > Cheers, > =20 > Stefano Faccin Standards ManagerResearch In Motion Corporation > 5000 Riverside Drive > Building 6, Brazos East, Ste. 100Irving, Texas 75039 USA > Office: (972) 910 3451 Internal: 820.63451: (510) 230 8422www.rim.com > E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0= 000/w > ww.rim.com> ; www.blackberry.com > E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0= 000/w > ww.blackberry.com> > >=20 > P Consider the environment before printing. >=20 >=20 > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of > Giaretta, Gerardo > Sent: Wednesday, February 02, 2011 9:14 PM > To: Sri Gundavelli; stefano faccin > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > Subject: Re: [netext] Consensus call to adopt I-D: > draft-bernardos-netext-pmipv6-flowmob as WG doc >=20 > Hi Sri, > =20 > There is no implicit assumption of synchronized policies. A basic example= that > shows that there is no assumption is the following: ANDSF policies may be > based also on location of the UE. For example the UE should prefer WLAN o= nly > in a given location. When the UE is attached over WLAN there is no way fo= r the > PDNGW/HA to verify the location of the UE and therefore to verify UE acti= ons > based on policies. > =20 > The assumption on synchronization of policies is only applicable to this = draft > and I think it is a wrong one. > =20 > Cheers > Gerardo > =20 >=20 > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of > Sri Gundavelli > Sent: Wednesday, February 02, 2011 6:50 PM > To: stefano faccin > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > Subject: Re: [netext] Consensus call to adopt I-D: > draft-bernardos-netext-pmipv6-flowmob as WG doc >=20 > Hi Stefano, >=20 > One comment. >=20 > Agree with you there is no ANDSF interface to the network node, but the > assumption of synchronized policies between the ANDSF server and the PDN = GW/HA > is there, implicitly IMO. With out this assumption, I do not know, how th= e HA > can ever validate the flow mobility options received in the BU. If the > operator requires any control on enforcing a flow policy rule, the PDN GW= /HA > needs to have synchronized policies, without which its always the client > decision. I=B9m not sure, operators in 3GPP would like that :) >=20 > No doubt, the lack of MN-AR interface is surely an issue for supporting > complex flow policies. I realize the issues and I agree with you. But, th= e > assumption of synchronized policies can offer some solution with some > configuration requirement on the HA (assuming there are no other issues). > There are also the proposals on flow mirroring on the UE ..., requiring n= o > flow policies. I=B9ve not evaluated this, however. Folks can comment on thi= s. >=20 > It is also to be noted, for some of the scenarios such, there is no flow > policy interface needed. We can identify what scenarios create any > configuration limitations on the HA and which one=B9s do not . As I=B9ve note= d > earlier, this is surely an open issue, that we need to discuss in the WG. >=20 >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 > =20 >=20 >=20 > On 2/2/11 9:08 AM, "stefano faccin" wrote: > Sri, > thanks for the reply. Can you clarify in which system or scenario ANDSF i= s > available to network entities as well? There is no such availability in 3= GPP, > and making such information available would require considerable architec= tural > changes, therefore the applicability of this solution to what seems to be= the > only realistic scenario hinges on 3GPP making considerable architectural > changes. I would therefore not be so hastily concluding that the ANDSF > information is available to the LMA and underestimate what it would reall= y > take to make the solution applicable. >=20 > If we cannot guarantee that there is at least one realistic solution to h= ave > the MNa nd LMA in synch, how do we expect that this solution is applicabl= e at > all? In 3GPP there is no need to have such implicit assumption, be cause = 1) > the MN is provided policies explicitly through the ANDSF, and 2) it is th= e MN > and only the MN that makes IP flow mobility decisions and communicates th= em > explicitly (with well defined signalling) to the LMA, and therefore no ma= gic > is needed. There is no need in 3GPP to have the ANDSF and PDN GW policies > synchronized, since the PDN GW does not use such policies. >=20 > Sri, in the end it is a matter of whether we develop a solution that will= rely > on some unknown magic to be deployed, or a solution that we know can be > deployed in at least one way because there are solutions to what I consid= er > major open issues. >=20 > Cheers, > Stefano >=20 > On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli wrote= : > Hi Stefano, >=20 > Thanks for the discussion. >=20 > As you say, the ANDSF policies are allowing the MN a.) to make the right > network attachment decision and b.) make the access selection on a flow b= asis. > This same policy that is present in the ANDSF server, is available for th= e > network nodes as well. I=B9m not sure, with out this assumption the solutio= n can > work for all currently listed cases. We clearly need the MN and the LMA t= o be > in synch with respect to the configured policy. How, that is done, I gues= s we > will not try to know. I thought even in 3GPP, this is the implied assump= tion > ? But, this is for you to clarify. Not specifically for IFOM where UE and= PDN > GW/HA are negotiating the flow policies, but generally that the PDN GW an= d the > ANDSF policy server will have synchronized policies. The MAG and the LMA = have > the ability to carry this flow policy information in signaling messages a= nd > influence the access selection. The policy is a opaque object, with exten= sible > formats, when carried in the signaling plane, should allow the LMA/MAG to > apply those access policies, while assuming MN is following the same rule= s. > These policies can surely reflect the specific WLAN access/operator speci= fic > rule. I=B9m surely with you, the lack of MN-AR interface is surely an issue= and > I see that. But, we need to understand, what are the limitations with the > approach of out of band policy interfaces and what will be the solution > limitations. If we need to tie the flow movement at the prefix granularit= y and > rely on the natural ND interface in the form of RA PIO option, more like = PDN > offload in MAPCON, or at the granularity of a flow level, is open for > discussion. I want to simplify this draft for sure, we can surely discuss= each > of these issues on the WG draft. >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 >=20 >=20 > On 2/1/11 8:29 PM, "stefano faccin" > wrote: > Sri, > thanks for the reply. >=20 > I'd like to comment on the "the flow policy decisions need not be based o= n the > specific WLAN network". Does it mean, as I believe it does, that the curr= ent > solution would not allow an operator deploying such solution to decide to > route flows over a specific WLAN or not depending on which specific WLAN = the > MN is connected to? E.g. the operator or the entity in control of the > decisions for the routing may want to direct certain traffic always over = WLANs > that the operator deploys, and instead route only some of the traffic ove= r > WLANs of roaming partners or of the MN user home. How does this solution > support that scenario if the LMA is not told specifically which WLAN the = MN is > connected to? From a deployment point of view, I do not believe we can af= ford > to leave out this scenario. Please note that the establishment of a secur= ity > relationship between the MN and the MAG, and a specific MAG identity, can= not > guarantee that the LMA knows which specific WLAN access network the MN is > connected to. Assuming that would severely restrict the deployment scenar= ios. >=20 > As for the MN and the LMA being magically in synch, I am very concerned a= bout > a "glass ball" solution. You mention ANDSF defined by 3GPP as a solution = for > this "out of band" delivery of policy. Fair enough, however there is an i= ssue > with that. ANDSF is designed specific to be a MN-centric solution where > policies are provisioned in the MN and the MN decides which network > technologies and access networks it needs to connect to, under what > conditions, and which IP traffic needs to be routed on such accesses. No = IP > point of attachment in the network (i.e. the PDN GW in 3GPP that is the L= MA in > PMIPv6) is aware under any conditions of such policy. Therefore, even if = in > order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would > unfortunately not provide a solution unless the MN can communicate to the= MAG > and the LMA the decisions the MN has taken based on the ANDSF policies. >=20 > I believe the key point here is that we need to understand how the soluti= on > can be realistically applied to a real scenario, and that we need to ensu= re > that important and realistic deployment scenarios are not excluded by the > solution. >=20 > Cheers, > Stefano >=20 > On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli > wrote: > Hi Stefano: >=20 > These are valid points and some good comments. Let me share my thoughts. >=20 > Carlo=B9s draft is not assuming any new MN-AR interface. Its going with the > assumption there is established policy on the mobile and on the LMA, whic= h > allows the mobile to select the access network at a flow level granularit= y, > without requiring any explicit signaling between the MAG and the MN. To l= arge > part this is all about out of band policy interface, such as ANDSF, towar= ds > the UE, leading to the assumption that magically the MN and the LMA are i= n > sync with respect to flow policies, access selection and they will make t= he > right forwarding decision. Secondly, the flow policy decisions need not b= e > based on the specific WLAN network, but it is implicitly driven by the MA= G =AD > LMA security relation, where the MAG attachment to the WLAN network > transitively allows the LMA to make the flow policy decisions based on th= e MAG > identity. If the WLAN network is not trusted, there is truly no MAG in th= at > network, where the LMA shares a security relation with that node. >=20 > There are still some open issues on this draft that needs to be discussed= in > the WG. On the approaches to allow more a flow aggregate movement, that = is a > discussion point. There are issues that we need to discuss, supporting sp= lit > link model, or eliminating some favorite brand of signaling message (FMA)= and > riding on PBU/PBA and just with one FMI trigger, and on the aspects aroun= d MN > applying the flow policies by flow mirroring. We have no agreement on tho= se > issues yet. >=20 > Its just a base draft, for further discussion and resolving those issues.= But, > hope that is not a stopper for base draft selection. >=20 >=20 > Sri >=20 >=20 >=20 >=20 >=20 >=20 > On 2/1/11 6:39 PM, "stefano faccin" > wrote: > Raj, > thanks for the email. >=20 > I need to apologize in advance if my questions have already been answered > before (though I cannot find a conclusive answer anywhere). >=20 > I think that a protocol that is developed in NETEXT (or other groups) sho= uld > have at least a potential realistic scenario for applicability. >=20 > In terms of applicability, though it is not part of the protocol definiti= on > per se, unless there are solutions in place for either the host to indica= te to > the network where the flows should be routed or for the LMA to receive so= mehow > from somewhere some policies, the solution cannot really provide flow mob= ility > since there is no way to decide which flows are routed where. If we are > thinking about a host-based solution, I have not yet seen a solution as t= o how > the host can indicate to the MAG and ultimately to the MAG which flows sh= ould > be routed on each access. If we are relying on modifications of layer 2 > protocols, aren't we defining a solution that works only with some > technologies (since for other access technologies it is rather unrealisti= c to > modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-ba= sed > solution, can we hear of at least one example of a real-life scenario whe= re > the LMA would receive such policies, and how such delivery would happen? = Also, > should there be a solution to have policies in the LMA, how does the LMA > actually decide to route flows on one access or the other? E.g., if some = flows > need to be routed on certain WLAN networks, but shall not be routed on ot= her > WLAN networks, how does the LMA know which specific WLAN network the host= is > connected to? Perhaps I missed the ability for the MAG to know e.g. the W= LAN > SSID and provide it to the LMA, in which case I would appreciate if someb= ody > could highlight to me where that is defined. >=20 > I think that, though not integral to the protocol specification, understa= nding > what framework the protocol would/needs to fit in is rather important. >=20 > Cheers, > Stefano >=20 >=20 > On Tue, Feb 1, 2011 at 3:47 PM, > > wrote: >=20 > Hello, >=20 > We have discussed the flow mobility solutions for Proxy MIP6 previously a= t > IETFs 78 and 79. > This is a consensus call for adopting this I-D: > draft-bernardos-netext-pmipv6-flowmob-02 > as the working group document. > I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt >=20 > The consensus call will expire on Feb 15th, 2011. Please indicate your > support or concerns in adopting this I-D as the WG baseline document on > the mailing list. >=20 > Please note that this I-D will serve as the baseline in the WG and will b= e > developed further based on input and feedback from WG members. >=20 > -Basavaraj >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext >=20 > =20 > =20 > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-publi= c > information. Any use of this information by anyone other than the intende= d > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from y= our > system. Use, dissemination, distribution, or reproduction of this transmi= ssion > by unintended recipients is not authorized and may be unlawful. > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-publi= c > information. Any use of this information by anyone other than the intende= d > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from y= our > system. Use, dissemination, distribution, or reproduction of this transmi= ssion > by unintended recipients is not authorized and may be unlawful. --B_3379591535_87738216 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmi= pv6-flowmob as WG doc Hi Stefano,

Sure. Closing the discussion, client-based vs network-based discussion. If = there is wide-spread adoption of DSMIPv6 stack on all the operating systems,= we would not have needed any specification work. So, the model of client ba= sed model is fine, if we can solve the adoption issue.

We need classification of the traffic based on some very high level paramet= ers, to most part, the base information elements around access technology is= sufficient. I’ve this set of Internet flows, which should break off w= hen WLAN access is available. If any operator requires more complex policies= , sure, they have the IFOM option and I agree with you, it can offer the sol= ution. But, the goal of the spec is to support base set of features.


Regards
Sri


On 2/3/11 3:01 PM, "Stefano Faccin" <sfaccin@rim.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Sri,
I am glad to hear that you also think that the network-based flow mobility = solution cannot intrinsically provide all the features of the client-based a= pproach.
 
I am also glad that you hear that access selection solutions in place today= are sci-fi. Why do you believe that an operator that wants e.g. to move the= voice traffic and video streaming to the WLAN APs it deploys (because it ca= n offload them and can control QoS) may not want to move the same flows to a= WLAN in a hotel where the user will get an awful user experience? Another e= xample: policies may be configured by an enterprise in the device so that th= e enterprise will allow the MN to direct some traffic on certain WLAN APs (e= .g. the one the enterprise deploys) but not on other WLAN APs. I think the p= er-access network scenarios are indeed more than realistic. Perhaps we’= ;re trying to oversimplify the scenarios just to fit the solution in them?  
Stefano Faccin Standards ManagerResearch In Motion Corporation
5000 Riverside Drive
Building 6, Brazos East, Ste. 100Irving, Texas 75039 USA
Office: (972) 910 3451  Internal: 820.63451: (510) 230 8422www.rim.com <outbind://28-= 00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB= 000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.rim.com= > ; www.blackberry.com <outbind://28-0000= 0000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB0000= 01B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.blackberry.= com>
<http://www.blackberry.com/>

P Consider the environment before printing.

From: Sri Gundavelli [mailto:sgundave@cisco.com]
Sent: Thursday, February 03, 2011 2:56 PM
To: Stefano Faccin; Giaretta, Gerardo; stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-n= etext-pmipv6-flowmob as WG doc
Hi Stefano,

My point on the synchronized policy assumption still remains, as I’ve= noted in the other thread.

Therefore, if we want to provide a protocol for netwo= rk based flow mobility to provide an alternative to existing solutions, we n= eed to provide a solution that realistically provides the same functionality= .

I will probably take a defensive stand on this. As I’ve stated before= , I do not believe network-based mobility approaches can match client based = approaches 1:1, in every aspect. Its simply not possible, specially when we = don’t have the needed MN-AR interface argument, for carrying Attachmen= t Preferences. But, most of the features that are practical from deployment = perspective (unlike some of the complex flow mobility scenarios, complexity = in the order of science fiction moves :)), every thing else can be achieved = over network-based approaches, with out any MN-AR interface. Hence, my argum= ent to keep the specs simple
 
As as for simplified policies versus what current sol= utions already provide (e.g. per access network policy and not just per acce= ss technology), why should we go ahead with a solution that brings us back i= n time wrt what we can provide to users and operators? Please note that even= today (and not just future releases of 3GPP or future IETF protocols= ) there are deployment scenarios where the decisions to choose or not whethe= r to route traffic over a certain WLAN is based on the specific WLAN (e.g. S= SID) and not just on the fact that the MN is connected to WLAN.

To large part, in the context of trusted non-3GPP access, basic flow mobili= ty functions can be supported. We can break this down and bring some of the = aspects around network ownership, cost parameters and tie the flow policy ru= les to it. But, I don’t think the goal is to support all such features= .



Regards
Sri



On 2/3/11 2:22 PM, "Stefano Faccin" <sfaccin@rim.com> wrote:
Hi Sri,
I need to agree with the Gerardo. You are making an assumption that is inco= rrect.Synchronizing policies between the MN and the LMA is not an easy and s= calable solution. I understand synchronizing policies between a MN and a pol= icy server that is the only repository for a given MN (i.e. one MN has its p= olicy in a single policy server). Assuming that all the LMAs in a network th= at the MN can be connected to have synchronized policies with the MN is clea= rly not realistic.

As as for simplified policies versus what current solutions already provide= (e.g. per access network policy and not just per access technology), why sh= ould we go ahead with a solution that brings us back in time wrt what we can= provide to users and operators? Please note that even today (and not= just future releases of 3GPP or future IETF protocols) there are deployment= scenarios where the decisions to choose or not whether to route traffic ove= r a certain WLAN is based on the specific WLAN (e.g. SSID) and not just on t= he fact that the MN is connected to WLAN.
 
Therefore, if we want to provide a protocol for network based flow mobility= to provide an alternative to existing solutions, we need to provide a solut= ion that realistically provides the same functionality.
 
Cheers,
 
Stefano Faccin Standards ManagerResearch In Motion Corporation
5000 Riverside Drive
Building 6, Brazos East, Ste. 100Irving, Texas 75039 USA
Office: (972) 910 3451  Internal: 820.63451: (510) 230 8422www.rim.com <outbind://28-= 00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB= 000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.rim.com= > ; www.blackberry.com <outbind://28-0000= 0000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB0000= 01B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.blackberry.= com>
<http://www.blackberry.com/>

P Consider the environment before printing.


From: netext-bounces@ietf.org [mailt= o:netext-bounces@ietf.org] On Behalf Of Giaretta, Gerardo
Sent: Wednesday, February 02, 2011 9:14 PM
To: Sri Gundavelli; stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-n= etext-pmipv6-flowmob as WG doc

Hi Sri,
 
There is no implicit assumption of synchronized policies. A basic example t= hat shows that there is no assumption is the following: ANDSF policies may b= e based also on location of the UE. For example the UE should prefer WLAN on= ly in a given location. When the UE is attached over WLAN there is no way fo= r the PDNGW/HA to verify the location of the UE and therefore to verify UE a= ctions based on policies.
 
The assumption on synchronization of policies is only applicable to this dr= aft and I think it is a wrong one.
 
Cheers
Gerardo
 

From: netext-bounces@ietf.org [mailt= o:netext-bounces@ietf.org] On Behalf Of Sri Gundavelli
Sent: Wednesday, February 02, 2011 6:50 PM
To: stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-n= etext-pmipv6-flowmob as WG doc

Hi Stefano,

One comment.

Agree with you there is no ANDSF interface to the network node, but the ass= umption of synchronized policies between the ANDSF server and the PDN GW/HA = is there, implicitly IMO. With out this assumption, I do not know, how the H= A can ever validate the flow mobility options received in the BU. If the ope= rator requires any control on enforcing a flow policy rule, the PDN GW/HA ne= eds to have synchronized policies, without which its always the client decis= ion. I’m not sure, operators in 3GPP would like that :)

No doubt, the lack of MN-AR interface is surely an issue for supporting com= plex flow policies. I realize the issues and I agree with you. But, the assu= mption of synchronized policies can offer some solution with some configurat= ion requirement on the HA (assuming there are no other issues). There are al= so the proposals on flow mirroring on the UE ..., requiring no flow policies= . I’ve not evaluated this, however. Folks can comment on this.

It is also to be noted, for some of the scenarios such, there is no flow po= licy interface needed. We can identify what scenarios create any configurati= on limitations on the HA and which one’s do not . As I’ve noted = earlier, this is surely an open issue, that we need to discuss in the WG.


Regards
Sri




 


On 2/2/11 9:08 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:
Sri,
thanks for the reply. Can you clarify in which system or scenario ANDSF is = available to network entities as well? There is no such availability in 3GPP= , and making such information available would require considerable architect= ural changes, therefore the applicability of this solution to what seems to = be the only realistic scenario hinges on 3GPP making considerable architectu= ral changes. I would therefore not be so hastily concluding that the ANDSF i= nformation is available to the LMA and underestimate what it would really ta= ke to make the solution applicable.

If we cannot guarantee that there is at least one realistic solution to hav= e the MNa nd LMA in synch, how do we expect that this solution is applicable= at all? In 3GPP there is no need to have such implicit assumption, be cause= 1) the MN is provided policies explicitly through the ANDSF, and 2) it is t= he MN and only the MN that makes IP flow mobility decisions and communicates= them explicitly (with well defined signalling) to the LMA, and therefore no= magic is needed. There is no need in 3GPP to have the ANDSF and PDN GW poli= cies synchronized, since the PDN GW does not use such policies.

Sri, in the end it is a matter of whether we develop a solution that will r= ely on some unknown magic to be deployed, or a solution that we know can be = deployed in at least one way because there are solutions to what I consider = major open issues.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli <sgundave@cisco.com> wrote:
Hi Stefano,

Thanks for the discussion.

As you say, the ANDSF policies are allowing the MN a.) to make the right ne= twork attachment decision and b.) make the access selection on a flow basis.= This same policy that is present in the ANDSF server, is available for the = network nodes as well. I’m not sure, with out this assumption the solu= tion can work for all currently listed cases. We clearly need the MN and the= LMA to be in synch with respect to the configured policy. How, that is done= , I guess we will not try to know.  I thought even in 3GPP, this is the= implied assumption ? But, this is for you to clarify. Not specifically for = IFOM where UE and PDN GW/HA are negotiating the flow policies, but generally= that the PDN GW and the ANDSF policy server will have synchronized policies= . The MAG and the LMA have the ability to carry this flow policy information= in signaling messages and influence the access selection. The policy is a o= paque object, with extensible formats, when carried in the signaling plane, = should allow the LMA/MAG to apply those access policies, while assuming MN i= s following the same rules. These policies can surely reflect the specific W= LAN access/operator specific rule. I’m surely with you, the lack of MN= -AR interface is surely an issue and I see that. But, we need to understand,= what are the limitations with the approach of  out of band policy inte= rfaces and what will be the solution limitations. If we need to tie the flow= movement at the prefix granularity and rely on the natural ND interface in = the form of RA PIO option, more like PDN offload in MAPCON, or at the granul= arity of a flow level, is open for discussion. I want to simplify this draft= for sure, we can surely discuss each of these issues on the WG draft.


Regards
Sri






On 2/1/11 8:29 PM, "stefano faccin" <sfaccinstd@gmail.com <htt= p://sfaccinstd@gmail.com> > wrote:
Sri,
thanks for the reply.

I'd like to comment on the "the flow policy decisions n= eed not be based on the specific WLAN network". Does it mean, as I beli= eve it does, that the current solution would not allow an operator deploying= such solution to decide to route flows over a specific WLAN or not dependin= g on which specific WLAN the MN is connected to? E.g. the operator or the en= tity in control of the decisions for the routing may want to direct certain = traffic always over WLANs that the operator deploys, and instead route only = some of the traffic over WLANs of roaming partners or of the MN user home. H= ow does this solution support that scenario if the LMA is not told specifica= lly which WLAN the MN is connected to? From a deployment point of view, I do= not believe we can afford to leave out this scenario. Please note that the = establishment of a security relationship between the MN and the MAG, and a s= pecific MAG identity, cannot guarantee that the LMA knows which specific WLA= N access network the MN is connected to. Assuming that would severely restri= ct the deployment scenarios.

As for the MN and the LMA being magically in synch, I am very concerned abo= ut a "glass ball" solution. You mention ANDSF defined by 3GPP as a= solution for this "out of band" delivery of policy. Fair enough, = however there is an issue with that. ANDSF is designed specific to be a MN-c= entric solution where policies are provisioned in the MN and the MN decides = which network technologies and access networks it needs to connect to, under= what conditions, and which IP traffic needs to be routed on such accesses. = No IP point of attachment in the network (i.e. the PDN GW in 3GPP that is th= e LMA in PMIPv6) is aware under any conditions of such policy. Therefore, ev= en if in order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF = would unfortunately not provide a solution unless the MN can communicate to = the MAG and the LMA the decisions the MN has taken based on the ANDSF polici= es.

I believe the key point here is that we need to understand how the solution= can be realistically applied to a real scenario, and that we need to ensure= that important and realistic deployment scenarios are not excluded by the s= olution.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli <sgundave@cisco.com <http://s= gundave@cisco.com> > wrote:
Hi Stefano:

These are valid points and some good comments. Let me share my thoughts.
Carlo’s draft is not assuming any new MN-AR interface. Its going with= the assumption there is established policy on the mobile and on the LMA, wh= ich allows the mobile to select the access network at a flow level granulari= ty, without requiring any explicit signaling between the MAG and the MN. To = large part this is all about out of band policy interface, such as ANDSF, to= wards the UE, leading to the assumption that magically the MN and the LMA ar= e in sync with respect to flow policies, access selection and they will make= the right forwarding decision. Secondly, the flow policy decisions need not= be based on the specific WLAN network, but it is implicitly driven by the M= AG – LMA security relation, where the MAG attachment to the WLAN netwo= rk transitively allows the LMA to make the flow policy decisions based on th= e MAG identity. If the WLAN network is not trusted, there is truly no MAG in= that network, where the LMA shares a security relation with that node.

There are still some open issues on this draft that needs to be discussed i= n the WG.  On the approaches to allow more a flow aggregate movement, t= hat is a discussion point. There are issues that we need to discuss, support= ing split link model, or eliminating some favorite brand of signaling messag= e (FMA) and riding on PBU/PBA and just with one FMI trigger, and on the aspe= cts around MN applying the flow policies by flow mirroring. We have no agree= ment on those issues yet.

Its just a base draft, for further discussion and resolving those issues. B= ut, hope that is not a stopper for base draft selection.


Sri






On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <htt= p://sfaccinstd@gmail.com>  <http://sfaccinstd@gmail.com> > wrote:
Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicate= to the network where the flows should be routed or for the LMA to receive s= omehow from somewhere some policies, the solution cannot really provide flow= mobility since there is no way to decide which flows are routed where. If w= e are thinking about a host-based solution, I have not yet seen a solution a= s to how the host can indicate to the MAG and ultimately to the MAG which fl= ows should be routed on each access. If we are relying on modifications of l= ayer 2 protocols, aren't we defining a solution that works only with some te= chnologies (since for other access technologies it is rather unrealistic to = modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-based= solution, can we hear of at least one example of a real-life scenario where= the LMA would receive such policies, and how such delivery would happen? Al= so, should there be a solution to have policies in the LMA, how does the LMA= actually decide to route flows on one access or the other? E.g., if some fl= ows need to be routed on certain WLAN networks, but shall not be routed on o= ther WLAN networks, how does the LMA know which specific WLAN network the ho= st is connected to? Perhaps I missed the ability for the MAG to know e.g. th= e WLAN SSID and provide it to the LMA, in which case I would appreciate if s= omebody could highlight to me where that is defined.

I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important. <= BR>
Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM,  <Basavaraj.Patil@nokia.com <http://Basavaraj.Patil@nokia.com>  <http://Basavaraj.Patil@nokia.com> > wrote:
Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= BR> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt<= /a>

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= BR> developed further based on input and feedback from WG members.

-Basavaraj

_______________________________________________
netext mailing list
netext@ietf.org <http://netext@ietf.org>  <http://netext@ietf.org>
https://www.ietf.org= /mailman/listinfo/netext
  
 
------------------------------------------------------------= ---------
This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor-= client or other applicable privileges), or constitute non-public information= . Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use, = dissemination, distribution, or reproduction of this transmission by uninten= ded recipients is not authorized and may be unlawful.
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor-= client or other applicable privileges), or constitute non-public information= . Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use, = dissemination, distribution, or reproduction of this transmission by uninten= ded recipients is not authorized and may be unlawful.
--B_3379591535_87738216-- --B_3379591535_87756494 Content-Type: image/jpeg; name="image.jpg" Content-ID: <3379591534_87734428> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8l JCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIo Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAAR CAAKAA4DASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDSu9NvV0vVpbjQL2KfU7xR5T6qqmRclsrn hecDFbGl6hqL69Noem63ZRQ6faops5Y2mmiYBQdz8BuSR1qD4pxpLdeHo5UV0N2cqwyD93tX exW0ELtJFBGjv95lQAt9T3oA/9k= --B_3379591535_87756494 Content-Type: image/png; name="image.png" Content-ID: <3379591534_87726402> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAIoAAAA+CAIAAAB7vhRQAAAAAXNSR0IArs4c6QAAAAlwSFlz AAAOxAAADsQBlSsOGwAAIthJREFUeF7tfAeYHdWV5q1b8eXXudXKoAyIIH1IgESwMTKDSDZe bNKsZa8/xh8MNgxj1mYxLGZtgseDDcwABsb2YH9ggglDMAiEyCIMEkkSCOWW1Orw8qt0b+1/ ql4/tbJEN9t8OxSPp3rVFc+555z//OfcUtjwLZyxAB/8I8ObUMLfGmNCYYES/Yq+63/ETyz1 LdH6Hvbh4RXCwxX8I2vrOH3tSNqK1W2X7j/78Ill4JWj5x2epaaeSPZ1qdPPUKpDs9TUs93J drhcXflDc8X/T8+CAQ65QWef7dJ/DbV+mf4hqjO2beNnexP7evbhtJ6d7xGOLc30pKpLJjh5 nMEtsBw1kIH0hfRZUGXS7fejkUMV0elxVfyQpBts9wZ3zaE9etAiGPTtbIsciqIFwXg1Mbtp kukFYkj8mxJIJv1AQtt24FUDv2rbObfQy7xe6Zajm4dawrj0OXRyw68euBQasByxm9RzmN5w ZHysXvZ2Np4IBezPgt0FziMVnFuRipRcVVTF80XOlJ1Bpada6HKKBSagGjjW2ngYkmGxP3e5 h32H2dlCfpFrCWOOYgTsEKO1mZmKH4TOTYm+EZbqPyHpaAtW9rBPwBQ1YDzA3gHgGcdvEQRC qjLgMlClbFStsWa2XUvEGPdEFffgq5zJz5Ny9ns4DtGgqJ0GFiOZyZgD7xJ6mIRkp6cnZ3wd GovA9iAWIHboxYdiAtK1VELpS5iKpsSEwt1wi8bzOlsjc+9UOrtxB3VXO4gLD+Ghw2o9oavC Hfj0D9lDo9QPNVpMH0Kt+5pP+bBwaQFXuEwF3GO8wgKLC2jLNgwWuDGcXdU8FQZIMc5PGNaI RNat5l0W+NGVDTJqstPo+vQP7pTEFW4kkBnZfKTQMEnAV/jvtsM+5c3XDxtu9URZYaSeIGhX E1P0BtUVUuHkmsLH/bQfWA9XpMG5w3mF+xlViWvcF76tsWygWK6iicDAh3ELu5k8meXpXr+U IzkbiFdhwqzhJAFpJfSoFMLwk/TCSUHQN6kpUlWo1iH2jcOnnn43su2BJBsXbxwDD+d6gabC fsIIM7gPsxVeIbGKRilMRfV9WRIycPA//Qefx6AxSL3ienHDsiXbKMsMcI90QzKHa+y3EODw SAF0y+H2yHhgaBBjDaX32xp8Nv40WA+9n1BosMa60/EDfD0g3DGZ8Qfb8ELMh3qG4FqQshuo NqEJdxzQhuQbmjsc3/cRegLmqTBSSBF64tyHm1OCSlJ9Nd/TY4uqChjJkH9BC+CYYNyBp1Rt GFWAw30xUPCRkgaqB9oibipy24NZhlU90cX7zadZs2anx4wra1wEQ6QeISFftQwHJbyRrl9o G1ued1qHLXPkqHTJJf4AyStCCkVVgRrcGN/Iq1vsfCEIDENTfYGI5UFRAVd9U2B3qZYroq9Q 6S3wrm73veV9FQCbmslggJnYVVFsYMTBaKV+7LCqZ8ATYLCNt1IzzI4OV/dcT+j6oK1HQKaA 0KriBBwDPuspXVOP8A6dAyvqczyLKSaoPWgoCuTwcnBkUmM2l+vL+T78TSXlQTVkPdAwTDGk alVV182UZLphGlXbXdvtvfpm5ePldsmDyQB7AhpWB6a6g9HT8MWe7UeIxdhIJd6hpmMe/AYH 6Br0wAkQtxURI96Ae8DWUs1PODiebMhJ3ZXCkkEyCDRIWUodbiwI9EDRmQBE0asiKApfKpoC G0A2S7icQADpDw7LF7YD8qFUKuZ5UMlkxWEHJVoam/K91VK5CtRJHhPLYOMOneNzpJ7RVqZN TZquj2GKYABRcNFPXRMHF3lBCH27TzjoMbjDuE0SQcZEcEKEyEqVJlMxlitSqJrFD5jabCSQ gSIrtSBvsgYcgDPjULg7rGOroRY1v1faPiwa8JwjRgUCvo3DlkhfgiuGYZIqQ3ARuKJcqI4e bY4+INFbKG/tiTBBPNTPYIHccKonKihEfiCl8AOtxgbgYMQLxdAgD8arhi9U6MV3VaEHXpwM S0V8hyGE3xwUgIbwLuHpdQQRgW0QvYqggi8SO4Vw7CVjbuClmt2JByX0uOv7psI5Zy6cFwcg QKzDChcC+ADy17ijyB7XJkRNtAQCIWmcSV1wrGnwb67nwbp0AyRUoPksnmQ9hUos5s6c0dy9 2d7SjcdKhuigPy59Wgc3aA//aS/cH05rxycUtYHFFV8Knfu6qgeq5SvIUDyOtF94ug8MnILi yEoge8QDaIf8Hwa3RtEBnBoxOIFKPo1clMI0IQIV5J3p+yMVpsazRT21STEKwquqVO7TVaFx MAdCVel0+EAd+AluSbU8FhPc8EjthkcFKD1wLGHrim0EXkwNDEjOR/YMolCtYucYCxzJ8uUz Tkq0QjWspCiDhW3D7NxqGV2Irdu4OUrPxMD7g/lHFAiEJjFylbSjxzyzymI+h7tgtpn3NN/T hVB9T3U9zXORXKq+JRwdQV1xFcVD+AZdI7jucoOrCDMSwVyyraMPVEaNM1y/xJGH1vJ/KBXA TYXwWYDBrsPwYLalwO/yq74BuEAWFLIE8Lak0uiDhf5FPoXxIaFr7EjUkRRBIq1WpbFqjT0k zm04rYd8M54vhKAZNW4oOp5cwsErAnIXGtM8riNmMAPS9aRflkKr6pqrKRUDOhS26dsxz447 +Pa49FWiviEWTxGu6vlGVcR9G5ahStf1PSeTbGZ+UlbjikyhxsAk4K8bSA80HOAD0aZS00AH BEDjvkdWqbrIh8APMFWDqYa8QY3TIe3U2AJKU8MclaIY94uFypSpMQMYe7tM6FM6mV3HnjBM 7t8y8JD9PRxjZHK8oVVJaJTBBxY4A6l1uvl8YPeygs2KCVMkY7aluczVbGFrgYEYA0emBDrk hKFb1dQi1GUqqZhiqm5cF5bhW7qIm25Mh3SrmUbnoMMbzWSFaDfdZLxk6GVVRX5FsYch52S+ DACqwTKIQmB3o0JkIPIjlCkYJwQa4P52LGiQI4U/hFtEhFQQmngAbWcakytXy3x+CJzbbtVw ySWXnHvuucuWLbvyyis3b968V11FKom+ETCj/esr9cN1Xfc87/jjj7/22muF5137s58tfO45 uK1TUpNbhaa5wtWVmMs3id5JX/nKOddcVu3deufPfsRWvP+tL83u9HuThx1+0FFz0uMPhC8K wDyHIAkykqZR2fTxsof+zV2zrNkSik+igWB9jsCD8CBEbOv0WY026wJe84HoRIoJi7wnRC8V DArHAVz2pes7rreqVFleZFqCIfkC6PbhvuC5iELYUVxECwmDaa7PmerD0MkejWzmwSe8d5ZW 9iq0ve6w3fXqwh05cuSGDRuig2+//fYLL7xwdyci/xsqIzoWgEgigMOlAzgRbagIsYv8edGi Rccddxz2f/fdd08+dX7v2nXfaj4sWXA0wSqQh+0lJh1w5ZN/yh7QhH1eeeTeRy757twJDelj jpn1kztNI7u7mym889Qj/7igI+GbQGUE2zSHJRSNV7zubIeceEhDNegBVgMhEAYScNXEe4Ll ZICCBOXBw6LOwPLSX1u0t/ZWK4WgDHSQYm5UaoiiDT1tffzBh4XqUeGKgScxZmRgJha/pS5c VNir9Pe6w65jz4QJE3Ck4xAuPO200/ZwloGGgnUoA9/QDQ1eKXepG/zJNMEYMtfxJk6YOHnS BHCKloockGhI7gc5Zp/ygwXQjY0kL2CZTEvLyLEl3z/2ssugm4rwkTaWA4YPUhhHSlfKcohg Y9kW3UggaxeSu4HuKDGQXhwkmV1pa0xRsMAVgIwlyn40rNCIQBgQJ2BVIcuBKMqgLJSCqdlT WpMzxzbMmtg4MqOVy6RtSrAoSwrNtT/ehAEozD/DqhKNT8L+pOohWbZTDyQbGUEk30j0kSh3 ucyePfsPf/jDzTfffMcdd8BfYZ9Jkyb95je/ufXWW2+77bYzzjhj5yA00PsZJjJ2ZCe8mSWE 42JEAgP1+bmDTjnuhL/7ZgkZkabi6Tdt3NKzsThu9ldYehJaOpBn6lxJKLALFuPM5MBnPEH3 6L/86P0lpxRoBhg0Qm4YzcB1fgWxJdVgSkgf8iMyvErx3wdmxpBA6FJNRdNBgRKoJmihigpz +jKB0Z6MHz65beqkNLIk4YZZrI6UGfKJKGtKlQNVEMGNcwVSU6TnMcM0C7khCDx4JAS97ZZI MdFioHTV77UG7qRpGjgsbDn77LPPO++86E8IVIlEAkq66KKLoi3z589/++23161bVz82Cjx1 xVNXIIjgwBtjNRgeYJPquU4P87932/XYBzaR0Hi5u/D23XePMTZZo1sYa3Q4s+CNyptfeuwP aQvjGDCaiqJm38auF1/rW782kY2XNLNBagm7xPXNuZjVUI7HzSY37sVk0VOa/HJb0vogxpSy lq3qNpQUVxJWscLUWNnwdIyIKugcoSRcUbGkV0ynSoc3j2hLO++95+Rd7qLcITQL+yHN8TQJ t2YGvNJgsRxXBQxXseJVuOgqPbQK2Bj6dpgTlkho9QE6bty4fD7vum61Gu7dbxUDRb0nYL1D nK8fFl0Gy5w5c+obFy5ciPW5c+fWt7zzzju5XA66TKfTqVQqmUxGutm2UAWOJZAwuj4GpC3F Srbm76+/vnXMKOG7CYWw7FO33LVy2ZKxIxvdCkVancHI8izoefa6f1zyq58sv/nKVb/6nx/8 85Vv/flud8P77UY1w6oqnQnQwRRmCsEMGVRGr8TMXNlk6P4wp33VaZjRR56oL+EmY46le8W+ WLkczyUwImzdaxhlN4+WBnPVzbrWKxxghc0dCeewqUaGx5Uyg2eErbsurMTlQQz9Pp7EcwW+ w0gXaDXx+KYuWCF+CoSGY489FoO+Pu6jaB2LxW666aYHH3zwlltuwfpAqxgooR2tZzvx7eZH HQ7g7I899hi0tWXLlieeeAK7P/7442vWrMFtwWgQ/wuFwr333nvggQdCMbAtgMBot9pC0TZo DCyffFDQ7RemHTj3lEu/g3IPfpoKy6/e+O//++eHTWowdQr1OKqiaCkFoTirptvMVFzzqokA 7t7xrSAh/JhbQRZKgV5Nu0q8RyDB8SiRSsIdFvq4Vu7155zw7U9eNzZteauD61rVBYODQJVv yoh8YSxT8pVKZvp3M+MnrH70iga9YCpBoZKwjfZ4blU2npk2ofn1FR/mcn4CBJHoyeWDRMIz YJEcdgluuyHQSoKXN2+NdedqTuiCCy4oFouLFy+GAqAGGEqkCQgNIeDQQw+1bZtUvSsvRRt3 qQIYAc4YhaLe3t6mJkJQ9YX4qtAS68a7B6UOxNZQ3qmnnoqdX3755aOPPhor0N8V37jA+evb qCav93v++ZGHDp5/fCGoJDxTNdSfnblgyV/uOWPGxI50Z/vJ3zrk8ju3IoEFBPCdJX+5N2Px JDyG43dvXP3BS/e1F3qaglLJ8h0lqYlMsSLTR88YP+uYl//XT6af9VUj/Xyx7cBEdsS4Gdcr pTVaKub16B8+d1mu9PERx/46M+O0/IcfaIl1nyy86oDjb0uMP6n02vc+WHhnE+oLjceMPnFB 570XNZzw3arrP3rfnbNPvPjIs35Y6vn4X2+4elP3m9847+pXX/9d58fvn3POL99a+uC6zldf eNl8+XX1xUULm9qypmn97ne/++lPf3r55ZffcMMNn3zyCXz+hx9+WA8QkWIiSe6ch+zJue3O 4iLdnHDCCRgCOCOW9evXYyN8XfQTC1IlGE2kSFwYS7lcBo4YqEg4Hl3T04GV4tYWN/e1y34A 3TghSwrdPPfHp/7jL7+fbna0N8UAq4SmIoVuQwLjVZmoHnnWeZPnnz/yb84de+aCGRdd+zfX 3r3V7OjjTdJooEIA/IePdLaYPOLY9JxTpl1xV3r838Wbz40Zh6DMU8h3Lbn9HN+0EtNOGTfl v8cPmvv6Lcd0vnd7YswpxULQu3zh+rVvvfPSbxMNqoyxiuUnRx+/SfG9bCbPqvNO/f7EE753 yYJZD/715n+4/r687Y8Ye6QWz6LY0zhqrpYcnSuZi1+177jt1s7ujZMnT8HDwGK++c1vfv/7 34carr76aviPMWPGQHRQSSQNiCuS5M6jfO+xZ+djopg0b968+p9GjRrV0dGBGFPf0tbWdtBB B0E9wA5nnnkmQAT2uf/++weeDXEUi6mpfTI/8uBpZ//wQoAFz7PhvsrrCndcedME1pYwAyvm oXsmRN2oNIBh1oQWp/zRd8pS5hl6A5hvtPBMu6PFcoBdqgGA35JJbl21lBV6R8w/3+9cGp84 L94wS65eCdY1t+lD1tnj51ZypzvR0rJl49LCx8tXvPGIw7oVUZGsV7ELdhFZglJBkNVitm30 BAkHVIWTz04ZtfI/n1j60ab/WPgo4mZTi1IpF+ySU0AEEjyRbHn6GYo6X5p3wrL/XIqVp556 Kh6PT548GYEAP//85z9/9NFHSCujUbtXemW/Obco5cTZx44di2/YxIoVK6677rrOzs6pU6di S6lU6uvru+qqq3BnEydOhG/FMOnq6gJMqOumPlKASU3V/JB1XXzlFU0jWtELnQDKZcojt99T Wd0VY2oyGVNiPgqXUXW4rGkO131gaSOua3GD63HGE4B5ne/yYpcKrg68CogWsJzg4PxqYfOa w78yb91jv060x9rHN9tbl6LFIBMXforlWNrPWqs7l7ccMKX5qIOnzV9gsGQllgaCzCTTHdlp nqubpsoKWjyZnTLrghEjTner0worlh4ye+bXvnzet8+6xS/1yl6eSKgHHzF35qy5B0467LXX tq5cRff51LNPzvvqScfOnXvWWWfBMpB9A9lGXAnG8fLly7EC5LZLixk4gveknl0eXM+NAKBh EFDAUUcdhZiPkyIBymaz7e3tuDAuj4j34x//+IEHHsCQQST75S9/GV0YRgYUhxWPCVPVenq7 jxs5e/rZJ/fYZQd2oirvvrj44d/8FrpJK4lsOmNTxT9MMZC9BgJsqKmUtix51l72vL76VfXV h1645m8X/uryRGltIy/rYFXIm2sYFvFEYuVLi9gnL/nFNyufPCr7Him6a7n/hsx3gSYz3bfH VlZobz5eevP+w8++qjE1RikuzijehvWLY8m+KV/+uiurSECLq97a+swVo0YHPfm3mrPjVr/5 l+L7//L3V19+4kktN143R69WH/njvx4/98QfXn7PrTf+/JZbHgjrV+kf/cOljltF9vfGG29g vD700EN4/Oeff/7EE0/8+te/juGL7x0i+s5eClt2hAYRKhsIDXp6epqbm3c4uJ7BDNyOkQL1 YAvs6cUXX2xsbIRW4OKifXCLuCestLS0ANRNnTLV4Uo1l7vizPNu/OOf0iNSwDQxeDCVXXHo 8SuXLZtgzBLuu0d9mTU2+ZVNW1pPv/jIy35dCWQcBOTWj6+YPXF8BmQKM5PMSmttaCSE/nxW VlFBQx+BAWYNjQOb7E0dY+MTJigAyEBLqay+vttrzqRjmlLOF7knsxljfc6l3ilTR3xpbNMK KP9t9VWdNbQhX4kVS23ZcUcEo8eNGTdh9dNP+92Luyt9z77FPiqw0WNYm2n2BtbmnurjT7o9 pagTOR6yCvtEuNUx8C51g43bWc8Oe0dObMdkJTwTNkZhPyLWsAJ/et99990ZLtAKgBlsCx7v 1XB58sknr7nmmugmIuwABxTOVgsuvOonqZZ4gN4k4UM3z/zT799ZtqQ51l4RjmUAOVSRigeg qsGWIO8BTEaJLmmMSLJRjfrYDpZJQw16V9HvdrUcHKOCD4KsCHCY5G1ZbcKYrK5a7UmtIROD 7Y1psgxe8AKU5rjerBe4bGrVW8arrR2ydQyqgDyjqa3tjAakx3wH8xrySDvNwF/5/MPFrkUG z3e0xKcfmjh4mtbYmGbxRE+X+GCZki9FbW0GSNJ91E0kit0pJtq+nfUQVxQu8JKwRMQuhA3Y JkIL4lvtgDD2gMl++OGHB0I74EXkQPWLwVBgLplMJmJIK5VKhFVwTqSosC1A/kqAZmque4p0 XMQczrXeTZtPPXhmk6eaepoXrAmZLXPmsVhQLazrbv3ad+Zc+lsknEhhVLf04M8vb08GpvT8 wLLVpK76xc2rty5/O6N5BuoC0A9IHcn1ZG7q9HY0gQhWRo2Oghh1doBfhixR3AE/SLRtWGkj n4jqAkSiSir3oNMObQ/CMHNVTzPigeJlFAdO2U8k3umyXl/lbtiiLH+/vHK1ADVIsiZ2G54N KerQdFHtQj1021IioqxcuTJaj6xkhwXbH330UUCy+vbzzz//4osvBlIAkQoG4cYbb6z/qW6U dZcIjzxz5kyU16AuI6x0+YjyjJ9+xunPPvJoFnWYAKVKeXIzP+OkJtfOeT2lscd89ZjrnvQk s9FfoCmGhwozckFwXgbqAzT9I8i998Bti3/7i7Y4GhDQpqHagTZiUmXC1IRQ4HeIXkG3GjVE oREIoAktOCCow1776AnBMAUijoInNutIVtFT4NpqApexHbB4fialVCt9+U1+6sEl+r2Lentt aidFGtbfUQNelmrtdbEOnhfdbb3nvffeQ9iArDHksURmCFVFJFKE2feMC+vZK8HnfrwX6eyu u+5asGCBg9ovknwfHWM6fN3d/3bPd769AGVGjSlVXIqJi6am5s1q7c11qV6p4mS/8/RaxlO4 gSoGuIJ+DrR84MZQmoPrY+iYEl1v3vnd+RmlZKGsoXBHGplGnkqDHi0rHNU2dG7gQmCqHfTd EIEJSyIvS2U3PA1WoEEk26iwGS4VSVFj9aQjuOchkpXjQamMaxWsjj8tk0+v2KQoTeSlyW6g mGpYZajVTfu7RAeroN2qB0wR3BfC+86mE2154YUXIpZ6v5aoIATQ8sorr4Derh/712eeOeec b/V09/T3iNGsrF/NbxqnWbbmgKdcv6Y8/Rs/+NKlNyHFpmaz/gkDEcePb5TVVj1z5+M3/ag9 IQ3pUREUNuamBNqq0UtFHVGWRCeQgokj0Ca0r1OhFW3yYUEP56BWQ7UY6BW063Cpc4E+RSpK U+sPlYKAN6pcV/qsUfcuLT+zYiPjiHugjKAbKnyE56g/ECh03ONgvdyeitbTp09HugvcjJrC QEYPtwC68xe/+EVEFuzXUudukaldfullM2bOqLru66+/dt11/6d761aiOjCqkUVLFRbw+79t T26WOQ3NNiVDptcV5ZTj5h987MnZtjEoJWH8U3CFQUNhQm54/9XXHrpHK3VlkZgi+aSeNNgh XJbLVJe601CLkEZoRqH5hX+l6BwW2cLm26jPEBaEPyFOGqizRlP4EaE0VuKihDvsMttuXbT5 7S0guUP5R1oJvzG2+gn/qEvsM7OeutCBlevOLdqIxwDaxgoqDhGdt+8Ljo3AXkR7t7a2wllF Z7NUtNVIZhmq7XgBnzxaufFL6dQGc2tS2mYhBipfFD1cT0tyoxFhwlKQ4viOqrhaTPVB9FQ1 5sdVtHNgRJOQMewD1ZMK2jYdKIZLdIaaauDBmKgHETMLSC31MR92LUjM/DJRoGZalfw5tgBN SLRjQ1ueGbhcMzay5hueXr2aGIVIKaSc2hQT8NaRTrazpH0Xz4577rYNMUJx2B35HVijHZZI xDCpvULDHS6I0UeSC102QFKpXI6qHXA0VMDEwIVZcBPczdwpqUOTLvcMYTLHLVgq8lRmIV5w jeYOeI4mweej3uMrvp3Ah8uYTsM/RCLRKKKCBbXUUhMHSqNgFKi8GfXcADsQwUCSDGNjBN5g jGFPPOKNROGWurDJ0+G+0HmCmamSW6tyyqKPAQvgvgwUW8Nz4BqYCUTqrdlLZDyDXnarnj3L vU597u8NRBqlZfv7h0+oEbbkX1AIFd8Ynx6ZopmFQeAkwcVxboOhpuY3TP2BP0OER20aokSh E3CZOtSonR1yrk0oDZEYNRBCC4C8YeCGUqhmjvYb2nFgX1RtKhXabRBLaGTi7CgQoaSAO9Ax prioAGmLVPq1TnfJRqQ5uKhHo6HmxFCKGzAxdSh0A9nuN+e2v/r4NPsHTloLWhujgEfN52Hv X1hLpr4NiL023CF9GAT1SpMxh/ImkWMc1z7hBsqAqameWgFqT0wH7HLaHTWbUgsp4TuGVkgX GB1pEGVCMClNL0tjyXJyxeGJqLf3M10+l+phTmNcTxqqcF2yFgx/ShbDcBItxDhEGqhJPPRR tclq0Xr9U1ujM0TaCw/ejVAx0xRXJI9I14QloU0XU1DRJEzsMo8n31tXWVFEuAV2qKGG/4Lq Ye1JNaa6od9AdzqaLWha2mcqCDo58jD0g8LOwuhIU63IdNBaj0urwkxWldSTb28Jx0RUZaZb +kxv6/NoPYiHk9tT8cCl8Rm2n5GtgEUboilnu1dzNIuHSGFUMAAQwDPZmM5jWGVulszWB1/b sryMGIM/omJO0/2HYg7Pnkbd51E9lspGpDCp2oagPLAzJLLIi4Vpyf43GO+32RHAI0LB9QMt noIz09PNS9fbr3ycD0+F8QP/9v/i5TufR/XENK0xoWnCQcZBegnn54KWq01Tp7ewRO2A+/DZ jesByhrwGZhAApeHs+AolGmaZRVtv3lEx5othftfWdtFExl1pmtoBKYes5qqPkN88HlUT3NS bUxgZrTqCY8SFHr/HmgwmuVObTlIt8IZBXv9EK+w42Q6aubEpDbCz9SESA6M3jyBJQSJ4QxT miCEpnaUbm0/iDV3vPJ+5x1PdXZiAiQQgRrH/Iloqnyolv4JJfttoft0wGeo+X24PooUrop3 2eAfglOwFhwkTplk/Y8jUlUPbZmUH9IMjoi/IcQcvVxg7wuxcEBp1Ly5484wPw0MOSZUQTFq 2N4JIhA6ozQV/W0o2pTjeM9OLF7Umx/+yPvTErSbQyMRP0K4IZLaPt3H3u90T3sMr3ow4Zfm tuE5Q+4QFRZ6v9cPDmv8b1PNzlzJMjC/wKf5GSGpFQIq6h/Z90f2qId6Z0GG7dUhpRBOHg1n FRGYVgi7SdVMpnwttryr+tLyvufWlqm3g6ZoDZbf3Pfbru+5H4/6Kc6+50MigVMUpv2QSSgW CDHGrjmxfXqjV3YEKnSkHnRab+MYIvZx7wsN7ZChJG3Wx3nt0MAHhw1DpDwWhTcYKOgZaujW rVhFUzeUtcffLby+BjVYcmJgb3CCWqPt3q88lHvs06MO5QUHnAtPDgGGAAhvhkJRi2azYWbU P51/gOl2YtYvKmIh/4XcEEA2OpLKnbu5n+3MJFKjRTMUIo9U90Y0KnSwAGin51rALa6iO8A0 Y0m7ai9b37ukq7hso7MW0+dIL8hv/BhoHsyG+IyksMfTDqd6UEvB5UOPjrFrYaaHIpzpTea1 Z01XeteB90eiDhqSwvu2F+aCAcP+FMe38fgDifxI2VFdAKQYAj0B8tCWAAKiCEYgA3K3XKb1 VN28p27I2R+u71m9tbwRE7BCeYVnxz7Ru1eiK/6Xc241QYbCQzEGz+8fPSZz5swDZK4rbBbp b9uKvFOIssMpCdgzfBsBRaSQ8yfJh6/tILlGTg1/V3y814o8WFgbQPSXCtJMcPA9Za/L0fpc pTufhwvDZJV+Ugi0JyIizu/0GyPOhgkNOM8+Nd8MrY0Np/VQGQE1mfBdkf20vEhREIBDq72F Y9foaHtfVauGRd6r7uFCnUQGSm/co76J6N0U9IGJbHvlAM2BDKdqI/5jwjFKqVToxFyV/rYB GhAYDUMzZWe/9De86kG8wTsd0BZDEYjIf4A3VEprXPIu4Wu9PNnvgequaNtK/cC6A4xkQtoj o8MXiG56HxL4NUzLA69G7zUIVenR/AjaGcU6HIHEK+oerpdB90u8g915eNWDwU2tLQNielQf hsevF6IG2g+Jr//NuRHii+4/Guh1UBdtDDtwavXQunpCpaKQjf7mmm2EnEQIOcLXwVANIzST 8AbIc9Yx4GBl/cXxX0jgCwl8IYEvJBBJ4P8CkLsiseCTLsQAAAAASUVORK5CYII= --B_3379591535_87756494 Content-Type: image/jpeg; name="image.jpg" Content-ID: <3379591534_87766063> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8l JCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIo Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAAR CAAKAA4DASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDSu9NvV0vVpbjQL2KfU7xR5T6qqmRclsrn hecDFbGl6hqL69Noem63ZRQ6faops5Y2mmiYBQdz8BuSR1qD4pxpLdeHo5UV0N2cqwyD93tX exW0ELtJFBGjv95lQAt9T3oA/9k= --B_3379591535_87756494 Content-Type: image/png; name="image.png" Content-ID: <3379591534_87723340> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAIoAAAA+CAIAAAB7vhRQAAAAAXNSR0IArs4c6QAAAAlwSFlz AAAOxAAADsQBlSsOGwAAIthJREFUeF7tfAeYHdWV5q1b8eXXudXKoAyIIH1IgESwMTKDSDZe bNKsZa8/xh8MNgxj1mYxLGZtgseDDcwABsb2YH9ggglDMAiEyCIMEkkSCOWW1Orw8qt0b+1/ ql4/tbJEN9t8OxSPp3rVFc+555z//OfcUtjwLZyxAB/8I8ObUMLfGmNCYYES/Yq+63/ETyz1 LdH6Hvbh4RXCwxX8I2vrOH3tSNqK1W2X7j/78Ill4JWj5x2epaaeSPZ1qdPPUKpDs9TUs93J drhcXflDc8X/T8+CAQ65QWef7dJ/DbV+mf4hqjO2beNnexP7evbhtJ6d7xGOLc30pKpLJjh5 nMEtsBw1kIH0hfRZUGXS7fejkUMV0elxVfyQpBts9wZ3zaE9etAiGPTtbIsciqIFwXg1Mbtp kukFYkj8mxJIJv1AQtt24FUDv2rbObfQy7xe6Zajm4dawrj0OXRyw68euBQasByxm9RzmN5w ZHysXvZ2Np4IBezPgt0FziMVnFuRipRcVVTF80XOlJ1Bpada6HKKBSagGjjW2ngYkmGxP3e5 h32H2dlCfpFrCWOOYgTsEKO1mZmKH4TOTYm+EZbqPyHpaAtW9rBPwBQ1YDzA3gHgGcdvEQRC qjLgMlClbFStsWa2XUvEGPdEFffgq5zJz5Ny9ns4DtGgqJ0GFiOZyZgD7xJ6mIRkp6cnZ3wd GovA9iAWIHboxYdiAtK1VELpS5iKpsSEwt1wi8bzOlsjc+9UOrtxB3VXO4gLD+Ghw2o9oavC Hfj0D9lDo9QPNVpMH0Kt+5pP+bBwaQFXuEwF3GO8wgKLC2jLNgwWuDGcXdU8FQZIMc5PGNaI RNat5l0W+NGVDTJqstPo+vQP7pTEFW4kkBnZfKTQMEnAV/jvtsM+5c3XDxtu9URZYaSeIGhX E1P0BtUVUuHkmsLH/bQfWA9XpMG5w3mF+xlViWvcF76tsWygWK6iicDAh3ELu5k8meXpXr+U IzkbiFdhwqzhJAFpJfSoFMLwk/TCSUHQN6kpUlWo1iH2jcOnnn43su2BJBsXbxwDD+d6gabC fsIIM7gPsxVeIbGKRilMRfV9WRIycPA//Qefx6AxSL3ienHDsiXbKMsMcI90QzKHa+y3EODw SAF0y+H2yHhgaBBjDaX32xp8Nv40WA+9n1BosMa60/EDfD0g3DGZ8Qfb8ELMh3qG4FqQshuo NqEJdxzQhuQbmjsc3/cRegLmqTBSSBF64tyHm1OCSlJ9Nd/TY4uqChjJkH9BC+CYYNyBp1Rt GFWAw30xUPCRkgaqB9oibipy24NZhlU90cX7zadZs2anx4wra1wEQ6QeISFftQwHJbyRrl9o G1ued1qHLXPkqHTJJf4AyStCCkVVgRrcGN/Iq1vsfCEIDENTfYGI5UFRAVd9U2B3qZYroq9Q 6S3wrm73veV9FQCbmslggJnYVVFsYMTBaKV+7LCqZ8ATYLCNt1IzzI4OV/dcT+j6oK1HQKaA 0KriBBwDPuspXVOP8A6dAyvqczyLKSaoPWgoCuTwcnBkUmM2l+vL+T78TSXlQTVkPdAwTDGk alVV182UZLphGlXbXdvtvfpm5ePldsmDyQB7AhpWB6a6g9HT8MWe7UeIxdhIJd6hpmMe/AYH 6Br0wAkQtxURI96Ae8DWUs1PODiebMhJ3ZXCkkEyCDRIWUodbiwI9EDRmQBE0asiKApfKpoC G0A2S7icQADpDw7LF7YD8qFUKuZ5UMlkxWEHJVoam/K91VK5CtRJHhPLYOMOneNzpJ7RVqZN TZquj2GKYABRcNFPXRMHF3lBCH27TzjoMbjDuE0SQcZEcEKEyEqVJlMxlitSqJrFD5jabCSQ gSIrtSBvsgYcgDPjULg7rGOroRY1v1faPiwa8JwjRgUCvo3DlkhfgiuGYZIqQ3ARuKJcqI4e bY4+INFbKG/tiTBBPNTPYIHccKonKihEfiCl8AOtxgbgYMQLxdAgD8arhi9U6MV3VaEHXpwM S0V8hyGE3xwUgIbwLuHpdQQRgW0QvYqggi8SO4Vw7CVjbuClmt2JByX0uOv7psI5Zy6cFwcg QKzDChcC+ADy17ijyB7XJkRNtAQCIWmcSV1wrGnwb67nwbp0AyRUoPksnmQ9hUos5s6c0dy9 2d7SjcdKhuigPy59Wgc3aA//aS/cH05rxycUtYHFFV8Knfu6qgeq5SvIUDyOtF94ug8MnILi yEoge8QDaIf8Hwa3RtEBnBoxOIFKPo1clMI0IQIV5J3p+yMVpsazRT21STEKwquqVO7TVaFx MAdCVel0+EAd+AluSbU8FhPc8EjthkcFKD1wLGHrim0EXkwNDEjOR/YMolCtYucYCxzJ8uUz Tkq0QjWspCiDhW3D7NxqGV2Irdu4OUrPxMD7g/lHFAiEJjFylbSjxzyzymI+h7tgtpn3NN/T hVB9T3U9zXORXKq+JRwdQV1xFcVD+AZdI7jucoOrCDMSwVyyraMPVEaNM1y/xJGH1vJ/KBXA TYXwWYDBrsPwYLalwO/yq74BuEAWFLIE8Lak0uiDhf5FPoXxIaFr7EjUkRRBIq1WpbFqjT0k zm04rYd8M54vhKAZNW4oOp5cwsErAnIXGtM8riNmMAPS9aRflkKr6pqrKRUDOhS26dsxz447 +Pa49FWiviEWTxGu6vlGVcR9G5ahStf1PSeTbGZ+UlbjikyhxsAk4K8bSA80HOAD0aZS00AH BEDjvkdWqbrIh8APMFWDqYa8QY3TIe3U2AJKU8MclaIY94uFypSpMQMYe7tM6FM6mV3HnjBM 7t8y8JD9PRxjZHK8oVVJaJTBBxY4A6l1uvl8YPeygs2KCVMkY7aluczVbGFrgYEYA0emBDrk hKFb1dQi1GUqqZhiqm5cF5bhW7qIm25Mh3SrmUbnoMMbzWSFaDfdZLxk6GVVRX5FsYch52S+ DACqwTKIQmB3o0JkIPIjlCkYJwQa4P52LGiQI4U/hFtEhFQQmngAbWcakytXy3x+CJzbbtVw ySWXnHvuucuWLbvyyis3b968V11FKom+ETCj/esr9cN1Xfc87/jjj7/22muF5137s58tfO45 uK1TUpNbhaa5wtWVmMs3id5JX/nKOddcVu3deufPfsRWvP+tL83u9HuThx1+0FFz0uMPhC8K wDyHIAkykqZR2fTxsof+zV2zrNkSik+igWB9jsCD8CBEbOv0WY026wJe84HoRIoJi7wnRC8V DArHAVz2pes7rreqVFleZFqCIfkC6PbhvuC5iELYUVxECwmDaa7PmerD0MkejWzmwSe8d5ZW 9iq0ve6w3fXqwh05cuSGDRuig2+//fYLL7xwdyci/xsqIzoWgEgigMOlAzgRbagIsYv8edGi Rccddxz2f/fdd08+dX7v2nXfaj4sWXA0wSqQh+0lJh1w5ZN/yh7QhH1eeeTeRy757twJDelj jpn1kztNI7u7mym889Qj/7igI+GbQGUE2zSHJRSNV7zubIeceEhDNegBVgMhEAYScNXEe4Ll ZICCBOXBw6LOwPLSX1u0t/ZWK4WgDHSQYm5UaoiiDT1tffzBh4XqUeGKgScxZmRgJha/pS5c VNir9Pe6w65jz4QJE3Ck4xAuPO200/ZwloGGgnUoA9/QDQ1eKXepG/zJNMEYMtfxJk6YOHnS BHCKloockGhI7gc5Zp/ygwXQjY0kL2CZTEvLyLEl3z/2ssugm4rwkTaWA4YPUhhHSlfKcohg Y9kW3UggaxeSu4HuKDGQXhwkmV1pa0xRsMAVgIwlyn40rNCIQBgQJ2BVIcuBKMqgLJSCqdlT WpMzxzbMmtg4MqOVy6RtSrAoSwrNtT/ehAEozD/DqhKNT8L+pOohWbZTDyQbGUEk30j0kSh3 ucyePfsPf/jDzTfffMcdd8BfYZ9Jkyb95je/ufXWW2+77bYzzjhj5yA00PsZJjJ2ZCe8mSWE 42JEAgP1+bmDTjnuhL/7ZgkZkabi6Tdt3NKzsThu9ldYehJaOpBn6lxJKLALFuPM5MBnPEH3 6L/86P0lpxRoBhg0Qm4YzcB1fgWxJdVgSkgf8iMyvErx3wdmxpBA6FJNRdNBgRKoJmihigpz +jKB0Z6MHz65beqkNLIk4YZZrI6UGfKJKGtKlQNVEMGNcwVSU6TnMcM0C7khCDx4JAS97ZZI MdFioHTV77UG7qRpGjgsbDn77LPPO++86E8IVIlEAkq66KKLoi3z589/++23161bVz82Cjx1 xVNXIIjgwBtjNRgeYJPquU4P87932/XYBzaR0Hi5u/D23XePMTZZo1sYa3Q4s+CNyptfeuwP aQvjGDCaiqJm38auF1/rW782kY2XNLNBagm7xPXNuZjVUI7HzSY37sVk0VOa/HJb0vogxpSy lq3qNpQUVxJWscLUWNnwdIyIKugcoSRcUbGkV0ynSoc3j2hLO++95+Rd7qLcITQL+yHN8TQJ t2YGvNJgsRxXBQxXseJVuOgqPbQK2Bj6dpgTlkho9QE6bty4fD7vum61Gu7dbxUDRb0nYL1D nK8fFl0Gy5w5c+obFy5ciPW5c+fWt7zzzju5XA66TKfTqVQqmUxGutm2UAWOJZAwuj4GpC3F Srbm76+/vnXMKOG7CYWw7FO33LVy2ZKxIxvdCkVancHI8izoefa6f1zyq58sv/nKVb/6nx/8 85Vv/flud8P77UY1w6oqnQnQwRRmCsEMGVRGr8TMXNlk6P4wp33VaZjRR56oL+EmY46le8W+ WLkczyUwImzdaxhlN4+WBnPVzbrWKxxghc0dCeewqUaGx5Uyg2eErbsurMTlQQz9Pp7EcwW+ w0gXaDXx+KYuWCF+CoSGY489FoO+Pu6jaB2LxW666aYHH3zwlltuwfpAqxgooR2tZzvx7eZH HQ7g7I899hi0tWXLlieeeAK7P/7442vWrMFtwWgQ/wuFwr333nvggQdCMbAtgMBot9pC0TZo DCyffFDQ7RemHTj3lEu/g3IPfpoKy6/e+O//++eHTWowdQr1OKqiaCkFoTirptvMVFzzqokA 7t7xrSAh/JhbQRZKgV5Nu0q8RyDB8SiRSsIdFvq4Vu7155zw7U9eNzZteauD61rVBYODQJVv yoh8YSxT8pVKZvp3M+MnrH70iga9YCpBoZKwjfZ4blU2npk2ofn1FR/mcn4CBJHoyeWDRMIz YJEcdgluuyHQSoKXN2+NdedqTuiCCy4oFouLFy+GAqAGGEqkCQgNIeDQQw+1bZtUvSsvRRt3 qQIYAc4YhaLe3t6mJkJQ9YX4qtAS68a7B6UOxNZQ3qmnnoqdX3755aOPPhor0N8V37jA+evb qCav93v++ZGHDp5/fCGoJDxTNdSfnblgyV/uOWPGxI50Z/vJ3zrk8ju3IoEFBPCdJX+5N2Px JDyG43dvXP3BS/e1F3qaglLJ8h0lqYlMsSLTR88YP+uYl//XT6af9VUj/Xyx7cBEdsS4Gdcr pTVaKub16B8+d1mu9PERx/46M+O0/IcfaIl1nyy86oDjb0uMP6n02vc+WHhnE+oLjceMPnFB 570XNZzw3arrP3rfnbNPvPjIs35Y6vn4X2+4elP3m9847+pXX/9d58fvn3POL99a+uC6zldf eNl8+XX1xUULm9qypmn97ne/++lPf3r55ZffcMMNn3zyCXz+hx9+WA8QkWIiSe6ch+zJue3O 4iLdnHDCCRgCOCOW9evXYyN8XfQTC1IlGE2kSFwYS7lcBo4YqEg4Hl3T04GV4tYWN/e1y34A 3TghSwrdPPfHp/7jL7+fbna0N8UAq4SmIoVuQwLjVZmoHnnWeZPnnz/yb84de+aCGRdd+zfX 3r3V7OjjTdJooEIA/IePdLaYPOLY9JxTpl1xV3r838Wbz40Zh6DMU8h3Lbn9HN+0EtNOGTfl v8cPmvv6Lcd0vnd7YswpxULQu3zh+rVvvfPSbxMNqoyxiuUnRx+/SfG9bCbPqvNO/f7EE753 yYJZD/715n+4/r687Y8Ye6QWz6LY0zhqrpYcnSuZi1+177jt1s7ujZMnT8HDwGK++c1vfv/7 34carr76aviPMWPGQHRQSSQNiCuS5M6jfO+xZ+djopg0b968+p9GjRrV0dGBGFPf0tbWdtBB B0E9wA5nnnkmQAT2uf/++weeDXEUi6mpfTI/8uBpZ//wQoAFz7PhvsrrCndcedME1pYwAyvm oXsmRN2oNIBh1oQWp/zRd8pS5hl6A5hvtPBMu6PFcoBdqgGA35JJbl21lBV6R8w/3+9cGp84 L94wS65eCdY1t+lD1tnj51ZypzvR0rJl49LCx8tXvPGIw7oVUZGsV7ELdhFZglJBkNVitm30 BAkHVIWTz04ZtfI/n1j60ab/WPgo4mZTi1IpF+ySU0AEEjyRbHn6GYo6X5p3wrL/XIqVp556 Kh6PT548GYEAP//85z9/9NFHSCujUbtXemW/Obco5cTZx44di2/YxIoVK6677rrOzs6pU6di S6lU6uvru+qqq3BnEydOhG/FMOnq6gJMqOumPlKASU3V/JB1XXzlFU0jWtELnQDKZcojt99T Wd0VY2oyGVNiPgqXUXW4rGkO131gaSOua3GD63HGE4B5ne/yYpcKrg68CogWsJzg4PxqYfOa w78yb91jv060x9rHN9tbl6LFIBMXforlWNrPWqs7l7ccMKX5qIOnzV9gsGQllgaCzCTTHdlp nqubpsoKWjyZnTLrghEjTner0worlh4ye+bXvnzet8+6xS/1yl6eSKgHHzF35qy5B0467LXX tq5cRff51LNPzvvqScfOnXvWWWfBMpB9A9lGXAnG8fLly7EC5LZLixk4gveknl0eXM+NAKBh EFDAUUcdhZiPkyIBymaz7e3tuDAuj4j34x//+IEHHsCQQST75S9/GV0YRgYUhxWPCVPVenq7 jxs5e/rZJ/fYZQd2oirvvrj44d/8FrpJK4lsOmNTxT9MMZC9BgJsqKmUtix51l72vL76VfXV h1645m8X/uryRGltIy/rYFXIm2sYFvFEYuVLi9gnL/nFNyufPCr7Him6a7n/hsx3gSYz3bfH VlZobz5eevP+w8++qjE1RikuzijehvWLY8m+KV/+uiurSECLq97a+swVo0YHPfm3mrPjVr/5 l+L7//L3V19+4kktN143R69WH/njvx4/98QfXn7PrTf+/JZbHgjrV+kf/cOljltF9vfGG29g vD700EN4/Oeff/7EE0/8+te/juGL7x0i+s5eClt2hAYRKhsIDXp6epqbm3c4uJ7BDNyOkQL1 YAvs6cUXX2xsbIRW4OKifXCLuCestLS0ANRNnTLV4Uo1l7vizPNu/OOf0iNSwDQxeDCVXXHo 8SuXLZtgzBLuu0d9mTU2+ZVNW1pPv/jIy35dCWQcBOTWj6+YPXF8BmQKM5PMSmttaCSE/nxW VlFBQx+BAWYNjQOb7E0dY+MTJigAyEBLqay+vttrzqRjmlLOF7knsxljfc6l3ilTR3xpbNMK KP9t9VWdNbQhX4kVS23ZcUcEo8eNGTdh9dNP+92Luyt9z77FPiqw0WNYm2n2BtbmnurjT7o9 pagTOR6yCvtEuNUx8C51g43bWc8Oe0dObMdkJTwTNkZhPyLWsAJ/et99990ZLtAKgBlsCx7v 1XB58sknr7nmmugmIuwABxTOVgsuvOonqZZ4gN4k4UM3z/zT799ZtqQ51l4RjmUAOVSRigeg qsGWIO8BTEaJLmmMSLJRjfrYDpZJQw16V9HvdrUcHKOCD4KsCHCY5G1ZbcKYrK5a7UmtIROD 7Y1psgxe8AKU5rjerBe4bGrVW8arrR2ydQyqgDyjqa3tjAakx3wH8xrySDvNwF/5/MPFrkUG z3e0xKcfmjh4mtbYmGbxRE+X+GCZki9FbW0GSNJ91E0kit0pJtq+nfUQVxQu8JKwRMQuhA3Y JkIL4lvtgDD2gMl++OGHB0I74EXkQPWLwVBgLplMJmJIK5VKhFVwTqSosC1A/kqAZmque4p0 XMQczrXeTZtPPXhmk6eaepoXrAmZLXPmsVhQLazrbv3ad+Zc+lsknEhhVLf04M8vb08GpvT8 wLLVpK76xc2rty5/O6N5BuoC0A9IHcn1ZG7q9HY0gQhWRo2Oghh1doBfhixR3AE/SLRtWGkj n4jqAkSiSir3oNMObQ/CMHNVTzPigeJlFAdO2U8k3umyXl/lbtiiLH+/vHK1ADVIsiZ2G54N KerQdFHtQj1021IioqxcuTJaj6xkhwXbH330UUCy+vbzzz//4osvBlIAkQoG4cYbb6z/qW6U dZcIjzxz5kyU16AuI6x0+YjyjJ9+xunPPvJoFnWYAKVKeXIzP+OkJtfOeT2lscd89ZjrnvQk s9FfoCmGhwozckFwXgbqAzT9I8i998Bti3/7i7Y4GhDQpqHagTZiUmXC1IRQ4HeIXkG3GjVE oREIoAktOCCow1776AnBMAUijoInNutIVtFT4NpqApexHbB4fialVCt9+U1+6sEl+r2Lentt aidFGtbfUQNelmrtdbEOnhfdbb3nvffeQ9iArDHksURmCFVFJFKE2feMC+vZK8HnfrwX6eyu u+5asGCBg9ovknwfHWM6fN3d/3bPd769AGVGjSlVXIqJi6am5s1q7c11qV6p4mS/8/RaxlO4 gSoGuIJ+DrR84MZQmoPrY+iYEl1v3vnd+RmlZKGsoXBHGplGnkqDHi0rHNU2dG7gQmCqHfTd EIEJSyIvS2U3PA1WoEEk26iwGS4VSVFj9aQjuOchkpXjQamMaxWsjj8tk0+v2KQoTeSlyW6g mGpYZajVTfu7RAeroN2qB0wR3BfC+86mE2154YUXIpZ6v5aoIATQ8sorr4Derh/712eeOeec b/V09/T3iNGsrF/NbxqnWbbmgKdcv6Y8/Rs/+NKlNyHFpmaz/gkDEcePb5TVVj1z5+M3/ag9 IQ3pUREUNuamBNqq0UtFHVGWRCeQgokj0Ca0r1OhFW3yYUEP56BWQ7UY6BW063Cpc4E+RSpK U+sPlYKAN6pcV/qsUfcuLT+zYiPjiHugjKAbKnyE56g/ECh03ONgvdyeitbTp09HugvcjJrC QEYPtwC68xe/+EVEFuzXUudukaldfullM2bOqLru66+/dt11/6d761aiOjCqkUVLFRbw+79t T26WOQ3NNiVDptcV5ZTj5h987MnZtjEoJWH8U3CFQUNhQm54/9XXHrpHK3VlkZgi+aSeNNgh XJbLVJe601CLkEZoRqH5hX+l6BwW2cLm26jPEBaEPyFOGqizRlP4EaE0VuKihDvsMttuXbT5 7S0guUP5R1oJvzG2+gn/qEvsM7OeutCBlevOLdqIxwDaxgoqDhGdt+8Ljo3AXkR7t7a2wllF Z7NUtNVIZhmq7XgBnzxaufFL6dQGc2tS2mYhBipfFD1cT0tyoxFhwlKQ4viOqrhaTPVB9FQ1 5sdVtHNgRJOQMewD1ZMK2jYdKIZLdIaaauDBmKgHETMLSC31MR92LUjM/DJRoGZalfw5tgBN SLRjQ1ueGbhcMzay5hueXr2aGIVIKaSc2hQT8NaRTrazpH0Xz4577rYNMUJx2B35HVijHZZI xDCpvULDHS6I0UeSC102QFKpXI6qHXA0VMDEwIVZcBPczdwpqUOTLvcMYTLHLVgq8lRmIV5w jeYOeI4mweej3uMrvp3Ah8uYTsM/RCLRKKKCBbXUUhMHSqNgFKi8GfXcADsQwUCSDGNjBN5g jGFPPOKNROGWurDJ0+G+0HmCmamSW6tyyqKPAQvgvgwUW8Nz4BqYCUTqrdlLZDyDXnarnj3L vU597u8NRBqlZfv7h0+oEbbkX1AIFd8Ynx6ZopmFQeAkwcVxboOhpuY3TP2BP0OER20aokSh E3CZOtSonR1yrk0oDZEYNRBCC4C8YeCGUqhmjvYb2nFgX1RtKhXabRBLaGTi7CgQoaSAO9Ax prioAGmLVPq1TnfJRqQ5uKhHo6HmxFCKGzAxdSh0A9nuN+e2v/r4NPsHTloLWhujgEfN52Hv X1hLpr4NiL023CF9GAT1SpMxh/ImkWMc1z7hBsqAqameWgFqT0wH7HLaHTWbUgsp4TuGVkgX GB1pEGVCMClNL0tjyXJyxeGJqLf3M10+l+phTmNcTxqqcF2yFgx/ShbDcBItxDhEGqhJPPRR tclq0Xr9U1ujM0TaCw/ejVAx0xRXJI9I14QloU0XU1DRJEzsMo8n31tXWVFEuAV2qKGG/4Lq Ye1JNaa6od9AdzqaLWha2mcqCDo58jD0g8LOwuhIU63IdNBaj0urwkxWldSTb28Jx0RUZaZb +kxv6/NoPYiHk9tT8cCl8Rm2n5GtgEUboilnu1dzNIuHSGFUMAAQwDPZmM5jWGVulszWB1/b sryMGIM/omJO0/2HYg7Pnkbd51E9lspGpDCp2oagPLAzJLLIi4Vpyf43GO+32RHAI0LB9QMt noIz09PNS9fbr3ycD0+F8QP/9v/i5TufR/XENK0xoWnCQcZBegnn54KWq01Tp7ewRO2A+/DZ jesByhrwGZhAApeHs+AolGmaZRVtv3lEx5othftfWdtFExl1pmtoBKYes5qqPkN88HlUT3NS bUxgZrTqCY8SFHr/HmgwmuVObTlIt8IZBXv9EK+w42Q6aubEpDbCz9SESA6M3jyBJQSJ4QxT miCEpnaUbm0/iDV3vPJ+5x1PdXZiAiQQgRrH/Iloqnyolv4JJfttoft0wGeo+X24PooUrop3 2eAfglOwFhwkTplk/Y8jUlUPbZmUH9IMjoi/IcQcvVxg7wuxcEBp1Ly5484wPw0MOSZUQTFq 2N4JIhA6ozQV/W0o2pTjeM9OLF7Umx/+yPvTErSbQyMRP0K4IZLaPt3H3u90T3sMr3ow4Zfm tuE5Q+4QFRZ6v9cPDmv8b1PNzlzJMjC/wKf5GSGpFQIq6h/Z90f2qId6Z0GG7dUhpRBOHg1n FRGYVgi7SdVMpnwttryr+tLyvufWlqm3g6ZoDZbf3Pfbru+5H4/6Kc6+50MigVMUpv2QSSgW CDHGrjmxfXqjV3YEKnSkHnRab+MYIvZx7wsN7ZChJG3Wx3nt0MAHhw1DpDwWhTcYKOgZaujW rVhFUzeUtcffLby+BjVYcmJgb3CCWqPt3q88lHvs06MO5QUHnAtPDgGGAAhvhkJRi2azYWbU P51/gOl2YtYvKmIh/4XcEEA2OpLKnbu5n+3MJFKjRTMUIo9U90Y0KnSwAGin51rALa6iO8A0 Y0m7ai9b37ukq7hso7MW0+dIL8hv/BhoHsyG+IyksMfTDqd6UEvB5UOPjrFrYaaHIpzpTea1 Z01XeteB90eiDhqSwvu2F+aCAcP+FMe38fgDifxI2VFdAKQYAj0B8tCWAAKiCEYgA3K3XKb1 VN28p27I2R+u71m9tbwRE7BCeYVnxz7Ru1eiK/6Xc241QYbCQzEGz+8fPSZz5swDZK4rbBbp b9uKvFOIssMpCdgzfBsBRaSQ8yfJh6/tILlGTg1/V3y814o8WFgbQPSXCtJMcPA9Za/L0fpc pTufhwvDZJV+Ugi0JyIizu/0GyPOhgkNOM8+Nd8MrY0Np/VQGQE1mfBdkf20vEhREIBDq72F Y9foaHtfVauGRd6r7uFCnUQGSm/co76J6N0U9IGJbHvlAM2BDKdqI/5jwjFKqVToxFyV/rYB GhAYDUMzZWe/9De86kG8wTsd0BZDEYjIf4A3VEprXPIu4Wu9PNnvgequaNtK/cC6A4xkQtoj o8MXiG56HxL4NUzLA69G7zUIVenR/AjaGcU6HIHEK+oerpdB90u8g915eNWDwU2tLQNielQf hsevF6IG2g+Jr//NuRHii+4/Guh1UBdtDDtwavXQunpCpaKQjf7mmm2EnEQIOcLXwVANIzST 8AbIc9Yx4GBl/cXxX0jgCwl8IYEvJBBJ4P8CkLsiseCTLsQAAAAASUVORK5CYII= --B_3379591535_87756494-- From julien.ietf@gmail.com Thu Feb 3 15:23:49 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A12EB3A6B3A for ; Thu, 3 Feb 2011 15:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cS0HnCT8VDMf for ; Thu, 3 Feb 2011 15:23:48 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 6AC183A687A for ; Thu, 3 Feb 2011 15:23:48 -0800 (PST) Received: by fxm9 with SMTP id 9so1883655fxm.31 for ; Thu, 03 Feb 2011 15:27:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZsKy6fCqwPT2Hz5fRerMNjKIkzzyZlhjSCHxXoDitos=; b=SQEVHye9adUCUxnPxnp2+fzWsbAxdNao3J5r17sDqhYzJc5lceG4xzr3Tv8gnPVqRt QC1zw5cI2ueHgCHMRh183XMwE27jZO4nljt0zce3VPgiKAzCNOBtPQbEUzSaPgDWC0uR 00DNG2Y0wdQg2Bs4sOPkT9bYSuPwCdobMvg+E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JncMYsCgJjedFoJGYsOTcql3yv2Xjk4k+3dJBEglcqoLJYZbce40uwqeqpsBgTShDr GNYlGtbcRcZqBhSxl1F/xgbM62xcFMdMFpg8e43o55rcqqHXSU/6Kk7KDutOvaWWKaDZ Y7nz7bmtIEdFy5ZGShDJoAXQ2OnCmLAiIeDa8= MIME-Version: 1.0 Received: by 10.103.12.14 with SMTP id p14mr2761430mui.39.1296775631142; Thu, 03 Feb 2011 15:27:11 -0800 (PST) Received: by 10.103.221.9 with HTTP; Thu, 3 Feb 2011 15:27:10 -0800 (PST) In-Reply-To: References: Date: Thu, 3 Feb 2011 15:27:11 -0800 Message-ID: From: Julien Laganier To: Rajeev Koodli Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 03 Feb 2011 23:23:49 -0000 HI Rajeev, On Thu, Feb 3, 2011 at 1:10 PM, Rajeev Koodli wrote: > > Hi Julien, > > On 2/3/11 10:52 AM, "Julien Laganier" wrote: > >> In the addressing model I outlined: at PMIPv6 session creation a set >> of prefixes is assigned the mobile node's session. Then physical >> interfaces can attach to / detach from this session. A single mobile >> node can also have multiple sessions (say 2) in parallel, associated >> with distinct set of prefixes, which results in the ability for the >> prefixes set to move across interfaces fully or partially as the >> interfaces are attached to / detached from the session. So all >> scenarios are supported in this simple addressing model which also has >> a minimal deviation from the basic 5213 model. > > If I understand this correctly, the LMA has a set of prefixes (which are > pre-assigned on *some* attach) which remain constant, but the physical > interfaces come and go. This is another way to look at the problem, agree. Ok. > I think this scenario is covered in the draft (perhaps not necessarily with > the same thinking as yours) where the LMA is free to allocate whatever and > any number of the prefix(es) it wishes to assign on any attach. > So, if the LMA chooses to move a flow from one MAG to another, it need not > perform any signaling. Right. > What this does not provide me is the flexibility, for instance, of providing > a prefix *when* I want to provide it, and assigning a prefix based on what > the physical interface the MN is attached to (so that I could route traffic > differently at the LMA if I so choose). I also would like to be able to > offer a prefix and revoke it based on TOD triggers. I do not *have* to > pre-assign my prefixes in anticipation of *potential* flow mobility. It does provide you with this flexibility. Whenever you want to offer a new prefix (set) over a physical interface (set) you simply bootstrap a new PMIPv6 session for that new prefix (set) over the physical interface (set.) If you want to revoke it because it's COB you can certainly tear down that session. All in all, a very simple model that allows all scenarios to be covered. I would suggest that we concentrate on devising the simplest addressing model and signaling framework, and move the scenarios in an annex. --julien From sfaccin@rim.com Thu Feb 3 15:31:30 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C509A3A688A for ; Thu, 3 Feb 2011 15:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.586 X-Spam-Level: X-Spam-Status: No, score=-4.586 tagged_above=-999 required=5 tests=[AWL=-0.384, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0rKW1pe4dfh for ; Thu, 3 Feb 2011 15:31:01 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id DF00B3A687A for ; Thu, 3 Feb 2011 15:31:00 -0800 (PST) X-AuditID: 0a666446-b7ba6ae0000051d3-8b-4d4b3b7ea859 Received: from XCH138CNC.rim.net ( [10.65.20.127]) by mhs04ykf.rim.net (RIM Mail) with SMTP id B3.7C.20947.E7B3B4D4; Thu, 3 Feb 2011 18:34:23 -0500 (EST) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH138CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Feb 2011 18:34:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CBC3FA.E141E772" Date: Thu, 3 Feb 2011 17:34:19 -0600 Message-ID: <680854867F7FD04BB9B06EB8ACA8D5AC05E1F0EE@XCH02DFW.rim.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLwmpURzmRlysrlUidlexdQorGZJPuBh2AgAAR4ICAAAzJgIAACkaAgADJ5gCAAKKGAP//oT5wgAEesLCAAAq77oAAADZggAAIIw+AAAGt8A== References: <680854867F7FD04BB9B06EB8ACA8D5AC05E1F0CB@XCH02DFW.rim.net> From: "Stefano Faccin" To: "Sri Gundavelli" X-OriginalArrivalTime: 03 Feb 2011 23:34:22.0897 (UTC) FILETIME=[E310F210:01CBC3FA] X-Brightmail-Tracker: AAAABgAAAZEXVB72F1QozBdUKM0XVCjOF1TWuQ== Cc: netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 03 Feb 2011 23:31:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC3FA.E141E772 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CBC3FA.E141E772" ------_=_NextPart_002_01CBC3FA.E141E772 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Sri, I cannot agree less on the fact that "the base information elements around access technology is sufficient." I have indicated clear examples that are already in use today for devices to choose whether to route traffic over WLAN or not (i.e. based on the specific SSID). I guess we do not want to design a solution to be deployed in the future that provides less functionality and restricts the scenarios? You may want to look at the work in MIF WG where the current practices document indicates how multiple interfaces are used in current scenarios. I think that unless we solve the open issues and make this solution applicable to real scenarios, it is not possible to adopt the draft. Stefano Faccin Standards Manager Research In Motion Corporation 5000 Riverside Drive Building 6, Brazos East, Ste. 100 Irving, Texas 75039 USA Office: (972) 910 3451 Internal: 820.63451 : (510) 230 8422 www.rim.com ; www.blackberry.com P Consider the environment before printing. From: Sri Gundavelli [mailto:sgundave@cisco.com] Sent: Thursday, February 03, 2011 3:26 PM To: Stefano Faccin; Giaretta, Gerardo; stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Hi Stefano, Sure. Closing the discussion, client-based vs network-based discussion. If there is wide-spread adoption of DSMIPv6 stack on all the operating systems, we would not have needed any specification work. So, the model of client based model is fine, if we can solve the adoption issue. We need classification of the traffic based on some very high level parameters, to most part, the base information elements around access technology is sufficient. I've this set of Internet flows, which should break off when WLAN access is available. If any operator requires more complex policies, sure, they have the IFOM option and I agree with you, it can offer the solution. But, the goal of the spec is to support base set of features. Regards Sri On 2/3/11 3:01 PM, "Stefano Faccin" wrote: Sri, I am glad to hear that you also think that the network-based flow mobility solution cannot intrinsically provide all the features of the client-based approach. I am also glad that you hear that access selection solutions in place today are sci-fi. Why do you believe that an operator that wants e.g. to move the voice traffic and video streaming to the WLAN APs it deploys (because it can offload them and can control QoS) may not want to move the same flows to a WLAN in a hotel where the user will get an awful user experience? Another example: policies may be configured by an enterprise in the device so that the enterprise will allow the MN to direct some traffic on certain WLAN APs (e.g. the one the enterprise deploys) but not on other WLAN APs. I think the per-access network scenarios are indeed more than realistic. Perhaps we're trying to oversimplify the scenarios just to fit the solution in them? Stefano Faccin Standards ManagerResearch In Motion Corporation 5000 Riverside Drive Building 6, Brazos East, Ste. 100Irving, Texas 75039 USA Office: (972) 910 3451 Internal: 820.63451: (510) 230 8422www.rim.com ; www.blackberry.com P Consider the environment before printing. From: Sri Gundavelli [mailto:sgundave@cisco.com] Sent: Thursday, February 03, 2011 2:56 PM To: Stefano Faccin; Giaretta, Gerardo; stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Hi Stefano, My point on the synchronized policy assumption still remains, as I've noted in the other thread. Therefore, if we want to provide a protocol for network based flow mobility to provide an alternative to existing solutions, we need to provide a solution that realistically provides the same functionality. I will probably take a defensive stand on this. As I've stated before, I do not believe network-based mobility approaches can match client based approaches 1:1, in every aspect. Its simply not possible, specially when we don't have the needed MN-AR interface argument, for carrying Attachment Preferences. But, most of the features that are practical from deployment perspective (unlike some of the complex flow mobility scenarios, complexity in the order of science fiction moves :)), every thing else can be achieved over network-based approaches, with out any MN-AR interface. Hence, my argument to keep the specs simple As as for simplified policies versus what current solutions already provide (e.g. per access network policy and not just per access technology), why should we go ahead with a solution that brings us back in time wrt what we can provide to users and operators? Please note that even today (and not just future releases of 3GPP or future IETF protocols) there are deployment scenarios where the decisions to choose or not whether to route traffic over a certain WLAN is based on the specific WLAN (e.g. SSID) and not just on the fact that the MN is connected to WLAN. To large part, in the context of trusted non-3GPP access, basic flow mobility functions can be supported. We can break this down and bring some of the aspects around network ownership, cost parameters and tie the flow policy rules to it. But, I don't think the goal is to support all such features. Regards Sri On 2/3/11 2:22 PM, "Stefano Faccin" wrote: Hi Sri, I need to agree with the Gerardo. You are making an assumption that is incorrect.Synchronizing policies between the MN and the LMA is not an easy and scalable solution. I understand synchronizing policies between a MN and a policy server that is the only repository for a given MN (i.e. one MN has its policy in a single policy server). Assuming that all the LMAs in a network that the MN can be connected to have synchronized policies with the MN is clearly not realistic. As as for simplified policies versus what current solutions already provide (e.g. per access network policy and not just per access technology), why should we go ahead with a solution that brings us back in time wrt what we can provide to users and operators? Please note that even today (and not just future releases of 3GPP or future IETF protocols) there are deployment scenarios where the decisions to choose or not whether to route traffic over a certain WLAN is based on the specific WLAN (e.g. SSID) and not just on the fact that the MN is connected to WLAN. Therefore, if we want to provide a protocol for network based flow mobility to provide an alternative to existing solutions, we need to provide a solution that realistically provides the same functionality. Cheers, Stefano Faccin Standards ManagerResearch In Motion Corporation 5000 Riverside Drive Building 6, Brazos East, Ste. 100Irving, Texas 75039 USA Office: (972) 910 3451 Internal: 820.63451: (510) 230 8422www.rim.com ; www.blackberry.com P Consider the environment before printing. From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Giaretta, Gerardo Sent: Wednesday, February 02, 2011 9:14 PM To: Sri Gundavelli; stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Hi Sri, There is no implicit assumption of synchronized policies. A basic example that shows that there is no assumption is the following: ANDSF policies may be based also on location of the UE. For example the UE should prefer WLAN only in a given location. When the UE is attached over WLAN there is no way for the PDNGW/HA to verify the location of the UE and therefore to verify UE actions based on policies. The assumption on synchronization of policies is only applicable to this draft and I think it is a wrong one. Cheers Gerardo From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Sri Gundavelli Sent: Wednesday, February 02, 2011 6:50 PM To: stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Hi Stefano, One comment. Agree with you there is no ANDSF interface to the network node, but the assumption of synchronized policies between the ANDSF server and the PDN GW/HA is there, implicitly IMO. With out this assumption, I do not know, how the HA can ever validate the flow mobility options received in the BU. If the operator requires any control on enforcing a flow policy rule, the PDN GW/HA needs to have synchronized policies, without which its always the client decision. I'm not sure, operators in 3GPP would like that :) No doubt, the lack of MN-AR interface is surely an issue for supporting complex flow policies. I realize the issues and I agree with you. But, the assumption of synchronized policies can offer some solution with some configuration requirement on the HA (assuming there are no other issues). There are also the proposals on flow mirroring on the UE ..., requiring no flow policies. I've not evaluated this, however. Folks can comment on this. It is also to be noted, for some of the scenarios such, there is no flow policy interface needed. We can identify what scenarios create any configuration limitations on the HA and which one's do not . As I've noted earlier, this is surely an open issue, that we need to discuss in the WG. Regards Sri On 2/2/11 9:08 AM, "stefano faccin" wrote: Sri, thanks for the reply. Can you clarify in which system or scenario ANDSF is available to network entities as well? There is no such availability in 3GPP, and making such information available would require considerable architectural changes, therefore the applicability of this solution to what seems to be the only realistic scenario hinges on 3GPP making considerable architectural changes. I would therefore not be so hastily concluding that the ANDSF information is available to the LMA and underestimate what it would really take to make the solution applicable. If we cannot guarantee that there is at least one realistic solution to have the MNa nd LMA in synch, how do we expect that this solution is applicable at all? In 3GPP there is no need to have such implicit assumption, be cause 1) the MN is provided policies explicitly through the ANDSF, and 2) it is the MN and only the MN that makes IP flow mobility decisions and communicates them explicitly (with well defined signalling) to the LMA, and therefore no magic is needed. There is no need in 3GPP to have the ANDSF and PDN GW policies synchronized, since the PDN GW does not use such policies. Sri, in the end it is a matter of whether we develop a solution that will rely on some unknown magic to be deployed, or a solution that we know can be deployed in at least one way because there are solutions to what I consider major open issues. Cheers, Stefano On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli wrote: Hi Stefano, Thanks for the discussion. As you say, the ANDSF policies are allowing the MN a.) to make the right network attachment decision and b.) make the access selection on a flow basis. This same policy that is present in the ANDSF server, is available for the network nodes as well. I'm not sure, with out this assumption the solution can work for all currently listed cases. We clearly need the MN and the LMA to be in synch with respect to the configured policy. How, that is done, I guess we will not try to know. I thought even in 3GPP, this is the implied assumption ? But, this is for you to clarify. Not specifically for IFOM where UE and PDN GW/HA are negotiating the flow policies, but generally that the PDN GW and the ANDSF policy server will have synchronized policies. The MAG and the LMA have the ability to carry this flow policy information in signaling messages and influence the access selection. The policy is a opaque object, with extensible formats, when carried in the signaling plane, should allow the LMA/MAG to apply those access policies, while assuming MN is following the same rules. These policies can surely reflect the specific WLAN access/operator specific rule. I'm surely with you, the lack of MN-AR interface is surely an issue and I see that. But, we need to understand, what are the limitations with the approach of out of band policy interfaces and what will be the solution limitations. If we need to tie the flow movement at the prefix granularity and rely on the natural ND interface in the form of RA PIO option, more like PDN offload in MAPCON, or at the granularity of a flow level, is open for discussion. I want to simplify this draft for sure, we can surely discuss each of these issues on the WG draft. Regards Sri On 2/1/11 8:29 PM, "stefano faccin" > wrote: Sri, thanks for the reply. I'd like to comment on the "the flow policy decisions need not be based on the specific WLAN network". Does it mean, as I believe it does, that the current solution would not allow an operator deploying such solution to decide to route flows over a specific WLAN or not depending on which specific WLAN the MN is connected to? E.g. the operator or the entity in control of the decisions for the routing may want to direct certain traffic always over WLANs that the operator deploys, and instead route only some of the traffic over WLANs of roaming partners or of the MN user home. How does this solution support that scenario if the LMA is not told specifically which WLAN the MN is connected to? From a deployment point of view, I do not believe we can afford to leave out this scenario. Please note that the establishment of a security relationship between the MN and the MAG, and a specific MAG identity, cannot guarantee that the LMA knows which specific WLAN access network the MN is connected to. Assuming that would severely restrict the deployment scenarios. As for the MN and the LMA being magically in synch, I am very concerned about a "glass ball" solution. You mention ANDSF defined by 3GPP as a solution for this "out of band" delivery of policy. Fair enough, however there is an issue with that. ANDSF is designed specific to be a MN-centric solution where policies are provisioned in the MN and the MN decides which network technologies and access networks it needs to connect to, under what conditions, and which IP traffic needs to be routed on such accesses. No IP point of attachment in the network (i.e. the PDN GW in 3GPP that is the LMA in PMIPv6) is aware under any conditions of such policy. Therefore, even if in order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would unfortunately not provide a solution unless the MN can communicate to the MAG and the LMA the decisions the MN has taken based on the ANDSF policies. I believe the key point here is that we need to understand how the solution can be realistically applied to a real scenario, and that we need to ensure that important and realistic deployment scenarios are not excluded by the solution. Cheers, Stefano On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli > wrote: Hi Stefano: These are valid points and some good comments. Let me share my thoughts. Carlo's draft is not assuming any new MN-AR interface. Its going with the assumption there is established policy on the mobile and on the LMA, which allows the mobile to select the access network at a flow level granularity, without requiring any explicit signaling between the MAG and the MN. To large part this is all about out of band policy interface, such as ANDSF, towards the UE, leading to the assumption that magically the MN and the LMA are in sync with respect to flow policies, access selection and they will make the right forwarding decision. Secondly, the flow policy decisions need not be based on the specific WLAN network, but it is implicitly driven by the MAG - LMA security relation, where the MAG attachment to the WLAN network transitively allows the LMA to make the flow policy decisions based on the MAG identity. If the WLAN network is not trusted, there is truly no MAG in that network, where the LMA shares a security relation with that node. There are still some open issues on this draft that needs to be discussed in the WG. On the approaches to allow more a flow aggregate movement, that is a discussion point. There are issues that we need to discuss, supporting split link model, or eliminating some favorite brand of signaling message (FMA) and riding on PBU/PBA and just with one FMI trigger, and on the aspects around MN applying the flow policies by flow mirroring. We have no agreement on those issues yet. Its just a base draft, for further discussion and resolving those issues. But, hope that is not a stopper for base draft selection. Sri On 2/1/11 6:39 PM, "stefano faccin" > wrote: Raj, thanks for the email. I need to apologize in advance if my questions have already been answered before (though I cannot find a conclusive answer anywhere). I think that a protocol that is developed in NETEXT (or other groups) should have at least a potential realistic scenario for applicability. In terms of applicability, though it is not part of the protocol definition per se, unless there are solutions in place for either the host to indicate to the network where the flows should be routed or for the LMA to receive somehow from somewhere some policies, the solution cannot really provide flow mobility since there is no way to decide which flows are routed where. If we are thinking about a host-based solution, I have not yet seen a solution as to how the host can indicate to the MAG and ultimately to the MAG which flows should be routed on each access. If we are relying on modifications of layer 2 protocols, aren't we defining a solution that works only with some technologies (since for other access technologies it is rather unrealistic to modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-based solution, can we hear of at least one example of a real-life scenario where the LMA would receive such policies, and how such delivery would happen? Also, should there be a solution to have policies in the LMA, how does the LMA actually decide to route flows on one access or the other? E.g., if some flows need to be routed on certain WLAN networks, but shall not be routed on other WLAN networks, how does the LMA know which specific WLAN network the host is connected to? Perhaps I missed the ability for the MAG to know e.g. the WLAN SSID and provide it to the LMA, in which case I would appreciate if somebody could highlight to me where that is defined. I think that, though not integral to the protocol specification, understanding what framework the protocol would/needs to fit in is rather important. Cheers, Stefano On Tue, Feb 1, 2011 at 3:47 PM, > wrote: Hello, We have discussed the flow mobility solutions for Proxy MIP6 previously at IETFs 78 and 79. This is a consensus call for adopting this I-D: draft-bernardos-netext-pmipv6-flowmob-02 as the working group document. I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt The consensus call will expire on Feb 15th, 2011. Please indicate your support or concerns in adopting this I-D as the WG baseline document on the mailing list. Please note that this I-D will serve as the baseline in the WG and will be developed further based on input and feedback from WG members. -Basavaraj _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_002_01CBC3FA.E141E772 Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable Re: [netext] Consensus call to adopt I-D: draft-b= ernardos-netext-pmipv6-flowmob as WG doc

Sri,

I cannot agree less on the fact tha= t “the base information elements around access technology is sufficient= .” I have indicated clear examples that are already in us= e today for devices to choose whether to route traffic over WLAN or not (i.e= . based on the specific SSID). I guess we do not want to design a solution t= o be deployed in the future that provides less functionality and restricts t= he scenarios? You may want to look at the work in MIF WG where the current p= ractices document indicates how multiple interfaces are used in current scen= arios.

 

I think that unless we solve the open issu= es and make this solution applicable to real scenarios, it is not possible t= o adopt the draft.

&nbs= p;

Stefa= no Faccin

 <= /span>

Standards Manager

=

Research In Motion Corporation 5000 Riverside Drive
Building 6, Brazos East, Ste. 100=

Irving, Texas 75039 USA
Office= : (972) 910 3451 

Intern= al: 820.63451

3DUntitled-1: (510) 230 8422

www.rim.com= ; www.bla= ckberry.com

Stefano Faccin

 

Standards Manager

Research In Motion Corporatio= n
5000 Riverside Drive
Building 6, Brazos East, Ste.= 100

Irving, Texas= 75039 USA
Office: (972) 910 3451 

Internal: 820.63451

3DUntitled-1: (510) 230 8422=

www.rim.com; www.blackberry.com

3D"ci=

 

P Consider the environment before printing.=

 

From: Sri Gundavelli [mailto:sgundave@cisco.= com]
Sent: Thursday, February 03, 2011 3:26 PM
To: Stef= ano Faccin; Giaretta, Gerardo; stefano faccin
Cc: netext@ietf.org;= Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to= adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

 

Hi Stefano,

Sure. Closing the discussion,= client-based vs network-based discussion. If there is wide-spread adoption= of DSMIPv6 stack on all the operating systems, we would not have needed any= specification work. So, the model of client based model is fine, if we can= solve the adoption issue.

We need classification of the traffic bas= ed on some very high level parameters, to most part, the base information el= ements around access technology is sufficient. I’ve this set of Intern= et flows, which should break off when WLAN access is available. If any opera= tor requires more complex policies, sure, they have the IFOM option and I ag= ree with you, it can offer the solution. But, the goal of the spec is to sup= port base set of features.


Regards
Sri


On 2/3/11 3:= 01 PM, "Stefano Faccin" <sfaccin@ri= m.com> wrote:

Sri,<= br>I am glad to hear that you also think that the network-based flow mobilit= y solution cannot intrinsically provide all the features of the client-based= approach.
 
I am also glad that you hear that access selection= solutions in place today are sci-fi. Why do you believe that an operator th= at wants e.g. to move the voice traffic and video streaming to the WLAN APs= it deploys (because it can offload them and can control QoS) may not want t= o move the same flows to a WLAN in a hotel where the user will get an awful= user experience? Another example: policies may be configured by an enterpri= se in the device so that the enterprise will allow the MN to direct some tra= ffic on certain WLAN APs (e.g. the one the enterprise deploys) but not on ot= her WLAN APs. I think the per-access network scenarios are indeed more than= realistic. Perhaps we’re trying to oversimplify the scenarios just to= fit the solution in them?
 
Stefano Faccin Standards ManagerRe= search In Motion Corporation
5000 Riverside Drive
Building 6, Bra= zos East, Ste. 100Irving, Texas 75039 USA
Office: (972) 910 3451  I= nternal: 820.63451: (510) 230 8422www.rim.com <outbind://28-00000000119E3389DDC5E04593E90FB13= 32A08C10700A3F06753D40D4149BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C8= 0529AAB2313EF3E0000006F1BEA0000/www.rim.com> ; www.blackberry.com<= span style=3D'color:#1F497D'> <outbind://28-00000000119E3389DDC5E04593E90= FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11= B4C80529AAB2313EF3E0000006F1BEA0000/www.blackberry.com>
<http://www.blackberry.com/>

P Consider the environment before printing.

From: Sri Gundavelli [mailto:sgundave@cisco.com]
Sent: Thursday, February 0= 3, 2011 2:56 PM
To: Stefano Faccin; Giaretta, Gerardo; stefano fac= cin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject:<= /b> Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-= flowmob as WG doc

Hi Stefano,

My point on the synchronized poli= cy assumption still remains, as I’ve noted in the other thread.
Therefore, if we want to provide a protocol f= or network based flow mobility to provide an alternative to existing solutio= ns, we need to provide a solution that realistically provides the same funct= ionality.

I will probably take a defensive stand on this. As= I’ve stated before, I do not believe network-based mobility approache= s can match client based approaches 1:1, in every aspect. Its simply not pos= sible, specially when we don’t have the needed MN-AR interface argumen= t, for carrying Attachment Preferences. But, most of the features that are p= ractical from deployment perspective (unlike some of the complex flow mobili= ty scenarios, complexity in the order of science fiction moves :)), every th= ing else can be achieved over network-based approaches, with out any MN-AR i= nterface. Hence, my argument to keep the specs simple
 
As as for simplified policies versus what current solu= tions already provide (e.g. per access network policy and not just per acces= s technology), why should we go ahead with a solution that brings us back in= time wrt what we can provide to users and operators? Please note that even= today (and not just future releases of 3GPP or future IETF protocols= ) there are deployment scenarios where the decisions to choose or not whethe= r to route traffic over a certain WLAN is based on the specific WLAN (e.g. S= SID) and not just on the fact that the MN is connected to WLAN.
<= br>To large part, in the context of trusted non-3GPP access, basic flow mobi= lity functions can be supported. We can break this down and bring some of th= e aspects around network ownership, cost parameters and tie the flow policy= rules to it. But, I don’t think the goal is to support all such featu= res.



Regards
Sri



On 2/3/11 2:22 PM, "S= tefano Faccin" <sfaccin@rim.com>= wrote:
Hi Sri,
I need to agree with the= Gerardo. You are making an assumption that is incorrect.Synchronizing polic= ies between the MN and the LMA is not an easy and scalable solution. I under= stand synchronizing policies between a MN and a policy server that is the on= ly repository for a given MN (i.e. one MN has its policy in a single policy= server). Assuming that all the LMAs in a network that the MN can be connect= ed to have synchronized policies with the MN is clearly not realistic.
As as for simplified policies versus what current solutions already provid= e (e.g. per access network policy and not just per access technology), why s= hould we go ahead with a solution that brings us back in time wrt what we ca= n provide to users and operators? Please note that even today (and no= t just future releases of 3GPP or future IETF protocols) there are deploymen= t scenarios where the decisions to choose or not whether to route traffic ov= er a certain WLAN is based on the specific WLAN (e.g. SSID) and not just on= the fact that the MN is connected to WLAN.
 
Therefore, if we w= ant to provide a protocol for network based flow mobility to provide an alte= rnative to existing solutions, we need to provide a solution that realistica= lly provides the same functionality.
 
Cheers,
 
Stef= ano Faccin Standards ManagerResearch In Motion Corporation 5000 Riverside Drive
Building 6, Brazos East, Ste. 100Irving, Texas 750= 39 USA
Office: (972) 910 3451  Internal: 820.63451: (510) 230 8422www.rim.com <outbi= nd://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42E= A30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www= .rim.com> ; www.blackberry.com <o= utbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16= E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000= /www.blackberry.com>
<http://www.blackberry.com/>
=
P Consider the environment before printing= .


From: netext= -bounces@ietf.org [mailto:net= ext-bounces@ietf.org] On Behalf Of Giaretta, Gerardo
Sent:<= /b> Wednesday, February 02, 2011 9:14 PM
To: Sri Gundavelli; stefa= no faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subj= ect: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pm= ipv6-flowmob as WG doc

Hi Sri,
 
There is no= implicit assumption of synchronized policies. A basic example that shows th= at there is no assumption is the following: ANDSF policies may be based also= on location of the UE. For example the UE should prefer WLAN only in a give= n location. When the UE is attached over WLAN there is no way for the PDNGW/= HA to verify the location of the UE and therefore to verify UE actions based= on policies.
 
The assumption on synchronization of policies is= only applicable to this draft and I think it is a wrong one.
 
= Cheers
Gerardo
 

From: netext-bounces@ietf.org [m= ailto:netext-bounces@ietf.org] On Behalf Of Sri Gundavelli
= Sent: Wednesday, February 02, 2011 6:50 PM
To: stefano faccin<= br>Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re= : [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmo= b as WG doc

Hi Stefano,

One comment.

Agree with you ther= e is no ANDSF interface to the network node, but the assumption of synchroni= zed policies between the ANDSF server and the PDN GW/HA is there, implicitly= IMO. With out this assumption, I do not know, how the HA can ever validate= the flow mobility options received in the BU. If the operator requires any= control on enforcing a flow policy rule, the PDN GW/HA needs to have synchr= onized policies, without which its always the client decision. I’m not= sure, operators in 3GPP would like that :)

No doubt, the lack of MN= -AR interface is surely an issue for supporting complex flow policies. I rea= lize the issues and I agree with you. But, the assumption of synchronized po= licies can offer some solution with some configuration requirement on the HA= (assuming there are no other issues). There are also the proposals on flow= mirroring on the UE ..., requiring no flow policies. I’ve not evaluat= ed this, however. Folks can comment on this.

It is also to be noted,= for some of the scenarios such, there is no flow policy interface needed. W= e can identify what scenarios create any configuration limitations on the HA= and which one’s do not . As I’ve noted earlier, this is surely= an open issue, that we need to discuss in the WG.



RegardsSri




 


On 2/2/11 9:08 AM, "stefano= faccin" <sfaccinstd@gmail.com&= gt; wrote:
Sri,
thanks for the reply. Can you clarify in which system= or scenario ANDSF is available to network entities as well? There is no suc= h availability in 3GPP, and making such information available would require= considerable architectural changes, therefore the applicability of this sol= ution to what seems to be the only realistic scenario hinges on 3GPP making= considerable architectural changes. I would therefore not be so hastily con= cluding that the ANDSF information is available to the LMA and underestimate= what it would really take to make the solution applicable.

If we can= not guarantee that there is at least one realistic solution to have the MNa= nd LMA in synch, how do we expect that this solution is applicable at all?= In 3GPP there is no need to have such implicit assumption, be cause 1) the= MN is provided policies explicitly through the ANDSF, and 2) it is the MN a= nd only the MN that makes IP flow mobility decisions and communicates them e= xplicitly (with well defined signalling) to the LMA, and therefore no magic= is needed. There is no need in 3GPP to have the ANDSF and PDN GW policies s= ynchronized, since the PDN GW does not use such policies.

Sri, in th= e end it is a matter of whether we develop a solution that will rely on some= unknown magic to be deployed, or a solution that we know can be deployed in= at least one way because there are solutions to what I consider major open= issues.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 9:06 PM, Sr= i Gundavelli <sgundave@cisco.com> w= rote:
Hi Stefano,

Thanks for the discussion.

As you say, th= e ANDSF policies are allowing the MN a.) to make the right network attachmen= t decision and b.) make the access selection on a flow basis. This same poli= cy that is present in the ANDSF server, is available for the network nodes a= s well. I’m not sure, with out this assumption the solution can work f= or all currently listed cases. We clearly need the MN and the LMA to be in s= ynch with respect to the configured policy. How, that is done, I guess we wi= ll not try to know.  I thought even in 3GPP, this is the implied assump= tion ? But, this is for you to clarify. Not specifically for IFOM where UE a= nd PDN GW/HA are negotiating the flow policies, but generally that the PDN G= W and the ANDSF policy server will have synchronized policies. The MAG and t= he LMA have the ability to carry this flow policy information in signaling m= essages and influence the access selection. The policy is a opaque object, w= ith extensible formats, when carried in the signaling plane, should allow th= e LMA/MAG to apply those access policies, while assuming MN is following the= same rules. These policies can surely reflect the specific WLAN access/oper= ator specific rule. I’m surely with you, the lack of MN-AR interface i= s surely an issue and I see that. But, we need to understand, what are the l= imitations with the approach of  out of band policy interfaces and what= will be the solution limitations. If we need to tie the flow movement at th= e prefix granularity and rely on the natural ND interface in the form of RA= PIO option, more like PDN offload in MAPCON, or at the granularity of a flo= w level, is open for discussion. I want to simplify this draft for sure, we= can surely discuss each of these issues on the WG draft.


Regards=
Sri






On 2/1/11 8:29 PM, "stefano faccin&q= uot; <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com> >= wrote:
Sri,
thanks for the reply.

I'd like to comment on the &quo= t;the flow policy decisions need not be based on the specific WLAN network&qu= ot;. Does it mean, as I believe it does, that the current solution would not= allow an operator deploying such solution to decide to route flows over a s= pecific WLAN or not depending on which specific WLAN the MN is connected to?= E.g. the operator or the entity in control of the decisions for the routing= may want to direct certain traffic always over WLANs that the operator depl= oys, and instead route only some of the traffic over WLANs of roaming partne= rs or of the MN user home. How does this solution support that scenario if t= he LMA is not told specifically which WLAN the MN is connected to? From a de= ployment point of view, I do not believe we can afford to leave out this sce= nario. Please note that the establishment of a security relationship between= the MN and the MAG, and a specific MAG identity, cannot guarantee that the= LMA knows which specific WLAN access network the MN is connected to. Assumi= ng that would severely restrict the deployment scenarios.

As for the MN= and the LMA being magically in synch, I am very concerned about a "gla= ss ball" solution. You mention ANDSF defined by 3GPP as a solution for= this "out of band" delivery of policy. Fair enough, however there= is an issue with that. ANDSF is designed specific to be a MN-centric soluti= on where policies are provisioned in the MN and the MN decides which network= technologies and access networks it needs to connect to, under what conditi= ons, and which IP traffic needs to be routed on such accesses. No IP point o= f attachment in the network (i.e. the PDN GW in 3GPP that is the LMA in PMIP= v6) is aware under any conditions of such policy. Therefore, even if in orde= r to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would unfortu= nately not provide a solution unless the MN can communicate to the MAG and t= he LMA the decisions the MN has taken based on the ANDSF policies.

I= believe the key point here is that we need to understand how the solution c= an be realistically applied to a real scenario, and that we need to ensure t= hat important and realistic deployment scenarios are not excluded by the sol= ution.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 7:43 PM, Sri G= undavelli <sgundave@cisco.com <http://sgundave@cisco.com> > wro= te:
Hi Stefano:

These are valid points and some good comments. Let= me share my thoughts.

Carlo’s draft is not assuming any new MN= -AR interface. Its going with the assumption there is established policy on= the mobile and on the LMA, which allows the mobile to select the access net= work at a flow level granularity, without requiring any explicit signaling b= etween the MAG and the MN. To large part this is all about out of band polic= y interface, such as ANDSF, towards the UE, leading to the assumption that m= agically the MN and the LMA are in sync with respect to flow policies, acces= s selection and they will make the right forwarding decision. Secondly, the= flow policy decisions need not be based on the specific WLAN network, but i= t is implicitly driven by the MAG – LMA security relation, where the M= AG attachment to the WLAN network transitively allows the LMA to make the fl= ow policy decisions based on the MAG identity. If the WLAN network is not tr= usted, there is truly no MAG in that network, where the LMA shares a securit= y relation with that node.

There are still some open issues on this d= raft that needs to be discussed in the WG.  On the approaches to allow= more a flow aggregate movement, that is a discussion point. There are issue= s that we need to discuss, supporting split link model, or eliminating some= favorite brand of signaling message (FMA) and riding on PBU/PBA and just wi= th one FMI trigger, and on the aspects around MN applying the flow policies= by flow mirroring. We have no agreement on those issues yet.

Its jus= t a base draft, for further discussion and resolving those issues. But, hope= that is not a stopper for base draft selection.


Sri






On 2/1/11 6:39 PM, "= ;stefano faccin" <sfaccinstd@gmail.= com <http://sfaccinstd@gmail.= com>  <http://sfaccin= std@gmail.com> > wrote:
Raj,
thanks for the email.

I= need to apologize in advance if my questions have already been answered bef= ore (though I cannot find a conclusive answer anywhere).

I think that= a protocol that is developed in NETEXT (or other groups) should have at lea= st a potential realistic scenario for applicability.

In terms of appl= icability, though it is not part of the protocol definition per se, unless t= here are solutions in place for either the host to indicate to the network w= here the flows should be routed or for the LMA to receive somehow from somew= here some policies, the solution cannot really provide flow mobility since t= here is no way to decide which flows are routed where. If we are thinking ab= out a host-based solution, I have not yet seen a solution as to how the host= can indicate to the MAG and ultimately to the MAG which flows should be rou= ted on each access. If we are relying on modifications of layer 2 protocols,= aren't we defining a solution that works only with some technologies (since= for other access technologies it is rather unrealistic to modify L2 for IP= flow mobility purposes)? If we are thinking of an LMA-based solution, can w= e hear of at least one example of a real-life scenario where the LMA would r= eceive such policies, and how such delivery would happen? Also, should there= be a solution to have policies in the LMA, how does the LMA actually decide= to route flows on one access or the other? E.g., if some flows need to be r= outed on certain WLAN networks, but shall not be routed on other WLAN networ= ks, how does the LMA know which specific WLAN network the host is connected= to? Perhaps I missed the ability for the MAG to know e.g. the WLAN SSID and= provide it to the LMA, in which case I would appreciate if somebody could h= ighlight to me where that is defined.

I think that, though not integr= al to the protocol specification, understanding what framework the protocol= would/needs to fit in is rather important.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 3:47 PM,  <Basavaraj.Patil@nokia.com <http://Basavaraj.Patil@nokia.com>  <http://Basavaraj.Patil@nokia.com> &g= t; wrote:

Hello,

We have discussed the flow mobility solutions= for Proxy MIP6 previously at
IETFs 78 and 79.
This is a consensus cal= l for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as t= he working group document.
I-D: http://www.ietf.org/id/draft-bernardo= s-netext-pmipv6-flowmob-02.txt

The consensus call will expire on= Feb 15th, 2011. Please indicate your
support or concerns in adopting thi= s I-D as the WG baseline document on
the mailing list.

Please note= that this I-D will serve as the baseline in the WG and will be
developed= further based on input and feedback from WG members.

-Basavaraj
<= br>_______________________________________________
netext mailing listnetext@ietf.org <http://netext@ietf.org>  <http://netext@ietf.org>
https://www.ietf.org/mailman/listinfo/netext=

 
 
-------------------------------------------------= --------------------
This transmission (including any attachments) may c= ontain confidential information, privileged material (including material pro= tected by the solicitor-client or other applicable privileges), or constitut= e non-public information. Any use of this information by anyone other than t= he intended recipient is prohibited. If you have received this transmission= in error, please immediately reply to the sender and delete this informatio= n from your system. Use, dissemination, distribution, or reproduction of thi= s transmission by unintended recipients is not authorized and may be unlawfu= l.
---------------------------------------------------------------------=
This transmission (including any attachments) may contain confidential= information, privileged material (including material protected by the solic= itor-client or other applicable privileges), or constitute non-public inform= ation. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please im= mediately reply to the sender and delete this information from your system.= Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful.

-----------------------------------------------------------------= ----
=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_002_01CBC3FA.E141E772-- ------_=_NextPart_001_01CBC3FA.E141E772 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAKAA4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDSu9Nv V0vVpbjQL2KfU7xR5T6qqmRclsrnhecDFbGl6hqL69Noem63ZRQ6faops5Y2mmiYBQdz8BuSR1qD 4pxpLdeHo5UV0N2cqwyD93tXexW0ELtJFBGjv95lQAt9T3oA/9k= ------_=_NextPart_001_01CBC3FA.E141E772 Content-Type: image/png; name="image002.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.png Content-Location: image002.png iVBORw0KGgoAAAANSUhEUgAAAIoAAAA+CAIAAAB7vhRQAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAIthJREFUeF7tfAeYHdWV5q1b8eXXudXKoAyIIH1IgESwMTKDSDZebNKsZa8/ xh8MNgxj1mYxLGZtgseDDcwABsb2YH9ggglDMAiEyCIMEkkSCOWW1Orw8qt0b+1/ql4/tbJEN9t8 OxSPp3rVFc+555z//OfcUtjwLZyxAB/8I8ObUMLfGmNCYYES/Yq+63/ETyz1LdH6Hvbh4RXCwxX8 I2vrOH3tSNqK1W2X7j/78Ill4JWj5x2epaaeSPZ1qdPPUKpDs9TUs93JdrhcXflDc8X/T8+CAQ65 QWef7dJ/DbV+mf4hqjO2beNnexP7evbhtJ6d7xGOLc30pKpLJjh5nMEtsBw1kIH0hfRZUGXS7fej kUMV0elxVfyQpBts9wZ3zaE9etAiGPTtbIsciqIFwXg1MbtpkukFYkj8mxJIJv1AQtt24FUDv2rb ObfQy7xe6Zajm4dawrj0OXRyw68euBQasByxm9RzmN5wZHysXvZ2Np4IBezPgt0FziMVnFuRipRc VVTF80XOlJ1Bpada6HKKBSagGjjW2ngYkmGxP3e5h32H2dlCfpFrCWOOYgTsEKO1mZmKH4TOTYm+ EZbqPyHpaAtW9rBPwBQ1YDzA3gHgGcdvEQRCqjLgMlClbFStsWa2XUvEGPdEFffgq5zJz5Ny9ns4 DtGgqJ0GFiOZyZgD7xJ6mIRkp6cnZ3wdGovA9iAWIHboxYdiAtK1VELpS5iKpsSEwt1wi8bzOlsj c+9UOrtxB3VXO4gLD+Ghw2o9oavCHfj0D9lDo9QPNVpMH0Kt+5pP+bBwaQFXuEwF3GO8wgKLC2jL NgwWuDGcXdU8FQZIMc5PGNaIRNat5l0W+NGVDTJqstPo+vQP7pTEFW4kkBnZfKTQMEnAV/jvtsM+ 5c3XDxtu9URZYaSeIGhXE1P0BtUVUuHkmsLH/bQfWA9XpMG5w3mF+xlViWvcF76tsWygWK6iicDA h3ELu5k8meXpXr+UIzkbiFdhwqzhJAFpJfSoFMLwk/TCSUHQN6kpUlWo1iH2jcOnnn43su2BJBsX bxwDD+d6gabCfsIIM7gPsxVeIbGKRilMRfV9WRIycPA//Qefx6AxSL3ienHDsiXbKMsMcI90QzKH a+y3EODwSAF0y+H2yHhgaBBjDaX32xp8Nv40WA+9n1BosMa60/EDfD0g3DGZ8Qfb8ELMh3qG4FqQ shuoNqEJdxzQhuQbmjsc3/cRegLmqTBSSBF64tyHm1OCSlJ9Nd/TY4uqChjJkH9BC+CYYNyBp1Rt GFWAw30xUPCRkgaqB9oibipy24NZhlU90cX7zadZs2anx4wra1wEQ6QeISFftQwHJbyRrl9oG1ue d1qHLXPkqHTJJf4AyStCCkVVgRrcGN/Iq1vsfCEIDENTfYGI5UFRAVd9U2B3qZYroq9Q6S3wrm73 veV9FQCbmslggJnYVVFsYMTBaKV+7LCqZ8ATYLCNt1IzzI4OV/dcT+j6oK1HQKaA0KriBBwDPusp XVOP8A6dAyvqczyLKSaoPWgoCuTwcnBkUmM2l+vL+T78TSXlQTVkPdAwTDGkalVV182UZLphGlXb Xdvtvfpm5ePldsmDyQB7AhpWB6a6g9HT8MWe7UeIxdhIJd6hpmMe/AYH6Br0wAkQtxURI96Ae8DW Us1PODiebMhJ3ZXCkkEyCDRIWUodbiwI9EDRmQBE0asiKApfKpoCG0A2S7icQADpDw7LF7YD8qFU KuZ5UMlkxWEHJVoam/K91VK5CtRJHhPLYOMOneNzpJ7RVqZNTZquj2GKYABRcNFPXRMHF3lBCH27 TzjoMbjDuE0SQcZEcEKEyEqVJlMxlitSqJrFD5jabCSQgSIrtSBvsgYcgDPjULg7rGOroRY1v1fa Piwa8JwjRgUCvo3DlkhfgiuGYZIqQ3ARuKJcqI4ebY4+INFbKG/tiTBBPNTPYIHccKonKihEfiCl 8AOtxgbgYMQLxdAgD8arhi9U6MV3VaEHXpwMS0V8hyGE3xwUgIbwLuHpdQQRgW0QvYqggi8SO4Vw 7CVjbuClmt2JByX0uOv7psI5Zy6cFwcgQKzDChcC+ADy17ijyB7XJkRNtAQCIWmcSV1wrGnwb67n wbp0AyRUoPksnmQ9hUos5s6c0dy92d7SjcdKhuigPy59Wgc3aA//aS/cH05rxycUtYHFFV8Knfu6 qgeq5SvIUDyOtF94ug8MnILiyEoge8QDaIf8Hwa3RtEBnBoxOIFKPo1clMI0IQIV5J3p+yMVpsaz RT21STEKwquqVO7TVaFxMAdCVel0+EAd+AluSbU8FhPc8EjthkcFKD1wLGHrim0EXkwNDEjOR/YM olCtYucYCxzJ8uUzTkq0QjWspCiDhW3D7NxqGV2Irdu4OUrPxMD7g/lHFAiEJjFylbSjxzyzymI+ h7tgtpn3NN/ThVB9T3U9zXORXKq+JRwdQV1xFcVD+AZdI7jucoOrCDMSwVyyraMPVEaNM1y/xJGH 1vJ/KBXATYXwWYDBrsPwYLalwO/yq74BuEAWFLIE8Lak0uiDhf5FPoXxIaFr7EjUkRRBIq1WpbFq jT0kzm04rYd8M54vhKAZNW4oOp5cwsErAnIXGtM8riNmMAPS9aRflkKr6pqrKRUDOhS26dsxz447 +Pa49FWiviEWTxGu6vlGVcR9G5ahStf1PSeTbGZ+UlbjikyhxsAk4K8bSA80HOAD0aZS00AHBEDj vkdWqbrIh8APMFWDqYa8QY3TIe3U2AJKU8MclaIY94uFypSpMQMYe7tM6FM6mV3HnjBM7t8y8JD9 PRxjZHK8oVVJaJTBBxY4A6l1uvl8YPeygs2KCVMkY7aluczVbGFrgYEYA0emBDrkhKFb1dQi1GUq qZhiqm5cF5bhW7qIm25Mh3SrmUbnoMMbzWSFaDfdZLxk6GVVRX5FsYch52S+DACqwTKIQmB3o0Jk IPIjlCkYJwQa4P52LGiQI4U/hFtEhFQQmngAbWcakytXy3x+CJzbbtVwySWXnHvuucuWLbvyyis3 b968V11FKom+ETCj/esr9cN1Xfc87/jjj7/22muF5137s58tfO45uK1TUpNbhaa5wtWVmMs3id5J X/nKOddcVu3deufPfsRWvP+tL83u9HuThx1+0FFz0uMPhC8KwDyHIAkykqZR2fTxsof+zV2zrNkS ik+igWB9jsCD8CBEbOv0WY026wJe84HoRIoJi7wnRC8VDArHAVz2pes7rreqVFleZFqCIfkC6Pbh vuC5iELYUVxECwmDaa7PmerD0MkejWzmwSe8d5ZW9iq0ve6w3fXqwh05cuSGDRuig2+//fYLL7xw dyci/xsqIzoWgEgigMOlAzgRbagIsYv8edGiRccddxz2f/fdd08+dX7v2nXfaj4sWXA0wSqQh+0l Jh1w5ZN/yh7QhH1eeeTeRy757twJDeljjpn1kztNI7u7mym889Qj/7igI+GbQGUE2zSHJRSNV7zu bIeceEhDNegBVgMhEAYScNXEe4LlZICCBOXBw6LOwPLSX1u0t/ZWK4WgDHSQYm5UaoiiDT1tffzB h4XqUeGKgScxZmRgJha/pS5cVNir9Pe6w65jz4QJE3Ck4xAuPO200/ZwloGGgnUoA9/QDQ1eKXep G/zJNMEYMtfxJk6YOHnSBHCKloockGhI7gc5Zp/ygwXQjY0kL2CZTEvLyLEl3z/2ssugm4rwkTaW A4YPUhhHSlfKcohgY9kW3UggaxeSu4HuKDGQXhwkmV1pa0xRsMAVgIwlyn40rNCIQBgQJ2BVIcuB KMqgLJSCqdlTWpMzxzbMmtg4MqOVy6RtSrAoSwrNtT/ehAEozD/DqhKNT8L+pOohWbZTDyQbGUEk 30j0kSh3ucyePfsPf/jDzTfffMcdd8BfYZ9Jkyb95je/ufXWW2+77bYzzjhj5yA00PsZJjJ2ZCe8 mSWE42JEAgP1+bmDTjnuhL/7ZgkZkabi6Tdt3NKzsThu9ldYehJaOpBn6lxJKLALFuPM5MBnPEH3 6L/86P0lpxRoBhg0Qm4YzcB1fgWxJdVgSkgf8iMyvErx3wdmxpBA6FJNRdNBgRKoJmihigpz+jKB 0Z6MHz65beqkNLIk4YZZrI6UGfKJKGtKlQNVEMGNcwVSU6TnMcM0C7khCDx4JAS97ZZIMdFioHTV 77UG7qRpGjgsbDn77LPPO++86E8IVIlEAkq66KKLoi3z589/++23161bVz82Cjx1xVNXIIjgwBtj NRgeYJPquU4P87932/XYBzaR0Hi5u/D23XePMTZZo1sYa3Q4s+CNyptfeuwPaQvjGDCaiqJm38au F1/rW782kY2XNLNBagm7xPXNuZjVUI7HzSY37sVk0VOa/HJb0vogxpSylq3qNpQUVxJWscLUWNnw dIyIKugcoSRcUbGkV0ynSoc3j2hLO++95+Rd7qLcITQL+yHN8TQJt2YGvNJgsRxXBQxXseJVuOgq PbQK2Bj6dpgTlkho9QE6bty4fD7vum61Gu7dbxUDRb0nYL1DnK8fFl0Gy5w5c+obFy5ciPW5c+fW t7zzzju5XA66TKfTqVQqmUxGutm2UAWOJZAwuj4GpC3FSrbm76+/vnXMKOG7CYWw7FO33LVy2ZKx IxvdCkVancHI8izoefa6f1zyq58sv/nKVb/6nx/885Vv/flud8P77UY1w6oqnQnQwRRmCsEMGVRG r8TMXNlk6P4wp33VaZjRR56oL+EmY46le8W+WLkczyUwImzdaxhlN4+WBnPVzbrWKxxghc0dCeew qUaGx5Uyg2eErbsurMTlQQz9Pp7EcwW+w0gXaDXx+KYuWCF+CoSGY489FoO+Pu6jaB2LxW666aYH H3zwlltuwfpAqxgooR2tZzvx7eZHHQ7g7I899hi0tWXLlieeeAK7P/7442vWrMFtwWgQ/wuFwr33 3nvggQdCMbAtgMBot9pC0TZoDCyffFDQ7RemHTj3lEu/g3IPfpoKy6/e+O//++eHTWowdQr1OKqi aCkFoTirptvMVFzzqokA7t7xrSAh/JhbQRZKgV5Nu0q8RyDB8SiRSsIdFvq4Vu7155zw7U9eNzZt eauD61rVBYODQJVvyoh8YSxT8pVKZvp3M+MnrH70iga9YCpBoZKwjfZ4blU2npk2ofn1FR/mcn4C BJHoyeWDRMIzYJEcdgluuyHQSoKXN2+NdedqTuiCCy4oFouLFy+GAqAGGEqkCQgNIeDQQw+1bZtU vSsvRRt3qQIYAc4YhaLe3t6mJkJQ9YX4qtAS68a7B6UOxNZQ3qmnnoqdX3755aOPPhor0N8V37jA +evbqCav93v++ZGHDp5/fCGoJDxTNdSfnblgyV/uOWPGxI50Z/vJ3zrk8ju3IoEFBPCdJX+5N2Px JDyG43dvXP3BS/e1F3qaglLJ8h0lqYlMsSLTR88YP+uYl//XT6af9VUj/Xyx7cBEdsS4GdcrpTVa Kub16B8+d1mu9PERx/46M+O0/IcfaIl1nyy86oDjb0uMP6n02vc+WHhnE+oLjceMPnFB570XNZzw 3arrP3rfnbNPvPjIs35Y6vn4X2+4elP3m9847+pXX/9d58fvn3POL99a+uC6zldfeNl8+XX1xUUL m9qypmn97ne/++lPf3r55ZffcMMNn3zyCXz+hx9+WA8QkWIiSe6ch+zJue3O4iLdnHDCCRgCOCOW 9evXYyN8XfQTC1IlGE2kSFwYS7lcBo4YqEg4Hl3T04GV4tYWN/e1y34A3TghSwrdPPfHp/7jL7+f bna0N8UAq4SmIoVuQwLjVZmoHnnWeZPnnz/yb84de+aCGRdd+zfX3r3V7OjjTdJooEIA/IePdLaY POLY9JxTpl1xV3r838Wbz40Zh6DMU8h3Lbn9HN+0EtNOGTflv8cPmvv6Lcd0vnd7YswpxULQu3zh +rVvvfPSbxMNqoyxiuUnRx+/SfG9bCbPqvNO/f7EE753yYJZD/715n+4/r687Y8Ye6QWz6LY0zhq rpYcnSuZi1+177jt1s7ujZMnT8HDwGK++c1vfv/734carr76aviPMWPGQHRQSSQNiCuS5M6jfO+x Z+djopg0b968+p9GjRrV0dGBGFPf0tbWdtBBB0E9wA5nnnkmQAT2uf/++weeDXEUi6mpfTI/8uBp Z//wQoAFz7PhvsrrCndcedME1pYwAyvmoXsmRN2oNIBh1oQWp/zRd8pS5hl6A5hvtPBMu6PFcoBd qgGA35JJbl21lBV6R8w/3+9cGp84L94wS65eCdY1t+lD1tnj51ZypzvR0rJl49LCx8tXvPGIw7oV UZGsV7ELdhFZglJBkNVitm30BAkHVIWTz04ZtfI/n1j60ab/WPgo4mZTi1IpF+ySU0AEEjyRbHn6 GYo6X5p3wrL/XIqVp556Kh6PT548GYEAP//85z9/9NFHSCujUbtXemW/Obco5cTZx44di2/YxIoV K6677rrOzs6pU6diS6lU6uvru+qqq3BnEydOhG/FMOnq6gJMqOumPlKASU3V/JB1XXzlFU0jWtEL nQDKZcojt99TWd0VY2oyGVNiPgqXUXW4rGkO131gaSOua3GD63HGE4B5ne/yYpcKrg68CogWsJzg 4PxqYfOaw78yb91jv060x9rHN9tbl6LFIBMXforlWNrPWqs7l7ccMKX5qIOnzV9gsGQllgaCzCTT HdlpnqubpsoKWjyZnTLrghEjTner0worlh4ye+bXvnzet8+6xS/1yl6eSKgHHzF35qy5B0467LXX tq5cRff51LNPzvvqScfOnXvWWWfBMpB9A9lGXAnG8fLly7EC5LZLixk4gveknl0eXM+NAKBhEFDA UUcdhZiPkyIBymaz7e3tuDAuj4j34x//+IEHHsCQQST75S9/GV0YRgYUhxWPCVPVenq7jxs5e/rZ J/fYZQd2oirvvrj44d/8FrpJK4lsOmNTxT9MMZC9BgJsqKmUtix51l72vL76VfXVh1645m8X/ury RGltIy/rYFXIm2sYFvFEYuVLi9gnL/nFNyufPCr7Him6a7n/hsx3gSYz3bfHVlZobz5eevP+w8++ qjE1RikuzijehvWLY8m+KV/+uiurSECLq97a+swVo0YHPfm3mrPjVr/5l+L7//L3V19+4kktN143 R69WH/njvx4/98QfXn7PrTf+/JZbHgjrV+kf/cOljltF9vfGG29gvD700EN4/Oeff/7EE0/8+te/ juGL7x0i+s5eClt2hAYRKhsIDXp6epqbm3c4uJ7BDNyOkQL1YAvs6cUXX2xsbIRW4OKifXCLuCes tLS0ANRNnTLV4Uo1l7vizPNu/OOf0iNSwDQxeDCVXXHo8SuXLZtgzBLuu0d9mTU2+ZVNW1pPv/jI y35dCWQcBOTWj6+YPXF8BmQKM5PMSmttaCSE/nxWVlFBQx+BAWYNjQOb7E0dY+MTJigAyEBLqay+ vttrzqRjmlLOF7knsxljfc6l3ilTR3xpbNMKKP9t9VWdNbQhX4kVS23ZcUcEo8eNGTdh9dNP+92L uyt9z77FPiqw0WNYm2n2BtbmnurjT7o9pagTOR6yCvtEuNUx8C51g43bWc8Oe0dObMdkJTwTNkZh PyLWsAJ/et99990ZLtAKgBlsCx7v1XB58sknr7nmmugmIuwABxTOVgsuvOonqZZ4gN4k4UM3z/zT 799ZtqQ51l4RjmUAOVSRigegqsGWIO8BTEaJLmmMSLJRjfrYDpZJQw16V9HvdrUcHKOCD4KsCHCY 5G1ZbcKYrK5a7UmtIROD7Y1psgxe8AKU5rjerBe4bGrVW8arrR2ydQyqgDyjqa3tjAakx3wH8xry SDvNwF/5/MPFrkUGz3e0xKcfmjh4mtbYmGbxRE+X+GCZki9FbW0GSNJ91E0kit0pJtq+nfUQVxQu 8JKwRMQuhA3YJkIL4lvtgDD2gMl++OGHB0I74EXkQPWLwVBgLplMJmJIK5VKhFVwTqSosC1A/kqA Zmque4p0XMQczrXeTZtPPXhmk6eaepoXrAmZLXPmsVhQLazrbv3ad+Zc+lsknEhhVLf04M8vb08G pvT8wLLVpK76xc2rty5/O6N5BuoC0A9IHcn1ZG7q9HY0gQhWRo2Oghh1doBfhixR3AE/SLRtWGkj n4jqAkSiSir3oNMObQ/CMHNVTzPigeJlFAdO2U8k3umyXl/lbtiiLH+/vHK1ADVIsiZ2G54NKerQ dFHtQj1021IioqxcuTJaj6xkhwXbH330UUCy+vbzzz//4osvBlIAkQoG4cYbb6z/qW6UdZcIjzxz 5kyU16AuI6x0+YjyjJ9+xunPPvJoFnWYAKVKeXIzP+OkJtfOeT2lscd89ZjrnvQks9FfoCmGhwoz ckFwXgbqAzT9I8i998Bti3/7i7Y4GhDQpqHagTZiUmXC1IRQ4HeIXkG3GjVEoREIoAktOCCow177 6AnBMAUijoInNutIVtFT4NpqApexHbB4fialVCt9+U1+6sEl+r2LenttaidFGtbfUQNelmrtdbEO nhfdbb3nvffeQ9iArDHksURmCFVFJFKE2feMC+vZK8HnfrwX6eyuu+5asGCBg9ovknwfHWM6fN3d /3bPd769AGVGjSlVXIqJi6am5s1q7c11qV6p4mS/8/RaxlO4gSoGuIJ+DrR84MZQmoPrY+iYEl1v 3vnd+RmlZKGsoXBHGplGnkqDHi0rHNU2dG7gQmCqHfTdEIEJSyIvS2U3PA1WoEEk26iwGS4VSVFj 9aQjuOchkpXjQamMaxWsjj8tk0+v2KQoTeSlyW6gmGpYZajVTfu7RAeroN2qB0wR3BfC+86mE215 4YUXIpZ6v5aoIATQ8sorr4Derh/712eeOeecb/V09/T3iNGsrF/NbxqnWbbmgKdcv6Y8/Rs/+NKl NyHFpmaz/gkDEcePb5TVVj1z5+M3/ag9IQ3pUREUNuamBNqq0UtFHVGWRCeQgokj0Ca0r1OhFW3y YUEP56BWQ7UY6BW063Cpc4E+RSpKU+sPlYKAN6pcV/qsUfcuLT+zYiPjiHugjKAbKnyE56g/ECh0 3ONgvdyeitbTp09HugvcjJrCQEYPtwC68xe/+EVEFuzXUudukaldfullM2bOqLru66+/dt11/6d7 61aiOjCqkUVLFRbw+79tT26WOQ3NNiVDptcV5ZTj5h987MnZtjEoJWH8U3CFQUNhQm54/9XXHrpH K3VlkZgi+aSeNNghXJbLVJe601CLkEZoRqH5hX+l6BwW2cLm26jPEBaEPyFOGqizRlP4EaE0VuKi hDvsMttuXbT57S0guUP5R1oJvzG2+gn/qEvsM7OeutCBlevOLdqIxwDaxgoqDhGdt+8Ljo3AXkR7 t7a2wllFZ7NUtNVIZhmq7XgBnzxaufFL6dQGc2tS2mYhBipfFD1cT0tyoxFhwlKQ4viOqrhaTPVB 9FQ15sdVtHNgRJOQMewD1ZMK2jYdKIZLdIaaauDBmKgHETMLSC31MR92LUjM/DJRoGZalfw5tgBN SLRjQ1ueGbhcMzay5hueXr2aGIVIKaSc2hQT8NaRTrazpH0Xz4577rYNMUJx2B35HVijHZZIxDCp vULDHS6I0UeSC102QFKpXI6qHXA0VMDEwIVZcBPczdwpqUOTLvcMYTLHLVgq8lRmIV5wjeYOeI4m weej3uMrvp3Ah8uYTsM/RCLRKKKCBbXUUhMHSqNgFKi8GfXcADsQwUCSDGNjBN5gjGFPPOKNROGW urDJ0+G+0HmCmamSW6tyyqKPAQvgvgwUW8Nz4BqYCUTqrdlLZDyDXnarnj3LvU597u8NRBqlZfv7 h0+oEbbkX1AIFd8Ynx6ZopmFQeAkwcVxboOhpuY3TP2BP0OER20aokShE3CZOtSonR1yrk0oDZEY NRBCC4C8YeCGUqhmjvYb2nFgX1RtKhXabRBLaGTi7CgQoaSAO9AxprioAGmLVPq1TnfJRqQ5uKhH o6HmxFCKGzAxdSh0A9nuN+e2v/r4NPsHTloLWhujgEfN52HvX1hLpr4NiL023CF9GAT1SpMxh/Im kWMc1z7hBsqAqameWgFqT0wH7HLaHTWbUgsp4TuGVkgXGB1pEGVCMClNL0tjyXJyxeGJqLf3M10+ l+phTmNcTxqqcF2yFgx/ShbDcBItxDhEGqhJPPRRtclq0Xr9U1ujM0TaCw/ejVAx0xRXJI9I14Ql oU0XU1DRJEzsMo8n31tXWVFEuAV2qKGG/4LqYe1JNaa6od9AdzqaLWha2mcqCDo58jD0g8LOwuhI U63IdNBaj0urwkxWldSTb28Jx0RUZaZb+kxv6/NoPYiHk9tT8cCl8Rm2n5GtgEUboilnu1dzNIuH SGFUMAAQwDPZmM5jWGVulszWB1/bsryMGIM/omJO0/2HYg7Pnkbd51E9lspGpDCp2oagPLAzJLLI i4Vpyf43GO+32RHAI0LB9QMtnoIz09PNS9fbr3ycD0+F8QP/9v/i5TufR/XENK0xoWnCQcZBegnn 54KWq01Tp7ewRO2A+/DZjesByhrwGZhAApeHs+AolGmaZRVtv3lEx5othftfWdtFExl1pmtoBKYe s5qqPkN88HlUT3NSbUxgZrTqCY8SFHr/HmgwmuVObTlIt8IZBXv9EK+w42Q6aubEpDbCz9SESA6M 3jyBJQSJ4QxTmiCEpnaUbm0/iDV3vPJ+5x1PdXZiAiQQgRrH/Iloqnyolv4JJfttoft0wGeo+X24 PooUrop32eAfglOwFhwkTplk/Y8jUlUPbZmUH9IMjoi/IcQcvVxg7wuxcEBp1Ly5484wPw0MOSZU QTFq2N4JIhA6ozQV/W0o2pTjeM9OLF7Umx/+yPvTErSbQyMRP0K4IZLaPt3H3u90T3sMr3ow4Zfm tuE5Q+4QFRZ6v9cPDmv8b1PNzlzJMjC/wKf5GSGpFQIq6h/Z90f2qId6Z0GG7dUhpRBOHg1nFRGY Vgi7SdVMpnwttryr+tLyvufWlqm3g6ZoDZbf3Pfbru+5H4/6Kc6+50MigVMUpv2QSSgWCDHGrjmx fXqjV3YEKnSkHnRab+MYIvZx7wsN7ZChJG3Wx3nt0MAHhw1DpDwWhTcYKOgZaujWrVhFUzeUtcff Lby+BjVYcmJgb3CCWqPt3q88lHvs06MO5QUHnAtPDgGGAAhvhkJRi2azYWbUP51/gOl2YtYvKmIh /4XcEEA2OpLKnbu5n+3MJFKjRTMUIo9U90Y0KnSwAGin51rALa6iO8A0Y0m7ai9b37ukq7hso7MW 0+dIL8hv/BhoHsyG+IyksMfTDqd6UEvB5UOPjrFrYaaHIpzpTea1Z01XeteB90eiDhqSwvu2F+aC AcP+FMe38fgDifxI2VFdAKQYAj0B8tCWAAKiCEYgA3K3XKb1VN28p27I2R+u71m9tbwRE7BCeYVn xz7Ru1eiK/6Xc241QYbCQzEGz+8fPSZz5swDZK4rbBbpb9uKvFOIssMpCdgzfBsBRaSQ8yfJh6/t ILlGTg1/V3y814o8WFgbQPSXCtJMcPA9Za/L0fpcpTufhwvDZJV+Ugi0JyIizu/0GyPOhgkNOM8+ Nd8MrY0Np/VQGQE1mfBdkf20vEhREIBDq72FY9foaHtfVauGRd6r7uFCnUQGSm/co76J6N0U9IGJ bHvlAM2BDKdqI/5jwjFKqVToxFyV/rYBGhAYDUMzZWe/9De86kG8wTsd0BZDEYjIf4A3VEprXPIu 4Wu9PNnvgequaNtK/cC6A4xkQtojo8MXiG56HxL4NUzLA69G7zUIVenR/AjaGcU6HIHEK+oerpdB 90u8g915eNWDwU2tLQNielQfhsevF6IG2g+Jr//NuRHii+4/Guh1UBdtDDtwavXQunpCpaKQjf7m mm2EnEQIOcLXwVANIzST8AbIc9Yx4GBl/cXxX0jgCwl8IYEvJBBJ4P8CkLsiseCTLsQAAAAASUVO RK5CYII= ------_=_NextPart_001_01CBC3FA.E141E772-- From rkoodli@cisco.com Thu Feb 3 15:38:26 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 895AB3A6B38 for ; Thu, 3 Feb 2011 15:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.205 X-Spam-Level: X-Spam-Status: No, score=-110.205 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJ0cOUib52ud for ; Thu, 3 Feb 2011 15:38:25 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id A3DFE3A6B36 for ; Thu, 3 Feb 2011 15:38:25 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABbMSk2tJXHA/2dsb2JhbAClNnOiApsAhVgEhHmGbIMzgwE Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rtp-iport-2.cisco.com with ESMTP; 03 Feb 2011 23:41:48 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p13Nfmmi006978; Thu, 3 Feb 2011 23:41:48 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Feb 2011 17:41:48 -0600 Received: from 10.21.83.244 ([10.21.83.244]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 Feb 2011 23:41:47 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 03 Feb 2011 16:00:16 -0800 From: Rajeev Koodli To: Julien Laganier Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvD/oDJOSCpTooPRUendFN68yt4aQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Feb 2011 23:41:48.0552 (UTC) FILETIME=[ECB28080:01CBC3FB] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 03 Feb 2011 23:38:26 -0000 Hi, On 2/3/11 3:27 PM, "Julien Laganier" wrote: >> What this does not provide me is the flexibility, for instance, of providing >> a prefix *when* I want to provide it, and assigning a prefix based on what >> the physical interface the MN is attached to (so that I could route traffic >> differently at the LMA if I so choose). I also would like to be able to >> offer a prefix and revoke it based on TOD triggers. I do not *have* to >> pre-assign my prefixes in anticipation of *potential* flow mobility. > > It does provide you with this flexibility. Whenever you want to offer > a new prefix (set) over a physical interface (set) you simply > bootstrap a new PMIPv6 session for that new prefix (set) over the > physical interface (set.) If you want to revoke it because it's COB > you can certainly tear down that session. > If it does, we are probably talking about the same thing, which is good :-) Help me understand then with this scenario: The MN attaches on if0, gets prefix p0. The MN attaches on if1, the LMA assigns the p1. At some point later, the LMA chooses to move some flows from if0 to if1. How do I do this without being forced to allocate both p0 and p1 on if1 at the time of attach (on if1)? Thanks, -Rajeev > All in all, a very simple model that allows all scenarios to be covered. > > I would suggest that we concentrate on devising the simplest > addressing model and signaling framework, and move the scenarios in an > annex. > > --julien From rkoodli@cisco.com Thu Feb 3 15:40:32 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DAF73A6B3E for ; Thu, 3 Feb 2011 15:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.529 X-Spam-Level: X-Spam-Status: No, score=-109.529 tagged_above=-999 required=5 tests=[AWL=-0.327, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuphBhvcDc3C for ; Thu, 3 Feb 2011 15:40:17 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id A87313A6B38 for ; Thu, 3 Feb 2011 15:40:16 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkICABbMSk2tJV2b/2dsb2JhbACCRZQMQIYJAYczaHOiApsAgnsBglwEhHmGbIMzgwGFcg Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-2.cisco.com with ESMTP; 03 Feb 2011 23:43:38 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p13NhcI2020325; Thu, 3 Feb 2011 23:43:38 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Feb 2011 17:43:38 -0600 Received: from 10.21.83.244 ([10.21.83.244]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 Feb 2011 23:43:38 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 03 Feb 2011 16:02:05 -0800 From: Rajeev Koodli To: "Giaretta, Gerardo" , Sri Gundavelli , stefano faccin Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLwmpURzmRlysrlUidlexdQorGZJPuBh2AgAAR4ICAAAzJgIAACkaAgADJ5gCAAKKGAP//oT5wgAEoMGn///x5AIAAF08J In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3379593725_54164582" X-OriginalArrivalTime: 03 Feb 2011 23:43:38.0270 (UTC) FILETIME=[2E1823E0:01CBC3FC] Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 03 Feb 2011 23:40:32 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3379593725_54164582 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi, I am asking if you could show how the propagation of SSID/ULI from the MN i= s considered reliable enough for the network to act on. That would help us understand what we need to do here to address your =B3flag=B2. Thanks, -Rajeev On 2/3/11 2:43 PM, "Giaretta, Gerardo" wrote: > Hi Rajeev, > =20 > Not sure I understand what you are asking me. My comment was mainly refer= red > to synchronization of policies which is an assumption not correct in my > opinion.=20 > =20 > Based on the current policy model adopted by 3GPP, the only way I can thi= nk of > to make the system working is to replicate the behavior of RFC 6089 where= the > MN initiates the flow movement. > =20 > The assumption on synchronization of policies may however be considered > acceptable in other SDOs or even in 3GPP in future. I am just raising an > applicability flag to the group (actually the flag was initially raised b= y > Stefano J) > =20 > Gerardo > =20 >=20 > From: Rajeev Koodli [mailto:rkoodli@cisco.com] > Sent: Thursday, February 03, 2011 2:51 PM > To: Giaretta, Gerardo; Sri Gundavelli; stefano faccin > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > Subject: Re: [netext] Consensus call to adopt I-D: > draft-bernardos-netext-pmipv6-flowmob as WG doc > =20 >=20 > Hi Gerardo, >=20 > Okay, so let=B9s agree that the current version of the draft does not have > SSID/ULI propagation to the LMA. >=20 > Do you care to suggest how the network deems such an information from the= MN > trustworthy? >=20 > I am sure you agree if we could have good input, we could design protocol= s > accordingly. > You will also probably agree that=B9s much better than just arguing about =B3= it > does not work in today=B9s 3GPP deployment=B2. >=20 > Regards, >=20 > -Rajeev >=20 >=20 > On 2/2/11 9:13 PM, "Giaretta, Gerardo" wrote: > Hi Sri, > =20 > There is no implicit assumption of synchronized policies. A basic example= that > shows that there is no assumption is the following: ANDSF policies may be > based also on location of the UE. For example the UE should prefer WLAN o= nly > in a given location. When the UE is attached over WLAN there is no way fo= r the > PDNGW/HA to verify the location of the UE and therefore to verify UE acti= ons > based on policies. > =20 > The assumption on synchronization of policies is only applicable to this = draft > and I think it is a wrong one. > =20 > Cheers > Gerardo > =20 >=20 > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of > Sri Gundavelli > Sent: Wednesday, February 02, 2011 6:50 PM > To: stefano faccin > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > Subject: Re: [netext] Consensus call to adopt I-D: > draft-bernardos-netext-pmipv6-flowmob as WG doc >=20 > Hi Stefano, >=20 > One comment. >=20 > Agree with you there is no ANDSF interface to the network node, but the > assumption of synchronized policies between the ANDSF server and the PDN = GW/HA > is there, implicitly IMO. With out this assumption, I do not know, how th= e HA > can ever validate the flow mobility options received in the BU. If the > operator requires any control on enforcing a flow policy rule, the PDN GW= /HA > needs to have synchronized policies, without which its always the client > decision. I=B9m not sure, operators in 3GPP would like that :) >=20 > No doubt, the lack of MN-AR interface is surely an issue for supporting > complex flow policies. I realize the issues and I agree with you. But, th= e > assumption of synchronized policies can offer some solution with some > configuration requirement on the HA (assuming there are no other issues). > There are also the proposals on flow mirroring on the UE ..., requiring n= o > flow policies. I=B9ve not evaluated this, however. Folks can comment on thi= s. >=20 > It is also to be noted, for some of the scenarios such, there is no flow > policy interface needed. We can identify what scenarios create any > configuration limitations on the HA and which one=B9s do not . As I=B9ve note= d > earlier, this is surely an open issue, that we need to discuss in the WG. >=20 >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 > =20 >=20 >=20 > On 2/2/11 9:08 AM, "stefano faccin" wrote: > Sri, > thanks for the reply. Can you clarify in which system or scenario ANDSF i= s > available to network entities as well? There is no such availability in 3= GPP, > and making such information available would require considerable architec= tural > changes, therefore the applicability of this solution to what seems to be= the > only realistic scenario hinges on 3GPP making considerable architectural > changes. I would therefore not be so hastily concluding that the ANDSF > information is available to the LMA and underestimate what it would reall= y > take to make the solution applicable. >=20 > If we cannot guarantee that there is at least one realistic solution to h= ave > the MNa nd LMA in synch, how do we expect that this solution is applicabl= e at > all? In 3GPP there is no need to have such implicit assumption, be cause = 1) > the MN is provided policies explicitly through the ANDSF, and 2) it is th= e MN > and only the MN that makes IP flow mobility decisions and communicates th= em > explicitly (with well defined signalling) to the LMA, and therefore no ma= gic > is needed. There is no need in 3GPP to have the ANDSF and PDN GW policies > synchronized, since the PDN GW does not use such policies. >=20 > Sri, in the end it is a matter of whether we develop a solution that will= rely > on some unknown magic to be deployed, or a solution that we know can be > deployed in at least one way because there are solutions to what I consid= er > major open issues. >=20 > Cheers, > Stefano >=20 > On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli wrote= : > Hi Stefano, >=20 > Thanks for the discussion. >=20 > As you say, the ANDSF policies are allowing the MN a.) to make the right > network attachment decision and b.) make the access selection on a flow b= asis. > This same policy that is present in the ANDSF server, is available for th= e > network nodes as well. I=B9m not sure, with out this assumption the solutio= n can > work for all currently listed cases. We clearly need the MN and the LMA t= o be > in synch with respect to the configured policy. How, that is done, I gues= s we > will not try to know. I thought even in 3GPP, this is the implied assump= tion > ? But, this is for you to clarify. Not specifically for IFOM where UE and= PDN > GW/HA are negotiating the flow policies, but generally that the PDN GW an= d the > ANDSF policy server will have synchronized policies. The MAG and the LMA = have > the ability to carry this flow policy information in signaling messages a= nd > influence the access selection. The policy is a opaque object, with exten= sible > formats, when carried in the signaling plane, should allow the LMA/MAG to > apply those access policies, while assuming MN is following the same rule= s. > These policies can surely reflect the specific WLAN access/operator speci= fic > rule. I=B9m surely with you, the lack of MN-AR interface is surely an issue= and > I see that. But, we need to understand, what are the limitations with the > approach of out of band policy interfaces and what will be the solution > limitations. If we need to tie the flow movement at the prefix granularit= y and > rely on the natural ND interface in the form of RA PIO option, more like = PDN > offload in MAPCON, or at the granularity of a flow level, is open for > discussion. I want to simplify this draft for sure, we can surely discuss= each > of these issues on the WG draft. >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 >=20 >=20 > On 2/1/11 8:29 PM, "stefano faccin" > wrote: > Sri, > thanks for the reply. >=20 > I'd like to comment on the "the flow policy decisions need not be based o= n the > specific WLAN network". Does it mean, as I believe it does, that the curr= ent > solution would not allow an operator deploying such solution to decide to > route flows over a specific WLAN or not depending on which specific WLAN = the > MN is connected to? E.g. the operator or the entity in control of the > decisions for the routing may want to direct certain traffic always over = WLANs > that the operator deploys, and instead route only some of the traffic ove= r > WLANs of roaming partners or of the MN user home. How does this solution > support that scenario if the LMA is not told specifically which WLAN the = MN is > connected to? From a deployment point of view, I do not believe we can af= ford > to leave out this scenario. Please note that the establishment of a secur= ity > relationship between the MN and the MAG, and a specific MAG identity, can= not > guarantee that the LMA knows which specific WLAN access network the MN is > connected to. Assuming that would severely restrict the deployment scenar= ios. >=20 > As for the MN and the LMA being magically in synch, I am very concerned a= bout > a "glass ball" solution. You mention ANDSF defined by 3GPP as a solution = for > this "out of band" delivery of policy. Fair enough, however there is an i= ssue > with that. ANDSF is designed specific to be a MN-centric solution where > policies are provisioned in the MN and the MN decides which network > technologies and access networks it needs to connect to, under what > conditions, and which IP traffic needs to be routed on such accesses. No = IP > point of attachment in the network (i.e. the PDN GW in 3GPP that is the L= MA in > PMIPv6) is aware under any conditions of such policy. Therefore, even if = in > order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would > unfortunately not provide a solution unless the MN can communicate to the= MAG > and the LMA the decisions the MN has taken based on the ANDSF policies. >=20 > I believe the key point here is that we need to understand how the soluti= on > can be realistically applied to a real scenario, and that we need to ensu= re > that important and realistic deployment scenarios are not excluded by the > solution. >=20 > Cheers, > Stefano >=20 > On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli > wrote: > Hi Stefano: >=20 > These are valid points and some good comments. Let me share my thoughts. >=20 > Carlo=B9s draft is not assuming any new MN-AR interface. Its going with the > assumption there is established policy on the mobile and on the LMA, whic= h > allows the mobile to select the access network at a flow level granularit= y, > without requiring any explicit signaling between the MAG and the MN. To l= arge > part this is all about out of band policy interface, such as ANDSF, towar= ds > the UE, leading to the assumption that magically the MN and the LMA are i= n > sync with respect to flow policies, access selection and they will make t= he > right forwarding decision. Secondly, the flow policy decisions need not b= e > based on the specific WLAN network, but it is implicitly driven by the MA= G =AD > LMA security relation, where the MAG attachment to the WLAN network > transitively allows the LMA to make the flow policy decisions based on th= e MAG > identity. If the WLAN network is not trusted, there is truly no MAG in th= at > network, where the LMA shares a security relation with that node. >=20 > There are still some open issues on this draft that needs to be discussed= in > the WG. On the approaches to allow more a flow aggregate movement, that = is a > discussion point. There are issues that we need to discuss, supporting sp= lit > link model, or eliminating some favorite brand of signaling message (FMA)= and > riding on PBU/PBA and just with one FMI trigger, and on the aspects aroun= d MN > applying the flow policies by flow mirroring. We have no agreement on tho= se > issues yet. >=20 > Its just a base draft, for further discussion and resolving those issues.= But, > hope that is not a stopper for base draft selection. >=20 >=20 > Sri >=20 >=20 >=20 >=20 >=20 >=20 > On 2/1/11 6:39 PM, "stefano faccin" > wrote: > Raj, > thanks for the email. >=20 > I need to apologize in advance if my questions have already been answered > before (though I cannot find a conclusive answer anywhere). >=20 > I think that a protocol that is developed in NETEXT (or other groups) sho= uld > have at least a potential realistic scenario for applicability. >=20 > In terms of applicability, though it is not part of the protocol definiti= on > per se, unless there are solutions in place for either the host to indica= te to > the network where the flows should be routed or for the LMA to receive so= mehow > from somewhere some policies, the solution cannot really provide flow mob= ility > since there is no way to decide which flows are routed where. If we are > thinking about a host-based solution, I have not yet seen a solution as t= o how > the host can indicate to the MAG and ultimately to the MAG which flows sh= ould > be routed on each access. If we are relying on modifications of layer 2 > protocols, aren't we defining a solution that works only with some > technologies (since for other access technologies it is rather unrealisti= c to > modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-ba= sed > solution, can we hear of at least one example of a real-life scenario whe= re > the LMA would receive such policies, and how such delivery would happen? = Also, > should there be a solution to have policies in the LMA, how does the LMA > actually decide to route flows on one access or the other? E.g., if some = flows > need to be routed on certain WLAN networks, but shall not be routed on ot= her > WLAN networks, how does the LMA know which specific WLAN network the host= is > connected to? Perhaps I missed the ability for the MAG to know e.g. the W= LAN > SSID and provide it to the LMA, in which case I would appreciate if someb= ody > could highlight to me where that is defined. >=20 > I think that, though not integral to the protocol specification, understa= nding > what framework the protocol would/needs to fit in is rather important. >=20 > Cheers, > Stefano >=20 >=20 > On Tue, Feb 1, 2011 at 3:47 PM, > > wrote: >=20 > Hello, >=20 > We have discussed the flow mobility solutions for Proxy MIP6 previously a= t > IETFs 78 and 79. > This is a consensus call for adopting this I-D: > draft-bernardos-netext-pmipv6-flowmob-02 > as the working group document. > I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt >=20 > The consensus call will expire on Feb 15th, 2011. Please indicate your > support or concerns in adopting this I-D as the WG baseline document on > the mailing list. >=20 > Please note that this I-D will serve as the baseline in the WG and will b= e > developed further based on input and feedback from WG members. >=20 > -Basavaraj >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext >=20 > =20 > =20 >=20 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext >=20 --B_3379593725_54164582 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmi= pv6-flowmob as WG doc
Hi,

I am asking if you could show how the propagation of SSID/ULI from the MN i= s considered reliable enough for the network to act on. That would help us u= nderstand what we need to do here to address your “flag”.

Thanks,

-Rajeev



On 2/3/11 2:43 PM, "Giaretta, Gerardo" <gerardog@qualcomm.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Hi Rajeev,
 
Not sure I understand what you are asking me. My comment was mainly referre= d to synchronization of policies which is an assumption not correct in my op= inion.
 
Based on the current policy model adopted by 3GPP, the only way I can think= of to make the system working is to replicate the behavior of RFC 6089 wher= e the MN initiates the flow movement.
 
The assumption on synchronization of policies may however be considered acc= eptable in other SDOs or even in 3GPP in future. I am just raising an applic= ability flag to the group (actually the flag was initially raised by Stefano= J= )
 
Gerardo
 

From: Rajeev Koodli [mailto:rkoodli@cisco.com]
Sent: Thursday, February 03, 2011 2:51 PM
To: Giaretta, Gerardo; Sri Gundavelli; stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-n= etext-pmipv6-flowmob as WG doc

Hi Gerardo,

Okay, so let’s agree that the current version of the draft does not h= ave SSID/ULI propagation to the LMA.

Do you care to suggest how the network deems such an information from the M= N trustworthy?

I am sure you agree if we could have good input, we could design protocols = accordingly.
You will also probably agree that’s much better than just arguing abo= ut “it does not work in today’s 3GPP deployment”.

Regards,

-Rajeev


On 2/2/11 9:13 PM, "Giaretta, Gerardo" <gerardog@qualcomm.com> wrote:
Hi Sri,
 
There is no implicit assumption of synchronized policies. A basic example t= hat shows that there is no assumption is the following: ANDSF policies may b= e based also on location of the UE. For example the UE should prefer WLAN on= ly in a given location. When the UE is attached over WLAN there is no way fo= r the PDNGW/HA to verify the location of the UE and therefore to verify UE a= ctions based on policies.
 
The assumption on synchronization of policies is only applicable to this dr= aft and I think it is a wrong one.
 
Cheers
Gerardo
 

From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Sri= Gundavelli
Sent: Wednesday, February 02, 2011 6:50 PM
To: stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-n= etext-pmipv6-flowmob as WG doc

Hi Stefano,

One comment.

Agree with you there is no ANDSF interface to the network node, but the ass= umption of synchronized policies between the ANDSF server and the PDN GW/HA = is there, implicitly IMO. With out this assumption, I do not know, how the H= A can ever validate the flow mobility options received in the BU. If the ope= rator requires any control on enforcing a flow policy rule, the PDN GW/HA ne= eds to have synchronized policies, without which its always the client decis= ion. I’m not sure, operators in 3GPP would like that :)

No doubt, the lack of MN-AR interface is surely an issue for supporting com= plex flow policies. I realize the issues and I agree with you. But, the assu= mption of synchronized policies can offer some solution with some configurat= ion requirement on the HA (assuming there are no other issues). There are al= so the proposals on flow mirroring on the UE ..., requiring no flow policies= . I’ve not evaluated this, however. Folks can comment on this.

It is also to be noted, for some of the scenarios such, there is no flow po= licy interface needed. We can identify what scenarios create any configurati= on limitations on the HA and which one’s do not . As I’ve noted = earlier, this is surely an open issue, that we need to discuss in the WG.


Regards
Sri




 


On 2/2/11 9:08 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:
Sri,
thanks for the reply. Can you clarify in which system or scenario ANDSF is = available to network entities as well? There is no such availability in 3GPP= , and making such information available would require considerable architect= ural changes, therefore the applicability of this solution to what seems to = be the only realistic scenario hinges on 3GPP making considerable architectu= ral changes. I would therefore not be so hastily concluding that the ANDSF i= nformation is available to the LMA and underestimate what it would really ta= ke to make the solution applicable.

If we cannot guarantee that there is at least one realistic solution to hav= e the MNa nd LMA in synch, how do we expect that this solution is applicable= at all? In 3GPP there is no need to have such implicit assumption, be cause= 1) the MN is provided policies explicitly through the ANDSF, and 2) it is t= he MN and only the MN that makes IP flow mobility decisions and communicates= them explicitly (with well defined signalling) to the LMA, and therefore no= magic is needed. There is no need in 3GPP to have the ANDSF and PDN GW poli= cies synchronized, since the PDN GW does not use such policies.

Sri, in the end it is a matter of whether we develop a solution that will r= ely on some unknown magic to be deployed, or a solution that we know can be = deployed in at least one way because there are solutions to what I consider = major open issues.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli <sgundave@cisco.com> wrote:
Hi Stefano,

Thanks for the discussion.

As you say, the ANDSF policies are allowing the MN a.) to make the right ne= twork attachment decision and b.) make the access selection on a flow basis.= This same policy that is present in the ANDSF server, is available for the = network nodes as well. I’m not sure, with out this assumption the solu= tion can work for all currently listed cases. We clearly need the MN and the= LMA to be in synch with respect to the configured policy. How, that is done= , I guess we will not try to know.  I thought even in 3GPP, this is the= implied assumption ? But, this is for you to clarify. Not specifically for = IFOM where UE and PDN GW/HA are negotiating the flow policies, but generally= that the PDN GW and the ANDSF policy server will have synchronized policies= . The MAG and the LMA have the ability to carry this flow policy information= in signaling messages and influence the access selection. The policy is a o= paque object, with extensible formats, when carried in the signaling plane, = should allow the LMA/MAG to apply those access policies, while assuming MN i= s following the same rules. These policies can surely reflect the specific W= LAN access/operator specific rule. I’m surely with you, the lack of MN= -AR interface is surely an issue and I see that. But, we need to understand,= what are the limitations with the approach of  out of band policy inte= rfaces and what will be the solution limitations. If we need to tie the flow= movement at the prefix granularity and rely on the natural ND interface in = the form of RA PIO option, more like PDN offload in MAPCON, or at the granul= arity of a flow level, is open for discussion. I want to simplify this draft= for sure, we can surely discuss each of these issues on the WG draft.


Regards
Sri






On 2/1/11 8:29 PM, "stefano faccin" <sfaccinstd@gmail.com <htt= p://sfaccinstd@gmail.com> > wrote:
Sri,
thanks for the reply.

I'd like to comment on the "the flow policy decisions need not be base= d on the specific WLAN network". Does it mean, as I believe it does, th= at the current solution would not allow an operator deploying such solution = to decide to route flows over a specific WLAN or not depending on which spec= ific WLAN the MN is connected to? E.g. the operator or the entity in control= of the decisions for the routing may want to direct certain traffic always = over WLANs that the operator deploys, and instead route only some of the tra= ffic over WLANs of roaming partners or of the MN user home. How does this so= lution support that scenario if the LMA is not told specifically which WLAN = the MN is connected to? From a deployment point of view, I do not believe we= can afford to leave out this scenario. Please note that the establishment o= f a security relationship between the MN and the MAG, and a specific MAG ide= ntity, cannot guarantee that the LMA knows which specific WLAN access networ= k the MN is connected to. Assuming that would severely restrict the deployme= nt scenarios.

As for the MN and the LMA being magically in synch, I am very concerned abo= ut a "glass ball" solution. You mention ANDSF defined by 3GPP as a= solution for this "out of band" delivery of policy. Fair enough, = however there is an issue with that. ANDSF is designed specific to be a MN-c= entric solution where policies are provisioned in the MN and the MN decides = which network technologies and access networks it needs to connect to, under= what conditions, and which IP traffic needs to be routed on such accesses. = No IP point of attachment in the network (i.e. the PDN GW in 3GPP that is th= e LMA in PMIPv6) is aware under any conditions of such policy. Therefore, ev= en if in order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF = would unfortunately not provide a solution unless the MN can communicate to = the MAG and the LMA the decisions the MN has taken based on the ANDSF polici= es.

I believe the key point here is that we need to understand how the solution= can be realistically applied to a real scenario, and that we need to ensure= that important and realistic deployment scenarios are not excluded by the s= olution.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli <sgundave@cisco.com <http://s= gundave@cisco.com> > wrote:
Hi Stefano:

These are valid points and some good comments. Let me share my thoughts.
Carlo’s draft is not assuming any new MN-AR interface. Its going with= the assumption there is established policy on the mobile and on the LMA, wh= ich allows the mobile to select the access network at a flow level granulari= ty, without requiring any explicit signaling between the MAG and the MN. To = large part this is all about out of band policy interface, such as ANDSF, to= wards the UE, leading to the assumption that magically the MN and the LMA ar= e in sync with respect to flow policies, access selection and they will make= the right forwarding decision. Secondly, the flow policy decisions need not= be based on the specific WLAN network, but it is implicitly driven by the M= AG – LMA security relation, where the MAG attachment to the WLAN netwo= rk transitively allows the LMA to make the flow policy decisions based on th= e MAG identity. If the WLAN network is not trusted, there is truly no MAG in= that network, where the LMA shares a security relation with that node.

There are still some open issues on this draft that needs to be discussed i= n the WG.  On the approaches to allow more a flow aggregate movement, t= hat is a discussion point. There are issues that we need to discuss, support= ing split link model, or eliminating some favorite brand of signaling messag= e (FMA) and riding on PBU/PBA and just with one FMI trigger, and on the aspe= cts around MN applying the flow policies by flow mirroring. We have no agree= ment on those issues yet.

Its just a base draft, for further discussion and resolving those issues. B= ut, hope that is not a stopper for base draft selection.


Sri






On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <htt= p://sfaccinstd@gmail.com>  <http://sfaccinstd@gmail.com> > wrote:
Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicate= to the network where the flows should be routed or for the LMA to receive s= omehow from somewhere some policies, the solution cannot really provide flow= mobility since there is no way to decide which flows are routed where. If w= e are thinking about a host-based solution, I have not yet seen a solution a= s to how the host can indicate to the MAG and ultimately to the MAG which fl= ows should be routed on each access. If we are relying on modifications of l= ayer 2 protocols, aren't we defining a solution that works only with some te= chnologies (since for other access technologies it is rather unrealistic to = modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-based= solution, can we hear of at least one example of a real-life scenario where= the LMA would receive such policies, and how such delivery would happen? Al= so, should there be a solution to have policies in the LMA, how does the LMA= actually decide to route flows on one access or the other? E.g., if some fl= ows need to be routed on certain WLAN networks, but shall not be routed on o= ther WLAN networks, how does the LMA know which specific WLAN network the ho= st is connected to? Perhaps I missed the ability for the MAG to know e.g. th= e WLAN SSID and provide it to the LMA, in which case I would appreciate if s= omebody could highlight to me where that is defined.

I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important. <= BR>
Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM,  <Basavaraj.Patil@nokia.com <http://Basavaraj.Patil@nokia.com>  <http://Basavaraj.Patil@nokia.com> > wrote:
Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= BR> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt<= /a>

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= BR> developed further based on input and feedback from WG members.

-Basavaraj

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


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

--B_3379593725_54164582-- From julien.ietf@gmail.com Thu Feb 3 15:46:14 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9294A3A6B42 for ; Thu, 3 Feb 2011 15:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqBM9krUIyzD for ; Thu, 3 Feb 2011 15:46:13 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 5DB243A6B43 for ; Thu, 3 Feb 2011 15:46:13 -0800 (PST) Received: by fxm9 with SMTP id 9so1906363fxm.31 for ; Thu, 03 Feb 2011 15:49:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2QEqBX7FEMe0sDcpMxc59NyEf54j6zHr6t8owzHI3cI=; b=bTFlkdtV4n4+w8KMM8Se1GqMIH3kbpJ9AlgpcJcFbmlzahVcWJLUSLU1Xr8CzNsh/z p5wK73W43qEqywjAFRWwI0AdpZkYA4toJ4U8QcY4uYn18OdNXrgOvFKq6+3OvgNGOYg1 6rUe7v+zPf6mUy4o0z64jTeEHz1UpCK0QuMvY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HsoJqjYLpEqjbO4M7yrEc2bVArMcCkGeuvs34m8Jnk64+Jc/tThDH9CNWuiDqrrnR9 B6i81aQ8aCH+CW5khC/UzwMiAC7GFc+Mle4/YbKcsvVXa2QXM2sr+mjge6BfRIKJ2cYA mU3InzavK0OKpZMLy8D0aLmJuCpISfrpgFEfM= MIME-Version: 1.0 Received: by 10.103.243.16 with SMTP id v16mr6702856mur.57.1296776976080; Thu, 03 Feb 2011 15:49:36 -0800 (PST) Received: by 10.103.221.9 with HTTP; Thu, 3 Feb 2011 15:49:35 -0800 (PST) In-Reply-To: References: Date: Thu, 3 Feb 2011 15:49:35 -0800 Message-ID: From: Julien Laganier To: Rajeev Koodli Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 03 Feb 2011 23:46:14 -0000 Hi Rajeev, On Thu, Feb 3, 2011 at 4:00 PM, Rajeev Koodli wrote: > > Hi, > > On 2/3/11 3:27 PM, "Julien Laganier" wrote: > >>> What this does not provide me is the flexibility, for instance, of providing >>> a prefix *when* I want to provide it, and assigning a prefix based on what >>> the physical interface the MN is attached to (so that I could route traffic >>> differently at the LMA if I so choose). I also would like to be able to >>> offer a prefix and revoke it based on TOD triggers. I do not *have* to >>> pre-assign my prefixes in anticipation of *potential* flow mobility. >> >> It does provide you with this flexibility. Whenever you want to offer >> a new prefix (set) over a physical interface (set) you simply >> bootstrap a new PMIPv6 session for that new prefix (set) over the >> physical interface (set.) If you want to revoke it because it's COB >> you can certainly tear down that session. >> > > If it does, we are probably talking about the same thing, which is good :-) Let's see :-) I'm breaking down your scenario below in steps, and adding below each step what action would happen in my model: > Help me understand then with this scenario: The MN attaches on if0, gets > prefix p0. New PMIPv6 session S0 is created with prefix set = {p0} over interface set {if0} > The MN attaches on if1, the LMA assigns the p1. New PMIPv6 session S1 is created with prefix set = {p1} over interface set {if1} > At some point later, the LMA chooses to move some flows from if0 to if1. Interface if1 is added to existing PMIPv6 session S0 which has prefix set = {p0} now extended over interface set {if0, if1} > How do I do this without being forced to allocate both p0 and p1 on if1 at the time of attach > (on if1)? By following the steps above? :-) --julien From rkoodli@cisco.com Thu Feb 3 16:00:42 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 110AC3A6B57 for ; Thu, 3 Feb 2011 16:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.21 X-Spam-Level: X-Spam-Status: No, score=-110.21 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OT9hLDFLsHR6 for ; Thu, 3 Feb 2011 16:00:41 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2CBBD3A6B4E for ; Thu, 3 Feb 2011 16:00:41 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMfQSk2tJV2Y/2dsb2JhbAClNnOhfZsChVgEhHmGbIMzgwE Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-2.cisco.com with ESMTP; 04 Feb 2011 00:04:04 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p14044b2017305; Fri, 4 Feb 2011 00:04:04 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Feb 2011 18:04:03 -0600 Received: from 10.21.83.244 ([10.21.83.244]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Fri, 4 Feb 2011 00:04:03 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 03 Feb 2011 16:22:30 -0800 From: Rajeev Koodli To: Julien Laganier Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvEAZvpoSVPBTNISEeUb0leo80epQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Feb 2011 00:04:03.0832 (UTC) FILETIME=[08960F80:01CBC3FF] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 00:00:42 -0000 On 2/3/11 3:49 PM, "Julien Laganier" wrote: > > I'm breaking down your scenario below in steps, and adding below each > step what action would happen in my model: > >> Help me understand then with this scenario: The MN attaches on if0, gets >> prefix p0. > > New PMIPv6 session S0 is created with prefix set = {p0} over interface set > {if0} > >> The MN attaches on if1, the LMA assigns the p1. > > New PMIPv6 session S1 is created with prefix set = {p1} over interface set > {if1} > >> At some point later, the LMA chooses to move some flows from if0 to if1. > > Interface if1 is added to existing PMIPv6 session S0 which has prefix > set = {p0} now extended over interface set {if0, if1} > I would insert that the LMA also informs the MAG hosting p1 to accept p0. >> How do I do this without being forced to allocate both p0 and p1 on if1 at >> the time of attach >> (on if1)? > > By following the steps above? :-) > Cool. This is what is in the draft, but presented differently. We could always make it better. -Rajeev > --julien From julien.ietf@gmail.com Thu Feb 3 16:02:27 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CECA3A68A4 for ; Thu, 3 Feb 2011 16:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8QJzeSs6oz3 for ; Thu, 3 Feb 2011 16:02:26 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id E10893A6983 for ; Thu, 3 Feb 2011 16:02:25 -0800 (PST) Received: by fxm9 with SMTP id 9so1919821fxm.31 for ; Thu, 03 Feb 2011 16:05:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CtczNEi4T5GeZCVeHeGJSXvYe2SaRQxTurPyypnZ9dM=; b=E9BkrrHdEA6oP3cqYSroMp4goezrAscF4my1o0Nk0EH1XdGwLo6XCwgoq41B8RM3G+ 1zRuvKQsBz59r54m66wieb2iLcXuG2ixut5fQ147o8UW/flSam9zyU6l7O/vTG55lYZS MCx5zA03DD+Gt2F3X9yIpdprYfevLv7sUA9tI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pCVhem5E5Q9uw8E7RB21DyodbuiG8F1aiswMJ6+wVJsfEnlq3pq9YIA6NZp3XCULzS cT1MAUo+M0hdje67JIAW95PliyTGv28oy7pUNyKLavKYrxukwguotL2YNfO0u0nR7edq FxqdlLySXZovNwtET5UHnwTbqqnK+CQIHwfrU= MIME-Version: 1.0 Received: by 10.103.124.3 with SMTP id b3mr5894635mun.3.1296777948305; Thu, 03 Feb 2011 16:05:48 -0800 (PST) Received: by 10.103.221.9 with HTTP; Thu, 3 Feb 2011 16:05:48 -0800 (PST) In-Reply-To: <1296774555.4238.46.camel@acorde.it.uc3m.es> References: <1296689037.3593.20.camel@acorde.it.uc3m.es> <1296774555.4238.46.camel@acorde.it.uc3m.es> Date: Thu, 3 Feb 2011 16:05:48 -0800 Message-ID: From: Julien Laganier To: cjbc@it.uc3m.es Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 00:02:27 -0000 Hi Carlos, Please see inline (I'm cutting thru the past messages for brevity) 2011/2/3 Carlos Jes=FAs Bernardos Cano : > > On Thu, 2011-02-03 at 10:52 -0800, Julien Laganier wrote: >> >> [...] >> Adopting a solution draft before we have decided what scenarios we >> want to support with solution sounds a bit like putting the cart >> before the horse. >> >> In the addressing model I outlined: at PMIPv6 session creation a set >> of prefixes is assigned the mobile node's session. Then physical >> interfaces can attach to / detach from this session. A single mobile >> node can also have multiple sessions (say 2) in parallel, associated >> with distinct set of prefixes, which results in the ability for the >> prefixes set to move across interfaces fully or partially as the >> interfaces are attached to / detached from the session. So all >> scenarios are supported in this simple addressing model which also has >> a minimal deviation from the basic 5213 model. >> >> If you think this model places unreasonable limitations on what >> scenarios can be supported, please explain how and why. >> >> From my perspective the way forward is to revise the individual draft >> submission to document this addressing model only, after which we know >> what we are asked to adopt as a WG item. > > I fail to see here how current draft deviates from your proposal. I > think it does this. Prefix models are just a way of presenting potential > use case deployments and the solution adapts to all scenarios presented > in the draft. I am sorry if this sounds blunt but -- To me the current draft digresses on details of (non normative) scenarios and has useless signaling for traffic selectors, yet it fails to explain the basics of what is the PMIPv6 flow mobility session made of and how it is maintained... I am proposing to make this crystal clear: A PMIPv6 session has a prefix set, and member physical interfaces set that can be attached/detached. If we agree on this, let's write it upfront in the spec and then defining the protocol is probably simple. As to scenarios, they should to annex, they are not normative. What' s normative is how do I create and tear down a PMI{Pv6 session. What is the addressing model for a session. How do I attach/detach interfaces from sessions. This is it. And it's not done IMHO. [...] >> As you rightfully note, "the traffic selectors are not needed from the >> mobility perspective." Thus, since PMIPv6 is not a policy exchange >> protocol (or did it stand for Policy and Mobility for IPv6 ;-) they >> are undesirable, should not be allowed optionally, and should be >> getting rid of entirely :-) > > You are right in that TS are not required from the mobility perspective. > They are optional in the draft and not even considered as the default > case. They were included because some people expressed in the mailing > lists that were required for some scenarios. Therefore, I'm fine > removing them if there is consensus for doing so. This seems backward. I do not believe that we need to have consensus to remove them. What we need to have them in a working group draft is consensus that there's a valid usecase that requires them, which I haven't seen so far. --julien From julien.ietf@gmail.com Thu Feb 3 16:08:39 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41B383A6A05 for ; Thu, 3 Feb 2011 16:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WGNA57wvOTx for ; Thu, 3 Feb 2011 16:08:38 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 463003A6B3B for ; Thu, 3 Feb 2011 16:08:38 -0800 (PST) Received: by fxm9 with SMTP id 9so1924170fxm.31 for ; Thu, 03 Feb 2011 16:12:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qb5JoHGsveCVCrB8l/HowH1y4ZYogjgPokNQZ3iN7D4=; b=EtFkjpp7vyjjdWIxy9eZFIftQRLqwSIWh+5Ziy7jLW7Ar/3VY6ONUwMVL+Zx6Yappo YRTBgNlH4U8OnN/yNL+7ULUHZoh39MLBOU5be0LSv8x6+45GpRA4dCf26iX2nJJTiVRe Gkg54DK/Z2ydWbvDr8jUlR94i6lvX3fEFqe00= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=V1SeSv+q2Z/whJiuKlnMwIBH0ZVFnIYTkdnv/Y/nIPrg0hT3kzxKi+Opq0uuZHvcfV Vjuf/3rCNACa4v+KDw1d9E5Vru6VrgT/KK5THynCCbv8tVAi1yHQE2L+XiN2cJVGAqkw T0vPUSx5ce56Zf4KJObhLgT0mTpYSsjEzeflo= MIME-Version: 1.0 Received: by 10.103.12.14 with SMTP id p14mr2799228mui.39.1296778321235; Thu, 03 Feb 2011 16:12:01 -0800 (PST) Received: by 10.103.221.9 with HTTP; Thu, 3 Feb 2011 16:12:01 -0800 (PST) In-Reply-To: References: Date: Thu, 3 Feb 2011 16:12:01 -0800 Message-ID: From: Julien Laganier To: Rajeev Koodli Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 00:08:39 -0000 On Thu, Feb 3, 2011 at 4:22 PM, Rajeev Koodli wrote: > > On 2/3/11 3:49 PM, "Julien Laganier" wrote: > >> >> I'm breaking down your scenario below in steps, and adding below each >> step what action would happen in my model: >> >>> Help me understand then with this scenario: The MN attaches on if0, gets >>> prefix p0. >> >> New PMIPv6 session S0 is created with prefix set = {p0} over interface set >> {if0} >> >>> The MN attaches on if1, the LMA assigns the p1. >> >> New PMIPv6 session S1 is created with prefix set = {p1} over interface set >> {if1} >> >>> At some point later, the LMA chooses to move some flows from if0 to if1. >> >> Interface if1 is added to existing PMIPv6 session S0 which has prefix >> set = {p0} now extended over interface set {if0, if1} > > I would insert that the LMA also informs the MAG hosting p1 to accept p0. Why would the LMA need to tell the MAG? >>> How do I do this without being forced to allocate both p0 and p1 on if1 at >>> the time of attach >>> (on if1)? >> >> By following the steps above? :-) > > Cool. This is what is in the draft, but presented differently. As per my note to Carlos, the draft doesn't do a good job at explaining the session model, and contains useless stuff that should be removed before I can consider making a decision on endorsing it or not. > We could always make it better. So let's do it and adopt the better version! --julien From cjbc@it.uc3m.es Thu Feb 3 16:23:08 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14ACB3A6405 for ; Thu, 3 Feb 2011 16:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.056 X-Spam-Level: X-Spam-Status: No, score=-4.056 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdmUzhFrcyxk for ; Thu, 3 Feb 2011 16:23:06 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 20B233A6A05 for ; Thu, 3 Feb 2011 16:23:05 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.3] (213.37.82.169.static.user.ono.com [213.37.82.169]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 928B7BABE47; Fri, 4 Feb 2011 01:26:27 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Julien Laganier In-Reply-To: References: <1296689037.3593.20.camel@acorde.it.uc3m.es> <1296774555.4238.46.camel@acorde.it.uc3m.es> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-HvOIcu6nktNjQs0QK5nC" Organization: Universidad Carlos III de Madrid Date: Fri, 04 Feb 2011 01:27:25 +0100 Message-ID: <1296779245.4238.114.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17934.003 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 04 Feb 2011 00:23:08 -0000 --=-HvOIcu6nktNjQs0QK5nC Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Julien, On Thu, 2011-02-03 at 16:05 -0800, Julien Laganier wrote: > Hi Carlos, >=20 > Please see inline (I'm cutting thru the past messages for brevity) >=20 > 2011/2/3 Carlos Jes=FAs Bernardos Cano : > > > > On Thu, 2011-02-03 at 10:52 -0800, Julien Laganier wrote: > >> > >> [...] > >> Adopting a solution draft before we have decided what scenarios we > >> want to support with solution sounds a bit like putting the cart > >> before the horse. > >> > >> In the addressing model I outlined: at PMIPv6 session creation a set > >> of prefixes is assigned the mobile node's session. Then physical > >> interfaces can attach to / detach from this session. A single mobile > >> node can also have multiple sessions (say 2) in parallel, associated > >> with distinct set of prefixes, which results in the ability for the > >> prefixes set to move across interfaces fully or partially as the > >> interfaces are attached to / detached from the session. So all > >> scenarios are supported in this simple addressing model which also has > >> a minimal deviation from the basic 5213 model. > >> > >> If you think this model places unreasonable limitations on what > >> scenarios can be supported, please explain how and why. > >> > >> From my perspective the way forward is to revise the individual draft > >> submission to document this addressing model only, after which we know > >> what we are asked to adopt as a WG item. > > > > I fail to see here how current draft deviates from your proposal. I > > think it does this. Prefix models are just a way of presenting potentia= l > > use case deployments and the solution adapts to all scenarios presented > > in the draft. >=20 > I am sorry if this sounds blunt but -- To me the current draft Don't be sorry, I'm trying to understand what are the differences in what you have in mind and what it is in the draft. I think we are not as far as you may think. > digresses on details of (non normative) scenarios and has useless I thought including scenarios to explain the basic operation of the protocol is not forbidden. There are other specs that do that. Anyway, this is not a major issue, they could be moved to an annex as you mention, they are just scenarios aimed at supporting the explanation of the operation, nothing else. > signaling for traffic selectors, yet it fails to explain the basics of As I mentioned in another e-mail, I'm fine removing the signalling for TS. Let's leave them out of the discussion for the time being (default mode of operation do not include it) > what is the PMIPv6 flow mobility session made of and how it is > maintained... I am proposing to make this crystal clear: A PMIPv6 > session has a prefix set, and member physical interfaces set that can > be attached/detached. If we agree on this, let's write it upfront in In my understanding, this is exactly what the draft does with the flowmob state at the LMA. This conceptual data structure contains BID, TS pairs, associating a flow (defined by a TS; default granularity is prefix, which perfectly matches what you proposes) with a BID (i.e. a mobility session in PMIPv6). > the spec and then defining the protocol is probably simple. As to Yes, it is indeed. > scenarios, they should to annex, they are not normative. What' s > normative is how do I create and tear down a PMI{Pv6 session. What is > the addressing model for a session. How do I attach/detach interfaces > from sessions. This is it. And it's not done IMHO. >=20 > [...] >=20 > >> As you rightfully note, "the traffic selectors are not needed from the > >> mobility perspective." Thus, since PMIPv6 is not a policy exchange > >> protocol (or did it stand for Policy and Mobility for IPv6 ;-) they > >> are undesirable, should not be allowed optionally, and should be > >> getting rid of entirely :-) > > > > You are right in that TS are not required from the mobility perspective= . > > They are optional in the draft and not even considered as the default > > case. They were included because some people expressed in the mailing > > lists that were required for some scenarios. Therefore, I'm fine > > removing them if there is consensus for doing so. >=20 > This seems backward. >=20 > I do not believe that we need to have consensus to remove them. >=20 > What we need to have them in a working group draft is consensus that > there's a valid usecase that requires them, which I haven't seen so > far. >=20 You are probably right. Let me try to recap previous discussions: You and now Sri don't think there is a usecase for this. Rajeev and Telemaco think otherwise. Probably I'm missing other opinions, I just want to trigger discussion on this, though it'd probably better if we do it in a separate thread. Carlos P.S. Please, do not think I'm in favor of keeping TS in the signaling. I just want to reflect in the draft the approach which the WG has reached consensus on. > --julien --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-HvOIcu6nktNjQs0QK5nC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1LR+0ACgkQNdy6TdFwT2fLEACfaiqjIjVoumVoQA8hSN29yWmS TQoAoM9auzSf882Jtn3895d0Gg8KKiWt =TI+j -----END PGP SIGNATURE----- --=-HvOIcu6nktNjQs0QK5nC-- From trungtm2909@gmail.com Thu Feb 3 19:00:49 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B71173A6AB7 for ; Thu, 3 Feb 2011 19:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjFnNdnH3M8N for ; Thu, 3 Feb 2011 19:00:48 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id A55083A6A16 for ; Thu, 3 Feb 2011 19:00:48 -0800 (PST) Received: by qyk34 with SMTP id 34so7276221qyk.10 for ; Thu, 03 Feb 2011 19:04:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zagTtJcTm4LXehhHRy6CO6QFNCmxJI4bvVLbWWG1YmM=; b=DZqBrHg7ThrefeEfToy/ilq9BhjAqoWRjKz6LV/GviTsxTxRkuxo7h+q5TyfAZ6IPp +H+h8FWWGYeTxKf2XedFzQvd2cNqPgvoHEx71lfEoW/q+1GT4tZIPnk9hixX6ilc+6qa f5Wxq+VTRa1e1M2lCsh4y21LZ54WU5Mx8lCgE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EUak4i+qzUkz+wO112cugv/MIdm5GWwhbgwZADxOBMVJQiUAJnlrz6t5K1sJfdvBya aobltjcIUQqOty5maPSc0WJX1fPGzgwev/XkYQoRRCe7QdqCUa5h1qTCPOn18IRD/cOW EzzPF3gY9McGDWP3cMmOrRLxda5mWNGvJPJ5I= MIME-Version: 1.0 Received: by 10.224.61.16 with SMTP id r16mr10449878qah.250.1296788652021; Thu, 03 Feb 2011 19:04:12 -0800 (PST) Received: by 10.224.89.11 with HTTP; Thu, 3 Feb 2011 19:04:11 -0800 (PST) In-Reply-To: References: Date: Fri, 4 Feb 2011 12:04:11 +0900 Message-ID: From: Tran Minh Trung To: Julien Laganier Content-Type: text/plain; charset=ISO-8859-1 Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 03:00:49 -0000 Hi Julien and Raij, Sri, Carlos and all, Sorry for jumping in the middle. It is holiday time in some Asia country now ^^. Back to the discussion on use-case scenarios. I agree with Julien that we do not need to discuss about different use-cases scenarios. What we need to do is extending PMIPv6 to support flow mobility, not extending PMIPv6 to support different use-cases scenarios. Let's start from the basic scenario (new prefix(es) for a new attachment) of the PMIPv6 and then extend it to support flow mobility. The question now is that is the right model for supporting flow mobility? IMHO, the flowing model is the right one, which reflects both Julien comments and what we have in the current draft. (1) A sigle mobile node has multiple sessions (2) Each session is associated with a distinct set of prefixes. (3) Interfaces are attached to/de-attached from the session. (4) Each interface can be attached to multiple session at a time. There is one question left from the discussion between Julien and Rajeev is that: Should LMA need to tell the MAG about new prefix(es) of the session that the interface attach to?. My answer is YES!. The MAG needs to know which prefixes are newly assigned to a MN attachment to send RA. Without this step, how can the MN know the right attachment to send a packet? Happy Lunar New Year! Regards, TrungTM From trungtm2909@gmail.com Thu Feb 3 19:07:03 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E5B03A69CF for ; Thu, 3 Feb 2011 19:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWaZxHGWUsS9 for ; Thu, 3 Feb 2011 19:07:02 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 62E303A69E4 for ; Thu, 3 Feb 2011 19:07:02 -0800 (PST) Received: by qwi2 with SMTP id 2so1589786qwi.31 for ; Thu, 03 Feb 2011 19:10:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=19FD5+16gsUTiiNeTcY7ry6+WW0XJwAJlEbAVJSnIxM=; b=IAwxRVArugjuiIRQ+EsCfOAkuXMzBGX+vbsKZWnI/Ob+r+E9q3Mc0cyDXN2PryvR8U nri+S/DCmn8UjJli7X5c8LvJzMXwySY1ZlrUbvpF/2ErhCGg8w5fI+MRiskTqC4WUXfw NlGyMDpo9DAbFHQJsDr8Oi1+CriRmOz9F9RDk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=bfOV3qcMJTL0ybHIogV50sMu6DwUBdL0F2IPTLQHOLJNW7aAATTTx9nb4J/QTmjKNY /AWFGPEmxdbI5X9cAJvsZjwj8RNAsiCnMVm2hkszpjDyEPs6oTxwXvWWvYKpPXEiuz7i bqzFszta3ZIlH0OB/EIf4P+frhz+1mHf5EXPA= MIME-Version: 1.0 Received: by 10.224.20.71 with SMTP id e7mr10509072qab.150.1296789024788; Thu, 03 Feb 2011 19:10:24 -0800 (PST) Received: by 10.224.89.11 with HTTP; Thu, 3 Feb 2011 19:10:24 -0800 (PST) In-Reply-To: References: Date: Fri, 4 Feb 2011 12:10:24 +0900 Message-ID: From: Tran Minh Trung To: Julien Laganier Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 03:07:03 -0000 Hi Julien, Rajeev, Sri, Carlos and all, Sorry for jumping in the middle. It is holiday time in some Asia country now ^^. Back to the discussion on use-case scenarios. I agree with Julien that we do not need to discuss about different use-cases scenarios. What we need to do is extending PMIPv6 to support flow mobility, not extending PMIPv6 to support different use-cases scenarios. Let's start from the basic scenario (new prefix(es) for a new attachment) of the PMIPv6 and then extend it to support flow mobility. The question now is that what the right model for supporting flow mobility = is. IMHO, the flowing model is the right one. It reflects both Julien comments and what we have in the current draft. (1) A sigle mobile node has multiple sessions (2) Each session is associated with a distinct set of prefixes. (3) Interfaces are attached to/de-attached from the session. (4) Each interface can be attached to multiple session at a time. There is one question left from the discussion between Julien and Rajeev is that: Should LMA need to tell the MAG about new prefix(es) of the session that the interface attach to?. My answer is YES!. The MAG needs to know which prefixes are newly assigned to a MN attachment to send RA. Without this step, how can the MN know the right attachment to send a packe= t? Happy Lunar New Year! Regards, TrungTM On Fri, Feb 4, 2011 at 9:12 AM, Julien Laganier wro= te: > On Thu, Feb 3, 2011 at 4:22 PM, Rajeev Koodli wrote: >> >> On 2/3/11 3:49 PM, "Julien Laganier" wrote: >> >>> >>> I'm breaking down your scenario below in steps, and adding below each >>> step what action would happen in my model: >>> >>>> Help me understand then with this scenario: The MN attaches on if0, ge= ts >>>> prefix p0. >>> >>> New PMIPv6 session S0 is created with prefix set =3D {p0} over interfac= e set >>> {if0} >>> >>>> The MN attaches on if1, the LMA assigns the p1. >>> >>> New PMIPv6 session S1 is created with prefix set =3D {p1} over interfac= e set >>> {if1} >>> >>>> At some point later, the LMA chooses to move some flows from if0 to if= 1. >>> >>> Interface if1 is added to existing PMIPv6 session S0 which has prefix >>> set =3D {p0} now extended over interface set {if0, if1} >> >> I would insert that the LMA also informs the MAG hosting p1 to accept p0= . > > Why would the LMA need to tell the MAG? > >>>> How do I do this without being forced to allocate both p0 and p1 on if= 1 at >>>> the time of attach >>>> (on if1)? >>> >>> By following the steps above? :-) >> >> Cool. This is what is in the draft, but presented differently. > > As per my note to Carlos, the draft doesn't do a good job at > explaining the session model, and contains useless stuff that should > be removed before I can consider making a decision on endorsing it or > not. > >> We could always make it better. > > So let's do it and adopt the better version! > > --julien > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 From sgundave@cisco.com Thu Feb 3 19:34:37 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B6223A6A3F for ; Thu, 3 Feb 2011 19:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.567 X-Spam-Level: X-Spam-Status: No, score=-9.567 tagged_above=-999 required=5 tests=[AWL=1.032, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26pGzuNfoWIS for ; Thu, 3 Feb 2011 19:34:36 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 5DF053A6A2E for ; Thu, 3 Feb 2011 19:34:36 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApABAGYDS02rR7Ht/2dsb2JhbACWU45lc6FSmwOFWASEeYof Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 04 Feb 2011 03:38:00 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p143c0rj011569; Fri, 4 Feb 2011 03:38:00 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Feb 2011 19:38:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Feb 2011 19:38:00 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvEGEFkgWFSyn++SLemOf+PEsKDMAAATvHg References: From: "Sri Gundavelli (sgundave)" To: "Tran Minh Trung" , "Julien Laganier" X-OriginalArrivalTime: 04 Feb 2011 03:38:00.0347 (UTC) FILETIME=[EBBECEB0:01CBC41C] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 03:34:37 -0000 Hi Tran, Julien's comment, as I understand, is to simplify the text, by taking the approach of building semantics around updating a mobility session. Keeping the relation between a mobility session, sub-interface set, prefix association to sub-interfaces, operations around moving the sub-interface(s) between mobility sessions, or prefix set between mobility sessions, or between sub-interfaces of a mobility session. There is no loss of functionality with respect to what is in the draft today, or with respect to what the base RFC-5213 supports. Instead of text mixing addressing models, flow policies and other things, the structure can be really improved with this approach. Off course, this does not take away any open issues on the shared prefix model, or on the policy availability requirements on the UE for supporting some cases. Now, to your question, if LMA will send the prefixes tied to an interface, yes, we are not changing the base MAG behavior on how its hosting prefixes on an access link. It will receive prefixes in the PBA and it will host the prefixes on the access link, by sending RA messages. We are not changing the IPv6 link model. Now, if end up supporting the approach where the prefix is shared across links, we need to resolve Gerardo's/Stefano's comments on policy assumptions on the MN. We need to distinguish this from other cases and have the needed text around any issues. Lets allow these discussions for some time, and summarize it carefully. Lets make sure, we are on the same page, before we write up the summary. Regards Sri =20 -----Original Message----- From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Tran Minh Trung Sent: Thursday, February 03, 2011 7:04 PM To: Julien Laganier Cc: Basavaraj.Patil@nokia.com; netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Hi Julien and Raij, Sri, Carlos and all, Sorry for jumping in the middle. It is holiday time in some Asia country now ^^. Back to the discussion on use-case scenarios. I agree with Julien that we do not need to discuss about different use-cases scenarios. What we need to do is extending PMIPv6 to support flow mobility, not extending PMIPv6 to support different use-cases scenarios. Let's start from the basic scenario (new prefix(es) for a new attachment) of the PMIPv6 and then extend it to support flow mobility. The question now is that is the right model for supporting flow mobility? IMHO, the flowing model is the right one, which reflects both Julien comments and what we have in the current draft. (1) A sigle mobile node has multiple sessions (2) Each session is associated with a distinct set of prefixes. (3) Interfaces are attached to/de-attached from the session. (4) Each interface can be attached to multiple session at a time. There is one question left from the discussion between Julien and Rajeev is that: Should LMA need to tell the MAG about new prefix(es) of the session that the interface attach to?. My answer is YES!. The MAG needs to know which prefixes are newly assigned to a MN attachment to send RA. Without this step, how can the MN know the right attachment to send a packet? Happy Lunar New Year! Regards, TrungTM _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From trungtm2909@gmail.com Thu Feb 3 19:55:00 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E4173A69FE for ; Thu, 3 Feb 2011 19:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4T0MOroE7U4V for ; Thu, 3 Feb 2011 19:54:58 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id A1BDA3A6A3F for ; Thu, 3 Feb 2011 19:54:58 -0800 (PST) Received: by qwi2 with SMTP id 2so1607197qwi.31 for ; Thu, 03 Feb 2011 19:58:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UGcVB2ZZkqUYUH64TwDPWrWjqZ5XjSil18LL84P7dWs=; b=oc9QWX7CMdBM6JbD+o7Y710OhtZyMBxU1uB+boatQ1Z0G9hEZkNdtkhal8tMYAX8qm jB688Cvk/weBUpDSJ2iGzAyem9CgtS4KLIT88mpX5LkCtDcNxLtxFjmzbGkmEFeGOW/c 5XnyiungiL1o4b/zE551FPAhx/RXaCmnWg/s8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=t7dhGy+O0Ify7Ba0UmnBkhvQvGlEuMJiuOrkkNQ9zNfuBQZ0mA67U3MH0rwrTajQJj m6iKaHEeSCj+BGhWPtAQSj9vTqukUOZ+3ElpE9xo0+WIb8yDfqywraA9yEEnjZl9aSWv tcsk9e/7EELRTOQS4SGY55TabWiPYxvtbw8Hg= MIME-Version: 1.0 Received: by 10.224.20.2 with SMTP id d2mr10408643qab.300.1296791900501; Thu, 03 Feb 2011 19:58:20 -0800 (PST) Received: by 10.224.89.11 with HTTP; Thu, 3 Feb 2011 19:58:18 -0800 (PST) In-Reply-To: References: Date: Fri, 4 Feb 2011 12:58:18 +0900 Message-ID: From: Tran Minh Trung To: Sri Gundavelli Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 03:55:00 -0000 Hi Sri and Julien, Please see my comments inline. On Fri, Feb 4, 2011 at 6:50 AM, Sri Gundavelli wrote: > Hi Julien, > > Thanks for your response, please see inline. > > > On 2/3/11 10:52 AM, "Julien Laganier" wrote: > >> Hi Sri, >> >> Please see inline: >> >> On Wed, Feb 2, 2011 at 4:13 PM, Sri Gundavelli (sgundave) >> wrote: >>> >>> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behal= f Of >>> Julien Laganier >>> Sent: Wednesday, February 02, 2011 3:45 PM >>> To: cjbc@it.uc3m.es >>> >>> Cc: netext@ietf.org; Basavaraj.Patil@nokia.com >>> Subject: Re: [netext] Consensus call to adopt I-D: >>> draft-bernardos-netext-pmipv6-flowmob as WG doc >>> >>> >>> 1. there is no need to support multiple addressing models. All scenario= s can >>> be supported by a single addressing model in which each PMIPv6 session = maps >>> to a set of prefixes that are equally accessible through the set of phy= sical >>> interfaces attached to that PMIPv6 session. This allows all scenarios, >>> including one in which two prefix sets are available through different >>> physical interfaces set. I understand that the WG has been divided on t= hat >>> question but that does not constitute a mandate to include everyone's w= ish >>> list =A0in a standard specification. Thus unless someone can come up wi= th >>> a=A0rebuttal=A0of my argument on why single addressing model (prefix-se= t per >>> interface-set) satisfies all scenarios, e.g., by pointing out a scenari= o in >>> which it does not, that should be the only addressing model supported i= n that >>> spec. >>> >>> >>> >>> [Sri] I guess, this goes back to our last discussion in this list. We a= llow >>> the hosting of multiple prefixes on an IPv6 link and the base RFC-5213 = allows >>> the same. You agreed and your comments on to take the approach of sessi= on >>> management, as supposed to addressing models. Now, we allow the ability= to >>> move a full/partial set of prefixes to a different interface, and optio= nally >>> allow the sharing of prefixes across links. This is one issue to discus= s the >>> shared link approach and see how to capture the final text. The text ca= n be >>> updated once we decide the scenarios that we support. This also probabl= y ties >>> to the policy interface to MN. Lets take this as an open issue. >> >> Adopting a solution draft before we have decided what scenarios we >> want to support with solution sounds a bit like putting the cart >> before the horse. >> >> In the addressing model I outlined: at PMIPv6 session creation a set >> of prefixes is assigned the mobile node's session. Then physical >> interfaces can attach to / detach from this session. A single mobile >> node can also have multiple sessions (say 2) in parallel, associated >> with distinct set of prefixes, which results in the ability for the >> prefixes set to move across interfaces fully or partially as the >> interfaces are attached to / detached from the session. So all >> scenarios are supported in this simple addressing model which also has >> a minimal deviation from the basic 5213 model. >> >> If you think this model places unreasonable limitations on what >> scenarios can be supported, please explain how and why. >> >> From my perspective the way forward is to revise the individual draft >> submission to document this addressing model only, after which we know >> what we are asked to adopt as a WG item. >> > I would like to summarize the session model as following: (1) A sigle mobile node has multiple sessions (2) Each session is associated with a distinct set of prefixes. (3) Interfaces are attached to/de-attached from the session. (4) Each interface can be attached to multiple session at a time. The item #4 is necessary for supporting full flow mobility. > >>> 2. there is no need to convey traffic selectors between the MAG and the= LMA. >>> The LMA forwards downlink packets as per the network-based policy, and = the >>> uplink packets to the Internet. The MAG forwards downlink packets to th= e MN, >>> and uplink packets to the LMA. End of the story. As above, unless someo= ne >>> comes up with a rebuttal of why that is not=A0sufficient=A0to address t= he >>> scenario we're concerned with (network-based flow mobility), the traffi= c >>> selectors shall be removed from the specification. >>> >>> [Sri] I tend to agree. The MAG does not have ability to convey flow lev= el >>> info over ND interface. At the end of the day, the MAG is hosting a set= of >>> prefixes on a link and that=B9s all. So, the traffic selectors are not = needed >>> from the mobility perspective, but if we look at this as exchange of po= licy, >>> we can allow them optionally. But, =A0I=B9m fine to get rid of this ent= irely, but >>> allowing this exchange is not undesirable either. >>> >> >> As you rightfully note, "the traffic selectors are not needed from the >> mobility perspective." Thus, since PMIPv6 is not a policy exchange >> protocol (or did it stand for Policy and Mobility for IPv6 ;-) they >> are undesirable, should not be allowed optionally, and should be >> getting rid of entirely :-) >> > > Works for me. No traffic spec in the protocol signaling is fine with me. > It works for me also. I agree that the LMA dose not need to send traffic selectors to the MAG. Regards, TrungTM > > Regards > Sri > > > > >> Best, >> >> --julien > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 From rkoodli@cisco.com Thu Feb 3 20:00:59 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D65143A6407 for ; Thu, 3 Feb 2011 20:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.23 X-Spam-Level: X-Spam-Status: No, score=-110.23 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbjY3NiZz5w3 for ; Thu, 3 Feb 2011 20:00:58 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C0F223A6A16 for ; Thu, 3 Feb 2011 20:00:58 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAcJS02tJXG9/2dsb2JhbAClOHOhY5sGhVgEhHmGbIMzgwE Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rtp-iport-2.cisco.com with ESMTP; 04 Feb 2011 04:04:22 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p1444MJd010719; Fri, 4 Feb 2011 04:04:22 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Feb 2011 22:04:22 -0600 Received: from 10.21.144.168 ([10.21.144.168]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Fri, 4 Feb 2011 04:04:21 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 03 Feb 2011 20:22:49 -0800 From: Rajeev Koodli To: Tran Minh Trung , Julien Laganier Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvEIy5OuEOsmkO47k+gb+octWK1xQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Feb 2011 04:04:22.0068 (UTC) FILETIME=[9A864740:01CBC420] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 04:01:00 -0000 On 2/3/11 7:10 PM, "Tran Minh Trung" wrote: > There is one question left from the discussion between Julien and > Rajeev is that: > Should LMA need to tell the MAG about new prefix(es) of the session > that the interface attach to?. > > My answer is YES!. > The MAG needs to know which prefixes are newly assigned to a MN > attachment to send RA. > Without this step, how can the MN know the right attachment to send a packet? > The LMA needs to provide the prefix info to the MAG. This can be either in PBA or in FMI (if not provided in PBA). Regards, -Rajeev > > Happy Lunar New Year! > Regards, > TrungTM > > On Fri, Feb 4, 2011 at 9:12 AM, Julien Laganier wrote: >> On Thu, Feb 3, 2011 at 4:22 PM, Rajeev Koodli wrote: >>> >>> On 2/3/11 3:49 PM, "Julien Laganier" wrote: >>> >>>> >>>> I'm breaking down your scenario below in steps, and adding below each >>>> step what action would happen in my model: >>>> >>>>> Help me understand then with this scenario: The MN attaches on if0, gets >>>>> prefix p0. >>>> >>>> New PMIPv6 session S0 is created with prefix set = {p0} over interface set >>>> {if0} >>>> >>>>> The MN attaches on if1, the LMA assigns the p1. >>>> >>>> New PMIPv6 session S1 is created with prefix set = {p1} over interface set >>>> {if1} >>>> >>>>> At some point later, the LMA chooses to move some flows from if0 to if1. >>>> >>>> Interface if1 is added to existing PMIPv6 session S0 which has prefix >>>> set = {p0} now extended over interface set {if0, if1} >>> >>> I would insert that the LMA also informs the MAG hosting p1 to accept p0. >> >> Why would the LMA need to tell the MAG? >> >>>>> How do I do this without being forced to allocate both p0 and p1 on if1 at >>>>> the time of attach >>>>> (on if1)? >>>> >>>> By following the steps above? :-) >>> >>> Cool. This is what is in the draft, but presented differently. >> >> As per my note to Carlos, the draft doesn't do a good job at >> explaining the session model, and contains useless stuff that should >> be removed before I can consider making a decision on endorsing it or >> not. >> >>> We could always make it better. >> >> So let's do it and adopt the better version! >> >> --julien >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> > > From sgundave@cisco.com Thu Feb 3 20:20:32 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D2A43A6AFC for ; Thu, 3 Feb 2011 20:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.962 X-Spam-Level: X-Spam-Status: No, score=-8.962 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JslV6tSAaBnl for ; Thu, 3 Feb 2011 20:20:12 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 844C23A6AF3 for ; Thu, 3 Feb 2011 20:20:11 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkICAAINS02rRN+J/2dsb2JhbACCRZQOQIYJAYczaHOhapsHgnsBglwEhHmGbIMzgwGFcg Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 04 Feb 2011 04:23:34 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p144NWND016405; Fri, 4 Feb 2011 04:23:32 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Feb 2011 20:23:34 -0800 Received: from 10.32.246.213 ([10.32.246.213]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Fri, 4 Feb 2011 04:23:33 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 03 Feb 2011 20:24:04 -0800 From: Sri Gundavelli To: "Giaretta, Gerardo" , stefano faccin Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLwmpURzmRlysrlUidlexdQorGZJPuBh2AgAAR4ICAAAzJgIAACkaAgADJ5gCAAKKGAP//oT5wgAEpJLmAAAFP8IAAWrj+ In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3379609447_88269623" X-OriginalArrivalTime: 04 Feb 2011 04:23:34.0806 (UTC) FILETIME=[499C2360:01CBC423] Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 04:20:32 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3379609447_88269623 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Gerardo/Stefano: Not sure, if that is sufficient and how it fits into the current trend towards supporting open client systems. We don=B9t have to agree on this. IMO= , this in some form translates to an implicit assumption, of HA having access to some policy, at least in some deployments, where the device qualificatio= n is not sufficient. In any case, where ever this is required, this is an administrative over ahead. Regards Sri On 2/3/11 3:00 PM, "Giaretta, Gerardo" wrote: > Hi Sri, > =20 > Conformance tests can be used to make sure the UE behaves accordingly. So= no > need for the PDN GW to perform any validation. > =20 > Cheers > Gerardo=20 > =20 >=20 > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Thursday, February 03, 2011 2:55 PM > To: Giaretta, Gerardo; stefano faccin > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > Subject: Re: [netext] Consensus call to adopt I-D: > draft-bernardos-netext-pmipv6-flowmob as WG doc > =20 > Hi Gerardo, >=20 > Sure, for supporting the specific scenario, the draft is making that > assumption. This does come at a cost for the operator having to ensure > synchronized policies between the ANDSF server and the PDN GW. But, my > question still remains, how in IFOM, a PDN GW can ever authorize and esta= blish > the flow policies requested by the UE. It needs the access to same policy= that > the operator configured on the ANDSF server. Else, its all in the mercy o= f the > UE with no network side validation. There can be all the needed informati= on > elements, around UE location, or network attachment in the protocol signa= ling, > directly from the UE in IFOM, but fundamentally the PDN GW needs access t= o the > same policy. I do agree, this assumption is an administrative overhead. >=20 >=20 > Regards > Sri=20 >=20 >=20 >=20 > On 2/2/11 9:13 PM, "Giaretta, Gerardo" wrote: > Hi Sri, > =20 > There is no implicit assumption of synchronized policies. A basic example= that > shows that there is no assumption is the following: ANDSF policies may be > based also on location of the UE. For example the UE should prefer WLAN o= nly > in a given location. When the UE is attached over WLAN there is no way fo= r the > PDNGW/HA to verify the location of the UE and therefore to verify UE acti= ons > based on policies. > =20 > The assumption on synchronization of policies is only applicable to this = draft > and I think it is a wrong one. > =20 > Cheers > Gerardo > =20 >=20 > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of > Sri Gundavelli > Sent: Wednesday, February 02, 2011 6:50 PM > To: stefano faccin > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > Subject: Re: [netext] Consensus call to adopt I-D: > draft-bernardos-netext-pmipv6-flowmob as WG doc >=20 > Hi Stefano, >=20 > One comment. >=20 > Agree with you there is no ANDSF interface to the network node, but the > assumption of synchronized policies between the ANDSF server and the PDN = GW/HA > is there, implicitly IMO. With out this assumption, I do not know, how th= e HA > can ever validate the flow mobility options received in the BU. If the > operator requires any control on enforcing a flow policy rule, the PDN GW= /HA > needs to have synchronized policies, without which its always the client > decision. I=B9m not sure, operators in 3GPP would like that :) >=20 > No doubt, the lack of MN-AR interface is surely an issue for supporting > complex flow policies. I realize the issues and I agree with you. But, th= e > assumption of synchronized policies can offer some solution with some > configuration requirement on the HA (assuming there are no other issues). > There are also the proposals on flow mirroring on the UE ..., requiring n= o > flow policies. I=B9ve not evaluated this, however. Folks can comment on thi= s. >=20 > It is also to be noted, for some of the scenarios such, there is no flow > policy interface needed. We can identify what scenarios create any > configuration limitations on the HA and which one=B9s do not . As I=B9ve note= d > earlier, this is surely an open issue, that we need to discuss in the WG. >=20 >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 > =20 >=20 >=20 > On 2/2/11 9:08 AM, "stefano faccin" wrote: > Sri, > thanks for the reply. Can you clarify in which system or scenario ANDSF i= s > available to network entities as well? There is no such availability in 3= GPP, > and making such information available would require considerable architec= tural > changes, therefore the applicability of this solution to what seems to be= the > only realistic scenario hinges on 3GPP making considerable architectural > changes. I would therefore not be so hastily concluding that the ANDSF > information is available to the LMA and underestimate what it would reall= y > take to make the solution applicable. >=20 > If we cannot guarantee that there is at least one realistic solution to h= ave > the MNa nd LMA in synch, how do we expect that this solution is applicabl= e at > all? In 3GPP there is no need to have such implicit assumption, be cause = 1) > the MN is provided policies explicitly through the ANDSF, and 2) it is th= e MN > and only the MN that makes IP flow mobility decisions and communicates th= em > explicitly (with well defined signalling) to the LMA, and therefore no ma= gic > is needed. There is no need in 3GPP to have the ANDSF and PDN GW policies > synchronized, since the PDN GW does not use such policies. >=20 > Sri, in the end it is a matter of whether we develop a solution that will= rely > on some unknown magic to be deployed, or a solution that we know can be > deployed in at least one way because there are solutions to what I consid= er > major open issues. >=20 > Cheers, > Stefano >=20 > On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli wrote= : > Hi Stefano, >=20 > Thanks for the discussion. >=20 > As you say, the ANDSF policies are allowing the MN a.) to make the right > network attachment decision and b.) make the access selection on a flow b= asis. > This same policy that is present in the ANDSF server, is available for th= e > network nodes as well. I=B9m not sure, with out this assumption the solutio= n can > work for all currently listed cases. We clearly need the MN and the LMA t= o be > in synch with respect to the configured policy. How, that is done, I gues= s we > will not try to know. I thought even in 3GPP, this is the implied assump= tion > ? But, this is for you to clarify. Not specifically for IFOM where UE and= PDN > GW/HA are negotiating the flow policies, but generally that the PDN GW an= d the > ANDSF policy server will have synchronized policies. The MAG and the LMA = have > the ability to carry this flow policy information in signaling messages a= nd > influence the access selection. The policy is a opaque object, with exten= sible > formats, when carried in the signaling plane, should allow the LMA/MAG to > apply those access policies, while assuming MN is following the same rule= s. > These policies can surely reflect the specific WLAN access/operator speci= fic > rule. I=B9m surely with you, the lack of MN-AR interface is surely an issue= and > I see that. But, we need to understand, what are the limitations with the > approach of out of band policy interfaces and what will be the solution > limitations. If we need to tie the flow movement at the prefix granularit= y and > rely on the natural ND interface in the form of RA PIO option, more like = PDN > offload in MAPCON, or at the granularity of a flow level, is open for > discussion. I want to simplify this draft for sure, we can surely discuss= each > of these issues on the WG draft. >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 >=20 >=20 > On 2/1/11 8:29 PM, "stefano faccin" > wrote: > Sri, > thanks for the reply. >=20 > I'd like to comment on the "the flow policy decisions need not be based o= n the > specific WLAN network". Does it mean, as I believe it does, that the curr= ent > solution would not allow an operator deploying such solution to decide to > route flows over a specific WLAN or not depending on which specific WLAN = the > MN is connected to? E.g. the operator or the entity in control of the > decisions for the routing may want to direct certain traffic always over = WLANs > that the operator deploys, and instead route only some of the traffic ove= r > WLANs of roaming partners or of the MN user home. How does this solution > support that scenario if the LMA is not told specifically which WLAN the = MN is > connected to? From a deployment point of view, I do not believe we can af= ford > to leave out this scenario. Please note that the establishment of a secur= ity > relationship between the MN and the MAG, and a specific MAG identity, can= not > guarantee that the LMA knows which specific WLAN access network the MN is > connected to. Assuming that would severely restrict the deployment scenar= ios. >=20 > As for the MN and the LMA being magically in synch, I am very concerned a= bout > a "glass ball" solution. You mention ANDSF defined by 3GPP as a solution = for > this "out of band" delivery of policy. Fair enough, however there is an i= ssue > with that. ANDSF is designed specific to be a MN-centric solution where > policies are provisioned in the MN and the MN decides which network > technologies and access networks it needs to connect to, under what > conditions, and which IP traffic needs to be routed on such accesses. No = IP > point of attachment in the network (i.e. the PDN GW in 3GPP that is the L= MA in > PMIPv6) is aware under any conditions of such policy. Therefore, even if = in > order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would > unfortunately not provide a solution unless the MN can communicate to the= MAG > and the LMA the decisions the MN has taken based on the ANDSF policies. >=20 > I believe the key point here is that we need to understand how the soluti= on > can be realistically applied to a real scenario, and that we need to ensu= re > that important and realistic deployment scenarios are not excluded by the > solution. >=20 > Cheers, > Stefano >=20 > On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli > wrote: > Hi Stefano: >=20 > These are valid points and some good comments. Let me share my thoughts. >=20 > Carlo=B9s draft is not assuming any new MN-AR interface. Its going with the > assumption there is established policy on the mobile and on the LMA, whic= h > allows the mobile to select the access network at a flow level granularit= y, > without requiring any explicit signaling between the MAG and the MN. To l= arge > part this is all about out of band policy interface, such as ANDSF, towar= ds > the UE, leading to the assumption that magically the MN and the LMA are i= n > sync with respect to flow policies, access selection and they will make t= he > right forwarding decision. Secondly, the flow policy decisions need not b= e > based on the specific WLAN network, but it is implicitly driven by the MA= G =AD > LMA security relation, where the MAG attachment to the WLAN network > transitively allows the LMA to make the flow policy decisions based on th= e MAG > identity. If the WLAN network is not trusted, there is truly no MAG in th= at > network, where the LMA shares a security relation with that node. >=20 > There are still some open issues on this draft that needs to be discussed= in > the WG. On the approaches to allow more a flow aggregate movement, that = is a > discussion point. There are issues that we need to discuss, supporting sp= lit > link model, or eliminating some favorite brand of signaling message (FMA)= and > riding on PBU/PBA and just with one FMI trigger, and on the aspects aroun= d MN > applying the flow policies by flow mirroring. We have no agreement on tho= se > issues yet. >=20 > Its just a base draft, for further discussion and resolving those issues.= But, > hope that is not a stopper for base draft selection. >=20 >=20 > Sri >=20 >=20 >=20 >=20 >=20 >=20 > On 2/1/11 6:39 PM, "stefano faccin" > wrote: > Raj, > thanks for the email. >=20 > I need to apologize in advance if my questions have already been answered > before (though I cannot find a conclusive answer anywhere). >=20 > I think that a protocol that is developed in NETEXT (or other groups) sho= uld > have at least a potential realistic scenario for applicability. >=20 > In terms of applicability, though it is not part of the protocol definiti= on > per se, unless there are solutions in place for either the host to indica= te to > the network where the flows should be routed or for the LMA to receive so= mehow > from somewhere some policies, the solution cannot really provide flow mob= ility > since there is no way to decide which flows are routed where. If we are > thinking about a host-based solution, I have not yet seen a solution as t= o how > the host can indicate to the MAG and ultimately to the MAG which flows sh= ould > be routed on each access. If we are relying on modifications of layer 2 > protocols, aren't we defining a solution that works only with some > technologies (since for other access technologies it is rather unrealisti= c to > modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-ba= sed > solution, can we hear of at least one example of a real-life scenario whe= re > the LMA would receive such policies, and how such delivery would happen? = Also, > should there be a solution to have policies in the LMA, how does the LMA > actually decide to route flows on one access or the other? E.g., if some = flows > need to be routed on certain WLAN networks, but shall not be routed on ot= her > WLAN networks, how does the LMA know which specific WLAN network the host= is > connected to? Perhaps I missed the ability for the MAG to know e.g. the W= LAN > SSID and provide it to the LMA, in which case I would appreciate if someb= ody > could highlight to me where that is defined. >=20 > I think that, though not integral to the protocol specification, understa= nding > what framework the protocol would/needs to fit in is rather important. >=20 > Cheers, > Stefano >=20 >=20 > On Tue, Feb 1, 2011 at 3:47 PM, > > wrote: >=20 > Hello, >=20 > We have discussed the flow mobility solutions for Proxy MIP6 previously a= t > IETFs 78 and 79. > This is a consensus call for adopting this I-D: > draft-bernardos-netext-pmipv6-flowmob-02 > as the working group document. > I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt >=20 > The consensus call will expire on Feb 15th, 2011. Please indicate your > support or concerns in adopting this I-D as the WG baseline document on > the mailing list. >=20 > Please note that this I-D will serve as the baseline in the WG and will b= e > developed further based on input and feedback from WG members. >=20 > -Basavaraj >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext >=20 > =20 > =20 >=20 --B_3379609447_88269623 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmi= pv6-flowmob as WG doc Hi Gerardo/Stefano:

Not sure, if that is sufficient and how it fits into the current trend towa= rds supporting open client systems. We don’t have to agree on this. IM= O, this in some form translates to an implicit assumption, of HA having acce= ss to some policy, at least in some deployments, where the device qualificat= ion is not sufficient. In any case, where ever this is required, this is an = administrative over ahead.

Regards
Sri




On 2/3/11 3:00 PM, "Giaretta, Gerardo" <gerardog@qualcomm.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Hi Sri,
 
Conformance tests can be used to make sure the UE behaves accordingly. So n= o need for the PDN GW to perform any validation.
 
Cheers
Gerardo
 

From: Sri Gundave= lli [mailto:sgundave@cisco.com]
Sent: Thursday, February 03, 2011 2:55 PM
To: Giaretta, Gerardo; stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-n= etext-pmipv6-flowmob as WG doc
Hi Gerardo,

Sure, for supporting the specific scenario, the draft is making that assump= tion. This does come at a cost for the operator having to ensure synchronize= d policies between the ANDSF server and the PDN GW. But, my question still r= emains, how in IFOM, a PDN GW can ever authorize and establish the flow poli= cies requested by the UE. It needs the access to same policy that the operat= or configured on the ANDSF server. Else, its all in the mercy of the UE with= no network side validation. There can be all the needed information element= s, around UE location, or network attachment in the protocol signaling, dire= ctly from the UE in IFOM, but fundamentally the PDN GW needs access to the s= ame policy. I do agree, this assumption is an administrative overhead.


Regards
Sri



On 2/2/11 9:13 PM, "Giaretta, Gerardo" <gerardog@qualcomm.com> wrote:
Hi Sri,
 
There is no implicit assumption of synchronized policies. A basic example t= hat shows that there is no assumption is the following: ANDSF policies may b= e based also on location of the UE. For example the UE should prefer WLAN on= ly in a given location. When the UE is attached over WLAN there is no way fo= r the PDNGW/HA to verify the location of the UE and therefore to verify UE a= ctions based on policies.
 
The assumption on synchronization of policies is only applicable to this dr= aft and I think it is a wrong one.
 
Cheers
Gerardo
 

From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Sri= Gundavelli
Sent: Wednesday, February 02, 2011 6:50 PM
To: stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-n= etext-pmipv6-flowmob as WG doc

Hi Stefano,

One comment.

Agree with you there is no ANDSF interface to the network node, but the ass= umption of synchronized policies between the ANDSF server and the PDN GW/HA = is there, implicitly IMO. With out this assumption, I do not know, how the H= A can ever validate the flow mobility options received in the BU. If the ope= rator requires any control on enforcing a flow policy rule, the PDN GW/HA ne= eds to have synchronized policies, without which its always the client decis= ion. I’m not sure, operators in 3GPP would like that :)

No doubt, the lack of MN-AR interface is surely an issue for supporting com= plex flow policies. I realize the issues and I agree with you. But, the assu= mption of synchronized policies can offer some solution with some configurat= ion requirement on the HA (assuming there are no other issues). There are al= so the proposals on flow mirroring on the UE ..., requiring no flow policies= . I’ve not evaluated this, however. Folks can comment on this.

It is also to be noted, for some of the scenarios such, there is no flow po= licy interface needed. We can identify what scenarios create any configurati= on limitations on the HA and which one’s do not . As I’ve noted = earlier, this is surely an open issue, that we need to discuss in the WG.


Regards
Sri




 


On 2/2/11 9:08 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:
Sri,
thanks for the reply. Can you clarify in which system or scenario ANDSF is = available to network entities as well? There is no such availability in 3GPP= , and making such information available would require considerable architect= ural changes, therefore the applicability of this solution to what seems to = be the only realistic scenario hinges on 3GPP making considerable architectu= ral changes. I would therefore not be so hastily concluding that the ANDSF i= nformation is available to the LMA and underestimate what it would really ta= ke to make the solution applicable.

If we cannot guarantee that there is at least one realistic solution to hav= e the MNa nd LMA in synch, how do we expect that this solution is applicable= at all? In 3GPP there is no need to have such implicit assumption, be cause= 1) the MN is provided policies explicitly through the ANDSF, and 2) it is t= he MN and only the MN that makes IP flow mobility decisions and communicates= them explicitly (with well defined signalling) to the LMA, and therefore no= magic is needed. There is no need in 3GPP to have the ANDSF and PDN GW poli= cies synchronized, since the PDN GW does not use such policies.

Sri, in the end it is a matter of whether we develop a solution that will r= ely on some unknown magic to be deployed, or a solution that we know can be = deployed in at least one way because there are solutions to what I consider = major open issues.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli <sgundave@cisco.com> wrote:
Hi Stefano,

Thanks for the discussion.

As you say, the ANDSF policies are allowing the MN a.) to make the right ne= twork attachment decision and b.) make the access selection on a flow basis.= This same policy that is present in the ANDSF server, is available for the = network nodes as well. I’m not sure, with out this assumption the solu= tion can work for all currently listed cases. We clearly need the MN and the= LMA to be in synch with respect to the configured policy. How, that is done= , I guess we will not try to know.  I thought even in 3GPP, this is the= implied assumption ? But, this is for you to clarify. Not specifically for = IFOM where UE and PDN GW/HA are negotiating the flow policies, but generally= that the PDN GW and the ANDSF policy server will have synchronized policies= . The MAG and the LMA have the ability to carry this flow policy information= in signaling messages and influence the access selection. The policy is a o= paque object, with extensible formats, when carried in the signaling plane, = should allow the LMA/MAG to apply those access policies, while assuming MN i= s following the same rules. These policies can surely reflect the specific W= LAN access/operator specific rule. I’m surely with you, the lack of MN= -AR interface is surely an issue and I see that. But, we need to understand,= what are the limitations with the approach of  out of band policy inte= rfaces and what will be the solution limitations. If we need to tie the flow= movement at the prefix granularity and rely on the natural ND interface in = the form of RA PIO option, more like PDN offload in MAPCON, or at the granul= arity of a flow level, is open for discussion. I want to simplify this draft= for sure, we can surely discuss each of these issues on the WG draft.


Regards
Sri






On 2/1/11 8:29 PM, "stefano faccin" <sfaccinstd@gmail.com <htt= p://sfaccinstd@gmail.com> > wrote:
Sri,
thanks for the reply.

I'd like to comment on the "the flow policy decisions need not be base= d on the specific WLAN network". Does it mean, as I believe it does, th= at the current solution would not allow an operator deploying such solution = to decide to route flows over a specific WLAN or not depending on which spec= ific WLAN the MN is connected to? E.g. the operator or the entity in control= of the decisions for the routing may want to direct certain traffic always = over WLANs that the operator deploys, and instead route only some of the tra= ffic over WLANs of roaming partners or of the MN user home. How does this so= lution support that scenario if the LMA is not told specifically which WLAN = the MN is connected to? From a deployment point of view, I do not believe we= can afford to leave out this scenario. Please note that the establishment o= f a security relationship between the MN and the MAG, and a specific MAG ide= ntity, cannot guarantee that the LMA knows which specific WLAN access networ= k the MN is connected to. Assuming that would severely restrict the deployme= nt scenarios.

As for the MN and the LMA being magically in synch, I am very concerned abo= ut a "glass ball" solution. You mention ANDSF defined by 3GPP as a= solution for this "out of band" delivery of policy. Fair enough, = however there is an issue with that. ANDSF is designed specific to be a MN-c= entric solution where policies are provisioned in the MN and the MN decides = which network technologies and access networks it needs to connect to, under= what conditions, and which IP traffic needs to be routed on such accesses. = No IP point of attachment in the network (i.e. the PDN GW in 3GPP that is th= e LMA in PMIPv6) is aware under any conditions of such policy. Therefore, ev= en if in order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF = would unfortunately not provide a solution unless the MN can communicate to = the MAG and the LMA the decisions the MN has taken based on the ANDSF polici= es.

I believe the key point here is that we need to understand how the solution= can be realistically applied to a real scenario, and that we need to ensure= that important and realistic deployment scenarios are not excluded by the s= olution.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli <sgundave@cisco.com <http://s= gundave@cisco.com> > wrote:
Hi Stefano:

These are valid points and some good comments. Let me share my thoughts.
Carlo’s draft is not assuming any new MN-AR interface. Its going with= the assumption there is established policy on the mobile and on the LMA, wh= ich allows the mobile to select the access network at a flow level granulari= ty, without requiring any explicit signaling between the MAG and the MN. To = large part this is all about out of band policy interface, such as ANDSF, to= wards the UE, leading to the assumption that magically the MN and the LMA ar= e in sync with respect to flow policies, access selection and they will make= the right forwarding decision. Secondly, the flow policy decisions need not= be based on the specific WLAN network, but it is implicitly driven by the M= AG – LMA security relation, where the MAG attachment to the WLAN netwo= rk transitively allows the LMA to make the flow policy decisions based on th= e MAG identity. If the WLAN network is not trusted, there is truly no MAG in= that network, where the LMA shares a security relation with that node.

There are still some open issues on this draft that needs to be discussed i= n the WG.  On the approaches to allow more a flow aggregate movement, t= hat is a discussion point. There are issues that we need to discuss, support= ing split link model, or eliminating some favorite brand of signaling messag= e (FMA) and riding on PBU/PBA and just with one FMI trigger, and on the aspe= cts around MN applying the flow policies by flow mirroring. We have no agree= ment on those issues yet.

Its just a base draft, for further discussion and resolving those issues. B= ut, hope that is not a stopper for base draft selection.


Sri






On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <htt= p://sfaccinstd@gmail.com>  <http://sfaccinstd@gmail.com> > wrote:
Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicate= to the network where the flows should be routed or for the LMA to receive s= omehow from somewhere some policies, the solution cannot really provide flow= mobility since there is no way to decide which flows are routed where. If w= e are thinking about a host-based solution, I have not yet seen a solution a= s to how the host can indicate to the MAG and ultimately to the MAG which fl= ows should be routed on each access. If we are relying on modifications of l= ayer 2 protocols, aren't we defining a solution that works only with some te= chnologies (since for other access technologies it is rather unrealistic to = modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-based= solution, can we hear of at least one example of a real-life scenario where= the LMA would receive such policies, and how such delivery would happen? Al= so, should there be a solution to have policies in the LMA, how does the LMA= actually decide to route flows on one access or the other? E.g., if some fl= ows need to be routed on certain WLAN networks, but shall not be routed on o= ther WLAN networks, how does the LMA know which specific WLAN network the ho= st is connected to? Perhaps I missed the ability for the MAG to know e.g. th= e WLAN SSID and provide it to the LMA, in which case I would appreciate if s= omebody could highlight to me where that is defined.

I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important. <= BR>
Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM,  <Basavaraj.Patil@nokia.com <http://Basavaraj.Patil@nokia.com>  <http://Basavaraj.Patil@nokia.com> > wrote:
Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= BR> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt<= /a>

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= BR> developed further based on input and feedback from WG members.

-Basavaraj

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

--B_3379609447_88269623-- From sgundave@cisco.com Thu Feb 3 21:10:58 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82A113A6B0D for ; Thu, 3 Feb 2011 21:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.982 X-Spam-Level: X-Spam-Status: No, score=-8.982 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hh+NzsO8c9Of for ; Thu, 3 Feb 2011 21:10:36 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id C9A963A6B07 for ; Thu, 3 Feb 2011 21:10:36 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkICAKoZS02rR7H+/2dsb2JhbACCRZQOQIYJAYczaHOhOJsBgnsBGYJDBIR5hmyDM4MBhXI Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 04 Feb 2011 05:13:59 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p145Dxsh015183; Fri, 4 Feb 2011 05:13:59 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Feb 2011 21:13:59 -0800 Received: from 10.32.246.213 ([10.32.246.213]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Fri, 4 Feb 2011 05:13:59 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 03 Feb 2011 21:14:32 -0800 From: Sri Gundavelli To: , , , Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLwmpURzmRlysrlUidlexdQorGZJPuBh2AgAAR4ICAAAzJgIAACkaAgADJ5gCAAKKGAP//oT5wgAAf2NyAAIzc8IAA5pGy In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C4620179629E@ftrdmel0.rd.francetelecom.fr> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3379612472_88458885" X-OriginalArrivalTime: 04 Feb 2011 05:13:59.0916 (UTC) FILETIME=[54B74AC0:01CBC42A] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 05:10:58 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3379612472_88458885 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Pierrick: I agree with lot of points. * Yes, its all about handover execution. This is the key point. A PBU message from the MN can be the first step towards activating the handover process. Or a FMI trigger from the LMA, may itself be the pre-trigger for PBU message from the MAG. At the end of the day, the LMA applies the policy and provides the set of prefixes to the MAG. MAG will continue to behave as in 5213. The decision logic, or the granularity of the policy rule applicability on the LMA can be out of scope * Policy synchronization is an issue, for the case where the UE=B9s forwardin= g decision is based on the policy and not based on the ND messages from the attached interface. It is very well may be that, we have the same issue for IFOM as well, IMO, but that=B9s beside the point for now. The policy activation on the UE, and the associated issues should be discussed in this context and as needed. * This draft should not deal with flow policies, how they are applied and what granularity can be out of scope, IMO. These policies need not be carried in PMIP signaling place, unless we have MN-AR interface * I=B9m not clear on the policy management though, before we say, it can be separate thread. The whole approach seems to be out of band at this point and not sure what can be specified on the PMIP signaling plane with respect to policy.=20 Regards Sri On 2/3/11 7:35 AM, "pierrick.seite@orange-ftgroup.com" wrote: > Hello, > =20 > This is an interesting discussion, thanks for bringing the ANDSF issues o= n the > table. Effectively, mobility control, i.e. access selection, is a key poi= nt > for an operator. From an operator point of view, criteria for selection i= s not > only RAT type or SSID; we can imagine plenty of other criteria. Different > mobility control models can be envisaged such as Network controlled or > terminal controlled and so on... For sure, in PMIP context, policies > synchronization can be an issue and how decision made on the terminal can > interact with network managed mobility should be discussed. But, I don't = think > draft-bernardos should go in this space. I think, we should clearly > distinguish mobility functions. IMHO, draft-bernardos should not be expec= ted > to deal with selection management, or mobility triggers, but only on the > handover execution. In other words, the draft should assume that handover > decision has been made (how decision is made is out of scope) and, then, = only > focus on mechanism allowing the LMA to transfer flow(s). Although related= , > mobility decision management, e.g. policy based, should be discussed in a > separated thread. > =20 > BR, > Pierrick > =20 > =20 >=20 >=20 > De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part = de > Stefano Faccin > Envoy=E9 : jeudi 3 f=E9vrier 2011 08:05 > =C0 : gerardog@qualcomm.com; sgundave@cisco.com; sfaccinstd@gmail.com > Cc : netext@ietf.org; Basavaraj.Patil@nokia.com > Objet : Re: [netext] Consensus call to adopt > I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc > =20 > Hello Sri, > From a point of view of applicability of the solution, I must agree with > Gerardo that assuming synchronization of policies is an issue of this sol= ution > since it comes with a set of restrictions on how the solution can be appl= ied. > Cheers, > Stefano >=20 > Stefano=20 > Stefano M. Faccin >=20 > Standards Manager > Research In Motion > 122 West John Carpenter Parkway > Irving, TX 75039=20 > Internal: 820 63451 > Desk: +1 972 910 3451 > BlackBerry: +1 510 230 8422 > sfaccin@rim.com=20 > Time zone: PST (GMT -8) > =20 >=20 > From: Giaretta, Gerardo [mailto:gerardog@qualcomm.com] > Sent: Wednesday, February 02, 2011 11:13 PM > To: Sri Gundavelli ; stefano faccin > Cc: netext@ietf.org ; Basavaraj.Patil@nokia.com > > Subject: Re: [netext] Consensus call to adopt I-D: > draft-bernardos-netext-pmipv6-flowmob as WG doc > =20 > Hi Sri, > =20 > There is no implicit assumption of synchronized policies. A basic example= that > shows that there is no assumption is the following: ANDSF policies may be > based also on location of the UE. For example the UE should prefer WLAN o= nly > in a given location. When the UE is attached over WLAN there is no way fo= r the > PDNGW/HA to verify the location of the UE and therefore to verify UE acti= ons > based on policies. > =20 > The assumption on synchronization of policies is only applicable to this = draft > and I think it is a wrong one. > =20 > Cheers > Gerardo > =20 >=20 > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of > Sri Gundavelli > Sent: Wednesday, February 02, 2011 6:50 PM > To: stefano faccin > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > Subject: Re: [netext] Consensus call to adopt I-D: > draft-bernardos-netext-pmipv6-flowmob as WG doc > =20 > Hi Stefano, >=20 > One comment. >=20 > Agree with you there is no ANDSF interface to the network node, but the > assumption of synchronized policies between the ANDSF server and the PDN = GW/HA > is there, implicitly IMO. With out this assumption, I do not know, how th= e HA > can ever validate the flow mobility options received in the BU. If the > operator requires any control on enforcing a flow policy rule, the PDN GW= /HA > needs to have synchronized policies, without which its always the client > decision. I=B9m not sure, operators in 3GPP would like that :) >=20 > No doubt, the lack of MN-AR interface is surely an issue for supporting > complex flow policies. I realize the issues and I agree with you. But, th= e > assumption of synchronized policies can offer some solution with some > configuration requirement on the HA (assuming there are no other issues). > There are also the proposals on flow mirroring on the UE ..., requiring n= o > flow policies. I=B9ve not evaluated this, however. Folks can comment on thi= s. >=20 > It is also to be noted, for some of the scenarios such, there is no flow > policy interface needed. We can identify what scenarios create any > configuration limitations on the HA and which one=B9s do not . As I=B9ve note= d > earlier, this is surely an open issue, that we need to discuss in the WG. >=20 >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 > =20 >=20 >=20 > On 2/2/11 9:08 AM, "stefano faccin" wrote: > Sri, > thanks for the reply. Can you clarify in which system or scenario ANDSF i= s > available to network entities as well? There is no such availability in 3= GPP, > and making such information available would require considerable architec= tural > changes, therefore the applicability of this solution to what seems to be= the > only realistic scenario hinges on 3GPP making considerable architectural > changes. I would therefore not be so hastily concluding that the ANDSF > information is available to the LMA and underestimate what it would reall= y > take to make the solution applicable. >=20 > If we cannot guarantee that there is at least one realistic solution to h= ave > the MNa nd LMA in synch, how do we expect that this solution is applicabl= e at > all? In 3GPP there is no need to have such implicit assumption, be cause = 1) > the MN is provided policies explicitly through the ANDSF, and 2) it is th= e MN > and only the MN that makes IP flow mobility decisions and communicates th= em > explicitly (with well defined signalling) to the LMA, and therefore no ma= gic > is needed. There is no need in 3GPP to have the ANDSF and PDN GW policies > synchronized, since the PDN GW does not use such policies. >=20 > Sri, in the end it is a matter of whether we develop a solution that will= rely > on some unknown magic to be deployed, or a solution that we know can be > deployed in at least one way because there are solutions to what I consid= er > major open issues. >=20 > Cheers, > Stefano >=20 > On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli wrote= : > Hi Stefano, >=20 > Thanks for the discussion. >=20 > As you say, the ANDSF policies are allowing the MN a.) to make the right > network attachment decision and b.) make the access selection on a flow b= asis. > This same policy that is present in the ANDSF server, is available for th= e > network nodes as well. I=B9m not sure, with out this assumption the solutio= n can > work for all currently listed cases. We clearly need the MN and the LMA t= o be > in synch with respect to the configured policy. How, that is done, I gues= s we > will not try to know. I thought even in 3GPP, this is the implied assump= tion > ? But, this is for you to clarify. Not specifically for IFOM where UE and= PDN > GW/HA are negotiating the flow policies, but generally that the PDN GW an= d the > ANDSF policy server will have synchronized policies. The MAG and the LMA = have > the ability to carry this flow policy information in signaling messages a= nd > influence the access selection. The policy is a opaque object, with exten= sible > formats, when carried in the signaling plane, should allow the LMA/MAG to > apply those access policies, while assuming MN is following the same rule= s. > These policies can surely reflect the specific WLAN access/operator speci= fic > rule. I=B9m surely with you, the lack of MN-AR interface is surely an issue= and > I see that. But, we need to understand, what are the limitations with the > approach of out of band policy interfaces and what will be the solution > limitations. If we need to tie the flow movement at the prefix granularit= y and > rely on the natural ND interface in the form of RA PIO option, more like = PDN > offload in MAPCON, or at the granularity of a flow level, is open for > discussion. I want to simplify this draft for sure, we can surely discuss= each > of these issues on the WG draft. >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 >=20 >=20 > On 2/1/11 8:29 PM, "stefano faccin" > wrote: > Sri, > thanks for the reply. >=20 > I'd like to comment on the "the flow policy decisions need not be based o= n the > specific WLAN network". Does it mean, as I believe it does, that the curr= ent > solution would not allow an operator deploying such solution to decide to > route flows over a specific WLAN or not depending on which specific WLAN = the > MN is connected to? E.g. the operator or the entity in control of the > decisions for the routing may want to direct certain traffic always over = WLANs > that the operator deploys, and instead route only some of the traffic ove= r > WLANs of roaming partners or of the MN user home. How does this solution > support that scenario if the LMA is not told specifically which WLAN the = MN is > connected to? From a deployment point of view, I do not believe we can af= ford > to leave out this scenario. Please note that the establishment of a secur= ity > relationship between the MN and the MAG, and a specific MAG identity, can= not > guarantee that the LMA knows which specific WLAN access network the MN is > connected to. Assuming that would severely restrict the deployment scenar= ios. >=20 > As for the MN and the LMA being magically in synch, I am very concerned a= bout > a "glass ball" solution. You mention ANDSF defined by 3GPP as a solution = for > this "out of band" delivery of policy. Fair enough, however there is an i= ssue > with that. ANDSF is designed specific to be a MN-centric solution where > policies are provisioned in the MN and the MN decides which network > technologies and access networks it needs to connect to, under what > conditions, and which IP traffic needs to be routed on such accesses. No = IP > point of attachment in the network (i.e. the PDN GW in 3GPP that is the L= MA in > PMIPv6) is aware under any conditions of such policy. Therefore, even if = in > order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would > unfortunately not provide a solution unless the MN can communicate to the= MAG > and the LMA the decisions the MN has taken based on the ANDSF policies. >=20 > I believe the key point here is that we need to understand how the soluti= on > can be realistically applied to a real scenario, and that we need to ensu= re > that important and realistic deployment scenarios are not excluded by the > solution. >=20 > Cheers, > Stefano >=20 > On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli > wrote: > Hi Stefano: >=20 > These are valid points and some good comments. Let me share my thoughts. >=20 > Carlo=B9s draft is not assuming any new MN-AR interface. Its going with the > assumption there is established policy on the mobile and on the LMA, whic= h > allows the mobile to select the access network at a flow level granularit= y, > without requiring any explicit signaling between the MAG and the MN. To l= arge > part this is all about out of band policy interface, such as ANDSF, towar= ds > the UE, leading to the assumption that magically the MN and the LMA are i= n > sync with respect to flow policies, access selection and they will make t= he > right forwarding decision. Secondly, the flow policy decisions need not b= e > based on the specific WLAN network, but it is implicitly driven by the MA= G =AD > LMA security relation, where the MAG attachment to the WLAN network > transitively allows the LMA to make the flow policy decisions based on th= e MAG > identity. If the WLAN network is not trusted, there is truly no MAG in th= at > network, where the LMA shares a security relation with that node. >=20 > There are still some open issues on this draft that needs to be discussed= in > the WG. On the approaches to allow more a flow aggregate movement, that = is a > discussion point. There are issues that we need to discuss, supporting sp= lit > link model, or eliminating some favorite brand of signaling message (FMA)= and > riding on PBU/PBA and just with one FMI trigger, and on the aspects aroun= d MN > applying the flow policies by flow mirroring. We have no agreement on tho= se > issues yet. >=20 > Its just a base draft, for further discussion and resolving those issues.= But, > hope that is not a stopper for base draft selection. > =20 >=20 > Sri >=20 >=20 >=20 >=20 >=20 >=20 > On 2/1/11 6:39 PM, "stefano faccin" > wrote: > Raj, > thanks for the email. >=20 > I need to apologize in advance if my questions have already been answered > before (though I cannot find a conclusive answer anywhere). >=20 > I think that a protocol that is developed in NETEXT (or other groups) sho= uld > have at least a potential realistic scenario for applicability. >=20 > In terms of applicability, though it is not part of the protocol definiti= on > per se, unless there are solutions in place for either the host to indica= te to > the network where the flows should be routed or for the LMA to receive so= mehow > from somewhere some policies, the solution cannot really provide flow mob= ility > since there is no way to decide which flows are routed where. If we are > thinking about a host-based solution, I have not yet seen a solution as t= o how > the host can indicate to the MAG and ultimately to the MAG which flows sh= ould > be routed on each access. If we are relying on modifications of layer 2 > protocols, aren't we defining a solution that works only with some > technologies (since for other access technologies it is rather unrealisti= c to > modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-ba= sed > solution, can we hear of at least one example of a real-life scenario whe= re > the LMA would receive such policies, and how such delivery would happen? = Also, > should there be a solution to have policies in the LMA, how does the LMA > actually decide to route flows on one access or the other? E.g., if some = flows > need to be routed on certain WLAN networks, but shall not be routed on ot= her > WLAN networks, how does the LMA know which specific WLAN network the host= is > connected to? Perhaps I missed the ability for the MAG to know e.g. the W= LAN > SSID and provide it to the LMA, in which case I would appreciate if someb= ody > could highlight to me where that is defined. >=20 > I think that, though not integral to the protocol specification, understa= nding > what framework the protocol would/needs to fit in is rather important. >=20 > Cheers, > Stefano >=20 >=20 > On Tue, Feb 1, 2011 at 3:47 PM, > > wrote: >=20 > Hello, >=20 > We have discussed the flow mobility solutions for Proxy MIP6 previously a= t > IETFs 78 and 79. > This is a consensus call for adopting this I-D: > draft-bernardos-netext-pmipv6-flowmob-02 > as the working group document. > I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt >=20 > The consensus call will expire on Feb 15th, 2011. Please indicate your > support or concerns in adopting this I-D as the WG baseline document on > the mailing list. >=20 > Please note that this I-D will serve as the baseline in the WG and will b= e > developed further based on input and feedback from WG members. >=20 > -Basavaraj >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > =20 > =20 > =20 > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-publi= c > information. Any use of this information by anyone other than the intende= d > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from y= our > system. Use, dissemination, distribution, or reproduction of this transmi= ssion > by unintended recipients is not authorized and may be unlawful. >=20 --B_3379612472_88458885 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmip= v6-flowmob as WG doc Hi Pierrick:

I agree with lot of points.

  • Yes, its all about handover execution. This is the k= ey point. A PBU message from the MN can be the first step towards activating= the handover process. Or a FMI trigger from the LMA, may itself be the pre-= trigger for PBU message from the MAG. At the end of the day, the LMA applies= the policy and provides the set of prefixes to the MAG. MAG will continue t= o behave as in 5213. The decision logic, or the granularity of the policy ru= le applicability on the LMA can be out of scope
  • Policy synchronization is an issue, for the case where t= he UE’s forwarding decision is based on the policy and not based on th= e ND messages from the attached interface. It is very well may be that, we h= ave the same issue for IFOM as well, IMO, but that’s beside the point = for now.  The policy activation on the UE, and the associated issues sh= ould be discussed in this context and as needed.
  • This draft should not deal with flow policies, how they = are applied and what granularity can be out of scope, IMO. These policies ne= ed not be carried in PMIP signaling place, unless we have MN-AR interface=20
  • I’m not clear on the policy management though, bef= ore we say, it can be separate thread. The whole approach seems to be out of= band at this point and not sure what can be specified on the PMIP signaling= plane with respect to policy.

Regards
Sri







On 2/3/11 7:35 AM, "pierri= ck.seite@orange-ftgroup.com" <pierrick.seite@orange-ftgroup.com> wrote:

Hello,
 
This is an interesting discussion, thanks for bringing the ANDSF issues on = the table. Effectively, mobility control, i.e. access selection, is a key po= int for an operator. From an operator point of view, criteria for selection = is not only RAT type or SSID; we can imagine plenty of other criteria. Diffe= rent mobility control models can be envisaged such as Network controlled or = terminal controlled and so on... For sure, in PMIP context, policies synchro= nization can be an issue and how decision made on the terminal can interact = with network managed mobility should be discussed. But, I don't think draft-= bernardos should go in this space. I think, we should clearly distinguish mo= bility functions. IMHO, draft-bernardos should not be expected to deal with = selection management, or mobility triggers, but only on the handover executi= on. In other words, the draft should assume that handover decision has been = made (how decision is made is out of scope) and, then, only focus on mechani= sm allowing the LMA to transfer flow(s). Although related, mobility decision= management, e.g. policy based, should be discussed in a separated thread.  
BR,
Pierrick
 

De : netext-bounces= @ietf.org [mailto:netext-bounce= s@ietf.org] De la part de Stefano Faccin
Envoyé : jeudi 3 février 2011 08:05
À : gerardog@qualcomm.com= ; sgundave@cisco.com; sfaccinstd@gmail.com
Cc : netext@ietf.org; Basavaraj.Patil@nokia.com
Objet : Re: [netext] Consensus call to adopt I-D:draft-bernardos-net= ext-pmipv6-flowmob as WG doc
Hello Sri,
>From a point of view of applicability of the solution, I must agree with Ge= rardo that assuming synchronization of policies is an issue of this solution= since it comes with a set of restrictions on how the solution can be applie= d.
Cheers,
Stefano

Stefano
Stefano M. Faccin

Standards Manager
Research In Motion
122 West John Carpenter Parkway
Irving, TX 75039
Internal: 820 63451
Desk: +1 972 910 3451
BlackBerry: +1 510 230 8422
sfaccin@rim.com
Time zone: PST (GMT -8)

From: Giaretta, Gerardo [mailto:gerardog@qualcomm.com]
Sent: Wednesday, February 02, 2011 11:13 PM
To: Sri Gundavelli <sgundave@cisco.c= om>; stefano faccin <sfaccinstd@gma= il.com>
Cc: netext@ietf.org <netext@ietf.org>; Bas= avaraj.Patil@nokia.com <Basavaraj= .Patil@nokia.com>
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-n= etext-pmipv6-flowmob as WG doc

Hi Sri,
 
There is no implicit assumption of synchronized policies. A basic example t= hat shows that there is no assumption is the following: ANDSF policies may b= e based also on location of the UE. For example the UE should prefer WLAN on= ly in a given location. When the UE is attached over WLAN there is no way fo= r the PDNGW/HA to verify the location of the UE and therefore to verify UE a= ctions based on policies.
 
The assumption on synchronization of policies is only applicable to this dr= aft and I think it is a wrong one.
 
Cheers
Gerardo
 

From: netext-bounces@ietf.org [mailt= o:netext-bounces@ietf.org] On Behalf Of Sri Gundavelli
Sent: Wednesday, February 02, 2011 6:50 PM
To: stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-n= etext-pmipv6-flowmob as WG doc
Hi Stefano,

One comment.

Agree with you there is no ANDSF interface to the network node, but the ass= umption of synchronized policies between the ANDSF server and the PDN GW/HA = is there, implicitly IMO. With out this assumption, I do not know, how the H= A can ever validate the flow mobility options received in the BU. If the ope= rator requires any control on enforcing a flow policy rule, the PDN GW/HA ne= eds to have synchronized policies, without which its always the client decis= ion. I’m not sure, operators in 3GPP would like that :)

No doubt, the lack of MN-AR interface is surely an issue for supporting com= plex flow policies. I realize the issues and I agree with you. But, the assu= mption of synchronized policies can offer some solution with some configurat= ion requirement on the HA (assuming there are no other issues). There are al= so the proposals on flow mirroring on the UE ..., requiring no flow policies= . I’ve not evaluated this, however. Folks can comment on this.

It is also to be noted, for some of the scenarios such, there is no flow po= licy interface needed. We can identify what scenarios create any configurati= on limitations on the HA and which one’s do not . As I’ve noted = earlier, this is surely an open issue, that we need to discuss in the WG.


Regards
Sri




 


On 2/2/11 9:08 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:
Sri,
thanks for the reply. Can you clarify in which system or scenario ANDSF is = available to network entities as well? There is no such availability in 3GPP= , and making such information available would require considerable architect= ural changes, therefore the applicability of this solution to what seems to = be the only realistic scenario hinges on 3GPP making considerable architectu= ral changes. I would therefore not be so hastily concluding that the ANDSF i= nformation is available to the LMA and underestimate what it would really ta= ke to make the solution applicable.

If we cannot guarantee that there is at least one realistic solution to hav= e the MNa nd LMA in synch, how do we expect that this solution is applicable= at all? In 3GPP there is no need to have such implicit assumption, be cause= 1) the MN is provided policies explicitly through the ANDSF, and 2) it is t= he MN and only the MN that makes IP flow mobility decisions and communicates= them explicitly (with well defined signalling) to the LMA, and therefore no= magic is needed. There is no need in 3GPP to have the ANDSF and PDN GW poli= cies synchronized, since the PDN GW does not use such policies.

Sri, in the end it is a matter of whether we develop a solution that will r= ely on some unknown magic to be deployed, or a solution that we know can be = deployed in at least one way because there are solutions to what I consider = major open issues.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli <sgundave@cisco.com> wrote:
Hi Stefano,

Thanks for the discussion.

As you say, the ANDSF policies are allowing the MN a.) to make the right ne= twork attachment decision and b.) make the access selection on a flow basis.= This same policy that is present in the ANDSF server, is available for the = network nodes as well. I’m not sure, with out this assumption the solu= tion can work for all currently listed cases. We clearly need the MN and the= LMA to be in synch with respect to the configured policy. How, that is done= , I guess we will not try to know.  I thought even in 3GPP, this is the= implied assumption ? But, this is for you to clarify. Not specifically for = IFOM where UE and PDN GW/HA are negotiating the flow policies, but generally= that the PDN GW and the ANDSF policy server will have synchronized policies= . The MAG and the LMA have the ability to carry this flow policy information= in signaling messages and influence the access selection. The policy is a o= paque object, with extensible formats, when carried in the signaling plane, = should allow the LMA/MAG to apply those access policies, while assuming MN i= s following the same rules. These policies can surely reflect the specific W= LAN access/operator specific rule. I’m surely with you, the lack of MN= -AR interface is surely an issue and I see that. But, we need to understand,= what are the limitations with the approach of  out of band policy inte= rfaces and what will be the solution limitations. If we need to tie the flow= movement at the prefix granularity and rely on the natural ND interface in = the form of RA PIO option, more like PDN offload in MAPCON, or at the granul= arity of a flow level, is open for discussion. I want to simplify this draft= for sure, we can surely discuss each of these issues on the WG draft.


Regards
Sri






On 2/1/11 8:29 PM, "stefano faccin" <sfaccinstd@gmail.com <htt= p://sfaccinstd@gmail.com> > wrote:
Sri,
thanks for the reply.

I'd like to comment on the "the flow policy decisions n= eed not be based on the specific WLAN network". Does it mean, as I beli= eve it does, that the current solution would not allow an operator deploying= such solution to decide to route flows over a specific WLAN or not dependin= g on which specific WLAN the MN is connected to? E.g. the operator or the en= tity in control of the decisions for the routing may want to direct certain = traffic always over WLANs that the operator deploys, and instead route only = some of the traffic over WLANs of roaming partners or of the MN user home. H= ow does this solution support that scenario if the LMA is not told specifica= lly which WLAN the MN is connected to? From a deployment point of view, I do= not believe we can afford to leave out this scenario. Please note that the = establishment of a security relationship between the MN and the MAG, and a s= pecific MAG identity, cannot guarantee that the LMA knows which specific WLA= N access network the MN is connected to. Assuming that would severely restri= ct the deployment scenarios.

As for the MN and the LMA being magically in synch, I am very concerned abo= ut a "glass ball" solution. You mention ANDSF defined by 3GPP as a= solution for this "out of band" delivery of policy. Fair enough, = however there is an issue with that. ANDSF is designed specific to be a MN-c= entric solution where policies are provisioned in the MN and the MN decides = which network technologies and access networks it needs to connect to, under= what conditions, and which IP traffic needs to be routed on such accesses. = No IP point of attachment in the network (i.e. the PDN GW in 3GPP that is th= e LMA in PMIPv6) is aware under any conditions of such policy. Therefore, ev= en if in order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF = would unfortunately not provide a solution unless the MN can communicate to = the MAG and the LMA the decisions the MN has taken based on the ANDSF polici= es.

I believe the key point here is that we need to understand how the solution= can be realistically applied to a real scenario, and that we need to ensure= that important and realistic deployment scenarios are not excluded by the s= olution.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli <sgundave@cisco.com <http://s= gundave@cisco.com> > wrote:
Hi Stefano:

These are valid points and some good comments. Let me share my thoughts.
Carlo’s draft is not assuming any new MN-AR interface. Its going with= the assumption there is established policy on the mobile and on the LMA, wh= ich allows the mobile to select the access network at a flow level granulari= ty, without requiring any explicit signaling between the MAG and the MN. To = large part this is all about out of band policy interface, such as ANDSF, to= wards the UE, leading to the assumption that magically the MN and the LMA ar= e in sync with respect to flow policies, access selection and they will make= the right forwarding decision. Secondly, the flow policy decisions need not= be based on the specific WLAN network, but it is implicitly driven by the M= AG – LMA security relation, where the MAG attachment to the WLAN netwo= rk transitively allows the LMA to make the flow policy decisions based on th= e MAG identity. If the WLAN network is not trusted, there is truly no MAG in= that network, where the LMA shares a security relation with that node.

There are still some open issues on this draft that needs to be discussed i= n the WG.  On the approaches to allow more a flow aggregate movement, t= hat is a discussion point. There are issues that we need to discuss, support= ing split link model, or eliminating some favorite brand of signaling messag= e (FMA) and riding on PBU/PBA and just with one FMI trigger, and on the aspe= cts around MN applying the flow policies by flow mirroring. We have no agree= ment on those issues yet.

Its just a base draft, for further discussion and resolving those issues. B= ut, hope that is not a stopper for base draft selection.


Sri






On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <htt= p://sfaccinstd@gmail.com>  <http://sfaccinstd@gmail.com> > wrote:
Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicate= to the network where the flows should be routed or for the LMA to receive s= omehow from somewhere some policies, the solution cannot really provide flow= mobility since there is no way to decide which flows are routed where. If w= e are thinking about a host-based solution, I have not yet seen a solution a= s to how the host can indicate to the MAG and ultimately to the MAG which fl= ows should be routed on each access. If we are relying on modifications of l= ayer 2 protocols, aren't we defining a solution that works only with some te= chnologies (since for other access technologies it is rather unrealistic to = modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-based= solution, can we hear of at least one example of a real-life scenario where= the LMA would receive such policies, and how such delivery would happen? Al= so, should there be a solution to have policies in the LMA, how does the LMA= actually decide to route flows on one access or the other? E.g., if some fl= ows need to be routed on certain WLAN networks, but shall not be routed on o= ther WLAN networks, how does the LMA know which specific WLAN network the ho= st is connected to? Perhaps I missed the ability for the MAG to know e.g. th= e WLAN SSID and provide it to the LMA, in which case I would appreciate if s= omebody could highlight to me where that is defined.

I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important. <= BR>
Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM,  <Basavaraj.Patil@nokia.com <http://Basavaraj.Patil@nokia.com>  <http://Basavaraj.Patil@nokia.com> > wrote:
Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= BR> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt<= /a>

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= BR> developed further based on input and feedback from WG members.

-Basavaraj

_______________________________________________
netext mailing list
netext@ietf.org <http://netext@ietf.org>  <http://netext@ietf.org>
https://www.ietf.org= /mailman/listinfo/netext
  
 
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor-= client or other applicable privileges), or constitute non-public information= . Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use, = dissemination, distribution, or reproduction of this transmission by uninten= ded recipients is not authorized and may be unlawful.

--B_3379612472_88458885-- From telemaco.melia@alcatel-lucent.com Fri Feb 4 01:46:48 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3567D3A68B7 for ; Fri, 4 Feb 2011 01:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.748 X-Spam-Level: X-Spam-Status: No, score=-5.748 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXnATnyf1RD4 for ; Fri, 4 Feb 2011 01:46:23 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 322FC3A68B8 for ; Fri, 4 Feb 2011 01:46:21 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p149jxG7018118 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 Feb 2011 10:49:36 +0100 Received: from FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com ([135.120.45.54]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 4 Feb 2011 10:49:11 +0100 From: "MELIA, TELEMACO (TELEMACO)" To: Stefano Faccin , Sri Gundavelli , "Giaretta, Gerardo" , stefano faccin Date: Fri, 4 Feb 2011 10:49:08 +0100 Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLwmpURzmRlysrlUidlexdQorGZJPuBh2AgAAR4ICAAAzJgIAACkaAgADJ5gCAAKKGAP//oT5wgAEesLCAAAq77oAAADZggAC0szA= Message-ID: <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CC7E@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> References: <680854867F7FD04BB9B06EB8ACA8D5AC05E1F0A3@XCH02DFW.rim.net> <680854867F7FD04BB9B06EB8ACA8D5AC05E1F0CB@XCH02DFW.rim.net> In-Reply-To: <680854867F7FD04BB9B06EB8ACA8D5AC05E1F0CB@XCH02DFW.rim.net> Accept-Language: en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_005_3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CC7EFRMRSSXCHMBSE_"; type="multipart/alternative" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 09:46:48 -0000 --_005_3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CC7EFRMRSSXCHMBSE_ Content-Type: multipart/alternative; boundary="_000_3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CC7EFRMRSSXCHMBSE_" --_000_3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CC7EFRMRSSXCHMBSE_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stefano, all, I believe the authors of the draft never intended to replicate all the feat= ures of the client based approach. In addition to this I fail to see why we should spend so much time in discu= ssing the WLAN ESSID issue. Of course we can debate about trusted/untrusted= access but I think this is orthogonal to the PMIP flow mobility discussion= . If not can you please explain? telemaco ________________________________ De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part de= Stefano Faccin Envoy=E9 : vendredi 4 f=E9vrier 2011 00:02 =C0 : Sri Gundavelli; Giaretta, Gerardo; stefano faccin Cc : netext@ietf.org; Basavaraj.Patil@nokia.com Objet : Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pm= ipv6-flowmob as WG doc Sri, I am glad to hear that you also think that the network-based flow mobility = solution cannot intrinsically provide all the features of the client-based = approach. I am also glad that you hear that access selection solutions in place today= are sci-fi. Why do you believe that an operator that wants e.g. to move th= e voice traffic and video streaming to the WLAN APs it deploys (because it = can offload them and can control QoS) may not want to move the same flows t= o a WLAN in a hotel where the user will get an awful user experience? Anoth= er example: policies may be configured by an enterprise in the device so th= at the enterprise will allow the MN to direct some traffic on certain WLAN = APs (e.g. the one the enterprise deploys) but not on other WLAN APs. I thin= k the per-access network scenarios are indeed more than realistic. Perhaps = we're trying to oversimplify the scenarios just to fit the solution in them= ? Stefano Faccin Standards Manager Research In Motion Corporation 5000 Riverside Drive Building 6, Brazos East, Ste. 100 Irving, Texas 75039 USA Office: (972) 910 3451 Internal: 820.63451 [cid:image001.jpg@01CBC458.F5EE4370]: (510) 230 8422 www.rim.com; www.blackberry.com [cid:image003.jpg@01CBC458.F5EE4370] P Consider the environment before printing. From: Sri Gundavelli [mailto:sgundave@cisco.com] Sent: Thursday, February 03, 2011 2:56 PM To: Stefano Faccin; Giaretta, Gerardo; stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-p= mipv6-flowmob as WG doc Hi Stefano, My point on the synchronized policy assumption still remains, as I've noted= in the other thread. Therefore, if we want to provide a protocol for network based flow mobility= to provide an alternative to existing solutions, we need to provide a solu= tion that realistically provides the same functionality. I will probably take a defensive stand on this. As I've stated before, I do= not believe network-based mobility approaches can match client based appro= aches 1:1, in every aspect. Its simply not possible, specially when we don'= t have the needed MN-AR interface argument, for carrying Attachment Prefere= nces. But, most of the features that are practical from deployment perspect= ive (unlike some of the complex flow mobility scenarios, complexity in the = order of science fiction moves :)), every thing else can be achieved over n= etwork-based approaches, with out any MN-AR interface. Hence, my argument t= o keep the specs simple As as for simplified policies versus what current solutions already provide= (e.g. per access network policy and not just per access technology), why s= hould we go ahead with a solution that brings us back in time wrt what we c= an provide to users and operators? Please note that even today (and not jus= t future releases of 3GPP or future IETF protocols) there are deployment sc= enarios where the decisions to choose or not whether to route traffic over = a certain WLAN is based on the specific WLAN (e.g. SSID) and not just on th= e fact that the MN is connected to WLAN. To large part, in the context of trusted non-3GPP access, basic flow mobili= ty functions can be supported. We can break this down and bring some of the= aspects around network ownership, cost parameters and tie the flow policy = rules to it. But, I don't think the goal is to support all such features. Regards Sri On 2/3/11 2:22 PM, "Stefano Faccin" wrote: Hi Sri, I need to agree with the Gerardo. You are making an assumption that is inco= rrect.Synchronizing policies between the MN and the LMA is not an easy and = scalable solution. I understand synchronizing policies between a MN and a p= olicy server that is the only repository for a given MN (i.e. one MN has it= s policy in a single policy server). Assuming that all the LMAs in a networ= k that the MN can be connected to have synchronized policies with the MN is= clearly not realistic. As as for simplified policies versus what current solutions already provide= (e.g. per access network policy and not just per access technology), why s= hould we go ahead with a solution that brings us back in time wrt what we c= an provide to users and operators? Please note that even today (and not jus= t future releases of 3GPP or future IETF protocols) there are deployment sc= enarios where the decisions to choose or not whether to route traffic over = a certain WLAN is based on the specific WLAN (e.g. SSID) and not just on th= e fact that the MN is connected to WLAN. Therefore, if we want to provide a protocol for network based flow mobility= to provide an alternative to existing solutions, we need to provide a solu= tion that realistically provides the same functionality. Cheers, Stefano Faccin Standards ManagerResearch In Motion Corporation 5000 Riverside Drive Building 6, Brazos East, Ste. 100Irving, Texas 75039 USA Office: (972) 910 3451 Internal: 820.63451[cid:image001.jpg@01CBC458.F5EE4= 370]: (510) 230 8422www.rim.com ; www.blackberry.com [cid:image003.jpg@01CBC458.F5EE4370] P Consider the environment before printing. From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of= Giaretta, Gerardo Sent: Wednesday, February 02, 2011 9:14 PM To: Sri Gundavelli; stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-p= mipv6-flowmob as WG doc Hi Sri, There is no implicit assumption of synchronized policies. A basic example t= hat shows that there is no assumption is the following: ANDSF policies may = be based also on location of the UE. For example the UE should prefer WLAN = only in a given location. When the UE is attached over WLAN there is no way= for the PDNGW/HA to verify the location of the UE and therefore to verify = UE actions based on policies. The assumption on synchronization of policies is only applicable to this dr= aft and I think it is a wrong one. Cheers Gerardo From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of= Sri Gundavelli Sent: Wednesday, February 02, 2011 6:50 PM To: stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-p= mipv6-flowmob as WG doc Hi Stefano, One comment. Agree with you there is no ANDSF interface to the network node, but the ass= umption of synchronized policies between the ANDSF server and the PDN GW/HA= is there, implicitly IMO. With out this assumption, I do not know, how the= HA can ever validate the flow mobility options received in the BU. If the = operator requires any control on enforcing a flow policy rule, the PDN GW/H= A needs to have synchronized policies, without which its always the client = decision. I'm not sure, operators in 3GPP would like that :) No doubt, the lack of MN-AR interface is surely an issue for supporting com= plex flow policies. I realize the issues and I agree with you. But, the ass= umption of synchronized policies can offer some solution with some configur= ation requirement on the HA (assuming there are no other issues). There are= also the proposals on flow mirroring on the UE ..., requiring no flow poli= cies. I've not evaluated this, however. Folks can comment on this. It is also to be noted, for some of the scenarios such, there is no flow po= licy interface needed. We can identify what scenarios create any configurat= ion limitations on the HA and which one's do not . As I've noted earlier, t= his is surely an open issue, that we need to discuss in the WG. Regards Sri On 2/2/11 9:08 AM, "stefano faccin" wrote: Sri, thanks for the reply. Can you clarify in which system or scenario ANDSF is = available to network entities as well? There is no such availability in 3GP= P, and making such information available would require considerable archite= ctural changes, therefore the applicability of this solution to what seems = to be the only realistic scenario hinges on 3GPP making considerable archit= ectural changes. I would therefore not be so hastily concluding that the AN= DSF information is available to the LMA and underestimate what it would rea= lly take to make the solution applicable. If we cannot guarantee that there is at least one realistic solution to hav= e the MNa nd LMA in synch, how do we expect that this solution is applicabl= e at all? In 3GPP there is no need to have such implicit assumption, be cau= se 1) the MN is provided policies explicitly through the ANDSF, and 2) it i= s the MN and only the MN that makes IP flow mobility decisions and communic= ates them explicitly (with well defined signalling) to the LMA, and therefo= re no magic is needed. There is no need in 3GPP to have the ANDSF and PDN G= W policies synchronized, since the PDN GW does not use such policies. Sri, in the end it is a matter of whether we develop a solution that will r= ely on some unknown magic to be deployed, or a solution that we know can be= deployed in at least one way because there are solutions to what I conside= r major open issues. Cheers, Stefano On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli wrote: Hi Stefano, Thanks for the discussion. As you say, the ANDSF policies are allowing the MN a.) to make the right ne= twork attachment decision and b.) make the access selection on a flow basis= . This same policy that is present in the ANDSF server, is available for th= e network nodes as well. I'm not sure, with out this assumption the solutio= n can work for all currently listed cases. We clearly need the MN and the L= MA to be in synch with respect to the configured policy. How, that is done,= I guess we will not try to know. I thought even in 3GPP, this is the impl= ied assumption ? But, this is for you to clarify. Not specifically for IFOM= where UE and PDN GW/HA are negotiating the flow policies, but generally th= at the PDN GW and the ANDSF policy server will have synchronized policies. = The MAG and the LMA have the ability to carry this flow policy information = in signaling messages and influence the access selection. The policy is a o= paque object, with extensible formats, when carried in the signaling plane,= should allow the LMA/MAG to apply those access policies, while assuming MN= is following the same rules. These policies can surely reflect the specifi= c WLAN access/operator specific rule. I'm surely with you, the lack of MN-A= R interface is surely an issue and I see that. But, we need to understand, = what are the limitations with the approach of out of band policy interface= s and what will be the solution limitations. If we need to tie the flow mov= ement at the prefix granularity and rely on the natural ND interface in the= form of RA PIO option, more like PDN offload in MAPCON, or at the granular= ity of a flow level, is open for discussion. I want to simplify this draft = for sure, we can surely discuss each of these issues on the WG draft. Regards Sri On 2/1/11 8:29 PM, "stefano faccin" > wrote: Sri, thanks for the reply. I'd like to comment on the "the flow policy decisions need not be based on = the specific WLAN network". Does it mean, as I believe it does, that the cu= rrent solution would not allow an operator deploying such solution to decid= e to route flows over a specific WLAN or not depending on which specific WL= AN the MN is connected to? E.g. the operator or the entity in control of th= e decisions for the routing may want to direct certain traffic always over = WLANs that the operator deploys, and instead route only some of the traffic= over WLANs of roaming partners or of the MN user home. How does this solut= ion support that scenario if the LMA is not told specifically which WLAN th= e MN is connected to? From a deployment point of view, I do not believe we = can afford to leave out this scenario. Please note that the establishment o= f a security relationship between the MN and the MAG, and a specific MAG id= entity, cannot guarantee that the LMA knows which specific WLAN access netw= ork the MN is connected to. Assuming that would severely restrict the deplo= yment scenarios. As for the MN and the LMA being magically in synch, I am very concerned abo= ut a "glass ball" solution. You mention ANDSF defined by 3GPP as a solution= for this "out of band" delivery of policy. Fair enough, however there is a= n issue with that. ANDSF is designed specific to be a MN-centric solution w= here policies are provisioned in the MN and the MN decides which network te= chnologies and access networks it needs to connect to, under what condition= s, and which IP traffic needs to be routed on such accesses. No IP point of= attachment in the network (i.e. the PDN GW in 3GPP that is the LMA in PMIP= v6) is aware under any conditions of such policy. Therefore, even if in ord= er to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would unfor= tunately not provide a solution unless the MN can communicate to the MAG an= d the LMA the decisions the MN has taken based on the ANDSF policies. I believe the key point here is that we need to understand how the solution= can be realistically applied to a real scenario, and that we need to ensur= e that important and realistic deployment scenarios are not excluded by the= solution. Cheers, Stefano On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli > wrote: Hi Stefano: These are valid points and some good comments. Let me share my thoughts. Carlo's draft is not assuming any new MN-AR interface. Its going with the a= ssumption there is established policy on the mobile and on the LMA, which a= llows the mobile to select the access network at a flow level granularity, = without requiring any explicit signaling between the MAG and the MN. To lar= ge part this is all about out of band policy interface, such as ANDSF, towa= rds the UE, leading to the assumption that magically the MN and the LMA are= in sync with respect to flow policies, access selection and they will make= the right forwarding decision. Secondly, the flow policy decisions need no= t be based on the specific WLAN network, but it is implicitly driven by the= MAG - LMA security relation, where the MAG attachment to the WLAN network = transitively allows the LMA to make the flow policy decisions based on the = MAG identity. If the WLAN network is not trusted, there is truly no MAG in = that network, where the LMA shares a security relation with that node. There are still some open issues on this draft that needs to be discussed i= n the WG. On the approaches to allow more a flow aggregate movement, that = is a discussion point. There are issues that we need to discuss, supporting= split link model, or eliminating some favorite brand of signaling message = (FMA) and riding on PBU/PBA and just with one FMI trigger, and on the aspec= ts around MN applying the flow policies by flow mirroring. We have no agree= ment on those issues yet. Its just a base draft, for further discussion and resolving those issues. B= ut, hope that is not a stopper for base draft selection. Sri On 2/1/11 6:39 PM, "stefano faccin" > wrote: Raj, thanks for the email. I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere). I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability. In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicat= e to the network where the flows should be routed or for the LMA to receive= somehow from somewhere some policies, the solution cannot really provide f= low mobility since there is no way to decide which flows are routed where. = If we are thinking about a host-based solution, I have not yet seen a solut= ion as to how the host can indicate to the MAG and ultimately to the MAG wh= ich flows should be routed on each access. If we are relying on modificatio= ns of layer 2 protocols, aren't we defining a solution that works only with= some technologies (since for other access technologies it is rather unreal= istic to modify L2 for IP flow mobility purposes)? If we are thinking of an= LMA-based solution, can we hear of at least one example of a real-life sce= nario where the LMA would receive such policies, and how such delivery woul= d happen? Also, should there be a solution to have policies in the LMA, how= does the LMA actually decide to route flows on one access or the other? E.= g., if some flows need to be routed on certain WLAN networks, but shall not= be routed on other WLAN networks, how does the LMA know which specific WLA= N network the host is connected to? Perhaps I missed the ability for the MA= G to know e.g. the WLAN SSID and provide it to the LMA, in which case I wou= ld appreciate if somebody could highlight to me where that is defined. I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important. Cheers, Stefano On Tue, Feb 1, 2011 at 3:47 PM, > wrote: Hello, We have discussed the flow mobility solutions for Proxy MIP6 previously at IETFs 78 and 79. This is a consensus call for adopting this I-D: draft-bernardos-netext-pmipv6-flowmob-02 as the working group document. I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt The consensus call will expire on Feb 15th, 2011. Please indicate your support or concerns in adopting this I-D as the WG baseline document on the mailing list. Please note that this I-D will serve as the baseline in the WG and will be developed further based on input and feedback from WG members. -Basavaraj _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --_000_3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CC7EFRMRSSXCHMBSE_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

Stefano, al= l,

 =

I believe t= he authors of the draft never intended to replicate all the features of the cl= ient based approach.

 =

In addition= to this I fail to see why we should spend so much time in discussing the WLAN ESSID issue. Of course we can debate about trusted/untrusted access but I t= hink this is orthogonal to the PMIP flow mobility discussion. If not can you ple= ase explain?

 =

telemaco

De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part de Stefano Faccin
Envoy=E9 : vendredi 4 f= =E9vrier 2011 00:02
=C0 : Sri Gundavelli; G= iaretta, Gerardo; stefano faccin
Cc : netext@ietf.org; Basavaraj.Patil@nokia.com
Objet : Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG do= c

 

Sri,

I am glad to h= ear that you also think that the network-based flow mobility solution cannot intrinsically provide all the features of the client-based approach. <= /o:p>

 

I am also glad= that you hear that access selection solutions in place today are sci-fi. Why do = you believe that an operator that wants e.g. to move the voice traffic and vide= o streaming to the WLAN APs it deploys (because it can offload them and can c= ontrol QoS) may not want to move the same flows to a WLAN in a hotel where the use= r will get an awful user experience? Another example: policies may be configu= red by an enterprise in the device so that the enterprise will allow the MN to direct some traffic on certain WLAN APs (e.g. the one the enterprise deploy= s) but not on other WLAN APs. I think the per-access network scenarios are ind= eed more than realistic. Perhaps we’re trying to oversimplify the scenari= os just to fit the solution in them?

 

Stefano Facc= in

 <= /o:p>

Standards Ma= nager

Research In Motion Corporation
5000 Riverside Drive
Building 6, Brazos East, Ste. 100

Irving, Texas = 75039 USA
Office: (972) 910 3451 

Internal: 820.= 63451

3DUntitled-1: (510) 230 8422

www.rim.com; www.blackberry.com

 

3D"cid:image004.png@01CB49EA.87D92140"=

 

P Consider the environment before printing.

 

From:= Sri Gundavelli [mailto:sgundave@cisco.com]
Sent: Thursday, February 03,= 2011 2:56 PM
To: Stefano Faccin; Giaretta= , Gerardo; stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consen= sus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

 

Hi Stefano,

My point on the synchronized policy assumption still remains, as I’ve noted in the other thread.

Therefore, if we want= to provide a protocol for network based flow mobility to provide an alternativ= e to existing solutions, we need to provide a solution that realistically provid= es the same functionality.

I will probably take a defensive stand on this. As I’ve stated before= , I do not believe network-based mobility approaches can match client based approaches 1:1, in every aspect. Its simply not possible, specially when we don’t have the needed MN-AR interface argument, for carrying Attachme= nt Preferences. But, most of the features that are practical from deployment perspective (unlike some of the complex flow mobility scenarios, complexity= in the order of science fiction moves :)), every thing else can be achieved ov= er network-based approaches, with out any MN-AR interface. Hence, my argument = to keep the specs simple
 
As as for simplified = policies versus what current solutions already provide (e.g. per access network poli= cy and not just per access technology), why should we go ahead with a solution that brings us back in time wrt what we can provide to users and operators? Please note that even today (and not just future releases of 3GPP or future IETF protocols) there are deployment scenarios where the decisions t= o choose or not whether to route traffic over a certain WLAN is based on the specific WLAN (e.g. SSID) and not just on the fact that the MN is connected= to WLAN.

To large part, in the context of trusted non-3GPP access, basic flow mobili= ty functions can be supported. We can break this down and bring some of the aspects around network ownership, cost parameters and tie the flow policy r= ules to it. But, I don’t think the goal is to support all such features.


Regards
Sri



On 2/3/11 2:22 PM, "Stefano Faccin" <sfaccin@rim.com> wrote:

Hi Sri,
I need to agree with the Gerardo. You are making an assumption that is incorrect.Synchronizing policies between the MN and the LMA is not an easy = and scalable solution. I understand synchronizing policies between a MN and a policy server that is the only repository for a given MN (i.e. one MN has i= ts policy in a single policy server). Assuming that all the LMAs in a network = that the MN can be connected to have synchronized policies with the MN is clearl= y not realistic.

As as for simplified policies versus what current solutions already provide (e.g. per access network policy and not just per access technology), why sh= ould we go ahead with a solution that brings us back in time wrt what we can pro= vide to users and operators? Please note that even today (and not just fu= ture releases of 3GPP or future IETF protocols) there are deployment scenarios w= here the decisions to choose or not whether to route traffic over a certain WLAN= is based on the specific WLAN (e.g. SSID) and not just on the fact that the MN= is connected to WLAN.
 
Therefore, if we want to provide a protocol for network based flow mobility= to provide an alternative to existing solutions, we need to provide a solution that realistically provides the same functionality.
 
Cheers,
 
Stefano Faccin Standards ManagerResearch In Motion Corporation
5000 Riverside Drive
Building 6, Brazos East, Ste. 100Irving, Texas 75039 USA
Office: (972) 910 3451  Internal: 820.63451= : (510) 230 8422www.rim.com <outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D41= 49BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1= BEA0000/www.rim.com> ; www.blackberry.com <outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F0= 6753D40D4149BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3= E0000006F1BEA0000/www.blackberry.com>
= <http://www.blackber= ry.com/>

P Consider the environment before printing.


From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org]= On Behalf Of Giaretta, Gerardo
Sent: Wednesday, February 02= , 2011 9:14 PM
To: Sri Gundavelli; stefano = faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consen= sus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

Hi Sri,
 
There is no implicit assumption of synchronized policies. A basic example t= hat shows that there is no assumption is the following: ANDSF policies may be b= ased also on location of the UE. For example the UE should prefer WLAN only in a given location. When the UE is attached over WLAN there is no way for the PDNGW/HA to verify the location of the UE and therefore to verify UE action= s based on policies.
 
The assumption on synchronization of policies is only applicable to this dr= aft and I think it is a wrong one.
 
Cheers
Gerardo
 

From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org]= On Behalf Of Sri Gundavelli
Sent: Wednesday, February 02= , 2011 6:50 PM
To: stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consen= sus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

Hi Stefano,

One comment.

Agree with you there is no ANDSF interface to the network node, but the assumption of synchronized policies between the ANDSF server and the PDN GW= /HA is there, implicitly IMO. With out this assumption, I do not know, how the = HA can ever validate the flow mobility options received in the BU. If the oper= ator requires any control on enforcing a flow policy rule, the PDN GW/HA needs t= o have synchronized policies, without which its always the client decision. I’m not sure, operators in 3GPP would like that :)

No doubt, the lack of MN-AR interface is surely an issue for supporting com= plex flow policies. I realize the issues and I agree with you. But, the assumpti= on of synchronized policies can offer some solution with some configuration requirement on the HA (assuming there are no other issues). There are also = the proposals on flow mirroring on the UE ..., requiring no flow policies. I’ve not evaluated this, however. Folks can comment on this.

It is also to be noted, for some of the scenarios such, there is no flow po= licy interface needed. We can identify what scenarios create any configuration limitations on the HA and which one’s do not . As I’ve noted earlier, this is surely an open issue, that we need to discuss in the WG. <= br>


Regards
Sri




 


On 2/2/11 9:08 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:
Sri,
thanks for the reply. Can you clarify in which system or scenario ANDSF is available to network entities as well? There is no such availability in 3GP= P, and making such information available would require considerable architectu= ral changes, therefore the applicability of this solution to what seems to be t= he only realistic scenario hinges on 3GPP making considerable architectural changes. I would therefore not be so hastily concluding that the ANDSF information is available to the LMA and underestimate what it would really = take to make the solution applicable.

If we cannot guarantee that there is at least one realistic solution to hav= e the MNa nd LMA in synch, how do we expect that this solution is applicable = at all? In 3GPP there is no need to have such implicit assumption, be cause 1)= the MN is provided policies explicitly through the ANDSF, and 2) it is the MN a= nd only the MN that makes IP flow mobility decisions and communicates them explicitly (with well defined signalling) to the LMA, and therefore no magi= c is needed. There is no need in 3GPP to have the ANDSF and PDN GW policies synchronized, since the PDN GW does not use such policies.

Sri, in the end it is a matter of whether we develop a solution that will r= ely on some unknown magic to be deployed, or a solution that we know can be dep= loyed in at least one way because there are solutions to what I consider major op= en issues.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli <sgundave@cisco.com> wrote:
Hi Stefano,

Thanks for the discussion.

As you say, the ANDSF policies are allowing the MN a.) to make the right network attachment decision and b.) make the access selection on a flow bas= is. This same policy that is present in the ANDSF server, is available for the network nodes as well. I’m not sure, with out this assumption the solution can work for all currently listed cases. We clearly need the MN an= d the LMA to be in synch with respect to the configured policy. How, that is done, I guess we will not try to know.  I thought even in 3GPP, this i= s the implied assumption ? But, this is for you to clarify. Not specifically = for IFOM where UE and PDN GW/HA are negotiating the flow policies, but generall= y that the PDN GW and the ANDSF policy server will have synchronized policies= . The MAG and the LMA have the ability to carry this flow policy information = in signaling messages and influence the access selection. The policy is a opaq= ue object, with extensible formats, when carried in the signaling plane, shoul= d allow the LMA/MAG to apply those access policies, while assuming MN is following the same rules. These policies can surely reflect the specific WL= AN access/operator specific rule. I’m surely with you, the lack of MN-AR interface is surely an issue and I see that. But, we need to understand, wh= at are the limitations with the approach of  out of band policy interface= s and what will be the solution limitations. If we need to tie the flow movem= ent at the prefix granularity and rely on the natural ND interface in the form = of RA PIO option, more like PDN offload in MAPCON, or at the granularity of a = flow level, is open for discussion. I want to simplify this draft for sure, we c= an surely discuss each of these issues on the WG draft.


Regards
Sri






On 2/1/11 8:29 PM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com= > > wrote:
Sri,
thanks for the reply.

I'd like to comment on the "the flow policy decisions need not be based on the specific WLAN network". Does it mea= n, as I believe it does, that the current solution would not allow an operator deploying such solution to decide to route flows over a specific WLAN or no= t depending on which specific WLAN the MN is connected to? E.g. the operator = or the entity in control of the decisions for the routing may want to direct certa= in traffic always over WLANs that the operator deploys, and instead route only some of the traffic over WLANs of roaming partners or of the MN user home. = How does this solution support that scenario if the LMA is not told specificall= y which WLAN the MN is connected to? From a deployment point of view, I do no= t believe we can afford to leave out this scenario. Please note that the establishment of a security relationship between the MN and the MAG, and a specific MAG identity, cannot guarantee that the LMA knows which specific W= LAN access network the MN is connected to. Assuming that would severely restric= t the deployment scenarios.

As for the MN and the LMA being magically in synch, I am very concerned abo= ut a "glass ball" solution. You mention ANDSF defined by 3GPP as a solution for this "out of band" delivery of policy. Fair enough, however there is an issue with that. ANDSF is designed specific to be a MN-centric solution where policies are provisioned in the MN and the MN dec= ides which network technologies and access networks it needs to connect to, unde= r what conditions, and which IP traffic needs to be routed on such accesses. = No IP point of attachment in the network (i.e. the PDN GW in 3GPP that is the = LMA in PMIPv6) is aware under any conditions of such policy. Therefore, even if= in order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would unfortunately not provide a solution unless the MN can communicate to the M= AG and the LMA the decisions the MN has taken based on the ANDSF policies.

I believe the key point here is that we need to understand how the solution= can be realistically applied to a real scenario, and that we need to ensure tha= t important and realistic deployment scenarios are not excluded by the soluti= on.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli <sgundave@cisco.com <http://sgundave@cisco.com>= > wrote:
Hi Stefano:

These are valid points and some good comments. Let me share my thoughts.
Carlo’s draft is not assuming any new MN-AR interface. Its going with= the assumption there is established policy on the mobile and on the LMA, which allows the mobile to select the access network at a flow level granularity, without requiring any explicit signaling between the MAG and the MN. To lar= ge part this is all about out of band policy interface, such as ANDSF, towards= the UE, leading to the assumption that magically the MN and the LMA are in sync with respect to flow policies, access selection and they will make the righ= t forwarding decision. Secondly, the flow policy decisions need not be based = on the specific WLAN network, but it is implicitly driven by the MAG – L= MA security relation, where the MAG attachment to the WLAN network transitivel= y allows the LMA to make the flow policy decisions based on the MAG identity.= If the WLAN network is not trusted, there is truly no MAG in that network, whe= re the LMA shares a security relation with that node.

There are still some open issues on this draft that needs to be discussed i= n the WG.  On the approaches to allow more a flow aggregate movement, th= at is a discussion point. There are issues that we need to discuss, supporting split link model, or eliminating some favorite brand of signaling message (= FMA) and riding on PBU/PBA and just with one FMI trigger, and on the aspects aro= und MN applying the flow policies by flow mirroring. We have no agreement on th= ose issues yet.

Its just a base draft, for further discussion and resolving those issues. B= ut, hope that is not a stopper for base draft selection.


Sri






On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com= >  <http://sfaccinstd@gmail.c= om> > wrote:
Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered before (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicate to = the network where the flows should be routed or for the LMA to receive somehow = from somewhere some policies, the solution cannot really provide flow mobility s= ince there is no way to decide which flows are routed where. If we are thinking about a host-based solution, I have not yet seen a solution as to how the h= ost can indicate to the MAG and ultimately to the MAG which flows should be rou= ted on each access. If we are relying on modifications of layer 2 protocols, ar= en't we defining a solution that works only with some technologies (since for ot= her access technologies it is rather unrealistic to modify L2 for IP flow mobil= ity purposes)? If we are thinking of an LMA-based solution, can we hear of at l= east one example of a real-life scenario where the LMA would receive such polici= es, and how such delivery would happen? Also, should there be a solution to hav= e policies in the LMA, how does the LMA actually decide to route flows on one access or the other? E.g., if some flows need to be routed on certain WLAN networks, but shall not be routed on other WLAN networks, how does the LMA = know which specific WLAN network the host is connected to? Perhaps I missed the ability for the MAG to know e.g. the WLAN SSID and provide it to the LMA, i= n which case I would appreciate if somebody could highlight to me where that = is defined.

I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important.

Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM,  <Basavaraj.Patil@nokia.com <http://Basavaraj.Patil@nok= ia.com>  <http://Basavaraj.Pat= il@nokia.com> > wrote:

Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= br> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt
The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= br> developed further based on input and feedback from WG members.

-Basavaraj

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

 
 
------------------------------------------------------= ---------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from you= r system. Use, dissemination, distribution, or reproduction of this transmiss= ion by unintended recipients is not authorized and may be unlawful.

------------------------------------------------= ---------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from you= r system. Use, dissemination, distribution, or reproduction of this transmiss= ion by unintended recipients is not authorized and may be unlawful. =

--_000_3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CC7EFRMRSSXCHMBSE_-- --_005_3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CC7EFRMRSSXCHMBSE_ Content-Type: image/jpeg; name="image003.jpg" Content-Description: image003.jpg Content-Disposition: inline; filename="image003.jpg"; size=2232; creation-date="Fri, 04 Feb 2011 10:49:09 GMT"; modification-date="Fri, 04 Feb 2011 10:49:09 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAA+AIoDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDxmiii gAooooAKKKkt08ydE9TQNK7sXRpalQTKQSORto/spf8Ansf++a0KOKZ7f1Sj2M/+yl/57H/vmg6U McTH/vmtDiljQyypGvV2Cj8aTsH1Sj2MeXT5oxlcOB6VVr0L/hFVz/x+t/37/wDr1QvfBcZkEgvW G7r+67/nXH9dofzfmcdfCqK5oHGUV1J8FqR8t+c+8X/16zr/AMMX1lG0qFLiNeSY85A9wa0hiqM3 ZSOJwkuhj0UUV0EBRRRQAqqzsFUZZjgD1NbvirwZrHg6a2i1aOIfaULxtE+4cYyPqMj86x7P/j9g /wCui/zr179oP/WaB9Lj/wBp0AeN0V6Z8I9O1b7Pqup6fZ6PPGuyJn1ORlC4yx24U+2c47VdxrNp 8KrzUjpnh9bXU3klySwnHmORhE27eOwB6CgDyu0tZb68gtIAGlnkWNATjLMcD9TW/q3hLU/CeuLY 6osfmGHzUaJtysCccHjvW7faJ4T0XxL4fTQNYur65fUIfOSaIqFXeMHO0d+3P+PZfEjQrrxF8Q9L 0604ea0AZyOI0Dksx+n88UG2Ht7RN7I4aw8JaxqWgXOt28KfY7bO4s+GfHXaO+K2NP8AhZ4j1Kzj u4ms44pRuTzZGBYeuNp4rrfHWq22i6fY+C9JXYpjBnAPKwqMhT7sRk/j6119zY6jfeH9Pi0zUDYy qkbNIFzuXZjH5kH8KylNqVl0R3yxFTkUtk3p6Hjms/DnW9ChjmvJbMxyNsDRyM2DjOD8o9KqaT4e uP7UgZpYiqHeQM9vw+ldd4oh1W01FLPVNRa9KJvQ5OAD7djxU+i6HNJbf2gkqeW8JPOcrhiG4742 j/voV5mIxNb3owR2wklSUpu9+xV/s+X++n61VvLO4EYxHuAOTt5rrbjS4RczCGdxFCzhwY8sAqhu Ofm4PtVe6sore1aTzJGkDxhcptGGTdzzwa8Zxrxu5LRGTnCa5b7nE0o4PHauo1Hw6JENyZDGETzJ GSIsWQRhztGfmPOKzX8PyLMEE2VJb5jGRhRCJQWH8JwcEdjmuiNKclexwycYu1zyvxFapaazMkYC o+HCjtkc/rmsyu8Hhy312C61eWd2M9tK1miJ8g8t0jDO+eOWJ246c5GQKydR8PR+HriK7aN9Ttkl lhnhngeD548KxGCTsyww2RzwQOlfS0rqnHm3scMt9DmaKfO8ck8jxRCGNmJWMEkIM8DJ5OKZWgh8 EgiuI5CCQjhsD2NfRvirwzoPxMtdNvU10RQwK5jaEqd2/aec9CNvSvm+lDMOjEfQ0Adh8QvB1l4M vLS3sNY+3C5RmeM4DRYxgnB6HJx9DTtQ8TeFItK0oaH4eeHVLGSKSS6uG+WQoOcqGOctz2rjCSep zRQB1974+v8AxH4s0bVNb8hI9PnjP7mMgBd4LHuT0r3XXvEXh/QLGfxRJNBPK9uIoCkgZphksqL7 EnJ+mT0r5boycAZ4HSgDtNJ1W61/WNQ1O7+aeQFnbPG5jwB6AAYHsK9wEMHibwxp62urSWZjCMzQ ybWBCFShwR3P6V4d4Sh8vSnlI5lkPPsBj/GtzAzXk1a/LWldXWx7UKUqtKDbs0dL4p8PQ6EkMy6o byWdyGV/v9M7s5Ofx9az9P1OO1tTE8soyT8q5IAOMj8cc1l4oxXBWUamysjrgpKPLJ3N7+3Yg+8X FwG3btw3Zz65z196G1yFg26e4bdjcG3HdjpnnnFYOKSub6vHux8iN268TLHZAIZgLdCyFPkI465z kH6V5hqfi7VL+KaBLiaCC4OZkWZiZv8AfOfm/Gt3xHfrZ6W8YP724GxR7dzXC17WAw8Yxc38rnk4 2SUlGJZi1K/gs5LOK9uI7aU5eFJWCMenK5wadPq2pXRJuNQupiYhCfMmZsxgghOT93IBx04FVKK9 Q88KKKKACiiigAooooAKKKKAPQ9JiW20i1i3KCIwx5HU8/1q3uX++v8A30K8x3H1oyfU158sDzNv mPSjj+VJKJ6duX++v/fQo3r/AH1/76FeY5PqaMn1NT9QX8xX9of3fxPSZb21gGZbqFMerism+8V2 VupW1BuZOxwVUf1NcZmgnNaQwNNfE7mc8fNq0VYnvL2e+uDPcSF3P5Aeg9qgoortSSVkcDbbuwoo opiCiiigD//Z --_005_3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CC7EFRMRSSXCHMBSE_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=722; creation-date="Fri, 04 Feb 2011 10:49:09 GMT"; modification-date="Fri, 04 Feb 2011 10:49:09 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAKAA4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDSu9Nv V0vVpbjQL2KfU7xR5T6qqmRclsrnhecDFbGl6hqL69Noem63ZRQ6faops5Y2mmiYBQdz8BuSR1qD 4pxpLdeHo5UV0N2cqwyD93tXexW0ELtJFBGjv95lQAt9T3oA/9k= --_005_3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CC7EFRMRSSXCHMBSE_-- From telemaco.melia@alcatel-lucent.com Fri Feb 4 01:54:24 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E89043A68CB for ; Fri, 4 Feb 2011 01:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.148 X-Spam-Level: X-Spam-Status: No, score=-6.148 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uf1y0I0B7Q28 for ; Fri, 4 Feb 2011 01:54:05 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 05D793A68A8 for ; Fri, 4 Feb 2011 01:54:02 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p149vDxs031218 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 Feb 2011 10:57:19 +0100 Received: from FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com ([135.120.45.54]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 4 Feb 2011 10:56:57 +0100 From: "MELIA, TELEMACO (TELEMACO)" To: Rajeev Koodli , "Giaretta, Gerardo" , Sri Gundavelli , stefano faccin Date: Fri, 4 Feb 2011 10:56:56 +0100 Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLwmpURzmRlysrlUidlexdQorGZJPuBh2AgAAR4ICAAAzJgIAACkaAgADJ5gCAAKKGAP//oT5wgAEoMGn///x5AIAAF08JgACl8zA= Message-ID: <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CC85@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CC85FRMRSSXCHMBSE_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 09:54:25 -0000 --_000_3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CC85FRMRSSXCHMBSE_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, it would help. telemaco ________________________________ De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part de= Rajeev Koodli Envoy=E9 : vendredi 4 f=E9vrier 2011 01:02 =C0 : Giaretta, Gerardo; Sri Gundavelli; stefano faccin Cc : netext@ietf.org; Basavaraj.Patil@nokia.com Objet : Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pm= ipv6-flowmob as WG doc Hi, I am asking if you could show how the propagation of SSID/ULI from the MN i= s considered reliable enough for the network to act on. That would help us = understand what we need to do here to address your "flag". Thanks, -Rajeev On 2/3/11 2:43 PM, "Giaretta, Gerardo" wrote: Hi Rajeev, Not sure I understand what you are asking me. My comment was mainly referre= d to synchronization of policies which is an assumption not correct in my o= pinion. Based on the current policy model adopted by 3GPP, the only way I can think= of to make the system working is to replicate the behavior of RFC 6089 whe= re the MN initiates the flow movement. The assumption on synchronization of policies may however be considered acc= eptable in other SDOs or even in 3GPP in future. I am just raising an appli= cability flag to the group (actually the flag was initially raised by Stefa= no :)) Gerardo From: Rajeev Koodli [mailto:rkoodli@cisco.com] Sent: Thursday, February 03, 2011 2:51 PM To: Giaretta, Gerardo; Sri Gundavelli; stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-p= mipv6-flowmob as WG doc Hi Gerardo, Okay, so let's agree that the current version of the draft does not have SS= ID/ULI propagation to the LMA. Do you care to suggest how the network deems such an information from the M= N trustworthy? I am sure you agree if we could have good input, we could design protocols = accordingly. You will also probably agree that's much better than just arguing about "it= does not work in today's 3GPP deployment". Regards, -Rajeev On 2/2/11 9:13 PM, "Giaretta, Gerardo" wrote: Hi Sri, There is no implicit assumption of synchronized policies. A basic example t= hat shows that there is no assumption is the following: ANDSF policies may = be based also on location of the UE. For example the UE should prefer WLAN = only in a given location. When the UE is attached over WLAN there is no way= for the PDNGW/HA to verify the location of the UE and therefore to verify = UE actions based on policies. The assumption on synchronization of policies is only applicable to this dr= aft and I think it is a wrong one. Cheers Gerardo From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of= Sri Gundavelli Sent: Wednesday, February 02, 2011 6:50 PM To: stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-p= mipv6-flowmob as WG doc Hi Stefano, One comment. Agree with you there is no ANDSF interface to the network node, but the ass= umption of synchronized policies between the ANDSF server and the PDN GW/HA= is there, implicitly IMO. With out this assumption, I do not know, how the= HA can ever validate the flow mobility options received in the BU. If the = operator requires any control on enforcing a flow policy rule, the PDN GW/H= A needs to have synchronized policies, without which its always the client = decision. I'm not sure, operators in 3GPP would like that :) No doubt, the lack of MN-AR interface is surely an issue for supporting com= plex flow policies. I realize the issues and I agree with you. But, the ass= umption of synchronized policies can offer some solution with some configur= ation requirement on the HA (assuming there are no other issues). There are= also the proposals on flow mirroring on the UE ..., requiring no flow poli= cies. I've not evaluated this, however. Folks can comment on this. It is also to be noted, for some of the scenarios such, there is no flow po= licy interface needed. We can identify what scenarios create any configurat= ion limitations on the HA and which one's do not . As I've noted earlier, t= his is surely an open issue, that we need to discuss in the WG. Regards Sri On 2/2/11 9:08 AM, "stefano faccin" wrote: Sri, thanks for the reply. Can you clarify in which system or scenario ANDSF is = available to network entities as well? There is no such availability in 3GP= P, and making such information available would require considerable archite= ctural changes, therefore the applicability of this solution to what seems = to be the only realistic scenario hinges on 3GPP making considerable archit= ectural changes. I would therefore not be so hastily concluding that the AN= DSF information is available to the LMA and underestimate what it would rea= lly take to make the solution applicable. If we cannot guarantee that there is at least one realistic solution to hav= e the MNa nd LMA in synch, how do we expect that this solution is applicabl= e at all? In 3GPP there is no need to have such implicit assumption, be cau= se 1) the MN is provided policies explicitly through the ANDSF, and 2) it i= s the MN and only the MN that makes IP flow mobility decisions and communic= ates them explicitly (with well defined signalling) to the LMA, and therefo= re no magic is needed. There is no need in 3GPP to have the ANDSF and PDN G= W policies synchronized, since the PDN GW does not use such policies. Sri, in the end it is a matter of whether we develop a solution that will r= ely on some unknown magic to be deployed, or a solution that we know can be= deployed in at least one way because there are solutions to what I conside= r major open issues. Cheers, Stefano On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli wrote: Hi Stefano, Thanks for the discussion. As you say, the ANDSF policies are allowing the MN a.) to make the right ne= twork attachment decision and b.) make the access selection on a flow basis= . This same policy that is present in the ANDSF server, is available for th= e network nodes as well. I'm not sure, with out this assumption the solutio= n can work for all currently listed cases. We clearly need the MN and the L= MA to be in synch with respect to the configured policy. How, that is done,= I guess we will not try to know. I thought even in 3GPP, this is the impl= ied assumption ? But, this is for you to clarify. Not specifically for IFOM= where UE and PDN GW/HA are negotiating the flow policies, but generally th= at the PDN GW and the ANDSF policy server will have synchronized policies. = The MAG and the LMA have the ability to carry this flow policy information = in signaling messages and influence the access selection. The policy is a o= paque object, with extensible formats, when carried in the signaling plane,= should allow the LMA/MAG to apply those access policies, while assuming MN= is following the same rules. These policies can surely reflect the specifi= c WLAN access/operator specific rule. I'm surely with you, the lack of MN-A= R interface is surely an issue and I see that. But, we need to understand, = what are the limitations with the approach of out of band policy interface= s and what will be the solution limitations. If we need to tie the flow mov= ement at the prefix granularity and rely on the natural ND interface in the= form of RA PIO option, more like PDN offload in MAPCON, or at the granular= ity of a flow level, is open for discussion. I want to simplify this draft = for sure, we can surely discuss each of these issues on the WG draft. Regards Sri On 2/1/11 8:29 PM, "stefano faccin" > wrote: Sri, thanks for the reply. I'd like to comment on the "the flow policy decisions need not be based on = the specific WLAN network". Does it mean, as I believe it does, that the cu= rrent solution would not allow an operator deploying such solution to decid= e to route flows over a specific WLAN or not depending on which specific WL= AN the MN is connected to? E.g. the operator or the entity in control of th= e decisions for the routing may want to direct certain traffic always over = WLANs that the operator deploys, and instead route only some of the traffic= over WLANs of roaming partners or of the MN user home. How does this solut= ion support that scenario if the LMA is not told specifically which WLAN th= e MN is connected to? From a deployment point of view, I do not believe we = can afford to leave out this scenario. Please note that the establishment o= f a security relationship between the MN and the MAG, and a specific MAG id= entity, cannot guarantee that the LMA knows which specific WLAN access netw= ork the MN is connected to. Assuming that would severely restrict the deplo= yment scenarios. As for the MN and the LMA being magically in synch, I am very concerned abo= ut a "glass ball" solution. You mention ANDSF defined by 3GPP as a solution= for this "out of band" delivery of policy. Fair enough, however there is a= n issue with that. ANDSF is designed specific to be a MN-centric solution w= here policies are provisioned in the MN and the MN decides which network te= chnologies and access networks it needs to connect to, under what condition= s, and which IP traffic needs to be routed on such accesses. No IP point of= attachment in the network (i.e. the PDN GW in 3GPP that is the LMA in PMIP= v6) is aware under any conditions of such policy. Therefore, even if in ord= er to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would unfor= tunately not provide a solution unless the MN can communicate to the MAG an= d the LMA the decisions the MN has taken based on the ANDSF policies. I believe the key point here is that we need to understand how the solution= can be realistically applied to a real scenario, and that we need to ensur= e that important and realistic deployment scenarios are not excluded by the= solution. Cheers, Stefano On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli > wrote: Hi Stefano: These are valid points and some good comments. Let me share my thoughts. Carlo's draft is not assuming any new MN-AR interface. Its going with the a= ssumption there is established policy on the mobile and on the LMA, which a= llows the mobile to select the access network at a flow level granularity, = without requiring any explicit signaling between the MAG and the MN. To lar= ge part this is all about out of band policy interface, such as ANDSF, towa= rds the UE, leading to the assumption that magically the MN and the LMA are= in sync with respect to flow policies, access selection and they will make= the right forwarding decision. Secondly, the flow policy decisions need no= t be based on the specific WLAN network, but it is implicitly driven by the= MAG - LMA security relation, where the MAG attachment to the WLAN network = transitively allows the LMA to make the flow policy decisions based on the = MAG identity. If the WLAN network is not trusted, there is truly no MAG in = that network, where the LMA shares a security relation with that node. There are still some open issues on this draft that needs to be discussed i= n the WG. On the approaches to allow more a flow aggregate movement, that = is a discussion point. There are issues that we need to discuss, supporting= split link model, or eliminating some favorite brand of signaling message = (FMA) and riding on PBU/PBA and just with one FMI trigger, and on the aspec= ts around MN applying the flow policies by flow mirroring. We have no agree= ment on those issues yet. Its just a base draft, for further discussion and resolving those issues. B= ut, hope that is not a stopper for base draft selection. Sri On 2/1/11 6:39 PM, "stefano faccin" > wrote: Raj, thanks for the email. I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere). I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability. In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicat= e to the network where the flows should be routed or for the LMA to receive= somehow from somewhere some policies, the solution cannot really provide f= low mobility since there is no way to decide which flows are routed where. = If we are thinking about a host-based solution, I have not yet seen a solut= ion as to how the host can indicate to the MAG and ultimately to the MAG wh= ich flows should be routed on each access. If we are relying on modificatio= ns of layer 2 protocols, aren't we defining a solution that works only with= some technologies (since for other access technologies it is rather unreal= istic to modify L2 for IP flow mobility purposes)? If we are thinking of an= LMA-based solution, can we hear of at least one example of a real-life sce= nario where the LMA would receive such policies, and how such delivery woul= d happen? Also, should there be a solution to have policies in the LMA, how= does the LMA actually decide to route flows on one access or the other? E.= g., if some flows need to be routed on certain WLAN networks, but shall not= be routed on other WLAN networks, how does the LMA know which specific WLA= N network the host is connected to? Perhaps I missed the ability for the MA= G to know e.g. the WLAN SSID and provide it to the LMA, in which case I wou= ld appreciate if somebody could highlight to me where that is defined. I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important. Cheers, Stefano On Tue, Feb 1, 2011 at 3:47 PM, > wrote: Hello, We have discussed the flow mobility solutions for Proxy MIP6 previously at IETFs 78 and 79. This is a consensus call for adopting this I-D: draft-bernardos-netext-pmipv6-flowmob-02 as the working group document. I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt The consensus call will expire on Feb 15th, 2011. Please indicate your support or concerns in adopting this I-D as the WG baseline document on the mailing list. Please note that this I-D will serve as the baseline in the WG and will be developed further based on input and feedback from WG members. -Basavaraj _______________________________________________ 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 --_000_3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CC85FRMRSSXCHMBSE_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

Yes, it wou= ld help.

 =

telemaco

 =

De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part de Rajeev Koodli
Envoy=E9 : vendredi 4 f= =E9vrier 2011 01:02
=C0 : Giaretta, Gerardo= ; Sri Gundavelli; stefano faccin
Cc : netext@ietf.org; Basavaraj.Patil@nokia.com
Objet : Re: [netext] Co= nsensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

 


Hi,

I am asking if you could show how the propagation of SSID/ULI from the MN i= s considered reliable enough for the network to act on. That would help us understand what we need to do here to address your “flag”.

Thanks,

-Rajeev



On 2/3/11 2:43 PM, "Giaretta, Gerardo" <gerardog@qualcomm.com> wrote:<= /font>

Hi Rajeev,
 
Not sure I understand what you are asking me. My comment was mainly referre= d to synchronization of policies which is an assumption not correct in my opinio= n.
 
Based on the current policy model adopted by 3GPP, the only way I can think= of to make the system working is to replicate the behavior of RFC 6089 where t= he MN initiates the flow movement.
 
The assumption on synchronization of policies may however be considered acceptable in other SDOs or even in 3GPP in future. I am just raising an applicability flag to the group (actually the flag was initially raised by Stefano J)
 
Gerardo
 

From: Rajeev= Koodli [mailto:rkoodli@cisco.com]
Sent: Thursday, February 03,= 2011 2:51 PM
To: Giaretta, Gerardo; Sri Gundavelli; stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consen= sus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc


Hi Gerardo,

Okay, so let’s agree that the current version of the draft does not h= ave SSID/ULI propagation to the LMA.

Do you care to suggest how the network deems such an information from the M= N trustworthy?

I am sure you agree if we could have good input, we could design protocols accordingly.
You will also probably agree that’s much better than just arguing abo= ut “it does not work in today’s 3GPP deployment”.

Regards,

-Rajeev


On 2/2/11 9:13 PM, "Giaretta, Gerardo" <gerardog@qualcomm.com> wrote:
Hi Sri,
 
There is no implicit assumption of synchronized policies. A basic example t= hat shows that there is no assumption is the following: ANDSF policies may be b= ased also on location of the UE. For example the UE should prefer WLAN only in a given location. When the UE is attached over WLAN there is no way for the PDNGW/HA to verify the location of the UE and therefore to verify UE action= s based on policies.
 
The assumption on synchronization of policies is only applicable to this dr= aft and I think it is a wrong one.
 
Cheers
Gerardo
 

From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org]= On Behalf Of Sri Gundavelli
Sent: Wednesday, February 02= , 2011 6:50 PM
To: stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consen= sus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

Hi Stefano,

One comment.

Agree with you there is no ANDSF interface to the network node, but the assumption of synchronized policies between the ANDSF server and the PDN GW= /HA is there, implicitly IMO. With out this assumption, I do not know, how the = HA can ever validate the flow mobility options received in the BU. If the operator requires any control on enforcing a flow policy rule, the PDN GW/HA needs t= o have synchronized policies, without which its always the client decision. I= ’m not sure, operators in 3GPP would like that :)

No doubt, the lack of MN-AR interface is surely an issue for supporting com= plex flow policies. I realize the issues and I agree with you. But, the assumpti= on of synchronized policies can offer some solution with some configuration requirement on the HA (assuming there are no other issues). There are also = the proposals on flow mirroring on the UE ..., requiring no flow policies. I= 217;ve not evaluated this, however. Folks can comment on this.

It is also to be noted, for some of the scenarios such, there is no flow po= licy interface needed. We can identify what scenarios create any configuration limitations on the HA and which one’s do not . As I’ve noted ea= rlier, this is surely an open issue, that we need to discuss in the WG.



Regards
Sri




 


On 2/2/11 9:08 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:
Sri,
thanks for the reply. Can you clarify in which system or scenario ANDSF is available to network entities as well? There is no such availability in 3GP= P, and making such information available would require considerable architectu= ral changes, therefore the applicability of this solution to what seems to be t= he only realistic scenario hinges on 3GPP making considerable architectural ch= anges. I would therefore not be so hastily concluding that the ANDSF information i= s available to the LMA and underestimate what it would really take to make th= e solution applicable.

If we cannot guarantee that there is at least one realistic solution to hav= e the MNa nd LMA in synch, how do we expect that this solution is applicable = at all? In 3GPP there is no need to have such implicit assumption, be cause 1)= the MN is provided policies explicitly through the ANDSF, and 2) it is the MN a= nd only the MN that makes IP flow mobility decisions and communicates them explicitly (with well defined signalling) to the LMA, and therefore no magi= c is needed. There is no need in 3GPP to have the ANDSF and PDN GW policies synchronized, since the PDN GW does not use such policies.

Sri, in the end it is a matter of whether we develop a solution that will r= ely on some unknown magic to be deployed, or a solution that we know can be deployed in at least one way because there are solutions to what I consider major open issues.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli <sgundave@cisco.com> wrote:
Hi Stefano,

Thanks for the discussion.

As you say, the ANDSF policies are allowing the MN a.) to make the right network attachment decision and b.) make the access selection on a flow bas= is. This same policy that is present in the ANDSF server, is available for the network nodes as well. I’m not sure, with out this assumption the sol= ution can work for all currently listed cases. We clearly need the MN and the LMA to = be in synch with respect to the configured policy. How, that is done, I guess = we will not try to know.  I thought even in 3GPP, this is the implied assumption ? But, this is for you to clarify. Not specifically for IFOM whe= re UE and PDN GW/HA are negotiating the flow policies, but generally that the = PDN GW and the ANDSF policy server will have synchronized policies. The MAG and= the LMA have the ability to carry this flow policy information in signaling messages and influence the access selection. The policy is a opaque object, with extensible formats, when carried in the signaling plane, should allow = the LMA/MAG to apply those access policies, while assuming MN is following the = same rules. These policies can surely reflect the specific WLAN access/operator specific rule. I’m surely with you, the lack of MN-AR interface is su= rely an issue and I see that. But, we need to understand, what are the limitations = with the approach of  out of band policy interfaces and what will be the solution limitations. If we need to tie the flow movement at the prefix granularity and rely on the natural ND interface in the form of RA PIO opti= on, more like PDN offload in MAPCON, or at the granularity of a flow level, is = open for discussion. I want to simplify this draft for sure, we can surely discu= ss each of these issues on the WG draft.


Regards
Sri






On 2/1/11 8:29 PM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com= > > wrote:
Sri,
thanks for the reply.

I'd like to comment on the "the flow policy decisions need not be base= d on the specific WLAN network". Does it mean, as I believe it does, that t= he current solution would not allow an operator deploying such solution to dec= ide to route flows over a specific WLAN or not depending on which specific WLAN= the MN is connected to? E.g. the operator or the entity in control of the decis= ions for the routing may want to direct certain traffic always over WLANs that t= he operator deploys, and instead route only some of the traffic over WLANs of roaming partners or of the MN user home. How does this solution support tha= t scenario if the LMA is not told specifically which WLAN the MN is connected= to? >From a deployment point of view, I do not believe we can afford to leave ou= t this scenario. Please note that the establishment of a security relationshi= p between the MN and the MAG, and a specific MAG identity, cannot guarantee t= hat the LMA knows which specific WLAN access network the MN is connected to. Assuming that would severely restrict the deployment scenarios.

As for the MN and the LMA being magically in synch, I am very concerned abo= ut a "glass ball" solution. You mention ANDSF defined by 3GPP as a sol= ution for this "out of band" delivery of policy. Fair enough, however t= here is an issue with that. ANDSF is designed specific to be a MN-centric soluti= on where policies are provisioned in the MN and the MN decides which network technologies and access networks it needs to connect to, under what conditi= ons, and which IP traffic needs to be routed on such accesses. No IP point of attachment in the network (i.e. the PDN GW in 3GPP that is the LMA in PMIPv= 6) is aware under any conditions of such policy. Therefore, even if in order t= o apply this solution to 3GPP we wanted to use ANDSF, ANDSF would unfortunate= ly not provide a solution unless the MN can communicate to the MAG and the LMA= the decisions the MN has taken based on the ANDSF policies.

I believe the key point here is that we need to understand how the solution= can be realistically applied to a real scenario, and that we need to ensure tha= t important and realistic deployment scenarios are not excluded by the soluti= on.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli <sgundave@cisco.com <http://sgundave@cisco.com>= > wrote:
Hi Stefano:

These are valid points and some good comments. Let me share my thoughts.
Carlo’s draft is not assuming any new MN-AR interface. Its going with= the assumption there is established policy on the mobile and on the LMA, which allows the mobile to select the access network at a flow level granularity, without requiring any explicit signaling between the MAG and the MN. To lar= ge part this is all about out of band policy interface, such as ANDSF, towards= the UE, leading to the assumption that magically the MN and the LMA are in sync with respect to flow policies, access selection and they will make the righ= t forwarding decision. Secondly, the flow policy decisions need not be based = on the specific WLAN network, but it is implicitly driven by the MAG – L= MA security relation, where the MAG attachment to the WLAN network transitivel= y allows the LMA to make the flow policy decisions based on the MAG identity.= If the WLAN network is not trusted, there is truly no MAG in that network, whe= re the LMA shares a security relation with that node.

There are still some open issues on this draft that needs to be discussed i= n the WG.  On the approaches to allow more a flow aggregate movement, th= at is a discussion point. There are issues that we need to discuss, supporting split link model, or eliminating some favorite brand of signaling message (= FMA) and riding on PBU/PBA and just with one FMI trigger, and on the aspects aro= und MN applying the flow policies by flow mirroring. We have no agreement on th= ose issues yet.

Its just a base draft, for further discussion and resolving those issues. B= ut, hope that is not a stopper for base draft selection.


Sri






On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com= >  <http://sfaccinstd@gmail.c= om> > wrote:
Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered before (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicate to = the network where the flows should be routed or for the LMA to receive somehow = from somewhere some policies, the solution cannot really provide flow mobility s= ince there is no way to decide which flows are routed where. If we are thinking about a host-based solution, I have not yet seen a solution as to how the h= ost can indicate to the MAG and ultimately to the MAG which flows should be rou= ted on each access. If we are relying on modifications of layer 2 protocols, ar= en't we defining a solution that works only with some technologies (since for ot= her access technologies it is rather unrealistic to modify L2 for IP flow mobil= ity purposes)? If we are thinking of an LMA-based solution, can we hear of at l= east one example of a real-life scenario where the LMA would receive such polici= es, and how such delivery would happen? Also, should there be a solution to hav= e policies in the LMA, how does the LMA actually decide to route flows on one access or the other? E.g., if some flows need to be routed on certain WLAN networks, but shall not be routed on other WLAN networks, how does the LMA = know which specific WLAN network the host is connected to? Perhaps I missed the ability for the MAG to know e.g. the WLAN SSID and provide it to the LMA, i= n which case I would appreciate if somebody could highlight to me where that = is defined.

I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important.

Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM,  <Basavaraj.Patil@nokia.com <http://Basavaraj.Patil@nok= ia.com>  <http://Basavaraj.Pat= il@nokia.com> > wrote:

Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= br> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt
The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= br> developed further based on input and feedback from WG members.

-Basavaraj

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

 
 


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

--_000_3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CC85FRMRSSXCHMBSE_-- From telemaco.melia@alcatel-lucent.com Fri Feb 4 02:07:27 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03B7F3A68E0 for ; Fri, 4 Feb 2011 02:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.165 X-Spam-Level: X-Spam-Status: No, score=-4.165 tagged_above=-999 required=5 tests=[AWL=-1.916, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ChQ6jfhRqMN for ; Fri, 4 Feb 2011 02:07:26 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 1916F3A68CB for ; Fri, 4 Feb 2011 02:07:25 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p14AAP6w002654 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 Feb 2011 11:10:46 +0100 Received: from FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com ([135.120.45.54]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 4 Feb 2011 11:10:33 +0100 From: "MELIA, TELEMACO (TELEMACO)" To: Julien Laganier , Rajeev Koodli Date: Fri, 4 Feb 2011 11:10:31 +0100 Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvEACrCFtSxHfB5Qky1OWWTDE6arwAUy5HA Message-ID: <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CC96@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 10:07:27 -0000 > > I would insert that the LMA also informs the MAG hosting p1 to accept p0. Why would the LMA need to tell the MAG? Packet forwarding? telemaco From JuanCarlos.Zuniga@InterDigital.com Fri Feb 4 08:31:45 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F9963A69BF for ; Fri, 4 Feb 2011 08:31:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZCgSe8pziFr for ; Fri, 4 Feb 2011 08:31:24 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id BA2AE3A695F for ; Fri, 4 Feb 2011 08:31:22 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Feb 2011 11:34:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBC489.6F9F525C" Date: Fri, 4 Feb 2011 11:34:46 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLwmpURzmRlysrlUidlexdQorGZJPuBh2AgAAR4ICAAAzJgIAACkaAgADJ5gCAAKKGAP//oT5wgAAf2NyAAIzc8IAA5pGygAC5E2A= References: <843DA8228A1BA74CA31FB4E111A5C4620179629E@ftrdmel0.rd.francetelecom.fr> From: "Zuniga, Juan Carlos" To: "Sri Gundavelli" , , X-OriginalArrivalTime: 04 Feb 2011 16:34:47.0971 (UTC) FILETIME=[700DD730:01CBC489] Cc: netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 16:31:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC489.6F9F525C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sri, Pierrick, Carlos, all, =20 Please see inline: =20 =20 From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of Sri Gundavelli Sent: February 4, 2011 12:15 AM To: pierrick.seite@orange-ftgroup.com; sfaccin@rim.com; = gerardog@qualcomm.com; sfaccinstd@gmail.com Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt = I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc =20 Hi Pierrick: I agree with lot of points. * Yes, its all about handover execution. This is the key point. A PBU = message from the MN can be the first step towards activating the = handover process. Or a FMI trigger from the LMA, may itself be the = pre-trigger for PBU message from the MAG. At the end of the day, the LMA = applies the policy and provides the set of prefixes to the MAG. MAG will = continue to behave as in 5213. The decision logic, or the granularity of = the policy rule applicability on the LMA can be out of scope=20 [JCZ] I would add the case in which the prefixes are pre-assigned and = the flow movement is started from the MN by simply sending packets to = the new interface "for instance" based on MN policies. This case would = require no MN/MAG/LMA signaling and would satisfy the 3GPP/ANDSF = concerns that have been raised without defining any policy management, = network selection, etc in this draft.=20 We just need to state in the draft that, if the LMA starts receiving = packets over a different interface, it would understand this as an = implicit IP Flow mobility change. In this case, the LMA should start = using the same interface on which the uplink packets were received for = subsequent downlink packets. * Policy synchronization is an issue, for the case where the UE's = forwarding decision is based on the policy and not based on the ND = messages from the attached interface. It is very well may be that, we = have the same issue for IFOM as well, IMO, but that's beside the point = for now. The policy activation on the UE, and the associated issues = should be discussed in this context and as needed.=20 * This draft should not deal with flow policies, how they are applied = and what granularity can be out of scope, IMO. These policies need not = be carried in PMIP signaling place, unless we have MN-AR interface=20 * I'm not clear on the policy management though, before we say, it can = be separate thread. The whole approach seems to be out of band at this = point and not sure what can be specified on the PMIP signaling plane = with respect to policy.=20 [JCZ] For these last three points, I agree with Pierrick that this draft = should concentrate on the PMIP flow movement and not on the policy = management. To me clarifying all the above points and cleaning up the wording and = scenarios order would make the draft good enough for group's adoption. Regards Sri On 2/3/11 7:35 AM, "pierrick.seite@orange-ftgroup.com" = wrote: Hello, =20 This is an interesting discussion, thanks for bringing the ANDSF issues = on the table. Effectively, mobility control, i.e. access selection, is a = key point for an operator. From an operator point of view, criteria for = selection is not only RAT type or SSID; we can imagine plenty of other = criteria. Different mobility control models can be envisaged such as = Network controlled or terminal controlled and so on... For sure, in PMIP = context, policies synchronization can be an issue and how decision made = on the terminal can interact with network managed mobility should be = discussed. But, I don't think draft-bernardos should go in this space. I = think, we should clearly distinguish mobility functions. IMHO, = draft-bernardos should not be expected to deal with selection = management, or mobility triggers, but only on the handover execution. In = other words, the draft should assume that handover decision has been = made (how decision is made is out of scope) and, then, only focus on = mechanism allowing the LMA to transfer flow(s). Although related, = mobility decision management, e.g. policy based, should be discussed in = a separated thread. =20 BR, Pierrick =20 ________________________________ De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part = de Stefano Faccin Envoy=E9 : jeudi 3 f=E9vrier 2011 08:05 =C0 : gerardog@qualcomm.com; sgundave@cisco.com; sfaccinstd@gmail.com Cc : netext@ietf.org; Basavaraj.Patil@nokia.com Objet : Re: [netext] Consensus call to adopt = I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Hello Sri, >From a point of view of applicability of the solution, I must agree with = Gerardo that assuming synchronization of policies is an issue of this = solution since it comes with a set of restrictions on how the solution = can be applied. Cheers, Stefano Stefano=20 Stefano M. Faccin=20 Standards Manager=20 Research In Motion=20 122 West John Carpenter Parkway=20 Irving, TX 75039=20 Internal: 820 63451=20 Desk: +1 972 910 3451=20 BlackBerry: +1 510 230 8422=20 sfaccin@rim.com=20 Time zone: PST (GMT -8) From: Giaretta, Gerardo [mailto:gerardog@qualcomm.com]=20 Sent: Wednesday, February 02, 2011 11:13 PM To: Sri Gundavelli ; stefano faccin = =20 Cc: netext@ietf.org ; Basavaraj.Patil@nokia.com = =20 Subject: Re: [netext] Consensus call to adopt I-D: = draft-bernardos-netext-pmipv6-flowmob as WG doc=20 Hi Sri, =20 There is no implicit assumption of synchronized policies. A basic = example that shows that there is no assumption is the following: ANDSF = policies may be based also on location of the UE. For example the UE = should prefer WLAN only in a given location. When the UE is attached = over WLAN there is no way for the PDNGW/HA to verify the location of the = UE and therefore to verify UE actions based on policies. =20 The assumption on synchronization of policies is only applicable to this = draft and I think it is a wrong one.=20 =20 Cheers Gerardo =20 From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of Sri Gundavelli Sent: Wednesday, February 02, 2011 6:50 PM To: stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: = draft-bernardos-netext-pmipv6-flowmob as WG doc Hi Stefano, One comment. Agree with you there is no ANDSF interface to the network node, but the = assumption of synchronized policies between the ANDSF server and the PDN = GW/HA is there, implicitly IMO. With out this assumption, I do not know, = how the HA can ever validate the flow mobility options received in the = BU. If the operator requires any control on enforcing a flow policy = rule, the PDN GW/HA needs to have synchronized policies, without which = its always the client decision. I'm not sure, operators in 3GPP would = like that :)=20 No doubt, the lack of MN-AR interface is surely an issue for supporting = complex flow policies. I realize the issues and I agree with you. But, = the assumption of synchronized policies can offer some solution with = some configuration requirement on the HA (assuming there are no other = issues). There are also the proposals on flow mirroring on the UE ..., = requiring no flow policies. I've not evaluated this, however. Folks can = comment on this. It is also to be noted, for some of the scenarios such, there is no flow = policy interface needed. We can identify what scenarios create any = configuration limitations on the HA and which one's do not . As I've = noted earlier, this is surely an open issue, that we need to discuss in = the WG.=20 Regards Sri =20 On 2/2/11 9:08 AM, "stefano faccin" wrote: Sri, thanks for the reply. Can you clarify in which system or scenario ANDSF = is available to network entities as well? There is no such availability = in 3GPP, and making such information available would require = considerable architectural changes, therefore the applicability of this = solution to what seems to be the only realistic scenario hinges on 3GPP = making considerable architectural changes. I would therefore not be so = hastily concluding that the ANDSF information is available to the LMA = and underestimate what it would really take to make the solution = applicable. If we cannot guarantee that there is at least one realistic solution to = have the MNa nd LMA in synch, how do we expect that this solution is = applicable at all? In 3GPP there is no need to have such implicit = assumption, be cause 1) the MN is provided policies explicitly through = the ANDSF, and 2) it is the MN and only the MN that makes IP flow = mobility decisions and communicates them explicitly (with well defined = signalling) to the LMA, and therefore no magic is needed. There is no = need in 3GPP to have the ANDSF and PDN GW policies synchronized, since = the PDN GW does not use such policies.=20 Sri, in the end it is a matter of whether we develop a solution that = will rely on some unknown magic to be deployed, or a solution that we = know can be deployed in at least one way because there are solutions to = what I consider major open issues. Cheers, Stefano On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli = wrote: Hi Stefano, Thanks for the discussion. As you say, the ANDSF policies are allowing the MN a.) to make the right = network attachment decision and b.) make the access selection on a flow = basis. This same policy that is present in the ANDSF server, is = available for the network nodes as well. I'm not sure, with out this = assumption the solution can work for all currently listed cases. We = clearly need the MN and the LMA to be in synch with respect to the = configured policy. How, that is done, I guess we will not try to know. = I thought even in 3GPP, this is the implied assumption ? But, this is = for you to clarify. Not specifically for IFOM where UE and PDN GW/HA are = negotiating the flow policies, but generally that the PDN GW and the = ANDSF policy server will have synchronized policies. The MAG and the LMA = have the ability to carry this flow policy information in signaling = messages and influence the access selection. The policy is a opaque = object, with extensible formats, when carried in the signaling plane, = should allow the LMA/MAG to apply those access policies, while assuming = MN is following the same rules. These policies can surely reflect the = specific WLAN access/operator specific rule. I'm surely with you, the = lack of MN-AR interface is surely an issue and I see that. But, we need = to understand, what are the limitations with the approach of out of = band policy interfaces and what will be the solution limitations. If we = need to tie the flow movement at the prefix granularity and rely on the = natural ND interface in the form of RA PIO option, more like PDN offload = in MAPCON, or at the granularity of a flow level, is open for = discussion. I want to simplify this draft for sure, we can surely = discuss each of these issues on the WG draft. Regards Sri On 2/1/11 8:29 PM, "stefano faccin" > wrote: Sri, thanks for the reply. I'd like to comment on the "the flow policy decisions need not be based = on the specific WLAN network". Does it mean, as I believe it does, that = the current solution would not allow an operator deploying such solution = to decide to route flows over a specific WLAN or not depending on which = specific WLAN the MN is connected to? E.g. the operator or the entity in = control of the decisions for the routing may want to direct certain = traffic always over WLANs that the operator deploys, and instead route = only some of the traffic over WLANs of roaming partners or of the MN = user home. How does this solution support that scenario if the LMA is = not told specifically which WLAN the MN is connected to? From a = deployment point of view, I do not believe we can afford to leave out = this scenario. Please note that the establishment of a security = relationship between the MN and the MAG, and a specific MAG identity, = cannot guarantee that the LMA knows which specific WLAN access network = the MN is connected to. Assuming that would severely restrict the = deployment scenarios. As for the MN and the LMA being magically in synch, I am very concerned = about a "glass ball" solution. You mention ANDSF defined by 3GPP as a = solution for this "out of band" delivery of policy. Fair enough, however = there is an issue with that. ANDSF is designed specific to be a = MN-centric solution where policies are provisioned in the MN and the MN = decides which network technologies and access networks it needs to = connect to, under what conditions, and which IP traffic needs to be = routed on such accesses. No IP point of attachment in the network (i.e. = the PDN GW in 3GPP that is the LMA in PMIPv6) is aware under any = conditions of such policy. Therefore, even if in order to apply this = solution to 3GPP we wanted to use ANDSF, ANDSF would unfortunately not = provide a solution unless the MN can communicate to the MAG and the LMA = the decisions the MN has taken based on the ANDSF policies. I believe the key point here is that we need to understand how the = solution can be realistically applied to a real scenario, and that we = need to ensure that important and realistic deployment scenarios are not = excluded by the solution. Cheers, Stefano On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli > wrote: Hi Stefano: These are valid points and some good comments. Let me share my thoughts. Carlo's draft is not assuming any new MN-AR interface. Its going with = the assumption there is established policy on the mobile and on the LMA, = which allows the mobile to select the access network at a flow level = granularity, without requiring any explicit signaling between the MAG = and the MN. To large part this is all about out of band policy = interface, such as ANDSF, towards the UE, leading to the assumption that = magically the MN and the LMA are in sync with respect to flow policies, = access selection and they will make the right forwarding decision. = Secondly, the flow policy decisions need not be based on the specific = WLAN network, but it is implicitly driven by the MAG - LMA security = relation, where the MAG attachment to the WLAN network transitively = allows the LMA to make the flow policy decisions based on the MAG = identity. If the WLAN network is not trusted, there is truly no MAG in = that network, where the LMA shares a security relation with that node. There are still some open issues on this draft that needs to be = discussed in the WG. On the approaches to allow more a flow aggregate = movement, that is a discussion point. There are issues that we need to = discuss, supporting split link model, or eliminating some favorite brand = of signaling message (FMA) and riding on PBU/PBA and just with one FMI = trigger, and on the aspects around MN applying the flow policies by flow = mirroring. We have no agreement on those issues yet. Its just a base draft, for further discussion and resolving those = issues. But, hope that is not a stopper for base draft selection. Sri On 2/1/11 6:39 PM, "stefano faccin" > wrote: Raj, thanks for the email. I need to apologize in advance if my questions have already been = answered before (though I cannot find a conclusive answer anywhere). I think that a protocol that is developed in NETEXT (or other groups) = should have at least a potential realistic scenario for applicability. In terms of applicability, though it is not part of the protocol = definition per se, unless there are solutions in place for either the = host to indicate to the network where the flows should be routed or for = the LMA to receive somehow from somewhere some policies, the solution = cannot really provide flow mobility since there is no way to decide = which flows are routed where. If we are thinking about a host-based = solution, I have not yet seen a solution as to how the host can indicate = to the MAG and ultimately to the MAG which flows should be routed on = each access. If we are relying on modifications of layer 2 protocols, = aren't we defining a solution that works only with some technologies = (since for other access technologies it is rather unrealistic to modify = L2 for IP flow mobility purposes)? If we are thinking of an LMA-based = solution, can we hear of at least one example of a real-life scenario = where the LMA would receive such policies, and how such delivery would = happen? Also, should there be a solution to have policies in the LMA, = how does the LMA actually decide to route flows on one access or the = other? E.g., if some flows need to be routed on certain WLAN networks, = but shall not be routed on other WLAN networks, how does the LMA know = which specific WLAN network the host is connected to? Perhaps I missed = the ability for the MAG to know e.g. the WLAN SSID and provide it to the = LMA, in which case I would appreciate if somebody could highlight to me = where that is defined. I think that, though not integral to the protocol specification, = understanding what framework the protocol would/needs to fit in is = rather important.=20 Cheers, Stefano On Tue, Feb 1, 2011 at 3:47 PM, > = wrote: Hello, We have discussed the flow mobility solutions for Proxy MIP6 previously = at IETFs 78 and 79. This is a consensus call for adopting this I-D: draft-bernardos-netext-pmipv6-flowmob-02 as the working group document. I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt The consensus call will expire on Feb 15th, 2011. Please indicate your support or concerns in adopting this I-D as the WG baseline document on the mailing list. Please note that this I-D will serve as the baseline in the WG and will = be developed further based on input and feedback from WG members. -Basavaraj _______________________________________________ netext mailing list netext@ietf.org =20 https://www.ietf.org/mailman/listinfo/netext =20 =20 ---------------------------------------------------------------------=20 This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this = transmission in error, please immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be unlawful.=20 ------_=_NextPart_001_01CBC489.6F9F525C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc

Sri, Pierrick, Carlos, all,

 

Please see inline:

 

 

From:= netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of = Sri Gundavelli
Sent: February 4, 2011 12:15 AM
To: pierrick.seite@orange-ftgroup.com; sfaccin@rim.com; gerardog@qualcomm.com; sfaccinstd@gmail.com
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG = doc

 

Hi Pierrick:

I agree with lot of points.

  • Yes, its all about handover execution. This is the key point. A PBU = message from the MN can be the first step towards activating the handover = process. Or a FMI trigger from the LMA, may itself be the pre-trigger for = PBU message from the MAG. At the end of the day, the LMA applies the = policy and provides the set of prefixes to the MAG. MAG will continue to = behave as in 5213. The decision logic, or the granularity of the policy = rule applicability on the LMA can be out of scope =

[JCZ] I would add the case in which the prefixes are pre-assigned and the flow movement is started from the MN by simply sending packets to the new = interface “for instance” based on MN policies. This case would require no = MN/MAG/LMA signaling and would satisfy the 3GPP/ANDSF concerns that have been raised without = defining any policy management, network selection, etc in this draft. =

We just need to state in the draft that, if the LMA starts receiving packets = over a different interface, it would understand this as an implicit IP Flow = mobility change. In this case, the LMA should start using the same interface on = which the uplink packets were received for subsequent downlink = packets.

  • Policy synchronization is an issue, for the case where the UE’s = forwarding decision is based on the policy and not based on the ND messages = from the attached interface. It is very well may be that, we have the same = issue for IFOM as well, IMO, but that’s beside the point for now.  The policy activation on the UE, and the associated issues = should be discussed in this context and as needed.
  • This draft should not deal with flow policies, how they are applied and = what granularity can be out of scope, IMO. These policies need not be = carried in PMIP signaling place, unless we have MN-AR interface =
  • I’m not clear on the policy management though, before we say, it can be separate thread. The whole approach seems to be out of band at this = point and not sure what can be specified on the PMIP signaling plane with respect to policy.

[JCZ] For these last three points, I agree with Pierrick that this draft = should concentrate on the PMIP flow movement and not on the policy = management.

To me clarifying all the above points and cleaning up the wording and = scenarios order would make the draft good enough for group’s = adoption.


Regards
Sri







On 2/3/11 7:35 AM, "pierrick.seite@orange-ftgroup.= com" <pierrick.seite@orange-ftgroup.= com> wrote:

Hello,
 
This is an interesting discussion, thanks for bringing the ANDSF issues = on the table. Effectively, mobility control, i.e. access selection, is a key = point for an operator. From an operator point of view, criteria for selection is = not only RAT type or SSID; we can imagine plenty of other criteria. Different = mobility control models can be envisaged such as Network controlled or terminal controlled and so on... For sure, in PMIP context, policies = synchronization can be an issue and how decision made on the terminal can interact with = network managed mobility should be discussed. But, I don't think draft-bernardos = should go in this space. I think, we should clearly distinguish mobility = functions. IMHO, draft-bernardos should not be expected to deal with selection = management, or mobility triggers, but only on the handover execution. In other = words, the draft should assume that handover decision has been made (how decision = is made is out of scope) and, then, only focus on mechanism allowing the LMA to transfer flow(s). Although related, mobility decision management, e.g. = policy based, should be discussed in a separated thread.
 
BR,
Pierrick

 

De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part de Stefano Faccin
Envoy=E9 : jeudi 3 f=E9vrier 2011 08:05
=C0 : gerardog@qualcomm.com; sgundave@cisco.com; sfaccinstd@gmail.com
Cc : netext@ietf.org; Basavaraj.Patil@nokia.com
Objet : Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc

Hello Sri,
>From a point of view of applicability of the solution, I must agree with Gerardo that assuming synchronization of policies is an issue of this = solution since it comes with a set of restrictions on how the solution can be = applied.
Cheers,
Stefano

Stefano
Stefano M. Faccin

Standards Manager
Research In Motion
122 West John Carpenter Parkway
Irving, TX 75039
Internal: 820 63451
Desk: +1 972 910 3451
BlackBerry: +1 510 230 8422
sfaccin@rim.com
Time zone: PST (GMT -8)


From<= /b>: Giaretta, = Gerardo [mailto:gerardog@qualcomm.com] =
Sent: Wednesday, February 02, 2011 11:13 PM
To: Sri Gundavelli <sgundave@cisco.com>; stefano faccin <sfaccinstd@gmail.com>
Cc: netext@ietf.org <netext@ietf.org>; Basavaraj.Patil@nokia.com <Basavaraj.Patil@nokia.com> =
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

Hi Sri,
 
There is no implicit assumption of synchronized policies. A basic = example that shows that there is no assumption is the following: ANDSF policies may = be based also on location of the UE. For example the UE should prefer WLAN only = in a given location. When the UE is attached over WLAN there is no way for = the PDNGW/HA to verify the location of the UE and therefore to verify UE = actions based on policies.
 
The assumption on synchronization of policies is only applicable to this = draft and I think it is a wrong one.
 
Cheers
Gerardo
 

From:= netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Sri Gundavelli
Sent: Wednesday, February 02, 2011 6:50 PM
To: stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

Hi = Stefano,

One comment.

Agree with you there is no ANDSF interface to the network node, but the assumption of synchronized policies between the ANDSF server and the PDN = GW/HA is there, implicitly IMO. With out this assumption, I do not know, how = the HA can ever validate the flow mobility options received in the BU. If the = operator requires any control on enforcing a flow policy rule, the PDN GW/HA = needs to have synchronized policies, without which its always the client = decision. I’m not sure, operators in 3GPP would like that :)

No doubt, the lack of MN-AR interface is surely an issue for supporting = complex flow policies. I realize the issues and I agree with you. But, the = assumption of synchronized policies can offer some solution with some configuration requirement on the HA (assuming there are no other issues). There are = also the proposals on flow mirroring on the UE ..., requiring no flow policies. I’ve not evaluated this, however. Folks can comment on this.

It is also to be noted, for some of the scenarios such, there is no flow = policy interface needed. We can identify what scenarios create any = configuration limitations on the HA and which one’s do not . As I’ve noted earlier, this is surely an open issue, that we need to discuss in the = WG.



Regards
Sri




 


On 2/2/11 9:08 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:
Sri,
thanks for the reply. Can you clarify in which system or scenario ANDSF = is available to network entities as well? There is no such availability in = 3GPP, and making such information available would require considerable = architectural changes, therefore the applicability of this solution to what seems to = be the only realistic scenario hinges on 3GPP making considerable architectural changes. I would therefore not be so hastily concluding that the ANDSF information is available to the LMA and underestimate what it would = really take to make the solution applicable.

If we cannot guarantee that there is at least one realistic solution to = have the MNa nd LMA in synch, how do we expect that this solution is = applicable at all? In 3GPP there is no need to have such implicit assumption, be cause = 1) the MN is provided policies explicitly through the ANDSF, and 2) it is the = MN and only the MN that makes IP flow mobility decisions and communicates them explicitly (with well defined signalling) to the LMA, and therefore no = magic is needed. There is no need in 3GPP to have the ANDSF and PDN GW policies synchronized, since the PDN GW does not use such policies.

Sri, in the end it is a matter of whether we develop a solution that = will rely on some unknown magic to be deployed, or a solution that we know can be deployed in at least one way because there are solutions to what I = consider major open issues.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli <sgundave@cisco.com> wrote:
Hi Stefano,

Thanks for the discussion.

As you say, the ANDSF policies are allowing the MN a.) to make the right network attachment decision and b.) make the access selection on a flow = basis. This same policy that is present in the ANDSF server, is available for = the network nodes as well. I’m not sure, with out this assumption the solution can work for all currently listed cases. We clearly need the MN = and the LMA to be in synch with respect to the configured policy. How, that = is done, I guess we will not try to know.  I thought even in 3GPP, = this is the implied assumption ? But, this is for you to clarify. Not = specifically for IFOM where UE and PDN GW/HA are negotiating the flow policies, but = generally that the PDN GW and the ANDSF policy server will have synchronized = policies. The MAG and the LMA have the ability to carry this flow policy = information in signaling messages and influence the access selection. The policy is a = opaque object, with extensible formats, when carried in the signaling plane, = should allow the LMA/MAG to apply those access policies, while assuming MN is following the same rules. These policies can surely reflect the specific = WLAN access/operator specific rule. I’m surely with you, the lack of = MN-AR interface is surely an issue and I see that. But, we need to understand, = what are the limitations with the approach of  out of band policy = interfaces and what will be the solution limitations. If we need to tie the flow = movement at the prefix granularity and rely on the natural ND interface in the = form of RA PIO option, more like PDN offload in MAPCON, or at the granularity of = a flow level, is open for discussion. I want to simplify this draft for sure, = we can surely discuss each of these issues on the WG draft.


Regards
Sri






On 2/1/11 8:29 PM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com> > wrote:
Sri,
thanks for the reply.

I'd like to comment on the "the flow policy decisions need not = be based on the specific WLAN network". Does it mean, as I believe it does, = that the current solution would not allow an operator deploying such solution = to decide to route flows over a specific WLAN or not depending on which = specific WLAN the MN is connected to? E.g. the operator or the entity in control = of the decisions for the routing may want to direct certain traffic always over = WLANs that the operator deploys, and instead route only some of the traffic = over WLANs of roaming partners or of the MN user home. How does this solution support that scenario if the LMA is not told specifically which WLAN the = MN is connected to? From a deployment point of view, I do not believe we can = afford to leave out this scenario. Please note that the establishment of a = security relationship between the MN and the MAG, and a specific MAG identity, = cannot guarantee that the LMA knows which specific WLAN access network the MN = is connected to. Assuming that would severely restrict the deployment = scenarios.

As for the MN and the LMA being magically in synch, I am very concerned = about a "glass ball" solution. You mention ANDSF defined by 3GPP as a solution for this "out of band" delivery of policy. Fair = enough, however there is an issue with that. ANDSF is designed specific to be a MN-centric solution where policies are provisioned in the MN and the MN = decides which network technologies and access networks it needs to connect to, = under what conditions, and which IP traffic needs to be routed on such = accesses. No IP point of attachment in the network (i.e. the PDN GW in 3GPP that is = the LMA in PMIPv6) is aware under any conditions of such policy. Therefore, even = if in order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would unfortunately not provide a solution unless the MN can communicate to = the MAG and the LMA the decisions the MN has taken based on the ANDSF = policies.

I believe the key point here is that we need to understand how the = solution can be realistically applied to a real scenario, and that we need to ensure = that important and realistic deployment scenarios are not excluded by the = solution.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli <sgundave@cisco.com <http://sgundave@cisco.com> = > wrote:
Hi Stefano:

These are valid points and some good comments. Let me share my = thoughts.

Carlo’s draft is not assuming any new MN-AR interface. Its going = with the assumption there is established policy on the mobile and on the LMA, = which allows the mobile to select the access network at a flow level = granularity, without requiring any explicit signaling between the MAG and the MN. To = large part this is all about out of band policy interface, such as ANDSF, towards = the UE, leading to the assumption that magically the MN and the LMA are in sync = with respect to flow policies, access selection and they will make the right forwarding decision. Secondly, the flow policy decisions need not be = based on the specific WLAN network, but it is implicitly driven by the MAG = – LMA security relation, where the MAG attachment to the WLAN network = transitively allows the LMA to make the flow policy decisions based on the MAG = identity. If the WLAN network is not trusted, there is truly no MAG in that network, = where the LMA shares a security relation with that node.

There are still some open issues on this draft that needs to be = discussed in the WG.  On the approaches to allow more a flow aggregate movement, = that is a discussion point. There are issues that we need to discuss, = supporting split link model, or eliminating some favorite brand of signaling = message (FMA) and riding on PBU/PBA and just with one FMI trigger, and on the aspects = around MN applying the flow policies by flow mirroring. We have no agreement on = those issues yet.

Its just a base draft, for further discussion and resolving those = issues. But, hope that is not a stopper for base draft selection.


Sri






On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com>  <http://sfaccinstd@gmail.com> > wrote:
Raj,
thanks for the email.

I need to apologize in advance if my questions have already been = answered before (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) = should have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol = definition per se, unless there are solutions in place for either the host to indicate = to the network where the flows should be routed or for the LMA to receive = somehow from somewhere some policies, the solution cannot really provide flow = mobility since there is no way to decide which flows are routed where. If we are = thinking about a host-based solution, I have not yet seen a solution as to how = the host can indicate to the MAG and ultimately to the MAG which flows should be = routed on each access. If we are relying on modifications of layer 2 protocols, = aren't we defining a solution that works only with some technologies (since for = other access technologies it is rather unrealistic to modify L2 for IP flow = mobility purposes)? If we are thinking of an LMA-based solution, can we hear of = at least one example of a real-life scenario where the LMA would receive such = policies, and how such delivery would happen? Also, should there be a solution to = have policies in the LMA, how does the LMA actually decide to route flows on = one access or the other? E.g., if some flows need to be routed on certain = WLAN networks, but shall not be routed on other WLAN networks, how does the = LMA know which specific WLAN network the host is connected to? Perhaps I missed = the ability for the MAG to know e.g. the WLAN SSID and provide it to the = LMA, in which case I would appreciate if somebody could highlight to me where = that is defined.

I think that, though not integral to the protocol specification, = understanding what framework the protocol would/needs to fit in is rather important. =

Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM,  <Basavaraj.Patil@nokia.com <http://Basavaraj.Patil@nokia.co= m>  <http://Basavaraj.Patil@nokia.co= m> > wrote:

Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously = at
IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt

The consensus call will expire on Feb 15th, 2011. Please indicate = your
support or concerns in adopting this I-D as the WG baseline document = on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will = be
developed further based on input and feedback from WG members.

-Basavaraj

_______________________________________________
netext mailing list
netext@ietf.org <http://netext@ietf.org> =  <http://netext@ietf.org>
https://www.ietf.or= g/mailman/listinfo/netext

 
 
--------------------------------------------------------------------- =
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than the = intended recipient is prohibited. If you have received this transmission in = error, please immediately reply to the sender and delete this information from = your system. Use, dissemination, distribution, or reproduction of this = transmission by unintended recipients is not authorized and may be unlawful. =

------_=_NextPart_001_01CBC489.6F9F525C-- From julien.ietf@gmail.com Fri Feb 4 10:10:40 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD07F3A6968 for ; Fri, 4 Feb 2011 10:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5D3VOxVaq8h for ; Fri, 4 Feb 2011 10:10:39 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 2E8EE3A694A for ; Fri, 4 Feb 2011 10:10:39 -0800 (PST) Received: by eyd10 with SMTP id 10so1550798eyd.31 for ; Fri, 04 Feb 2011 10:14:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dwVSULf+R5Cd6wUcMkZhy/Eob800W05ltrTDkS+7NdE=; b=uI5Nj7EW5vsFjSPWfxXuYLh7D4PtUBH6kR7jnZTqNONUTdYyGQf0WIN0XN3vT2hAwA 697ieKD0QpQp8pE1FCJXMBW+lubC7OhDdqgv5I6v4cMJek/u9Vh0zgr/801sBKjKrkGm Nw8z600NxyKyAi3QW78qSJJAUf564pVErWl/I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wmxa2K+3HYuatVKs2R7bD4cx3md8v1EJdHkD++9Z6eRzOofeGNBslVpK50lwrm3Pjd YrfHrOeypnJqltEgwZ4F41WsYefJbow4deM7r8pzj0Yb/fyAafZ1Aqs9d6ngDBqm/P4t 39t4qd5yZ7BrEbIrNBVrdHrnTh0MP7mBRrJm8= MIME-Version: 1.0 Received: by 10.103.192.12 with SMTP id u12mr5032377mup.75.1296843243650; Fri, 04 Feb 2011 10:14:03 -0800 (PST) Received: by 10.103.221.9 with HTTP; Fri, 4 Feb 2011 10:14:03 -0800 (PST) In-Reply-To: <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CC96@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> References: <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CC96@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> Date: Fri, 4 Feb 2011 10:14:03 -0800 Message-ID: From: Julien Laganier To: "MELIA, TELEMACO (TELEMACO)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "Basavaraj.Patil@nokia.com" , "netext@ietf.org" Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 18:10:40 -0000 On Fri, Feb 4, 2011 at 2:10 AM, MELIA, TELEMACO (TELEMACO) wrote: >>> >>> I would insert that the LMA also informs the MAG hosting p1 to accept p0. >> >> Why would the LMA need to tell the MAG? > > Packet forwarding? So the requirement is that a MAG knows the prefix set of the MN's sessions. This can be done at session creation and does not need to be (re)done at flow movement. --julien From sfaccin@rim.com Fri Feb 4 10:12:15 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CAFB3A693C for ; Fri, 4 Feb 2011 10:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.548 X-Spam-Level: X-Spam-Status: No, score=-4.548 tagged_above=-999 required=5 tests=[AWL=-0.346, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VV3pueiaR4P3 for ; Fri, 4 Feb 2011 10:11:47 -0800 (PST) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 138403A6968 for ; Fri, 4 Feb 2011 10:11:30 -0800 (PST) X-AuditID: 0a401fcb-b7c02ae0000009e2-b3-4d4c421ef427 Received: from XCH138CNC.rim.net ( [10.65.20.127]) by mhs03ykf.rim.net (RIM Mail) with SMTP id FE.79.02530.E124C4D4; Fri, 4 Feb 2011 13:14:54 -0500 (EST) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH138CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Feb 2011 13:14:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CBC497.69E98F49" Date: Fri, 4 Feb 2011 12:14:50 -0600 Message-ID: <680854867F7FD04BB9B06EB8ACA8D5AC05E1F356@XCH02DFW.rim.net> In-Reply-To: <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CC7E@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLwmpURzmRlysrlUidlexdQorGZJPuBh2AgAAR4ICAAAzJgIAACkaAgADJ5gCAAKKGAP//oT5wgAEesLCAAAq77oAAADZggAC0szCAAI3PsA== References: <680854867F7FD04BB9B06EB8ACA8D5AC05E1F0A3@XCH02DFW.rim.net> <680854867F7FD04BB9B06EB8ACA8D5AC05E1F0CB@XCH02DFW.rim.net> <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CC7E@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> From: "Stefano Faccin" To: "MELIA, TELEMACO (TELEMACO)" , "Sri Gundavelli" , "Giaretta, Gerardo" , "stefano faccin" X-OriginalArrivalTime: 04 Feb 2011 18:14:54.0580 (UTC) FILETIME=[6C45A340:01CBC497] X-Brightmail-Tracker: AAAABgAAAZEXVB72F1QozBdUKM0XVCjOF1TWuQ== Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 18:12:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC497.69E98F49 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CBC497.69E98F49" ------_=_NextPart_002_01CBC497.69E98F49 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Telemaco, I apologize if I fail to make my point. I am just trying to see how this solution can get applied to a realistic cas= e. I guess we want to design a protocol that solves issues and provides a to= ol for realistic use cases, I hope? If so, my point is that we have open iss= ues on how this protocol will be used in those cases. Now, we also want to d= evelop a protocol that has a customer, correct? Not just have an academic ex= ercise, correct? If so, it has been said previously on this ML that 3GPP is= the biggest potential customer for this work (if there are others I must ha= ve missed the emails indicating what other customers are out there). So, if= we want to make this applicable to 3GPP, it means it will go in future rele= ases of 3GPP, obviously. Which means it needs to support what is already sup= ported in current releases, otherwise you are proposing a solution that step= s backwards in time in terms of what it can support. As for the use cases I have provided (i.e. per access network versus per acc= ess technology), I have not heard any real use case confuting the relevance= of the use cases, but just what this protocol cannot do to support them, wh= ich concerns me. Cheers, Stefano Faccin Standards Manager Research In Motion Corporation 5000 Riverside Drive Building 6, Brazos East, Ste. 100 Irving, Texas 75039 USA Office: (972) 910 3451 Internal: 820.63451 : (510) 230 8422 www.rim.com ; www.blackberry.com P Consider the environment before printing. From: MELIA, TELEMACO (TELEMACO) [mailto:telemaco.melia@alcatel-lucent.com]= Sent: Friday, February 04, 2011 1:49 AM To: Stefano Faccin; Sri Gundavelli; Giaretta, Gerardo; stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: RE: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmi= pv6-flowmob as WG doc Stefano, all, I believe the authors of the draft never intended to replicate all the featu= res of the client based approach. In addition to this I fail to see why we should spend so much time in discus= sing the WLAN ESSID issue. Of course we can debate about trusted/untrusted a= ccess but I think this is orthogonal to the PMIP flow mobility discussion. I= f not can you please explain? telemaco ________________________________ De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part de= Stefano Faccin Envoy=E9 : vendredi 4 f=E9vrier 2011 00:02 =C0 : Sri Gundavelli; Giaretta, Gerardo; stefano faccin Cc : netext@ietf.org; Basavaraj.Patil@nokia.com Objet : Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmi= pv6-flowmob as WG doc Sri, I am glad to hear that you also think that the network-based flow mobility s= olution cannot intrinsically provide all the features of the client-based ap= proach. I am also glad that you hear that access selection solutions in place today= are sci-fi. Why do you believe that an operator that wants e.g. to move the= voice traffic and video streaming to the WLAN APs it deploys (because it ca= n offload them and can control QoS) may not want to move the same flows to a= WLAN in a hotel where the user will get an awful user experience? Another e= xample: policies may be configured by an enterprise in the device so that th= e enterprise will allow the MN to direct some traffic on certain WLAN APs (e= .g. the one the enterprise deploys) but not on other WLAN APs. I think the p= er-access network scenarios are indeed more than realistic. Perhaps we're tr= ying to oversimplify the scenarios just to fit the solution in them? Stefano Faccin Standards Manager Research In Motion Corporation 5000 Riverside Drive Building 6, Brazos East, Ste. 100 Irving, Texas 75039 USA Office: (972) 910 3451 Internal: 820.63451 : (510) 230 8422 www.rim.com ; www.blackberry.com P Consider the environment before printing. From: Sri Gundavelli [mailto:sgundave@cisco.com] Sent: Thursday, February 03, 2011 2:56 PM To: Stefano Faccin; Giaretta, Gerardo; stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pm= ipv6-flowmob as WG doc Hi Stefano, My point on the synchronized policy assumption still remains, as I've noted= in the other thread. Therefore, if we want to provide a protocol for network based flow mobility= to provide an alternative to existing solutions, we need to provide a solut= ion that realistically provides the same functionality. I will probably take a defensive stand on this. As I've stated before, I do= not believe network-based mobility approaches can match client based approa= ches 1:1, in every aspect. Its simply not possible, specially when we don't= have the needed MN-AR interface argument, for carrying Attachment Preferenc= es. But, most of the features that are practical from deployment perspective= (unlike some of the complex flow mobility scenarios, complexity in the orde= r of science fiction moves :)), every thing else can be achieved over networ= k-based approaches, with out any MN-AR interface. Hence, my argument to keep= the specs simple As as for simplified policies versus what current solutions already provide= (e.g. per access network policy and not just per access technology), why sh= ould we go ahead with a solution that brings us back in time wrt what we can= provide to users and operators? Please note that even today (and not just f= uture releases of 3GPP or future IETF protocols) there are deployment scenar= ios where the decisions to choose or not whether to route traffic over a cer= tain WLAN is based on the specific WLAN (e.g. SSID) and not just on the fact= that the MN is connected to WLAN. To large part, in the context of trusted non-3GPP access, basic flow mobilit= y functions can be supported. We can break this down and bring some of the a= spects around network ownership, cost parameters and tie the flow policy rul= es to it. But, I don't think the goal is to support all such features. Regards Sri On 2/3/11 2:22 PM, "Stefano Faccin" wrote: Hi Sri, I need to agree with the Gerardo. You are making an assumption that is incor= rect.Synchronizing policies between the MN and the LMA is not an easy and sc= alable solution. I understand synchronizing policies between a MN and a poli= cy server that is the only repository for a given MN (i.e. one MN has its po= licy in a single policy server). Assuming that all the LMAs in a network tha= t the MN can be connected to have synchronized policies with the MN is clear= ly not realistic. As as for simplified policies versus what current solutions already provide= (e.g. per access network policy and not just per access technology), why sh= ould we go ahead with a solution that brings us back in time wrt what we can= provide to users and operators? Please note that even today (and not just f= uture releases of 3GPP or future IETF protocols) there are deployment scenar= ios where the decisions to choose or not whether to route traffic over a cer= tain WLAN is based on the specific WLAN (e.g. SSID) and not just on the fact= that the MN is connected to WLAN. Therefore, if we want to provide a protocol for network based flow mobility= to provide an alternative to existing solutions, we need to provide a solut= ion that realistically provides the same functionality. Cheers, Stefano Faccin Standards ManagerResearch In Motion Corporation 5000 Riverside Drive Building 6, Brazos East, Ste. 100Irving, Texas 75039 USA Office: (972) 910 3451 Internal: 820.63451: (510) 230 8422www.rim.com ; www.blackberry.com P Consider the environment before printing. From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of= Giaretta, Gerardo Sent: Wednesday, February 02, 2011 9:14 PM To: Sri Gundavelli; stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pm= ipv6-flowmob as WG doc Hi Sri, There is no implicit assumption of synchronized policies. A basic example th= at shows that there is no assumption is the following: ANDSF policies may be= based also on location of the UE. For example the UE should prefer WLAN onl= y in a given location. When the UE is attached over WLAN there is no way for= the PDNGW/HA to verify the location of the UE and therefore to verify UE ac= tions based on policies. The assumption on synchronization of policies is only applicable to this dra= ft and I think it is a wrong one. Cheers Gerardo From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of= Sri Gundavelli Sent: Wednesday, February 02, 2011 6:50 PM To: stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pm= ipv6-flowmob as WG doc Hi Stefano, One comment. Agree with you there is no ANDSF interface to the network node, but the assu= mption of synchronized policies between the ANDSF server and the PDN GW/HA i= s there, implicitly IMO. With out this assumption, I do not know, how the HA= can ever validate the flow mobility options received in the BU. If the oper= ator requires any control on enforcing a flow policy rule, the PDN GW/HA nee= ds to have synchronized policies, without which its always the client decisi= on. I'm not sure, operators in 3GPP would like that :) No doubt, the lack of MN-AR interface is surely an issue for supporting comp= lex flow policies. I realize the issues and I agree with you. But, the assum= ption of synchronized policies can offer some solution with some configurati= on requirement on the HA (assuming there are no other issues). There are als= o the proposals on flow mirroring on the UE ..., requiring no flow policies.= I've not evaluated this, however. Folks can comment on this. It is also to be noted, for some of the scenarios such, there is no flow pol= icy interface needed. We can identify what scenarios create any configuratio= n limitations on the HA and which one's do not . As I've noted earlier, this= is surely an open issue, that we need to discuss in the WG. Regards Sri On 2/2/11 9:08 AM, "stefano faccin" wrote: Sri, thanks for the reply. Can you clarify in which system or scenario ANDSF is a= vailable to network entities as well? There is no such availability in 3GPP,= and making such information available would require considerable architectu= ral changes, therefore the applicability of this solution to what seems to b= e the only realistic scenario hinges on 3GPP making considerable architectur= al changes. I would therefore not be so hastily concluding that the ANDSF in= formation is available to the LMA and underestimate what it would really tak= e to make the solution applicable. If we cannot guarantee that there is at least one realistic solution to have= the MNa nd LMA in synch, how do we expect that this solution is applicable= at all? In 3GPP there is no need to have such implicit assumption, be cause= 1) the MN is provided policies explicitly through the ANDSF, and 2) it is t= he MN and only the MN that makes IP flow mobility decisions and communicates= them explicitly (with well defined signalling) to the LMA, and therefore no= magic is needed. There is no need in 3GPP to have the ANDSF and PDN GW poli= cies synchronized, since the PDN GW does not use such policies. Sri, in the end it is a matter of whether we develop a solution that will re= ly on some unknown magic to be deployed, or a solution that we know can be d= eployed in at least one way because there are solutions to what I consider m= ajor open issues. Cheers, Stefano On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli wrote: Hi Stefano, Thanks for the discussion. As you say, the ANDSF policies are allowing the MN a.) to make the right net= work attachment decision and b.) make the access selection on a flow basis.= This same policy that is present in the ANDSF server, is available for the= network nodes as well. I'm not sure, with out this assumption the solution= can work for all currently listed cases. We clearly need the MN and the LMA= to be in synch with respect to the configured policy. How, that is done, I= guess we will not try to know. I thought even in 3GPP, this is the implied= assumption ? But, this is for you to clarify. Not specifically for IFOM whe= re UE and PDN GW/HA are negotiating the flow policies, but generally that th= e PDN GW and the ANDSF policy server will have synchronized policies. The MA= G and the LMA have the ability to carry this flow policy information in sign= aling messages and influence the access selection. The policy is a opaque ob= ject, with extensible formats, when carried in the signaling plane, should a= llow the LMA/MAG to apply those access policies, while assuming MN is follow= ing the same rules. These policies can surely reflect the specific WLAN acce= ss/operator specific rule. I'm surely with you, the lack of MN-AR interface= is surely an issue and I see that. But, we need to understand, what are the= limitations with the approach of out of band policy interfaces and what wi= ll be the solution limitations. If we need to tie the flow movement at the p= refix granularity and rely on the natural ND interface in the form of RA PIO= option, more like PDN offload in MAPCON, or at the granularity of a flow le= vel, is open for discussion. I want to simplify this draft for sure, we can= surely discuss each of these issues on the WG draft. Regards Sri On 2/1/11 8:29 PM, "stefano faccin" > wrote: Sri, thanks for the reply. I'd like to comment on the "the flow policy decisions need not be based on t= he specific WLAN network". Does it mean, as I believe it does, that the curr= ent solution would not allow an operator deploying such solution to decide t= o route flows over a specific WLAN or not depending on which specific WLAN t= he MN is connected to? E.g. the operator or the entity in control of the dec= isions for the routing may want to direct certain traffic always over WLANs= that the operator deploys, and instead route only some of the traffic over= WLANs of roaming partners or of the MN user home. How does this solution su= pport that scenario if the LMA is not told specifically which WLAN the MN is= connected to? From a deployment point of view, I do not believe we can affo= rd to leave out this scenario. Please note that the establishment of a secur= ity relationship between the MN and the MAG, and a specific MAG identity, ca= nnot guarantee that the LMA knows which specific WLAN access network the MN= is connected to. Assuming that would severely restrict the deployment scena= rios. As for the MN and the LMA being magically in synch, I am very concerned abou= t a "glass ball" solution. You mention ANDSF defined by 3GPP as a solution f= or this "out of band" delivery of policy. Fair enough, however there is an i= ssue with that. ANDSF is designed specific to be a MN-centric solution where= policies are provisioned in the MN and the MN decides which network technol= ogies and access networks it needs to connect to, under what conditions, and= which IP traffic needs to be routed on such accesses. No IP point of attach= ment in the network (i.e. the PDN GW in 3GPP that is the LMA in PMIPv6) is a= ware under any conditions of such policy. Therefore, even if in order to app= ly this solution to 3GPP we wanted to use ANDSF, ANDSF would unfortunately n= ot provide a solution unless the MN can communicate to the MAG and the LMA t= he decisions the MN has taken based on the ANDSF policies. I believe the key point here is that we need to understand how the solution= can be realistically applied to a real scenario, and that we need to ensure= that important and realistic deployment scenarios are not excluded by the s= olution. Cheers, Stefano On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli > wrote: Hi Stefano: These are valid points and some good comments. Let me share my thoughts. Carlo's draft is not assuming any new MN-AR interface. Its going with the as= sumption there is established policy on the mobile and on the LMA, which all= ows the mobile to select the access network at a flow level granularity, wit= hout requiring any explicit signaling between the MAG and the MN. To large p= art this is all about out of band policy interface, such as ANDSF, towards t= he UE, leading to the assumption that magically the MN and the LMA are in sy= nc with respect to flow policies, access selection and they will make the ri= ght forwarding decision. Secondly, the flow policy decisions need not be bas= ed on the specific WLAN network, but it is implicitly driven by the MAG - LM= A security relation, where the MAG attachment to the WLAN network transitive= ly allows the LMA to make the flow policy decisions based on the MAG identit= y. If the WLAN network is not trusted, there is truly no MAG in that network= , where the LMA shares a security relation with that node. There are still some open issues on this draft that needs to be discussed in= the WG. On the approaches to allow more a flow aggregate movement, that is= a discussion point. There are issues that we need to discuss, supporting sp= lit link model, or eliminating some favorite brand of signaling message (FMA= ) and riding on PBU/PBA and just with one FMI trigger, and on the aspects ar= ound MN applying the flow policies by flow mirroring. We have no agreement o= n those issues yet. Its just a base draft, for further discussion and resolving those issues. Bu= t, hope that is not a stopper for base draft selection. Sri On 2/1/11 6:39 PM, "stefano faccin" > wrote: Raj, thanks for the email. I need to apologize in advance if my questions have already been answered be= fore (though I cannot find a conclusive answer anywhere). I think that a protocol that is developed in NETEXT (or other groups) should= have at least a potential realistic scenario for applicability. In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicate= to the network where the flows should be routed or for the LMA to receive s= omehow from somewhere some policies, the solution cannot really provide flow= mobility since there is no way to decide which flows are routed where. If w= e are thinking about a host-based solution, I have not yet seen a solution a= s to how the host can indicate to the MAG and ultimately to the MAG which fl= ows should be routed on each access. If we are relying on modifications of l= ayer 2 protocols, aren't we defining a solution that works only with some te= chnologies (since for other access technologies it is rather unrealistic to= modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-base= d solution, can we hear of at least one example of a real-life scenario wher= e the LMA would receive such policies, and how such delivery would happen? A= lso, should there be a solution to have policies in the LMA, how does the LM= A actually decide to route flows on one access or the other? E.g., if some f= lows need to be routed on certain WLAN networks, but shall not be routed on= other WLAN networks, how does the LMA know which specific WLAN network the= host is connected to? Perhaps I missed the ability for the MAG to know e.g.= the WLAN SSID and provide it to the LMA, in which case I would appreciate i= f somebody could highlight to me where that is defined. I think that, though not integral to the protocol specification, understandi= ng what framework the protocol would/needs to fit in is rather important. Cheers, Stefano On Tue, Feb 1, 2011 at 3:47 PM, > wrote: Hello, We have discussed the flow mobility solutions for Proxy MIP6 previously at IETFs 78 and 79. This is a consensus call for adopting this I-D: draft-bernardos-netext-pmipv6-flowmob-02 as the working group document. I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt The consensus call will expire on Feb 15th, 2011. Please indicate your support or concerns in adopting this I-D as the WG baseline document on the mailing list. Please note that this I-D will serve as the baseline in the WG and will be developed further based on input and feedback from WG members. -Basavaraj _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_002_01CBC497.69E98F49 Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable Re: [netext] Consensus call to adopt I-D: draft-b= ernardos-netext-pmipv6-flowmob as WG doc

Telemaco,

I apologize if I fail to make= my point.

 =

I am just trying to see how this solut= ion can get applied to a realistic case. I guess we want to design a protoco= l that solves issues and provides a tool for realistic use cases, I hope? If= so, my point is that we have open issues on how this protocol will be used= in those cases. Now, we also want to develop a protocol that has a customer= , correct? Not just have an academic exercise, correct? If so, it has been s= aid previously on this ML that 3GPP is the biggest potential customer for th= is work (if there are others I must have missed the emails indicating what o= ther customers are out there). So, if we want to make this applicable to 3GP= P, it means it will go in future releases of 3GPP, obviously. Which means it= needs to support what is already supported in current releases, otherwise y= ou are proposing a solution that steps backwards in time in terms of what it= can support.

 

As for the use cases I have provide= d (i.e. per access network versus per access technology), I have not heard a= ny real use case confuting the relevance of the use cases, but just what thi= s protocol cannot do to support them, which concerns me. <= /p>

Cheers,

 

Stefano Faccin

 

S= tandards Manager

Research I= n Motion Corporation
5000 Riverside Drive
Building 6,= Brazos East, Ste. 100

= Irving, Texas 75039 USA
Office: (972) 910 3451 

Internal: 820.63451

3DUntitled-1: (510) 230 8422

www.rim.com; www.blackberry.com

3D"cid:image004.png@01CB49EA.87D92140"

 

P Consider the environment before printing.

 =

From: MELIA, TELEMACO (TELEMA= CO) [mailto:telemaco.melia@alcatel-lucent.com]
Sent: Friday, Febr= uary 04, 2011 1:49 AM
To: Stefano Faccin; Sri Gundavelli; Giaretta= , Gerardo; stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nok= ia.com
Subject: RE: [netext] Consensus call to adopt I-D:draft-ber= nardos-netext-pmipv6-flowmob as WG doc

 

Stefano, all,=

 

<= p class=3DMsoNormal>I believe the authors of the draft never intended= to replicate all the features of the client based approach.

 

 

= telemaco

De : netext= -bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part de Stef= ano Faccin
Envoy=E9 : vendredi 4 f=E9vrier 2011 00:02
= =C0 : Sri Gundavelli; Giaretta, Gerardo; stefano faccin
Cc&nb= sp;: netext@ietf.org; Basavaraj.Patil@nokia.com
Objet : R= e: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowm= ob as WG doc

 

Sri,

I am glad to hear th= at you also think that the network-based flow mobility solution cannot intri= nsically provide all the features of the client-based approach. <= /span>

 

I am also glad that you hear that access selection solutions= in place today are sci-fi. Why do you believe that an operator that wants e= .g. to move the voice traffic and video streaming to the WLAN APs it deploys= (because it can offload them and can control QoS) may not want to move the= same flows to a WLAN in a hotel where the user will get an awful user exper= ience? Another example: policies may be configured by an enterprise in the d= evice so that the enterprise will allow the MN to direct some traffic on cer= tain WLAN APs (e.g. the one the enterprise deploys) but not on other WLAN AP= s. I think the per-access network scenarios are indeed more than realistic.= Perhaps we’re trying to oversimplify the scenarios just to fit the so= lution in them?

 <= /o:p>

Stefano Faccin

 

Standards Manager<= /o:p>

Research In Motion Corporation
5000 Riverside Drive
Building 6, Brazos East, Ste. 100=

Irving, Texas 75039 USA
O= ffice: (972) 910 3451 

I= nternal: 820.63451

3DUntitled-1: (510) 230 8422<= /p>

www.rim.com; www.blackberry.com

 

<= a href=3D"http://www.blackberry.com/">3D"cid:image004.png@01CB49EA.87D92140"<= /a>

 <= /span>

P Consider the environment b= efore printing.

 

From:<= /b> Sri G= undavelli [mailto:sgundave@cisco.com]
Sent: Thursday, February 03= , 2011 2:56 PM
To: Stefano Faccin; Giaretta, Gerardo; stefano facc= in
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-f= lowmob as WG doc

=  

Hi Stefano,
<= br>My point on the synchronized policy assumption still remains, as I’= ve noted in the other thread.

Therefore= , if we want to provide a protocol for network based flow mobility to provid= e an alternative to existing solutions, we need to provide a solution that r= ealistically provides the same functionality.

I will probably= take a defensive stand on this. As I’ve stated before, I do not belie= ve network-based mobility approaches can match client based approaches 1:1,= in every aspect. Its simply not possible, specially when we don’t hav= e the needed MN-AR interface argument, for carrying Attachment Preferences.= But, most of the features that are practical from deployment perspective (u= nlike some of the complex flow mobility scenarios, complexity in the order o= f science fiction moves :)), every thing else can be achieved over network-b= ased approaches, with out any MN-AR interface. Hence, my argument to keep th= e specs simple
 
As as for simplif= ied policies versus what current solutions already provide (e.g. per access= network policy and not just per access technology), why should we go ahead= with a solution that brings us back in time wrt what we can provide to user= s and operators? Please note that even today (and not just future rel= eases of 3GPP or future IETF protocols) there are deployment scenarios where= the decisions to choose or not whether to route traffic over a certain WLAN= is based on the specific WLAN (e.g. SSID) and not just on the fact that the= MN is connected to WLAN.

To large part, in the context of tr= usted non-3GPP access, basic flow mobility functions can be supported. We ca= n break this down and bring some of the aspects around network ownership, co= st parameters and tie the flow policy rules to it. But, I don’t think= the goal is to support all such features.



Regards
Sri
=


On 2/3/11 2:22 PM, "Stefano Faccin" <sfaccin@rim.com> wrote:

Hi Sri,
I need to agree with the Gerardo. You are maki= ng an assumption that is incorrect.Synchronizing policies between the MN and= the LMA is not an easy and scalable solution. I understand synchronizing po= licies between a MN and a policy server that is the only repository for a gi= ven MN (i.e. one MN has its policy in a single policy server). Assuming that= all the LMAs in a network that the MN can be connected to have synchronized= policies with the MN is clearly not realistic.

As as for simplified= policies versus what current solutions already provide (e.g. per access net= work policy and not just per access technology), why should we go ahead with= a solution that brings us back in time wrt what we can provide to users and= operators? Please note that even today (and not just future releases= of 3GPP or future IETF protocols) there are deployment scenarios where the= decisions to choose or not whether to route traffic over a certain WLAN is= based on the specific WLAN (e.g. SSID) and not just on the fact that the MN= is connected to WLAN.
 
Therefore, if we want to provide a prot= ocol for network based flow mobility to provide an alternative to existing s= olutions, we need to provide a solution that realistically provides the same= functionality.
 
Cheers,
 
Stefano Faccin Standards= ManagerResearch In Motion Corporation
5000 Riverside Drive
Bui= lding 6, Brazos East, Ste. 100Irving, Texas 75039 USA
Office: (972) 910= 3451  Internal: 820.63451: (510) 230 8422www= .rim.com <outbind://28-00000000119E3389DDC5= E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB000001B7908B0000F7B5= 0AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.rim.com> ; www.bl= ackberry.com <outbind://28-00000000119E3389= DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB000001B7908B0000= F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.blackberry.com>
<http://www.blackberry.com/&= gt;

P Consider the environment before= printing.


From: netext-bounces@ietf.org [m= ailto:netext-bounces@ietf.org] On Behalf Of Giaretta, Gerardo
= Sent: Wednesday, February 02, 2011 9:14 PM
To: Sri Gundavel= li; stefano faccin
Cc: netext@ietf.org= ; Basavaraj.Patil@nokia.comSubject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-n= etext-pmipv6-flowmob as WG doc

Hi Sri,
 
Ther= e is no implicit assumption of synchronized policies. A basic example that s= hows that there is no assumption is the following: ANDSF policies may be bas= ed also on location of the UE. For example the UE should prefer WLAN only in= a given location. When the UE is attached over WLAN there is no way for the= PDNGW/HA to verify the location of the UE and therefore to verify UE action= s based on policies.
 
The assumption on synchronization of polic= ies is only applicable to this draft and I think it is a wrong one.
&nbs= p;
Cheers
Gerardo
 

From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Sri Gundavelli<= br>Sent: Wednesday, February 02, 2011 6:50 PM
To: stefano f= accin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject:<= /b> Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-= flowmob as WG doc

Hi Stefano,

One comment.

Agree with yo= u there is no ANDSF interface to the network node, but the assumption of syn= chronized policies between the ANDSF server and the PDN GW/HA is there, impl= icitly IMO. With out this assumption, I do not know, how the HA can ever val= idate the flow mobility options received in the BU. If the operator requires= any control on enforcing a flow policy rule, the PDN GW/HA needs to have sy= nchronized policies, without which its always the client decision. I’m= not sure, operators in 3GPP would like that :)

No doubt, the lack o= f MN-AR interface is surely an issue for supporting complex flow policies. I= realize the issues and I agree with you. But, the assumption of synchronize= d policies can offer some solution with some configuration requirement on th= e HA (assuming there are no other issues). There are also the proposals on f= low mirroring on the UE ..., requiring no flow policies. I’ve not eval= uated this, however. Folks can comment on this.

It is also to be note= d, for some of the scenarios such, there is no flow policy interface needed.= We can identify what scenarios create any configuration limitations on the= HA and which one’s do not . As I’ve noted earlier, this is sure= ly an open issue, that we need to discuss in the WG.



Regards=
Sri




 


On 2/2/11 9:08 AM, "stefan= o faccin" <sfaccinstd@gmail.com= > wrote:
Sri,
thanks for the reply. Can you clarify in which system= or scenario ANDSF is available to network entities as well? There is no suc= h availability in 3GPP, and making such information available would require= considerable architectural changes, therefore the applicability of this sol= ution to what seems to be the only realistic scenario hinges on 3GPP making= considerable architectural changes. I would therefore not be so hastily con= cluding that the ANDSF information is available to the LMA and underestimate= what it would really take to make the solution applicable.

If we can= not guarantee that there is at least one realistic solution to have the MNa= nd LMA in synch, how do we expect that this solution is applicable at all?= In 3GPP there is no need to have such implicit assumption, be cause 1) the= MN is provided policies explicitly through the ANDSF, and 2) it is the MN a= nd only the MN that makes IP flow mobility decisions and communicates them e= xplicitly (with well defined signalling) to the LMA, and therefore no magic= is needed. There is no need in 3GPP to have the ANDSF and PDN GW policies s= ynchronized, since the PDN GW does not use such policies.

Sri, in th= e end it is a matter of whether we develop a solution that will rely on some= unknown magic to be deployed, or a solution that we know can be deployed in= at least one way because there are solutions to what I consider major open= issues.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 9:06 PM, Sr= i Gundavelli <sgundave@cisco.com> w= rote:
Hi Stefano,

Thanks for the discussion.

As you say, th= e ANDSF policies are allowing the MN a.) to make the right network attachmen= t decision and b.) make the access selection on a flow basis. This same poli= cy that is present in the ANDSF server, is available for the network nodes a= s well. I’m not sure, with out this assumption the solution can work f= or all currently listed cases. We clearly need the MN and the LMA to be in s= ynch with respect to the configured policy. How, that is done, I guess we wi= ll not try to know.  I thought even in 3GPP, this is the implied assump= tion ? But, this is for you to clarify. Not specifically for IFOM where UE a= nd PDN GW/HA are negotiating the flow policies, but generally that the PDN G= W and the ANDSF policy server will have synchronized policies. The MAG and t= he LMA have the ability to carry this flow policy information in signaling m= essages and influence the access selection. The policy is a opaque object, w= ith extensible formats, when carried in the signaling plane, should allow th= e LMA/MAG to apply those access policies, while assuming MN is following the= same rules. These policies can surely reflect the specific WLAN access/oper= ator specific rule. I’m surely with you, the lack of MN-AR interface i= s surely an issue and I see that. But, we need to understand, what are the l= imitations with the approach of  out of band policy interfaces and what= will be the solution limitations. If we need to tie the flow movement at th= e prefix granularity and rely on the natural ND interface in the form of RA= PIO option, more like PDN offload in MAPCON, or at the granularity of a flo= w level, is open for discussion. I want to simplify this draft for sure, we= can surely discuss each of these issues on the WG draft.


Regards=
Sri






On 2/1/11 8:29 PM, "stefano faccin&q= uot; <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com> >= wrote:
Sri,
thanks for the reply.

I'd like to comment on the &quo= t;the flow policy decisions need not be based on the specific WLAN network&qu= ot;. Does it mean, as I believe it does, that the current solution would not= allow an operator deploying such solution to decide to route flows over a s= pecific WLAN or not depending on which specific WLAN the MN is connected to?= E.g. the operator or the entity in control of the decisions for the routing= may want to direct certain traffic always over WLANs that the operator depl= oys, and instead route only some of the traffic over WLANs of roaming partne= rs or of the MN user home. How does this solution support that scenario if t= he LMA is not told specifically which WLAN the MN is connected to? From a de= ployment point of view, I do not believe we can afford to leave out this sce= nario. Please note that the establishment of a security relationship between= the MN and the MAG, and a specific MAG identity, cannot guarantee that the= LMA knows which specific WLAN access network the MN is connected to. Assumi= ng that would severely restrict the deployment scenarios.

As for the MN= and the LMA being magically in synch, I am very concerned about a "gla= ss ball" solution. You mention ANDSF defined by 3GPP as a solution for= this "out of band" delivery of policy. Fair enough, however there= is an issue with that. ANDSF is designed specific to be a MN-centric soluti= on where policies are provisioned in the MN and the MN decides which network= technologies and access networks it needs to connect to, under what conditi= ons, and which IP traffic needs to be routed on such accesses. No IP point o= f attachment in the network (i.e. the PDN GW in 3GPP that is the LMA in PMIP= v6) is aware under any conditions of such policy. Therefore, even if in orde= r to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would unfortu= nately not provide a solution unless the MN can communicate to the MAG and t= he LMA the decisions the MN has taken based on the ANDSF policies.

I= believe the key point here is that we need to understand how the solution c= an be realistically applied to a real scenario, and that we need to ensure t= hat important and realistic deployment scenarios are not excluded by the sol= ution.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 7:43 PM, Sri G= undavelli <sgundave@cisco.com <http://sgundave@cisco.com> > wro= te:
Hi Stefano:

These are valid points and some good comments. Let= me share my thoughts.

Carlo’s draft is not assuming any new MN= -AR interface. Its going with the assumption there is established policy on= the mobile and on the LMA, which allows the mobile to select the access net= work at a flow level granularity, without requiring any explicit signaling b= etween the MAG and the MN. To large part this is all about out of band polic= y interface, such as ANDSF, towards the UE, leading to the assumption that m= agically the MN and the LMA are in sync with respect to flow policies, acces= s selection and they will make the right forwarding decision. Secondly, the= flow policy decisions need not be based on the specific WLAN network, but i= t is implicitly driven by the MAG – LMA security relation, where the M= AG attachment to the WLAN network transitively allows the LMA to make the fl= ow policy decisions based on the MAG identity. If the WLAN network is not tr= usted, there is truly no MAG in that network, where the LMA shares a securit= y relation with that node.

There are still some open issues on this d= raft that needs to be discussed in the WG.  On the approaches to allow= more a flow aggregate movement, that is a discussion point. There are issue= s that we need to discuss, supporting split link model, or eliminating some= favorite brand of signaling message (FMA) and riding on PBU/PBA and just wi= th one FMI trigger, and on the aspects around MN applying the flow policies= by flow mirroring. We have no agreement on those issues yet.

Its jus= t a base draft, for further discussion and resolving those issues. But, hope= that is not a stopper for base draft selection.


Sri






On 2/1/11 6:39 PM, "= ;stefano faccin" <sfaccinstd@gmail.= com <http://sfaccinstd@gmail.= com>  <http://sfaccin= std@gmail.com> > wrote:
Raj,
thanks for the email.

I= need to apologize in advance if my questions have already been answered bef= ore (though I cannot find a conclusive answer anywhere).

I think that= a protocol that is developed in NETEXT (or other groups) should have at lea= st a potential realistic scenario for applicability.

In terms of appl= icability, though it is not part of the protocol definition per se, unless t= here are solutions in place for either the host to indicate to the network w= here the flows should be routed or for the LMA to receive somehow from somew= here some policies, the solution cannot really provide flow mobility since t= here is no way to decide which flows are routed where. If we are thinking ab= out a host-based solution, I have not yet seen a solution as to how the host= can indicate to the MAG and ultimately to the MAG which flows should be rou= ted on each access. If we are relying on modifications of layer 2 protocols,= aren't we defining a solution that works only with some technologies (since= for other access technologies it is rather unrealistic to modify L2 for IP= flow mobility purposes)? If we are thinking of an LMA-based solution, can w= e hear of at least one example of a real-life scenario where the LMA would r= eceive such policies, and how such delivery would happen? Also, should there= be a solution to have policies in the LMA, how does the LMA actually decide= to route flows on one access or the other? E.g., if some flows need to be r= outed on certain WLAN networks, but shall not be routed on other WLAN networ= ks, how does the LMA know which specific WLAN network the host is connected= to? Perhaps I missed the ability for the MAG to know e.g. the WLAN SSID and= provide it to the LMA, in which case I would appreciate if somebody could h= ighlight to me where that is defined.

I think that, though not integr= al to the protocol specification, understanding what framework the protocol= would/needs to fit in is rather important.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 3:47 PM,  <Basavaraj.Patil@nokia.com <http://Basavaraj.Patil@nokia.com>  <http://Basavaraj.Patil@nokia.com> &g= t; wrote:

Hello,

We have discussed the flow mobility solutions= for Proxy MIP6 previously at
IETFs 78 and 79.
This is a consensus cal= l for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as t= he working group document.
I-D: http://www.ietf.org/id/draft-bernardo= s-netext-pmipv6-flowmob-02.txt

The consensus call will expire on= Feb 15th, 2011. Please indicate your
support or concerns in adopting thi= s I-D as the WG baseline document on
the mailing list.

Please note= that this I-D will serve as the baseline in the WG and will be
developed= further based on input and feedback from WG members.

-Basavaraj
<= br>_______________________________________________
netext mailing listnetext@ietf.org <http://netext@ietf.org>  <http://netext@ietf.org>
https://www.ietf.org/mailman/listinfo/netext=

 
 
-------------------------------------------------= --------------------
This transmission (including any attachments) may c= ontain confidential information, privileged material (including material pro= tected by the solicitor-client or other applicable privileges), or constitut= e non-public information. Any use of this information by anyone other than t= he intended recipient is prohibited. If you have received this transmission= in error, please immediately reply to the sender and delete this informatio= n from your system. Use, dissemination, distribution, or reproduction of thi= s transmission by unintended recipients is not authorized and may be unlawfu= l.

-------------------------------= --------------------------------------
This transmission (including any= attachments) may contain confidential information, privileged material (inc= luding material protected by the solicitor-client or other applicable privil= eges), or constitute non-public information. Any use of this information by= anyone other than the intended recipient is prohibited. If you have receive= d this transmission in error, please immediately reply to the sender and del= ete this information from your system. Use, dissemination, distribution, or= reproduction of this transmission by unintended recipients is not authorize= d and may be unlawful.

--------------------------------= -------------------------------------
=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_002_01CBC497.69E98F49-- ------_=_NextPart_001_01CBC497.69E98F49 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAKAA4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDSu9Nv V0vVpbjQL2KfU7xR5T6qqmRclsrnhecDFbGl6hqL69Noem63ZRQ6faops5Y2mmiYBQdz8BuSR1qD 4pxpLdeHo5UV0N2cqwyD93tXexW0ELtJFBGjv95lQAt9T3oA/9k= ------_=_NextPart_001_01CBC497.69E98F49 Content-Type: image/png; name="image002.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.png Content-Location: image002.png iVBORw0KGgoAAAANSUhEUgAAAIoAAAA+CAIAAAB7vhRQAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAIthJREFUeF7tfAeYHdWV5q1b8eXXudXKoAyIIH1IgESwMTKDSDZebNKsZa8/ xh8MNgxj1mYxLGZtgseDDcwABsb2YH9ggglDMAiEyCIMEkkSCOWW1Orw8qt0b+1/ql4/tbJEN9t8 OxSPp3rVFc+555z//OfcUtjwLZyxAB/8I8ObUMLfGmNCYYES/Yq+63/ETyz1LdH6Hvbh4RXCwxX8 I2vrOH3tSNqK1W2X7j/78Ill4JWj5x2epaaeSPZ1qdPPUKpDs9TUs93JdrhcXflDc8X/T8+CAQ65 QWef7dJ/DbV+mf4hqjO2beNnexP7evbhtJ6d7xGOLc30pKpLJjh5nMEtsBw1kIH0hfRZUGXS7fej kUMV0elxVfyQpBts9wZ3zaE9etAiGPTtbIsciqIFwXg1MbtpkukFYkj8mxJIJv1AQtt24FUDv2rb ObfQy7xe6Zajm4dawrj0OXRyw68euBQasByxm9RzmN5wZHysXvZ2Np4IBezPgt0FziMVnFuRipRc VVTF80XOlJ1Bpada6HKKBSagGjjW2ngYkmGxP3e5h32H2dlCfpFrCWOOYgTsEKO1mZmKH4TOTYm+ EZbqPyHpaAtW9rBPwBQ1YDzA3gHgGcdvEQRCqjLgMlClbFStsWa2XUvEGPdEFffgq5zJz5Ny9ns4 DtGgqJ0GFiOZyZgD7xJ6mIRkp6cnZ3wdGovA9iAWIHboxYdiAtK1VELpS5iKpsSEwt1wi8bzOlsj c+9UOrtxB3VXO4gLD+Ghw2o9oavCHfj0D9lDo9QPNVpMH0Kt+5pP+bBwaQFXuEwF3GO8wgKLC2jL NgwWuDGcXdU8FQZIMc5PGNaIRNat5l0W+NGVDTJqstPo+vQP7pTEFW4kkBnZfKTQMEnAV/jvtsM+ 5c3XDxtu9URZYaSeIGhXE1P0BtUVUuHkmsLH/bQfWA9XpMG5w3mF+xlViWvcF76tsWygWK6iicDA h3ELu5k8meXpXr+UIzkbiFdhwqzhJAFpJfSoFMLwk/TCSUHQN6kpUlWo1iH2jcOnnn43su2BJBsX bxwDD+d6gabCfsIIM7gPsxVeIbGKRilMRfV9WRIycPA//Qefx6AxSL3ienHDsiXbKMsMcI90QzKH a+y3EODwSAF0y+H2yHhgaBBjDaX32xp8Nv40WA+9n1BosMa60/EDfD0g3DGZ8Qfb8ELMh3qG4FqQ shuoNqEJdxzQhuQbmjsc3/cRegLmqTBSSBF64tyHm1OCSlJ9Nd/TY4uqChjJkH9BC+CYYNyBp1Rt GFWAw30xUPCRkgaqB9oibipy24NZhlU90cX7zadZs2anx4wra1wEQ6QeISFftQwHJbyRrl9oG1ue d1qHLXPkqHTJJf4AyStCCkVVgRrcGN/Iq1vsfCEIDENTfYGI5UFRAVd9U2B3qZYroq9Q6S3wrm73 veV9FQCbmslggJnYVVFsYMTBaKV+7LCqZ8ATYLCNt1IzzI4OV/dcT+j6oK1HQKaA0KriBBwDPusp XVOP8A6dAyvqczyLKSaoPWgoCuTwcnBkUmM2l+vL+T78TSXlQTVkPdAwTDGkalVV182UZLphGlXb Xdvtvfpm5ePldsmDyQB7AhpWB6a6g9HT8MWe7UeIxdhIJd6hpmMe/AYH6Br0wAkQtxURI96Ae8DW Us1PODiebMhJ3ZXCkkEyCDRIWUodbiwI9EDRmQBE0asiKApfKpoCG0A2S7icQADpDw7LF7YD8qFU KuZ5UMlkxWEHJVoam/K91VK5CtRJHhPLYOMOneNzpJ7RVqZNTZquj2GKYABRcNFPXRMHF3lBCH27 TzjoMbjDuE0SQcZEcEKEyEqVJlMxlitSqJrFD5jabCSQgSIrtSBvsgYcgDPjULg7rGOroRY1v1fa Piwa8JwjRgUCvo3DlkhfgiuGYZIqQ3ARuKJcqI4ebY4+INFbKG/tiTBBPNTPYIHccKonKihEfiCl 8AOtxgbgYMQLxdAgD8arhi9U6MV3VaEHXpwMS0V8hyGE3xwUgIbwLuHpdQQRgW0QvYqggi8SO4Vw 7CVjbuClmt2JByX0uOv7psI5Zy6cFwcgQKzDChcC+ADy17ijyB7XJkRNtAQCIWmcSV1wrGnwb67n wbp0AyRUoPksnmQ9hUos5s6c0dy92d7SjcdKhuigPy59Wgc3aA//aS/cH05rxycUtYHFFV8Knfu6 qgeq5SvIUDyOtF94ug8MnILiyEoge8QDaIf8Hwa3RtEBnBoxOIFKPo1clMI0IQIV5J3p+yMVpsaz RT21STEKwquqVO7TVaFxMAdCVel0+EAd+AluSbU8FhPc8EjthkcFKD1wLGHrim0EXkwNDEjOR/YM olCtYucYCxzJ8uUzTkq0QjWspCiDhW3D7NxqGV2Irdu4OUrPxMD7g/lHFAiEJjFylbSjxzyzymI+ h7tgtpn3NN/ThVB9T3U9zXORXKq+JRwdQV1xFcVD+AZdI7jucoOrCDMSwVyyraMPVEaNM1y/xJGH 1vJ/KBXATYXwWYDBrsPwYLalwO/yq74BuEAWFLIE8Lak0uiDhf5FPoXxIaFr7EjUkRRBIq1WpbFq jT0kzm04rYd8M54vhKAZNW4oOp5cwsErAnIXGtM8riNmMAPS9aRflkKr6pqrKRUDOhS26dsxz447 +Pa49FWiviEWTxGu6vlGVcR9G5ahStf1PSeTbGZ+UlbjikyhxsAk4K8bSA80HOAD0aZS00AHBEDj vkdWqbrIh8APMFWDqYa8QY3TIe3U2AJKU8MclaIY94uFypSpMQMYe7tM6FM6mV3HnjBM7t8y8JD9 PRxjZHK8oVVJaJTBBxY4A6l1uvl8YPeygs2KCVMkY7aluczVbGFrgYEYA0emBDrkhKFb1dQi1GUq qZhiqm5cF5bhW7qIm25Mh3SrmUbnoMMbzWSFaDfdZLxk6GVVRX5FsYch52S+DACqwTKIQmB3o0Jk IPIjlCkYJwQa4P52LGiQI4U/hFtEhFQQmngAbWcakytXy3x+CJzbbtVwySWXnHvuucuWLbvyyis3 b968V11FKom+ETCj/esr9cN1Xfc87/jjj7/22muF5137s58tfO45uK1TUpNbhaa5wtWVmMs3id5J X/nKOddcVu3deufPfsRWvP+tL83u9HuThx1+0FFz0uMPhC8KwDyHIAkykqZR2fTxsof+zV2zrNkS ik+igWB9jsCD8CBEbOv0WY026wJe84HoRIoJi7wnRC8VDArHAVz2pes7rreqVFleZFqCIfkC6Pbh vuC5iELYUVxECwmDaa7PmerD0MkejWzmwSe8d5ZW9iq0ve6w3fXqwh05cuSGDRuig2+//fYLL7xw dyci/xsqIzoWgEgigMOlAzgRbagIsYv8edGiRccddxz2f/fdd08+dX7v2nXfaj4sWXA0wSqQh+0l Jh1w5ZN/yh7QhH1eeeTeRy757twJDeljjpn1kztNI7u7mym889Qj/7igI+GbQGUE2zSHJRSNV7zu bIeceEhDNegBVgMhEAYScNXEe4LlZICCBOXBw6LOwPLSX1u0t/ZWK4WgDHSQYm5UaoiiDT1tffzB h4XqUeGKgScxZmRgJha/pS5cVNir9Pe6w65jz4QJE3Ck4xAuPO200/ZwloGGgnUoA9/QDQ1eKXep G/zJNMEYMtfxJk6YOHnSBHCKloockGhI7gc5Zp/ygwXQjY0kL2CZTEvLyLEl3z/2ssugm4rwkTaW A4YPUhhHSlfKcohgY9kW3UggaxeSu4HuKDGQXhwkmV1pa0xRsMAVgIwlyn40rNCIQBgQJ2BVIcuB KMqgLJSCqdlTWpMzxzbMmtg4MqOVy6RtSrAoSwrNtT/ehAEozD/DqhKNT8L+pOohWbZTDyQbGUEk 30j0kSh3ucyePfsPf/jDzTfffMcdd8BfYZ9Jkyb95je/ufXWW2+77bYzzjhj5yA00PsZJjJ2ZCe8 mSWE42JEAgP1+bmDTjnuhL/7ZgkZkabi6Tdt3NKzsThu9ldYehJaOpBn6lxJKLALFuPM5MBnPEH3 6L/86P0lpxRoBhg0Qm4YzcB1fgWxJdVgSkgf8iMyvErx3wdmxpBA6FJNRdNBgRKoJmihigpz+jKB 0Z6MHz65beqkNLIk4YZZrI6UGfKJKGtKlQNVEMGNcwVSU6TnMcM0C7khCDx4JAS97ZZIMdFioHTV 77UG7qRpGjgsbDn77LPPO++86E8IVIlEAkq66KKLoi3z589/++23161bVz82Cjx1xVNXIIjgwBtj NRgeYJPquU4P87932/XYBzaR0Hi5u/D23XePMTZZo1sYa3Q4s+CNyptfeuwPaQvjGDCaiqJm38au F1/rW782kY2XNLNBagm7xPXNuZjVUI7HzSY37sVk0VOa/HJb0vogxpSylq3qNpQUVxJWscLUWNnw dIyIKugcoSRcUbGkV0ynSoc3j2hLO++95+Rd7qLcITQL+yHN8TQJt2YGvNJgsRxXBQxXseJVuOgq PbQK2Bj6dpgTlkho9QE6bty4fD7vum61Gu7dbxUDRb0nYL1DnK8fFl0Gy5w5c+obFy5ciPW5c+fW t7zzzju5XA66TKfTqVQqmUxGutm2UAWOJZAwuj4GpC3FSrbm76+/vnXMKOG7CYWw7FO33LVy2ZKx IxvdCkVancHI8izoefa6f1zyq58sv/nKVb/6nx/885Vv/flud8P77UY1w6oqnQnQwRRmCsEMGVRG r8TMXNlk6P4wp33VaZjRR56oL+EmY46le8W+WLkczyUwImzdaxhlN4+WBnPVzbrWKxxghc0dCeew qUaGx5Uyg2eErbsurMTlQQz9Pp7EcwW+w0gXaDXx+KYuWCF+CoSGY489FoO+Pu6jaB2LxW666aYH H3zwlltuwfpAqxgooR2tZzvx7eZHHQ7g7I899hi0tWXLlieeeAK7P/7442vWrMFtwWgQ/wuFwr33 3nvggQdCMbAtgMBot9pC0TZoDCyffFDQ7RemHTj3lEu/g3IPfpoKy6/e+O//++eHTWowdQr1OKqi aCkFoTirptvMVFzzqokA7t7xrSAh/JhbQRZKgV5Nu0q8RyDB8SiRSsIdFvq4Vu7155zw7U9eNzZt eauD61rVBYODQJVvyoh8YSxT8pVKZvp3M+MnrH70iga9YCpBoZKwjfZ4blU2npk2ofn1FR/mcn4C BJHoyeWDRMIzYJEcdgluuyHQSoKXN2+NdedqTuiCCy4oFouLFy+GAqAGGEqkCQgNIeDQQw+1bZtU vSsvRRt3qQIYAc4YhaLe3t6mJkJQ9YX4qtAS68a7B6UOxNZQ3qmnnoqdX3755aOPPhor0N8V37jA +evbqCav93v++ZGHDp5/fCGoJDxTNdSfnblgyV/uOWPGxI50Z/vJ3zrk8ju3IoEFBPCdJX+5N2Px JDyG43dvXP3BS/e1F3qaglLJ8h0lqYlMsSLTR88YP+uYl//XT6af9VUj/Xyx7cBEdsS4GdcrpTVa Kub16B8+d1mu9PERx/46M+O0/IcfaIl1nyy86oDjb0uMP6n02vc+WHhnE+oLjceMPnFB570XNZzw 3arrP3rfnbNPvPjIs35Y6vn4X2+4elP3m9847+pXX/9d58fvn3POL99a+uC6zldfeNl8+XX1xUUL m9qypmn97ne/++lPf3r55ZffcMMNn3zyCXz+hx9+WA8QkWIiSe6ch+zJue3O4iLdnHDCCRgCOCOW 9evXYyN8XfQTC1IlGE2kSFwYS7lcBo4YqEg4Hl3T04GV4tYWN/e1y34A3TghSwrdPPfHp/7jL7+f bna0N8UAq4SmIoVuQwLjVZmoHnnWeZPnnz/yb84de+aCGRdd+zfX3r3V7OjjTdJooEIA/IePdLaY POLY9JxTpl1xV3r838Wbz40Zh6DMU8h3Lbn9HN+0EtNOGTflv8cPmvv6Lcd0vnd7YswpxULQu3zh +rVvvfPSbxMNqoyxiuUnRx+/SfG9bCbPqvNO/f7EE753yYJZD/715n+4/r687Y8Ye6QWz6LY0zhq rpYcnSuZi1+177jt1s7ujZMnT8HDwGK++c1vfv/734carr76aviPMWPGQHRQSSQNiCuS5M6jfO+x Z+djopg0b968+p9GjRrV0dGBGFPf0tbWdtBBB0E9wA5nnnkmQAT2uf/++weeDXEUi6mpfTI/8uBp Z//wQoAFz7PhvsrrCndcedME1pYwAyvmoXsmRN2oNIBh1oQWp/zRd8pS5hl6A5hvtPBMu6PFcoBd qgGA35JJbl21lBV6R8w/3+9cGp84L94wS65eCdY1t+lD1tnj51ZypzvR0rJl49LCx8tXvPGIw7oV UZGsV7ELdhFZglJBkNVitm30BAkHVIWTz04ZtfI/n1j60ab/WPgo4mZTi1IpF+ySU0AEEjyRbHn6 GYo6X5p3wrL/XIqVp556Kh6PT548GYEAP//85z9/9NFHSCujUbtXemW/Obco5cTZx44di2/YxIoV K6677rrOzs6pU6diS6lU6uvru+qqq3BnEydOhG/FMOnq6gJMqOumPlKASU3V/JB1XXzlFU0jWtEL nQDKZcojt99TWd0VY2oyGVNiPgqXUXW4rGkO131gaSOua3GD63HGE4B5ne/yYpcKrg68CogWsJzg 4PxqYfOaw78yb91jv060x9rHN9tbl6LFIBMXforlWNrPWqs7l7ccMKX5qIOnzV9gsGQllgaCzCTT HdlpnqubpsoKWjyZnTLrghEjTner0worlh4ye+bXvnzet8+6xS/1yl6eSKgHHzF35qy5B0467LXX tq5cRff51LNPzvvqScfOnXvWWWfBMpB9A9lGXAnG8fLly7EC5LZLixk4gveknl0eXM+NAKBhEFDA UUcdhZiPkyIBymaz7e3tuDAuj4j34x//+IEHHsCQQST75S9/GV0YRgYUhxWPCVPVenq7jxs5e/rZ J/fYZQd2oirvvrj44d/8FrpJK4lsOmNTxT9MMZC9BgJsqKmUtix51l72vL76VfXVh1645m8X/ury RGltIy/rYFXIm2sYFvFEYuVLi9gnL/nFNyufPCr7Him6a7n/hsx3gSYz3bfHVlZobz5eevP+w8++ qjE1RikuzijehvWLY8m+KV/+uiurSECLq97a+swVo0YHPfm3mrPjVr/5l+L7//L3V19+4kktN143 R69WH/njvx4/98QfXn7PrTf+/JZbHgjrV+kf/cOljltF9vfGG29gvD700EN4/Oeff/7EE0/8+te/ juGL7x0i+s5eClt2hAYRKhsIDXp6epqbm3c4uJ7BDNyOkQL1YAvs6cUXX2xsbIRW4OKifXCLuCes tLS0ANRNnTLV4Uo1l7vizPNu/OOf0iNSwDQxeDCVXXHo8SuXLZtgzBLuu0d9mTU2+ZVNW1pPv/jI y35dCWQcBOTWj6+YPXF8BmQKM5PMSmttaCSE/nxWVlFBQx+BAWYNjQOb7E0dY+MTJigAyEBLqay+ vttrzqRjmlLOF7knsxljfc6l3ilTR3xpbNMKKP9t9VWdNbQhX4kVS23ZcUcEo8eNGTdh9dNP+92L uyt9z77FPiqw0WNYm2n2BtbmnurjT7o9pagTOR6yCvtEuNUx8C51g43bWc8Oe0dObMdkJTwTNkZh PyLWsAJ/et99990ZLtAKgBlsCx7v1XB58sknr7nmmugmIuwABxTOVgsuvOonqZZ4gN4k4UM3z/zT 799ZtqQ51l4RjmUAOVSRigegqsGWIO8BTEaJLmmMSLJRjfrYDpZJQw16V9HvdrUcHKOCD4KsCHCY 5G1ZbcKYrK5a7UmtIROD7Y1psgxe8AKU5rjerBe4bGrVW8arrR2ydQyqgDyjqa3tjAakx3wH8xry SDvNwF/5/MPFrkUGz3e0xKcfmjh4mtbYmGbxRE+X+GCZki9FbW0GSNJ91E0kit0pJtq+nfUQVxQu 8JKwRMQuhA3YJkIL4lvtgDD2gMl++OGHB0I74EXkQPWLwVBgLplMJmJIK5VKhFVwTqSosC1A/kqA Zmque4p0XMQczrXeTZtPPXhmk6eaepoXrAmZLXPmsVhQLazrbv3ad+Zc+lsknEhhVLf04M8vb08G pvT8wLLVpK76xc2rty5/O6N5BuoC0A9IHcn1ZG7q9HY0gQhWRo2Oghh1doBfhixR3AE/SLRtWGkj n4jqAkSiSir3oNMObQ/CMHNVTzPigeJlFAdO2U8k3umyXl/lbtiiLH+/vHK1ADVIsiZ2G54NKerQ dFHtQj1021IioqxcuTJaj6xkhwXbH330UUCy+vbzzz//4osvBlIAkQoG4cYbb6z/qW6UdZcIjzxz 5kyU16AuI6x0+YjyjJ9+xunPPvJoFnWYAKVKeXIzP+OkJtfOeT2lscd89ZjrnvQks9FfoCmGhwoz ckFwXgbqAzT9I8i998Bti3/7i7Y4GhDQpqHagTZiUmXC1IRQ4HeIXkG3GjVEoREIoAktOCCow177 6AnBMAUijoInNutIVtFT4NpqApexHbB4fialVCt9+U1+6sEl+r2LenttaidFGtbfUQNelmrtdbEO nhfdbb3nvffeQ9iArDHksURmCFVFJFKE2feMC+vZK8HnfrwX6eyuu+5asGCBg9ovknwfHWM6fN3d /3bPd769AGVGjSlVXIqJi6am5s1q7c11qV6p4mS/8/RaxlO4gSoGuIJ+DrR84MZQmoPrY+iYEl1v 3vnd+RmlZKGsoXBHGplGnkqDHi0rHNU2dG7gQmCqHfTdEIEJSyIvS2U3PA1WoEEk26iwGS4VSVFj 9aQjuOchkpXjQamMaxWsjj8tk0+v2KQoTeSlyW6gmGpYZajVTfu7RAeroN2qB0wR3BfC+86mE215 4YUXIpZ6v5aoIATQ8sorr4Derh/712eeOeecb/V09/T3iNGsrF/NbxqnWbbmgKdcv6Y8/Rs/+NKl NyHFpmaz/gkDEcePb5TVVj1z5+M3/ag9IQ3pUREUNuamBNqq0UtFHVGWRCeQgokj0Ca0r1OhFW3y YUEP56BWQ7UY6BW063Cpc4E+RSpKU+sPlYKAN6pcV/qsUfcuLT+zYiPjiHugjKAbKnyE56g/ECh0 3ONgvdyeitbTp09HugvcjJrCQEYPtwC68xe/+EVEFuzXUudukaldfullM2bOqLru66+/dt11/6d7 61aiOjCqkUVLFRbw+79tT26WOQ3NNiVDptcV5ZTj5h987MnZtjEoJWH8U3CFQUNhQm54/9XXHrpH K3VlkZgi+aSeNNghXJbLVJe601CLkEZoRqH5hX+l6BwW2cLm26jPEBaEPyFOGqizRlP4EaE0VuKi hDvsMttuXbT57S0guUP5R1oJvzG2+gn/qEvsM7OeutCBlevOLdqIxwDaxgoqDhGdt+8Ljo3AXkR7 t7a2wllFZ7NUtNVIZhmq7XgBnzxaufFL6dQGc2tS2mYhBipfFD1cT0tyoxFhwlKQ4viOqrhaTPVB 9FQ15sdVtHNgRJOQMewD1ZMK2jYdKIZLdIaaauDBmKgHETMLSC31MR92LUjM/DJRoGZalfw5tgBN SLRjQ1ueGbhcMzay5hueXr2aGIVIKaSc2hQT8NaRTrazpH0Xz4577rYNMUJx2B35HVijHZZIxDCp vULDHS6I0UeSC102QFKpXI6qHXA0VMDEwIVZcBPczdwpqUOTLvcMYTLHLVgq8lRmIV5wjeYOeI4m weej3uMrvp3Ah8uYTsM/RCLRKKKCBbXUUhMHSqNgFKi8GfXcADsQwUCSDGNjBN5gjGFPPOKNROGW urDJ0+G+0HmCmamSW6tyyqKPAQvgvgwUW8Nz4BqYCUTqrdlLZDyDXnarnj3LvU597u8NRBqlZfv7 h0+oEbbkX1AIFd8Ynx6ZopmFQeAkwcVxboOhpuY3TP2BP0OER20aokShE3CZOtSonR1yrk0oDZEY NRBCC4C8YeCGUqhmjvYb2nFgX1RtKhXabRBLaGTi7CgQoaSAO9AxprioAGmLVPq1TnfJRqQ5uKhH o6HmxFCKGzAxdSh0A9nuN+e2v/r4NPsHTloLWhujgEfN52HvX1hLpr4NiL023CF9GAT1SpMxh/Im kWMc1z7hBsqAqameWgFqT0wH7HLaHTWbUgsp4TuGVkgXGB1pEGVCMClNL0tjyXJyxeGJqLf3M10+ l+phTmNcTxqqcF2yFgx/ShbDcBItxDhEGqhJPPRRtclq0Xr9U1ujM0TaCw/ejVAx0xRXJI9I14Ql oU0XU1DRJEzsMo8n31tXWVFEuAV2qKGG/4LqYe1JNaa6od9AdzqaLWha2mcqCDo58jD0g8LOwuhI U63IdNBaj0urwkxWldSTb28Jx0RUZaZb+kxv6/NoPYiHk9tT8cCl8Rm2n5GtgEUboilnu1dzNIuH SGFUMAAQwDPZmM5jWGVulszWB1/bsryMGIM/omJO0/2HYg7Pnkbd51E9lspGpDCp2oagPLAzJLLI i4Vpyf43GO+32RHAI0LB9QMtnoIz09PNS9fbr3ycD0+F8QP/9v/i5TufR/XENK0xoWnCQcZBegnn 54KWq01Tp7ewRO2A+/DZjesByhrwGZhAApeHs+AolGmaZRVtv3lEx5othftfWdtFExl1pmtoBKYe s5qqPkN88HlUT3NSbUxgZrTqCY8SFHr/HmgwmuVObTlIt8IZBXv9EK+w42Q6aubEpDbCz9SESA6M 3jyBJQSJ4QxTmiCEpnaUbm0/iDV3vPJ+5x1PdXZiAiQQgRrH/Iloqnyolv4JJfttoft0wGeo+X24 PooUrop32eAfglOwFhwkTplk/Y8jUlUPbZmUH9IMjoi/IcQcvVxg7wuxcEBp1Ly5484wPw0MOSZU QTFq2N4JIhA6ozQV/W0o2pTjeM9OLF7Umx/+yPvTErSbQyMRP0K4IZLaPt3H3u90T3sMr3ow4Zfm tuE5Q+4QFRZ6v9cPDmv8b1PNzlzJMjC/wKf5GSGpFQIq6h/Z90f2qId6Z0GG7dUhpRBOHg1nFRGY Vgi7SdVMpnwttryr+tLyvufWlqm3g6ZoDZbf3Pfbru+5H4/6Kc6+50MigVMUpv2QSSgWCDHGrjmx fXqjV3YEKnSkHnRab+MYIvZx7wsN7ZChJG3Wx3nt0MAHhw1DpDwWhTcYKOgZaujWrVhFUzeUtcff Lby+BjVYcmJgb3CCWqPt3q88lHvs06MO5QUHnAtPDgGGAAhvhkJRi2azYWbUP51/gOl2YtYvKmIh /4XcEEA2OpLKnbu5n+3MJFKjRTMUIo9U90Y0KnSwAGin51rALa6iO8A0Y0m7ai9b37ukq7hso7MW 0+dIL8hv/BhoHsyG+IyksMfTDqd6UEvB5UOPjrFrYaaHIpzpTea1Z01XeteB90eiDhqSwvu2F+aC AcP+FMe38fgDifxI2VFdAKQYAj0B8tCWAAKiCEYgA3K3XKb1VN28p27I2R+u71m9tbwRE7BCeYVn xz7Ru1eiK/6Xc241QYbCQzEGz+8fPSZz5swDZK4rbBbpb9uKvFOIssMpCdgzfBsBRaSQ8yfJh6/t ILlGTg1/V3y814o8WFgbQPSXCtJMcPA9Za/L0fpcpTufhwvDZJV+Ugi0JyIizu/0GyPOhgkNOM8+ Nd8MrY0Np/VQGQE1mfBdkf20vEhREIBDq72FY9foaHtfVauGRd6r7uFCnUQGSm/co76J6N0U9IGJ bHvlAM2BDKdqI/5jwjFKqVToxFyV/rYBGhAYDUMzZWe/9De86kG8wTsd0BZDEYjIf4A3VEprXPIu 4Wu9PNnvgequaNtK/cC6A4xkQtojo8MXiG56HxL4NUzLA69G7zUIVenR/AjaGcU6HIHEK+oerpdB 90u8g915eNWDwU2tLQNielQfhsevF6IG2g+Jr//NuRHii+4/Guh1UBdtDDtwavXQunpCpaKQjf7m mm2EnEQIOcLXwVANIzST8AbIc9Yx4GBl/cXxX0jgCwl8IYEvJBBJ4P8CkLsiseCTLsQAAAAASUVO RK5CYII= ------_=_NextPart_001_01CBC497.69E98F49 Content-Type: image/jpeg; name="image003.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image003.jpg Content-Location: image003.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAA+AIoDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDxmiii gAooooAKKKkt08ydE9TQNK7sXRpalQTKQSORto/spf8Ansf++a0KOKZ7f1Sj2M/+yl/57H/vmg6U McTH/vmtDiljQyypGvV2Cj8aTsH1Sj2MeXT5oxlcOB6VVr0L/hFVz/x+t/37/wDr1QvfBcZkEgvW G7r+67/nXH9dofzfmcdfCqK5oHGUV1J8FqR8t+c+8X/16zr/AMMX1lG0qFLiNeSY85A9wa0hiqM3 ZSOJwkuhj0UUV0EBRRRQAqqzsFUZZjgD1NbvirwZrHg6a2i1aOIfaULxtE+4cYyPqMj86x7P/j9g /wCui/zr179oP/WaB9Lj/wBp0AeN0V6Z8I9O1b7Pqup6fZ6PPGuyJn1ORlC4yx24U+2c47VdxrNp 8KrzUjpnh9bXU3klySwnHmORhE27eOwB6CgDyu0tZb68gtIAGlnkWNATjLMcD9TW/q3hLU/CeuLY 6osfmGHzUaJtysCccHjvW7faJ4T0XxL4fTQNYur65fUIfOSaIqFXeMHO0d+3P+PZfEjQrrxF8Q9L 0604ea0AZyOI0Dksx+n88UG2Ht7RN7I4aw8JaxqWgXOt28KfY7bO4s+GfHXaO+K2NP8AhZ4j1Kzj u4ms44pRuTzZGBYeuNp4rrfHWq22i6fY+C9JXYpjBnAPKwqMhT7sRk/j6119zY6jfeH9Pi0zUDYy qkbNIFzuXZjH5kH8KylNqVl0R3yxFTkUtk3p6Hjms/DnW9ChjmvJbMxyNsDRyM2DjOD8o9KqaT4e uP7UgZpYiqHeQM9vw+ldd4oh1W01FLPVNRa9KJvQ5OAD7djxU+i6HNJbf2gkqeW8JPOcrhiG4742 j/voV5mIxNb3owR2wklSUpu9+xV/s+X++n61VvLO4EYxHuAOTt5rrbjS4RczCGdxFCzhwY8sAqhu Ofm4PtVe6sore1aTzJGkDxhcptGGTdzzwa8Zxrxu5LRGTnCa5b7nE0o4PHauo1Hw6JENyZDGETzJ GSIsWQRhztGfmPOKzX8PyLMEE2VJb5jGRhRCJQWH8JwcEdjmuiNKclexwycYu1zyvxFapaazMkYC o+HCjtkc/rmsyu8Hhy312C61eWd2M9tK1miJ8g8t0jDO+eOWJ246c5GQKydR8PR+HriK7aN9Ttkl lhnhngeD548KxGCTsyww2RzwQOlfS0rqnHm3scMt9DmaKfO8ck8jxRCGNmJWMEkIM8DJ5OKZWgh8 EgiuI5CCQjhsD2NfRvirwzoPxMtdNvU10RQwK5jaEqd2/aec9CNvSvm+lDMOjEfQ0Adh8QvB1l4M vLS3sNY+3C5RmeM4DRYxgnB6HJx9DTtQ8TeFItK0oaH4eeHVLGSKSS6uG+WQoOcqGOctz2rjCSep zRQB1974+v8AxH4s0bVNb8hI9PnjP7mMgBd4LHuT0r3XXvEXh/QLGfxRJNBPK9uIoCkgZphksqL7 EnJ+mT0r5boycAZ4HSgDtNJ1W61/WNQ1O7+aeQFnbPG5jwB6AAYHsK9wEMHibwxp62urSWZjCMzQ ybWBCFShwR3P6V4d4Sh8vSnlI5lkPPsBj/GtzAzXk1a/LWldXWx7UKUqtKDbs0dL4p8PQ6EkMy6o byWdyGV/v9M7s5Ofx9az9P1OO1tTE8soyT8q5IAOMj8cc1l4oxXBWUamysjrgpKPLJ3N7+3Yg+8X FwG3btw3Zz65z196G1yFg26e4bdjcG3HdjpnnnFYOKSub6vHux8iN268TLHZAIZgLdCyFPkI465z kH6V5hqfi7VL+KaBLiaCC4OZkWZiZv8AfOfm/Gt3xHfrZ6W8YP724GxR7dzXC17WAw8Yxc38rnk4 2SUlGJZi1K/gs5LOK9uI7aU5eFJWCMenK5wadPq2pXRJuNQupiYhCfMmZsxgghOT93IBx04FVKK9 Q88KKKKACiiigAooooAKKKKAPQ9JiW20i1i3KCIwx5HU8/1q3uX++v8A30K8x3H1oyfU158sDzNv mPSjj+VJKJ6duX++v/fQo3r/AH1/76FeY5PqaMn1NT9QX8xX9of3fxPSZb21gGZbqFMerism+8V2 VupW1BuZOxwVUf1NcZmgnNaQwNNfE7mc8fNq0VYnvL2e+uDPcSF3P5Aeg9qgoortSSVkcDbbuwoo opiCiiigD//Z ------_=_NextPart_001_01CBC497.69E98F49-- From julien.ietf@gmail.com Fri Feb 4 10:13:01 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 499D13A694A for ; Fri, 4 Feb 2011 10:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLiDj2LTmgv5 for ; Fri, 4 Feb 2011 10:13:00 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 594F23A693C for ; Fri, 4 Feb 2011 10:13:00 -0800 (PST) Received: by ewy8 with SMTP id 8so1549015ewy.31 for ; Fri, 04 Feb 2011 10:16:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AaHgzSkkHr96DfbxoBELucDofCysuehz9Lr9zpDxhOk=; b=qQoaHfKg74LCRq+TN4JN192sOeM2Wywbr8noajaq4qbGRQHWn9To3HN+BqYsaE/Z3b huWzlfUmO6uRooVIn3Wk1/sQYbTyVdzzrQaTI5hYOgiItE3uj20nT4UU2t/Tr17KuvN3 1o56K9UjT1yvDaKTF016ifZy9i5UCUJcmZ76I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dBKA6K1PTHWoMF5pxd27EP4GlZwKnRdsRk+dhvvpUPJjeVtwlYkr8ghdu8TVD+LhYU Gdpk5iO8Q3xabI/reOmA2v6VTXYS9HUvH5XqDhYZvyXgdBbzaRK9J5UvR0kbxV136JeQ oJR+HUCTUNt6YzAB+DolabfflAJl5dRozbNs4= MIME-Version: 1.0 Received: by 10.103.12.14 with SMTP id p14mr3822604mui.39.1296843385134; Fri, 04 Feb 2011 10:16:25 -0800 (PST) Received: by 10.103.221.9 with HTTP; Fri, 4 Feb 2011 10:16:24 -0800 (PST) In-Reply-To: References: Date: Fri, 4 Feb 2011 10:16:24 -0800 Message-ID: From: Julien Laganier To: Rajeev Koodli Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 18:13:01 -0000 On Thu, Feb 3, 2011 at 8:22 PM, Rajeev Koodli wrote: > > > > On 2/3/11 7:10 PM, "Tran Minh Trung" wrote: > >> There is one question left from the discussion between Julien and >> Rajeev is that: >> Should LMA need to tell the MAG about new prefix(es) of the session >> that the interface attach to?. >> >> My answer is YES!. >> The MAG needs to know which prefixes are newly assigned to a MN >> attachment to send RA. >> Without this step, how can the MN know the right attachment to send a packet? >> > > The LMA needs to provide the prefix info to the MAG. This can be either in > PBA or in FMI (if not provided in PBA). The LMA can provide the prefix to the MAG at session creation, i.e., in the PBU. This information does not need to be (re)conveyed at flow movement. --julien From julien.ietf@gmail.com Fri Feb 4 10:13:23 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E81373A694A for ; Fri, 4 Feb 2011 10:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mm2y+nfMSVgD for ; Fri, 4 Feb 2011 10:13:22 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 619983A693C for ; Fri, 4 Feb 2011 10:13:22 -0800 (PST) Received: by eyd10 with SMTP id 10so1552679eyd.31 for ; Fri, 04 Feb 2011 10:16:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sNWD6d1+30ypLJdD1nJHGpFEmo9Y1UCGRyp/Xxhlz0k=; b=YscqH3R22iCqsmBbUmVW89/uas2V5X0cEQ2P26s76MHM8SQrNU5/EmLge5PV3awDg7 aMPxcV0vizzgBAZia/cmbgp86T7BNId9mJm/N58aB5hEB763UjUSn2nzPY2smOJo8nWo Mlc46wJ8h7AZNiTxs8zW0NRwV5lG0Hrq81FXo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=nJBadCaXdB7KCOvvhNnXcNFSo6I3mhW/hbolQXFXB+/Kl0+jWVbiUyIthjJP6VUHkD 5afFBUjqsvxu17CYye5jDwhcAYf45ChzUiw1X4MxcMOCQqceHbmNAkLb8gdh17VRA3ZZ LFHMBITQAuRYaWVHvCxNXypPG/o3BZAb79/84= MIME-Version: 1.0 Received: by 10.103.199.18 with SMTP id b18mr7703607muq.21.1296843307713; Fri, 04 Feb 2011 10:15:07 -0800 (PST) Received: by 10.103.221.9 with HTTP; Fri, 4 Feb 2011 10:15:07 -0800 (PST) In-Reply-To: References: Date: Fri, 4 Feb 2011 10:15:07 -0800 Message-ID: From: Julien Laganier To: Tran Minh Trung Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 18:13:24 -0000 Hi Tran, I think you and I agree on this. --julien On Thu, Feb 3, 2011 at 7:58 PM, Tran Minh Trung wro= te: > Hi Sri and Julien, > > Please see my comments inline. > > On Fri, Feb 4, 2011 at 6:50 AM, Sri Gundavelli wrote= : >> Hi Julien, >> >> Thanks for your response, please see inline. >> >> >> On 2/3/11 10:52 AM, "Julien Laganier" wrote: >> >>> Hi Sri, >>> >>> Please see inline: >>> >>> On Wed, Feb 2, 2011 at 4:13 PM, Sri Gundavelli (sgundave) >>> wrote: >>>> >>>> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Beha= lf Of >>>> Julien Laganier >>>> Sent: Wednesday, February 02, 2011 3:45 PM >>>> To: cjbc@it.uc3m.es >>>> >>>> Cc: netext@ietf.org; Basavaraj.Patil@nokia.com >>>> Subject: Re: [netext] Consensus call to adopt I-D: >>>> draft-bernardos-netext-pmipv6-flowmob as WG doc >>>> >>>> >>>> 1. there is no need to support multiple addressing models. All scenari= os can >>>> be supported by a single addressing model in which each PMIPv6 session= maps >>>> to a set of prefixes that are equally accessible through the set of ph= ysical >>>> interfaces attached to that PMIPv6 session. This allows all scenarios, >>>> including one in which two prefix sets are available through different >>>> physical interfaces set. I understand that the WG has been divided on = that >>>> question but that does not constitute a mandate to include everyone's = wish >>>> list =A0in a standard specification. Thus unless someone can come up w= ith >>>> a=A0rebuttal=A0of my argument on why single addressing model (prefix-s= et per >>>> interface-set) satisfies all scenarios, e.g., by pointing out a scenar= io in >>>> which it does not, that should be the only addressing model supported = in that >>>> spec. >>>> >>>> >>>> >>>> [Sri] I guess, this goes back to our last discussion in this list. We = allow >>>> the hosting of multiple prefixes on an IPv6 link and the base RFC-5213= allows >>>> the same. You agreed and your comments on to take the approach of sess= ion >>>> management, as supposed to addressing models. Now, we allow the abilit= y to >>>> move a full/partial set of prefixes to a different interface, and opti= onally >>>> allow the sharing of prefixes across links. This is one issue to discu= ss the >>>> shared link approach and see how to capture the final text. The text c= an be >>>> updated once we decide the scenarios that we support. This also probab= ly ties >>>> to the policy interface to MN. Lets take this as an open issue. >>> >>> Adopting a solution draft before we have decided what scenarios we >>> want to support with solution sounds a bit like putting the cart >>> before the horse. >>> >>> In the addressing model I outlined: at PMIPv6 session creation a set >>> of prefixes is assigned the mobile node's session. Then physical >>> interfaces can attach to / detach from this session. A single mobile >>> node can also have multiple sessions (say 2) in parallel, associated >>> with distinct set of prefixes, which results in the ability for the >>> prefixes set to move across interfaces fully or partially as the >>> interfaces are attached to / detached from the session. So all >>> scenarios are supported in this simple addressing model which also has >>> a minimal deviation from the basic 5213 model. >>> >>> If you think this model places unreasonable limitations on what >>> scenarios can be supported, please explain how and why. >>> >>> From my perspective the way forward is to revise the individual draft >>> submission to document this addressing model only, after which we know >>> what we are asked to adopt as a WG item. >>> >> > > > > I would like to summarize the session model as following: > > (1) A sigle mobile node has multiple sessions > (2) Each session is associated with a distinct set of prefixes. > (3) Interfaces are attached to/de-attached from the session. > (4) Each interface can be attached to multiple session at a time. > > The item #4 is necessary for supporting full flow mobility. > >> >>>> 2. there is no need to convey traffic selectors between the MAG and th= e LMA. >>>> The LMA forwards downlink packets as per the network-based policy, and= the >>>> uplink packets to the Internet. The MAG forwards downlink packets to t= he MN, >>>> and uplink packets to the LMA. End of the story. As above, unless some= one >>>> comes up with a rebuttal of why that is not=A0sufficient=A0to address = the >>>> scenario we're concerned with (network-based flow mobility), the traff= ic >>>> selectors shall be removed from the specification. >>>> >>>> [Sri] I tend to agree. The MAG does not have ability to convey flow le= vel >>>> info over ND interface. At the end of the day, the MAG is hosting a se= t of >>>> prefixes on a link and that=B9s all. So, the traffic selectors are not= needed >>>> from the mobility perspective, but if we look at this as exchange of p= olicy, >>>> we can allow them optionally. But, =A0I=B9m fine to get rid of this en= tirely, but >>>> allowing this exchange is not undesirable either. >>>> >>> >>> As you rightfully note, "the traffic selectors are not needed from the >>> mobility perspective." Thus, since PMIPv6 is not a policy exchange >>> protocol (or did it stand for Policy and Mobility for IPv6 ;-) they >>> are undesirable, should not be allowed optionally, and should be >>> getting rid of entirely :-) >>> >> >> Works for me. No traffic spec in the protocol signaling is fine with me. >> > > It works for me also. I agree that the LMA dose not need to send > traffic selectors to the MAG. > > Regards, > TrungTM > >> >> Regards >> Sri >> >> >> >> >>> Best, >>> >>> --julien >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> > > > > -- > Ph.D., Senior Member > Electronics and Telecommunications Research Institute > Standards Research Center > 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA > Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 > From sfaccin@rim.com Fri Feb 4 10:13:37 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E8D73A693C for ; Fri, 4 Feb 2011 10:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.516 X-Spam-Level: X-Spam-Status: No, score=-4.516 tagged_above=-999 required=5 tests=[AWL=-0.314, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84uIlhD-+HbX for ; Fri, 4 Feb 2011 10:13:16 -0800 (PST) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 9DF313A69EB for ; Fri, 4 Feb 2011 10:13:15 -0800 (PST) X-AuditID: 0a401fcb-b7c02ae0000009e2-77-4d4c42884707 Received: from XCH138CNC.rim.net ( [10.65.20.127]) by mhs03ykf.rim.net (RIM Mail) with SMTP id 8F.99.02530.8824C4D4; Fri, 4 Feb 2011 13:16:40 -0500 (EST) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH138CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Feb 2011 13:16:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CBC497.A89AF3C1" Date: Fri, 4 Feb 2011 12:16:35 -0600 Message-ID: <680854867F7FD04BB9B06EB8ACA8D5AC05E1F35A@XCH02DFW.rim.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLwmpURzmRlysrlUidlexdQorGZJPuBh2AgAAR4ICAAAzJgIAACkaAgADJ5gCAAKKGAP//oT5wgAEpJLmAAAFP8IAAWrj+gADoOBA= References: From: "Stefano Faccin" To: "Sri Gundavelli" , "Giaretta, Gerardo" , "stefano faccin" X-OriginalArrivalTime: 04 Feb 2011 18:16:40.0531 (UTC) FILETIME=[AB6C7A30:01CBC497] X-Brightmail-Tracker: AAAABgAAAZEXVB72F1QozBdUKM0XVCjOF1TWuQ== Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 18:13:37 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC497.A89AF3C1 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CBC497.A89AF3C1" ------_=_NextPart_002_01CBC497.A89AF3C1 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Sri, I guess we need to agree to disagree. There is no such assumption in 3GPP (if there is a reference to where it is captured would be useful) on the fact that the HA has the same policies that the UE has. I do not agree it is an administrative overhead, sorry. Cheers, Stefano Faccin Standards Manager Research In Motion Corporation 5000 Riverside Drive Building 6, Brazos East, Ste. 100 Irving, Texas 75039 USA Office: (972) 910 3451 Internal: 820.63451 : (510) 230 8422 www.rim.com ; www.blackberry.com P Consider the environment before printing. From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Sri Gundavelli Sent: Thursday, February 03, 2011 8:24 PM To: Giaretta, Gerardo; stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Hi Gerardo/Stefano: Not sure, if that is sufficient and how it fits into the current trend towards supporting open client systems. We don't have to agree on this. IMO, this in some form translates to an implicit assumption, of HA having access to some policy, at least in some deployments, where the device qualification is not sufficient. In any case, where ever this is required, this is an administrative over ahead. Regards Sri On 2/3/11 3:00 PM, "Giaretta, Gerardo" wrote: Hi Sri, Conformance tests can be used to make sure the UE behaves accordingly. So no need for the PDN GW to perform any validation. Cheers Gerardo From: Sri Gundavelli [mailto:sgundave@cisco.com] Sent: Thursday, February 03, 2011 2:55 PM To: Giaretta, Gerardo; stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Hi Gerardo, Sure, for supporting the specific scenario, the draft is making that assumption. This does come at a cost for the operator having to ensure synchronized policies between the ANDSF server and the PDN GW. But, my question still remains, how in IFOM, a PDN GW can ever authorize and establish the flow policies requested by the UE. It needs the access to same policy that the operator configured on the ANDSF server. Else, its all in the mercy of the UE with no network side validation. There can be all the needed information elements, around UE location, or network attachment in the protocol signaling, directly from the UE in IFOM, but fundamentally the PDN GW needs access to the same policy. I do agree, this assumption is an administrative overhead. Regards Sri On 2/2/11 9:13 PM, "Giaretta, Gerardo" wrote: Hi Sri, There is no implicit assumption of synchronized policies. A basic example that shows that there is no assumption is the following: ANDSF policies may be based also on location of the UE. For example the UE should prefer WLAN only in a given location. When the UE is attached over WLAN there is no way for the PDNGW/HA to verify the location of the UE and therefore to verify UE actions based on policies. The assumption on synchronization of policies is only applicable to this draft and I think it is a wrong one. Cheers Gerardo From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Sri Gundavelli Sent: Wednesday, February 02, 2011 6:50 PM To: stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Hi Stefano, One comment. Agree with you there is no ANDSF interface to the network node, but the assumption of synchronized policies between the ANDSF server and the PDN GW/HA is there, implicitly IMO. With out this assumption, I do not know, how the HA can ever validate the flow mobility options received in the BU. If the operator requires any control on enforcing a flow policy rule, the PDN GW/HA needs to have synchronized policies, without which its always the client decision. I'm not sure, operators in 3GPP would like that :) No doubt, the lack of MN-AR interface is surely an issue for supporting complex flow policies. I realize the issues and I agree with you. But, the assumption of synchronized policies can offer some solution with some configuration requirement on the HA (assuming there are no other issues). There are also the proposals on flow mirroring on the UE ..., requiring no flow policies. I've not evaluated this, however. Folks can comment on this. It is also to be noted, for some of the scenarios such, there is no flow policy interface needed. We can identify what scenarios create any configuration limitations on the HA and which one's do not . As I've noted earlier, this is surely an open issue, that we need to discuss in the WG. Regards Sri On 2/2/11 9:08 AM, "stefano faccin" wrote: Sri, thanks for the reply. Can you clarify in which system or scenario ANDSF is available to network entities as well? There is no such availability in 3GPP, and making such information available would require considerable architectural changes, therefore the applicability of this solution to what seems to be the only realistic scenario hinges on 3GPP making considerable architectural changes. I would therefore not be so hastily concluding that the ANDSF information is available to the LMA and underestimate what it would really take to make the solution applicable. If we cannot guarantee that there is at least one realistic solution to have the MNa nd LMA in synch, how do we expect that this solution is applicable at all? In 3GPP there is no need to have such implicit assumption, be cause 1) the MN is provided policies explicitly through the ANDSF, and 2) it is the MN and only the MN that makes IP flow mobility decisions and communicates them explicitly (with well defined signalling) to the LMA, and therefore no magic is needed. There is no need in 3GPP to have the ANDSF and PDN GW policies synchronized, since the PDN GW does not use such policies. Sri, in the end it is a matter of whether we develop a solution that will rely on some unknown magic to be deployed, or a solution that we know can be deployed in at least one way because there are solutions to what I consider major open issues. Cheers, Stefano On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli wrote: Hi Stefano, Thanks for the discussion. As you say, the ANDSF policies are allowing the MN a.) to make the right network attachment decision and b.) make the access selection on a flow basis. This same policy that is present in the ANDSF server, is available for the network nodes as well. I'm not sure, with out this assumption the solution can work for all currently listed cases. We clearly need the MN and the LMA to be in synch with respect to the configured policy. How, that is done, I guess we will not try to know. I thought even in 3GPP, this is the implied assumption ? But, this is for you to clarify. Not specifically for IFOM where UE and PDN GW/HA are negotiating the flow policies, but generally that the PDN GW and the ANDSF policy server will have synchronized policies. The MAG and the LMA have the ability to carry this flow policy information in signaling messages and influence the access selection. The policy is a opaque object, with extensible formats, when carried in the signaling plane, should allow the LMA/MAG to apply those access policies, while assuming MN is following the same rules. These policies can surely reflect the specific WLAN access/operator specific rule. I'm surely with you, the lack of MN-AR interface is surely an issue and I see that. But, we need to understand, what are the limitations with the approach of out of band policy interfaces and what will be the solution limitations. If we need to tie the flow movement at the prefix granularity and rely on the natural ND interface in the form of RA PIO option, more like PDN offload in MAPCON, or at the granularity of a flow level, is open for discussion. I want to simplify this draft for sure, we can surely discuss each of these issues on the WG draft. Regards Sri On 2/1/11 8:29 PM, "stefano faccin" > wrote: Sri, thanks for the reply. I'd like to comment on the "the flow policy decisions need not be based on the specific WLAN network". Does it mean, as I believe it does, that the current solution would not allow an operator deploying such solution to decide to route flows over a specific WLAN or not depending on which specific WLAN the MN is connected to? E.g. the operator or the entity in control of the decisions for the routing may want to direct certain traffic always over WLANs that the operator deploys, and instead route only some of the traffic over WLANs of roaming partners or of the MN user home. How does this solution support that scenario if the LMA is not told specifically which WLAN the MN is connected to? From a deployment point of view, I do not believe we can afford to leave out this scenario. Please note that the establishment of a security relationship between the MN and the MAG, and a specific MAG identity, cannot guarantee that the LMA knows which specific WLAN access network the MN is connected to. Assuming that would severely restrict the deployment scenarios. As for the MN and the LMA being magically in synch, I am very concerned about a "glass ball" solution. You mention ANDSF defined by 3GPP as a solution for this "out of band" delivery of policy. Fair enough, however there is an issue with that. ANDSF is designed specific to be a MN-centric solution where policies are provisioned in the MN and the MN decides which network technologies and access networks it needs to connect to, under what conditions, and which IP traffic needs to be routed on such accesses. No IP point of attachment in the network (i.e. the PDN GW in 3GPP that is the LMA in PMIPv6) is aware under any conditions of such policy. Therefore, even if in order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would unfortunately not provide a solution unless the MN can communicate to the MAG and the LMA the decisions the MN has taken based on the ANDSF policies. I believe the key point here is that we need to understand how the solution can be realistically applied to a real scenario, and that we need to ensure that important and realistic deployment scenarios are not excluded by the solution. Cheers, Stefano On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli > wrote: Hi Stefano: These are valid points and some good comments. Let me share my thoughts. Carlo's draft is not assuming any new MN-AR interface. Its going with the assumption there is established policy on the mobile and on the LMA, which allows the mobile to select the access network at a flow level granularity, without requiring any explicit signaling between the MAG and the MN. To large part this is all about out of band policy interface, such as ANDSF, towards the UE, leading to the assumption that magically the MN and the LMA are in sync with respect to flow policies, access selection and they will make the right forwarding decision. Secondly, the flow policy decisions need not be based on the specific WLAN network, but it is implicitly driven by the MAG - LMA security relation, where the MAG attachment to the WLAN network transitively allows the LMA to make the flow policy decisions based on the MAG identity. If the WLAN network is not trusted, there is truly no MAG in that network, where the LMA shares a security relation with that node. There are still some open issues on this draft that needs to be discussed in the WG. On the approaches to allow more a flow aggregate movement, that is a discussion point. There are issues that we need to discuss, supporting split link model, or eliminating some favorite brand of signaling message (FMA) and riding on PBU/PBA and just with one FMI trigger, and on the aspects around MN applying the flow policies by flow mirroring. We have no agreement on those issues yet. Its just a base draft, for further discussion and resolving those issues. But, hope that is not a stopper for base draft selection. Sri On 2/1/11 6:39 PM, "stefano faccin" > wrote: Raj, thanks for the email. I need to apologize in advance if my questions have already been answered before (though I cannot find a conclusive answer anywhere). I think that a protocol that is developed in NETEXT (or other groups) should have at least a potential realistic scenario for applicability. In terms of applicability, though it is not part of the protocol definition per se, unless there are solutions in place for either the host to indicate to the network where the flows should be routed or for the LMA to receive somehow from somewhere some policies, the solution cannot really provide flow mobility since there is no way to decide which flows are routed where. If we are thinking about a host-based solution, I have not yet seen a solution as to how the host can indicate to the MAG and ultimately to the MAG which flows should be routed on each access. If we are relying on modifications of layer 2 protocols, aren't we defining a solution that works only with some technologies (since for other access technologies it is rather unrealistic to modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-based solution, can we hear of at least one example of a real-life scenario where the LMA would receive such policies, and how such delivery would happen? Also, should there be a solution to have policies in the LMA, how does the LMA actually decide to route flows on one access or the other? E.g., if some flows need to be routed on certain WLAN networks, but shall not be routed on other WLAN networks, how does the LMA know which specific WLAN network the host is connected to? Perhaps I missed the ability for the MAG to know e.g. the WLAN SSID and provide it to the LMA, in which case I would appreciate if somebody could highlight to me where that is defined. I think that, though not integral to the protocol specification, understanding what framework the protocol would/needs to fit in is rather important. Cheers, Stefano On Tue, Feb 1, 2011 at 3:47 PM, > wrote: Hello, We have discussed the flow mobility solutions for Proxy MIP6 previously at IETFs 78 and 79. This is a consensus call for adopting this I-D: draft-bernardos-netext-pmipv6-flowmob-02 as the working group document. I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt The consensus call will expire on Feb 15th, 2011. Please indicate your support or concerns in adopting this I-D as the WG baseline document on the mailing list. Please note that this I-D will serve as the baseline in the WG and will be developed further based on input and feedback from WG members. -Basavaraj _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_002_01CBC497.A89AF3C1 Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable Re: [netext] Consensus call to adopt I-D: draft-b= ernardos-netext-pmipv6-flowmob as WG doc

Sri,

I guess we need to agree to disagre= e. There is no such assumption in 3GPP (if there is a reference to where it= is captured would be useful) on the fact that the HA has the same policies= that the UE has.

&nbs= p;

I do not= agree it is an administrative overhead, sorry.

Cheers,

Stefano Faccin=

 

Standards Manager

Research In Motion Corporation
5000 Riverside Drive
= Building 6, Brazos East, Ste. 100

Irving, Texas 75039 USA
Office: (972) 910 3451 

Internal: 820.63451<= /span>

3DUntitled-1: (510= ) 230 8422

www.rim.com; www.blackberry.com

3D"cid:image004.png@01CB49EA.87D92140"

 =

P Consider the environment before= printing.

 

From: netext-bou= nces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Sri Gunda= velli
Sent: Thursday, February 03, 2011 8:24 PM
To: Giar= etta, Gerardo; stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil= @nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draf= t-bernardos-netext-pmipv6-flowmob as WG doc

 

Hi Gerardo/Stefano:

Not sure, if that is sufficient and ho= w it fits into the current trend towards supporting open client systems. We= don’t have to agree on this. IMO, this in some form translates to an= implicit assumption, of HA having access to some policy, at least in some d= eployments, where the device qualification is not sufficient. In any case, w= here ever this is required, this is an administrative over ahead.

Reg= ards
Sri




On 2/3/11 3:00 PM, "Giaretta, Gerardo&qu= ot; <gerardog@qualcomm.com> wrot= e:

= Hi Sri,<= br> 
Conformance tests can be used to make sure the UE behaves accor= dingly. So no need for the PDN GW to perform any validation.
 
Ch= eers
Gerardo
 

From: Sri Gundavelli [mailto:sgundave@cisco.com]
Sent: Thurs= day, February 03, 2011 2:55 PM
To: Giaretta, Gerardo; stefano facc= in
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject:= Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flo= wmob as WG doc

Hi Gerardo,

Sure, for supporting the specific sc= enario, the draft is making that assumption. This does come at a cost for th= e operator having to ensure synchronized policies between the ANDSF server a= nd the PDN GW. But, my question still remains, how in IFOM, a PDN GW can eve= r authorize and establish the flow policies requested by the UE. It needs th= e access to same policy that the operator configured on the ANDSF server. El= se, its all in the mercy of the UE with no network side validation. There ca= n be all the needed information elements, around UE location, or network att= achment in the protocol signaling, directly from the UE in IFOM, but fundame= ntally the PDN GW needs access to the same policy. I do agree, this assumpti= on is an administrative overhead.


Regards
Sri



= On 2/2/11 9:13 PM, "Giaretta, Gerardo" <gerardog@qualcomm.com> wrote:
Hi Sri,
 
Ther= e is no implicit assumption of synchronized policies. A basic example that s= hows that there is no assumption is the following: ANDSF policies may be bas= ed also on location of the UE. For example the UE should prefer WLAN only in= a given location. When the UE is attached over WLAN there is no way for the= PDNGW/HA to verify the location of the UE and therefore to verify UE action= s based on policies.
 
The assumption on synchronization of polic= ies is only applicable to this draft and I think it is a wrong one.
&nbs= p;
Cheers
Gerardo
 

From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Sri Gundavel= li
Sent: Wednesday, February 02, 2011 6:50 PM
To: stefan= o faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subjec= t: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmip= v6-flowmob as WG doc

Hi Stefano,

One comment.

Agree with= you there is no ANDSF interface to the network node, but the assumption of= synchronized policies between the ANDSF server and the PDN GW/HA is there,= implicitly IMO. With out this assumption, I do not know, how the HA can eve= r validate the flow mobility options received in the BU. If the operator req= uires any control on enforcing a flow policy rule, the PDN GW/HA needs to ha= ve synchronized policies, without which its always the client decision. I= 217;m not sure, operators in 3GPP would like that :)

No doubt, the l= ack of MN-AR interface is surely an issue for supporting complex flow polici= es. I realize the issues and I agree with you. But, the assumption of synchr= onized policies can offer some solution with some configuration requirement= on the HA (assuming there are no other issues). There are also the proposal= s on flow mirroring on the UE ..., requiring no flow policies. I’ve no= t evaluated this, however. Folks can comment on this.

It is also to b= e noted, for some of the scenarios such, there is no flow policy interface n= eeded. We can identify what scenarios create any configuration limitations o= n the HA and which one’s do not . As I’ve noted earlier, this is= surely an open issue, that we need to discuss in the WG.



Re= gards
Sri




 


On 2/2/11 9:08 AM, "s= tefano faccin" <sfaccinstd@gmail.co= m> wrote:
Sri,
thanks for the reply. Can you clarify in which s= ystem or scenario ANDSF is available to network entities as well? There is n= o such availability in 3GPP, and making such information available would req= uire considerable architectural changes, therefore the applicability of this= solution to what seems to be the only realistic scenario hinges on 3GPP mak= ing considerable architectural changes. I would therefore not be so hastily= concluding that the ANDSF information is available to the LMA and underesti= mate what it would really take to make the solution applicable.

If we= cannot guarantee that there is at least one realistic solution to have the= MNa nd LMA in synch, how do we expect that this solution is applicable at a= ll? In 3GPP there is no need to have such implicit assumption, be cause 1) t= he MN is provided policies explicitly through the ANDSF, and 2) it is the MN= and only the MN that makes IP flow mobility decisions and communicates them= explicitly (with well defined signalling) to the LMA, and therefore no magi= c is needed. There is no need in 3GPP to have the ANDSF and PDN GW policies= synchronized, since the PDN GW does not use such policies.

Sri, in= the end it is a matter of whether we develop a solution that will rely on s= ome unknown magic to be deployed, or a solution that we know can be deployed= in at least one way because there are solutions to what I consider major op= en issues.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 9:06 PM,= Sri Gundavelli <sgundave@cisco.com>= ; wrote:
Hi Stefano,

Thanks for the discussion.

As you say,= the ANDSF policies are allowing the MN a.) to make the right network attach= ment decision and b.) make the access selection on a flow basis. This same p= olicy that is present in the ANDSF server, is available for the network node= s as well. I’m not sure, with out this assumption the solution can wor= k for all currently listed cases. We clearly need the MN and the LMA to be i= n synch with respect to the configured policy. How, that is done, I guess we= will not try to know.  I thought even in 3GPP, this is the implied ass= umption ? But, this is for you to clarify. Not specifically for IFOM where U= E and PDN GW/HA are negotiating the flow policies, but generally that the PD= N GW and the ANDSF policy server will have synchronized policies. The MAG an= d the LMA have the ability to carry this flow policy information in signalin= g messages and influence the access selection. The policy is a opaque object= , with extensible formats, when carried in the signaling plane, should allow= the LMA/MAG to apply those access policies, while assuming MN is following= the same rules. These policies can surely reflect the specific WLAN access/= operator specific rule. I’m surely with you, the lack of MN-AR interfa= ce is surely an issue and I see that. But, we need to understand, what are t= he limitations with the approach of  out of band policy interfaces and= what will be the solution limitations. If we need to tie the flow movement= at the prefix granularity and rely on the natural ND interface in the form= of RA PIO option, more like PDN offload in MAPCON, or at the granularity of= a flow level, is open for discussion. I want to simplify this draft for sur= e, we can surely discuss each of these issues on the WG draft.


Re= gards
Sri






On 2/1/11 8:29 PM, "stefano fac= cin" <sfaccinstd@gmail.com <= http://sfaccinstd@gmail.com>= > wrote:
Sri,
thanks for the reply.

I'd like to comment on t= he "the flow policy decisions need not be based on the specific WLAN ne= twork". Does it mean, as I believe it does, that the current solution w= ould not allow an operator deploying such solution to decide to route flows= over a specific WLAN or not depending on which specific WLAN the MN is conn= ected to? E.g. the operator or the entity in control of the decisions for th= e routing may want to direct certain traffic always over WLANs that the oper= ator deploys, and instead route only some of the traffic over WLANs of roami= ng partners or of the MN user home. How does this solution support that scen= ario if the LMA is not told specifically which WLAN the MN is connected to?= From a deployment point of view, I do not believe we can afford to leave ou= t this scenario. Please note that the establishment of a security relationsh= ip between the MN and the MAG, and a specific MAG identity, cannot guarantee= that the LMA knows which specific WLAN access network the MN is connected t= o. Assuming that would severely restrict the deployment scenarios.

As= for the MN and the LMA being magically in synch, I am very concerned about= a "glass ball" solution. You mention ANDSF defined by 3GPP as a s= olution for this "out of band" delivery of policy. Fair enough, ho= wever there is an issue with that. ANDSF is designed specific to be a MN-cen= tric solution where policies are provisioned in the MN and the MN decides wh= ich network technologies and access networks it needs to connect to, under w= hat conditions, and which IP traffic needs to be routed on such accesses. No= IP point of attachment in the network (i.e. the PDN GW in 3GPP that is the= LMA in PMIPv6) is aware under any conditions of such policy. Therefore, eve= n if in order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF w= ould unfortunately not provide a solution unless the MN can communicate to t= he MAG and the LMA the decisions the MN has taken based on the ANDSF policie= s.

I believe the key point here is that we need to understand how the= solution can be realistically applied to a real scenario, and that we need= to ensure that important and realistic deployment scenarios are not exclude= d by the solution.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 7:= 43 PM, Sri Gundavelli <sgundave@cisco.com<= /a> <http://sgundave@cisco.com&= gt; > wrote:
Hi Stefano:

These are valid points and some good c= omments. Let me share my thoughts.

Carlo’s draft is not assumin= g any new MN-AR interface. Its going with the assumption there is establishe= d policy on the mobile and on the LMA, which allows the mobile to select the= access network at a flow level granularity, without requiring any explicit= signaling between the MAG and the MN. To large part this is all about out o= f band policy interface, such as ANDSF, towards the UE, leading to the assum= ption that magically the MN and the LMA are in sync with respect to flow pol= icies, access selection and they will make the right forwarding decision. Se= condly, the flow policy decisions need not be based on the specific WLAN net= work, but it is implicitly driven by the MAG – LMA security relation,= where the MAG attachment to the WLAN network transitively allows the LMA to= make the flow policy decisions based on the MAG identity. If the WLAN netwo= rk is not trusted, there is truly no MAG in that network, where the LMA shar= es a security relation with that node.

There are still some open issu= es on this draft that needs to be discussed in the WG.  On the approach= es to allow more a flow aggregate movement, that is a discussion point. Ther= e are issues that we need to discuss, supporting split link model, or elimin= ating some favorite brand of signaling message (FMA) and riding on PBU/PBA a= nd just with one FMI trigger, and on the aspects around MN applying the flow= policies by flow mirroring. We have no agreement on those issues yet.
Its just a base draft, for further discussion and resolving those issues.= But, hope that is not a stopper for base draft selection.


Sri






On 2/1/11 6:39= PM, "stefano faccin" <sfaccin= std@gmail.com <http://sfaccin= std@gmail.com>  <http= ://sfaccinstd@gmail.com> > wrote:
Raj,
thanks for the email.=

I need to apologize in advance if my questions have already been ans= wered before (though I cannot find a conclusive answer anywhere).

I t= hink that a protocol that is developed in NETEXT (or other groups) should ha= ve at least a potential realistic scenario for applicability.

In term= s of applicability, though it is not part of the protocol definition per se,= unless there are solutions in place for either the host to indicate to the= network where the flows should be routed or for the LMA to receive somehow= from somewhere some policies, the solution cannot really provide flow mobil= ity since there is no way to decide which flows are routed where. If we are= thinking about a host-based solution, I have not yet seen a solution as to= how the host can indicate to the MAG and ultimately to the MAG which flows= should be routed on each access. If we are relying on modifications of laye= r 2 protocols, aren't we defining a solution that works only with some techn= ologies (since for other access technologies it is rather unrealistic to mod= ify L2 for IP flow mobility purposes)? If we are thinking of an LMA-based so= lution, can we hear of at least one example of a real-life scenario where th= e LMA would receive such policies, and how such delivery would happen? Also,= should there be a solution to have policies in the LMA, how does the LMA ac= tually decide to route flows on one access or the other? E.g., if some flows= need to be routed on certain WLAN networks, but shall not be routed on othe= r WLAN networks, how does the LMA know which specific WLAN network the host= is connected to? Perhaps I missed the ability for the MAG to know e.g. the= WLAN SSID and provide it to the LMA, in which case I would appreciate if so= mebody could highlight to me where that is defined.

I think that, tho= ugh not integral to the protocol specification, understanding what framework= the protocol would/needs to fit in is rather important.

Cheers,
= Stefano


On Tue, Feb 1, 2011 at 3:47 PM,  <Basavaraj.Patil@nokia.com <http://Basavaraj.Patil@nokia.com>  <= ;http://Basavaraj.Patil@nokia.c= om> > wrote:

Hello,

We have discussed the flow mobil= ity solutions for Proxy MIP6 previously at
IETFs 78 and 79.
This is a= consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flow= mob-02
as the working group document.
I-D: http://www.ietf.org/id/= draft-bernardos-netext-pmipv6-flowmob-02.txt

The consensus call w= ill expire on Feb 15th, 2011. Please indicate your
support or concerns in= adopting this I-D as the WG baseline document on
the mailing list.
Please note that this I-D will serve as the baseline in the WG and will be=
developed further based on input and feedback from WG members.

-B= asavaraj

_______________________________________________
netext ma= iling list
netext@ietf.org <http://netext@ietf.org>  <http://netext@ietf.org>
https://www.ietf.org/mailman/listin= fo/netext

 
 

-----------= ----------------------------------------------------------
=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_002_01CBC497.A89AF3C1-- ------_=_NextPart_001_01CBC497.A89AF3C1 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAKAA4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDSu9Nv V0vVpbjQL2KfU7xR5T6qqmRclsrnhecDFbGl6hqL69Noem63ZRQ6faops5Y2mmiYBQdz8BuSR1qD 4pxpLdeHo5UV0N2cqwyD93tXexW0ELtJFBGjv95lQAt9T3oA/9k= ------_=_NextPart_001_01CBC497.A89AF3C1 Content-Type: image/png; name="image002.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.png Content-Location: image002.png iVBORw0KGgoAAAANSUhEUgAAAIoAAAA+CAIAAAB7vhRQAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAIthJREFUeF7tfAeYHdWV5q1b8eXXudXKoAyIIH1IgESwMTKDSDZebNKsZa8/ xh8MNgxj1mYxLGZtgseDDcwABsb2YH9ggglDMAiEyCIMEkkSCOWW1Orw8qt0b+1/ql4/tbJEN9t8 OxSPp3rVFc+555z//OfcUtjwLZyxAB/8I8ObUMLfGmNCYYES/Yq+63/ETyz1LdH6Hvbh4RXCwxX8 I2vrOH3tSNqK1W2X7j/78Ill4JWj5x2epaaeSPZ1qdPPUKpDs9TUs93JdrhcXflDc8X/T8+CAQ65 QWef7dJ/DbV+mf4hqjO2beNnexP7evbhtJ6d7xGOLc30pKpLJjh5nMEtsBw1kIH0hfRZUGXS7fej kUMV0elxVfyQpBts9wZ3zaE9etAiGPTtbIsciqIFwXg1MbtpkukFYkj8mxJIJv1AQtt24FUDv2rb ObfQy7xe6Zajm4dawrj0OXRyw68euBQasByxm9RzmN5wZHysXvZ2Np4IBezPgt0FziMVnFuRipRc VVTF80XOlJ1Bpada6HKKBSagGjjW2ngYkmGxP3e5h32H2dlCfpFrCWOOYgTsEKO1mZmKH4TOTYm+ EZbqPyHpaAtW9rBPwBQ1YDzA3gHgGcdvEQRCqjLgMlClbFStsWa2XUvEGPdEFffgq5zJz5Ny9ns4 DtGgqJ0GFiOZyZgD7xJ6mIRkp6cnZ3wdGovA9iAWIHboxYdiAtK1VELpS5iKpsSEwt1wi8bzOlsj c+9UOrtxB3VXO4gLD+Ghw2o9oavCHfj0D9lDo9QPNVpMH0Kt+5pP+bBwaQFXuEwF3GO8wgKLC2jL NgwWuDGcXdU8FQZIMc5PGNaIRNat5l0W+NGVDTJqstPo+vQP7pTEFW4kkBnZfKTQMEnAV/jvtsM+ 5c3XDxtu9URZYaSeIGhXE1P0BtUVUuHkmsLH/bQfWA9XpMG5w3mF+xlViWvcF76tsWygWK6iicDA h3ELu5k8meXpXr+UIzkbiFdhwqzhJAFpJfSoFMLwk/TCSUHQN6kpUlWo1iH2jcOnnn43su2BJBsX bxwDD+d6gabCfsIIM7gPsxVeIbGKRilMRfV9WRIycPA//Qefx6AxSL3ienHDsiXbKMsMcI90QzKH a+y3EODwSAF0y+H2yHhgaBBjDaX32xp8Nv40WA+9n1BosMa60/EDfD0g3DGZ8Qfb8ELMh3qG4FqQ shuoNqEJdxzQhuQbmjsc3/cRegLmqTBSSBF64tyHm1OCSlJ9Nd/TY4uqChjJkH9BC+CYYNyBp1Rt GFWAw30xUPCRkgaqB9oibipy24NZhlU90cX7zadZs2anx4wra1wEQ6QeISFftQwHJbyRrl9oG1ue d1qHLXPkqHTJJf4AyStCCkVVgRrcGN/Iq1vsfCEIDENTfYGI5UFRAVd9U2B3qZYroq9Q6S3wrm73 veV9FQCbmslggJnYVVFsYMTBaKV+7LCqZ8ATYLCNt1IzzI4OV/dcT+j6oK1HQKaA0KriBBwDPusp XVOP8A6dAyvqczyLKSaoPWgoCuTwcnBkUmM2l+vL+T78TSXlQTVkPdAwTDGkalVV182UZLphGlXb Xdvtvfpm5ePldsmDyQB7AhpWB6a6g9HT8MWe7UeIxdhIJd6hpmMe/AYH6Br0wAkQtxURI96Ae8DW Us1PODiebMhJ3ZXCkkEyCDRIWUodbiwI9EDRmQBE0asiKApfKpoCG0A2S7icQADpDw7LF7YD8qFU KuZ5UMlkxWEHJVoam/K91VK5CtRJHhPLYOMOneNzpJ7RVqZNTZquj2GKYABRcNFPXRMHF3lBCH27 TzjoMbjDuE0SQcZEcEKEyEqVJlMxlitSqJrFD5jabCSQgSIrtSBvsgYcgDPjULg7rGOroRY1v1fa Piwa8JwjRgUCvo3DlkhfgiuGYZIqQ3ARuKJcqI4ebY4+INFbKG/tiTBBPNTPYIHccKonKihEfiCl 8AOtxgbgYMQLxdAgD8arhi9U6MV3VaEHXpwMS0V8hyGE3xwUgIbwLuHpdQQRgW0QvYqggi8SO4Vw 7CVjbuClmt2JByX0uOv7psI5Zy6cFwcgQKzDChcC+ADy17ijyB7XJkRNtAQCIWmcSV1wrGnwb67n wbp0AyRUoPksnmQ9hUos5s6c0dy92d7SjcdKhuigPy59Wgc3aA//aS/cH05rxycUtYHFFV8Knfu6 qgeq5SvIUDyOtF94ug8MnILiyEoge8QDaIf8Hwa3RtEBnBoxOIFKPo1clMI0IQIV5J3p+yMVpsaz RT21STEKwquqVO7TVaFxMAdCVel0+EAd+AluSbU8FhPc8EjthkcFKD1wLGHrim0EXkwNDEjOR/YM olCtYucYCxzJ8uUzTkq0QjWspCiDhW3D7NxqGV2Irdu4OUrPxMD7g/lHFAiEJjFylbSjxzyzymI+ h7tgtpn3NN/ThVB9T3U9zXORXKq+JRwdQV1xFcVD+AZdI7jucoOrCDMSwVyyraMPVEaNM1y/xJGH 1vJ/KBXATYXwWYDBrsPwYLalwO/yq74BuEAWFLIE8Lak0uiDhf5FPoXxIaFr7EjUkRRBIq1WpbFq jT0kzm04rYd8M54vhKAZNW4oOp5cwsErAnIXGtM8riNmMAPS9aRflkKr6pqrKRUDOhS26dsxz447 +Pa49FWiviEWTxGu6vlGVcR9G5ahStf1PSeTbGZ+UlbjikyhxsAk4K8bSA80HOAD0aZS00AHBEDj vkdWqbrIh8APMFWDqYa8QY3TIe3U2AJKU8MclaIY94uFypSpMQMYe7tM6FM6mV3HnjBM7t8y8JD9 PRxjZHK8oVVJaJTBBxY4A6l1uvl8YPeygs2KCVMkY7aluczVbGFrgYEYA0emBDrkhKFb1dQi1GUq qZhiqm5cF5bhW7qIm25Mh3SrmUbnoMMbzWSFaDfdZLxk6GVVRX5FsYch52S+DACqwTKIQmB3o0Jk IPIjlCkYJwQa4P52LGiQI4U/hFtEhFQQmngAbWcakytXy3x+CJzbbtVwySWXnHvuucuWLbvyyis3 b968V11FKom+ETCj/esr9cN1Xfc87/jjj7/22muF5137s58tfO45uK1TUpNbhaa5wtWVmMs3id5J X/nKOddcVu3deufPfsRWvP+tL83u9HuThx1+0FFz0uMPhC8KwDyHIAkykqZR2fTxsof+zV2zrNkS ik+igWB9jsCD8CBEbOv0WY026wJe84HoRIoJi7wnRC8VDArHAVz2pes7rreqVFleZFqCIfkC6Pbh vuC5iELYUVxECwmDaa7PmerD0MkejWzmwSe8d5ZW9iq0ve6w3fXqwh05cuSGDRuig2+//fYLL7xw dyci/xsqIzoWgEgigMOlAzgRbagIsYv8edGiRccddxz2f/fdd08+dX7v2nXfaj4sWXA0wSqQh+0l Jh1w5ZN/yh7QhH1eeeTeRy757twJDeljjpn1kztNI7u7mym889Qj/7igI+GbQGUE2zSHJRSNV7zu bIeceEhDNegBVgMhEAYScNXEe4LlZICCBOXBw6LOwPLSX1u0t/ZWK4WgDHSQYm5UaoiiDT1tffzB h4XqUeGKgScxZmRgJha/pS5cVNir9Pe6w65jz4QJE3Ck4xAuPO200/ZwloGGgnUoA9/QDQ1eKXep G/zJNMEYMtfxJk6YOHnSBHCKloockGhI7gc5Zp/ygwXQjY0kL2CZTEvLyLEl3z/2ssugm4rwkTaW A4YPUhhHSlfKcohgY9kW3UggaxeSu4HuKDGQXhwkmV1pa0xRsMAVgIwlyn40rNCIQBgQJ2BVIcuB KMqgLJSCqdlTWpMzxzbMmtg4MqOVy6RtSrAoSwrNtT/ehAEozD/DqhKNT8L+pOohWbZTDyQbGUEk 30j0kSh3ucyePfsPf/jDzTfffMcdd8BfYZ9Jkyb95je/ufXWW2+77bYzzjhj5yA00PsZJjJ2ZCe8 mSWE42JEAgP1+bmDTjnuhL/7ZgkZkabi6Tdt3NKzsThu9ldYehJaOpBn6lxJKLALFuPM5MBnPEH3 6L/86P0lpxRoBhg0Qm4YzcB1fgWxJdVgSkgf8iMyvErx3wdmxpBA6FJNRdNBgRKoJmihigpz+jKB 0Z6MHz65beqkNLIk4YZZrI6UGfKJKGtKlQNVEMGNcwVSU6TnMcM0C7khCDx4JAS97ZZIMdFioHTV 77UG7qRpGjgsbDn77LPPO++86E8IVIlEAkq66KKLoi3z589/++23161bVz82Cjx1xVNXIIjgwBtj NRgeYJPquU4P87932/XYBzaR0Hi5u/D23XePMTZZo1sYa3Q4s+CNyptfeuwPaQvjGDCaiqJm38au F1/rW782kY2XNLNBagm7xPXNuZjVUI7HzSY37sVk0VOa/HJb0vogxpSylq3qNpQUVxJWscLUWNnw dIyIKugcoSRcUbGkV0ynSoc3j2hLO++95+Rd7qLcITQL+yHN8TQJt2YGvNJgsRxXBQxXseJVuOgq PbQK2Bj6dpgTlkho9QE6bty4fD7vum61Gu7dbxUDRb0nYL1DnK8fFl0Gy5w5c+obFy5ciPW5c+fW t7zzzju5XA66TKfTqVQqmUxGutm2UAWOJZAwuj4GpC3FSrbm76+/vnXMKOG7CYWw7FO33LVy2ZKx IxvdCkVancHI8izoefa6f1zyq58sv/nKVb/6nx/885Vv/flud8P77UY1w6oqnQnQwRRmCsEMGVRG r8TMXNlk6P4wp33VaZjRR56oL+EmY46le8W+WLkczyUwImzdaxhlN4+WBnPVzbrWKxxghc0dCeew qUaGx5Uyg2eErbsurMTlQQz9Pp7EcwW+w0gXaDXx+KYuWCF+CoSGY489FoO+Pu6jaB2LxW666aYH H3zwlltuwfpAqxgooR2tZzvx7eZHHQ7g7I899hi0tWXLlieeeAK7P/7442vWrMFtwWgQ/wuFwr33 3nvggQdCMbAtgMBot9pC0TZoDCyffFDQ7RemHTj3lEu/g3IPfpoKy6/e+O//++eHTWowdQr1OKqi aCkFoTirptvMVFzzqokA7t7xrSAh/JhbQRZKgV5Nu0q8RyDB8SiRSsIdFvq4Vu7155zw7U9eNzZt eauD61rVBYODQJVvyoh8YSxT8pVKZvp3M+MnrH70iga9YCpBoZKwjfZ4blU2npk2ofn1FR/mcn4C BJHoyeWDRMIzYJEcdgluuyHQSoKXN2+NdedqTuiCCy4oFouLFy+GAqAGGEqkCQgNIeDQQw+1bZtU vSsvRRt3qQIYAc4YhaLe3t6mJkJQ9YX4qtAS68a7B6UOxNZQ3qmnnoqdX3755aOPPhor0N8V37jA +evbqCav93v++ZGHDp5/fCGoJDxTNdSfnblgyV/uOWPGxI50Z/vJ3zrk8ju3IoEFBPCdJX+5N2Px JDyG43dvXP3BS/e1F3qaglLJ8h0lqYlMsSLTR88YP+uYl//XT6af9VUj/Xyx7cBEdsS4GdcrpTVa Kub16B8+d1mu9PERx/46M+O0/IcfaIl1nyy86oDjb0uMP6n02vc+WHhnE+oLjceMPnFB570XNZzw 3arrP3rfnbNPvPjIs35Y6vn4X2+4elP3m9847+pXX/9d58fvn3POL99a+uC6zldfeNl8+XX1xUUL m9qypmn97ne/++lPf3r55ZffcMMNn3zyCXz+hx9+WA8QkWIiSe6ch+zJue3O4iLdnHDCCRgCOCOW 9evXYyN8XfQTC1IlGE2kSFwYS7lcBo4YqEg4Hl3T04GV4tYWN/e1y34A3TghSwrdPPfHp/7jL7+f bna0N8UAq4SmIoVuQwLjVZmoHnnWeZPnnz/yb84de+aCGRdd+zfX3r3V7OjjTdJooEIA/IePdLaY POLY9JxTpl1xV3r838Wbz40Zh6DMU8h3Lbn9HN+0EtNOGTflv8cPmvv6Lcd0vnd7YswpxULQu3zh +rVvvfPSbxMNqoyxiuUnRx+/SfG9bCbPqvNO/f7EE753yYJZD/715n+4/r687Y8Ye6QWz6LY0zhq rpYcnSuZi1+177jt1s7ujZMnT8HDwGK++c1vfv/734carr76aviPMWPGQHRQSSQNiCuS5M6jfO+x Z+djopg0b968+p9GjRrV0dGBGFPf0tbWdtBBB0E9wA5nnnkmQAT2uf/++weeDXEUi6mpfTI/8uBp Z//wQoAFz7PhvsrrCndcedME1pYwAyvmoXsmRN2oNIBh1oQWp/zRd8pS5hl6A5hvtPBMu6PFcoBd qgGA35JJbl21lBV6R8w/3+9cGp84L94wS65eCdY1t+lD1tnj51ZypzvR0rJl49LCx8tXvPGIw7oV UZGsV7ELdhFZglJBkNVitm30BAkHVIWTz04ZtfI/n1j60ab/WPgo4mZTi1IpF+ySU0AEEjyRbHn6 GYo6X5p3wrL/XIqVp556Kh6PT548GYEAP//85z9/9NFHSCujUbtXemW/Obco5cTZx44di2/YxIoV K6677rrOzs6pU6diS6lU6uvru+qqq3BnEydOhG/FMOnq6gJMqOumPlKASU3V/JB1XXzlFU0jWtEL nQDKZcojt99TWd0VY2oyGVNiPgqXUXW4rGkO131gaSOua3GD63HGE4B5ne/yYpcKrg68CogWsJzg 4PxqYfOaw78yb91jv060x9rHN9tbl6LFIBMXforlWNrPWqs7l7ccMKX5qIOnzV9gsGQllgaCzCTT HdlpnqubpsoKWjyZnTLrghEjTner0worlh4ye+bXvnzet8+6xS/1yl6eSKgHHzF35qy5B0467LXX tq5cRff51LNPzvvqScfOnXvWWWfBMpB9A9lGXAnG8fLly7EC5LZLixk4gveknl0eXM+NAKBhEFDA UUcdhZiPkyIBymaz7e3tuDAuj4j34x//+IEHHsCQQST75S9/GV0YRgYUhxWPCVPVenq7jxs5e/rZ J/fYZQd2oirvvrj44d/8FrpJK4lsOmNTxT9MMZC9BgJsqKmUtix51l72vL76VfXVh1645m8X/ury RGltIy/rYFXIm2sYFvFEYuVLi9gnL/nFNyufPCr7Him6a7n/hsx3gSYz3bfHVlZobz5eevP+w8++ qjE1RikuzijehvWLY8m+KV/+uiurSECLq97a+swVo0YHPfm3mrPjVr/5l+L7//L3V19+4kktN143 R69WH/njvx4/98QfXn7PrTf+/JZbHgjrV+kf/cOljltF9vfGG29gvD700EN4/Oeff/7EE0/8+te/ juGL7x0i+s5eClt2hAYRKhsIDXp6epqbm3c4uJ7BDNyOkQL1YAvs6cUXX2xsbIRW4OKifXCLuCes tLS0ANRNnTLV4Uo1l7vizPNu/OOf0iNSwDQxeDCVXXHo8SuXLZtgzBLuu0d9mTU2+ZVNW1pPv/jI y35dCWQcBOTWj6+YPXF8BmQKM5PMSmttaCSE/nxWVlFBQx+BAWYNjQOb7E0dY+MTJigAyEBLqay+ vttrzqRjmlLOF7knsxljfc6l3ilTR3xpbNMKKP9t9VWdNbQhX4kVS23ZcUcEo8eNGTdh9dNP+92L uyt9z77FPiqw0WNYm2n2BtbmnurjT7o9pagTOR6yCvtEuNUx8C51g43bWc8Oe0dObMdkJTwTNkZh PyLWsAJ/et99990ZLtAKgBlsCx7v1XB58sknr7nmmugmIuwABxTOVgsuvOonqZZ4gN4k4UM3z/zT 799ZtqQ51l4RjmUAOVSRigegqsGWIO8BTEaJLmmMSLJRjfrYDpZJQw16V9HvdrUcHKOCD4KsCHCY 5G1ZbcKYrK5a7UmtIROD7Y1psgxe8AKU5rjerBe4bGrVW8arrR2ydQyqgDyjqa3tjAakx3wH8xry SDvNwF/5/MPFrkUGz3e0xKcfmjh4mtbYmGbxRE+X+GCZki9FbW0GSNJ91E0kit0pJtq+nfUQVxQu 8JKwRMQuhA3YJkIL4lvtgDD2gMl++OGHB0I74EXkQPWLwVBgLplMJmJIK5VKhFVwTqSosC1A/kqA Zmque4p0XMQczrXeTZtPPXhmk6eaepoXrAmZLXPmsVhQLazrbv3ad+Zc+lsknEhhVLf04M8vb08G pvT8wLLVpK76xc2rty5/O6N5BuoC0A9IHcn1ZG7q9HY0gQhWRo2Oghh1doBfhixR3AE/SLRtWGkj n4jqAkSiSir3oNMObQ/CMHNVTzPigeJlFAdO2U8k3umyXl/lbtiiLH+/vHK1ADVIsiZ2G54NKerQ dFHtQj1021IioqxcuTJaj6xkhwXbH330UUCy+vbzzz//4osvBlIAkQoG4cYbb6z/qW6UdZcIjzxz 5kyU16AuI6x0+YjyjJ9+xunPPvJoFnWYAKVKeXIzP+OkJtfOeT2lscd89ZjrnvQks9FfoCmGhwoz ckFwXgbqAzT9I8i998Bti3/7i7Y4GhDQpqHagTZiUmXC1IRQ4HeIXkG3GjVEoREIoAktOCCow177 6AnBMAUijoInNutIVtFT4NpqApexHbB4fialVCt9+U1+6sEl+r2LenttaidFGtbfUQNelmrtdbEO nhfdbb3nvffeQ9iArDHksURmCFVFJFKE2feMC+vZK8HnfrwX6eyuu+5asGCBg9ovknwfHWM6fN3d /3bPd769AGVGjSlVXIqJi6am5s1q7c11qV6p4mS/8/RaxlO4gSoGuIJ+DrR84MZQmoPrY+iYEl1v 3vnd+RmlZKGsoXBHGplGnkqDHi0rHNU2dG7gQmCqHfTdEIEJSyIvS2U3PA1WoEEk26iwGS4VSVFj 9aQjuOchkpXjQamMaxWsjj8tk0+v2KQoTeSlyW6gmGpYZajVTfu7RAeroN2qB0wR3BfC+86mE215 4YUXIpZ6v5aoIATQ8sorr4Derh/712eeOeecb/V09/T3iNGsrF/NbxqnWbbmgKdcv6Y8/Rs/+NKl NyHFpmaz/gkDEcePb5TVVj1z5+M3/ag9IQ3pUREUNuamBNqq0UtFHVGWRCeQgokj0Ca0r1OhFW3y YUEP56BWQ7UY6BW063Cpc4E+RSpKU+sPlYKAN6pcV/qsUfcuLT+zYiPjiHugjKAbKnyE56g/ECh0 3ONgvdyeitbTp09HugvcjJrCQEYPtwC68xe/+EVEFuzXUudukaldfullM2bOqLru66+/dt11/6d7 61aiOjCqkUVLFRbw+79tT26WOQ3NNiVDptcV5ZTj5h987MnZtjEoJWH8U3CFQUNhQm54/9XXHrpH K3VlkZgi+aSeNNghXJbLVJe601CLkEZoRqH5hX+l6BwW2cLm26jPEBaEPyFOGqizRlP4EaE0VuKi hDvsMttuXbT57S0guUP5R1oJvzG2+gn/qEvsM7OeutCBlevOLdqIxwDaxgoqDhGdt+8Ljo3AXkR7 t7a2wllFZ7NUtNVIZhmq7XgBnzxaufFL6dQGc2tS2mYhBipfFD1cT0tyoxFhwlKQ4viOqrhaTPVB 9FQ15sdVtHNgRJOQMewD1ZMK2jYdKIZLdIaaauDBmKgHETMLSC31MR92LUjM/DJRoGZalfw5tgBN SLRjQ1ueGbhcMzay5hueXr2aGIVIKaSc2hQT8NaRTrazpH0Xz4577rYNMUJx2B35HVijHZZIxDCp vULDHS6I0UeSC102QFKpXI6qHXA0VMDEwIVZcBPczdwpqUOTLvcMYTLHLVgq8lRmIV5wjeYOeI4m weej3uMrvp3Ah8uYTsM/RCLRKKKCBbXUUhMHSqNgFKi8GfXcADsQwUCSDGNjBN5gjGFPPOKNROGW urDJ0+G+0HmCmamSW6tyyqKPAQvgvgwUW8Nz4BqYCUTqrdlLZDyDXnarnj3LvU597u8NRBqlZfv7 h0+oEbbkX1AIFd8Ynx6ZopmFQeAkwcVxboOhpuY3TP2BP0OER20aokShE3CZOtSonR1yrk0oDZEY NRBCC4C8YeCGUqhmjvYb2nFgX1RtKhXabRBLaGTi7CgQoaSAO9AxprioAGmLVPq1TnfJRqQ5uKhH o6HmxFCKGzAxdSh0A9nuN+e2v/r4NPsHTloLWhujgEfN52HvX1hLpr4NiL023CF9GAT1SpMxh/Im kWMc1z7hBsqAqameWgFqT0wH7HLaHTWbUgsp4TuGVkgXGB1pEGVCMClNL0tjyXJyxeGJqLf3M10+ l+phTmNcTxqqcF2yFgx/ShbDcBItxDhEGqhJPPRRtclq0Xr9U1ujM0TaCw/ejVAx0xRXJI9I14Ql oU0XU1DRJEzsMo8n31tXWVFEuAV2qKGG/4LqYe1JNaa6od9AdzqaLWha2mcqCDo58jD0g8LOwuhI U63IdNBaj0urwkxWldSTb28Jx0RUZaZb+kxv6/NoPYiHk9tT8cCl8Rm2n5GtgEUboilnu1dzNIuH SGFUMAAQwDPZmM5jWGVulszWB1/bsryMGIM/omJO0/2HYg7Pnkbd51E9lspGpDCp2oagPLAzJLLI i4Vpyf43GO+32RHAI0LB9QMtnoIz09PNS9fbr3ycD0+F8QP/9v/i5TufR/XENK0xoWnCQcZBegnn 54KWq01Tp7ewRO2A+/DZjesByhrwGZhAApeHs+AolGmaZRVtv3lEx5othftfWdtFExl1pmtoBKYe s5qqPkN88HlUT3NSbUxgZrTqCY8SFHr/HmgwmuVObTlIt8IZBXv9EK+w42Q6aubEpDbCz9SESA6M 3jyBJQSJ4QxTmiCEpnaUbm0/iDV3vPJ+5x1PdXZiAiQQgRrH/Iloqnyolv4JJfttoft0wGeo+X24 PooUrop32eAfglOwFhwkTplk/Y8jUlUPbZmUH9IMjoi/IcQcvVxg7wuxcEBp1Ly5484wPw0MOSZU QTFq2N4JIhA6ozQV/W0o2pTjeM9OLF7Umx/+yPvTErSbQyMRP0K4IZLaPt3H3u90T3sMr3ow4Zfm tuE5Q+4QFRZ6v9cPDmv8b1PNzlzJMjC/wKf5GSGpFQIq6h/Z90f2qId6Z0GG7dUhpRBOHg1nFRGY Vgi7SdVMpnwttryr+tLyvufWlqm3g6ZoDZbf3Pfbru+5H4/6Kc6+50MigVMUpv2QSSgWCDHGrjmx fXqjV3YEKnSkHnRab+MYIvZx7wsN7ZChJG3Wx3nt0MAHhw1DpDwWhTcYKOgZaujWrVhFUzeUtcff Lby+BjVYcmJgb3CCWqPt3q88lHvs06MO5QUHnAtPDgGGAAhvhkJRi2azYWbUP51/gOl2YtYvKmIh /4XcEEA2OpLKnbu5n+3MJFKjRTMUIo9U90Y0KnSwAGin51rALa6iO8A0Y0m7ai9b37ukq7hso7MW 0+dIL8hv/BhoHsyG+IyksMfTDqd6UEvB5UOPjrFrYaaHIpzpTea1Z01XeteB90eiDhqSwvu2F+aC AcP+FMe38fgDifxI2VFdAKQYAj0B8tCWAAKiCEYgA3K3XKb1VN28p27I2R+u71m9tbwRE7BCeYVn xz7Ru1eiK/6Xc241QYbCQzEGz+8fPSZz5swDZK4rbBbpb9uKvFOIssMpCdgzfBsBRaSQ8yfJh6/t ILlGTg1/V3y814o8WFgbQPSXCtJMcPA9Za/L0fpcpTufhwvDZJV+Ugi0JyIizu/0GyPOhgkNOM8+ Nd8MrY0Np/VQGQE1mfBdkf20vEhREIBDq72FY9foaHtfVauGRd6r7uFCnUQGSm/co76J6N0U9IGJ bHvlAM2BDKdqI/5jwjFKqVToxFyV/rYBGhAYDUMzZWe/9De86kG8wTsd0BZDEYjIf4A3VEprXPIu 4Wu9PNnvgequaNtK/cC6A4xkQtojo8MXiG56HxL4NUzLA69G7zUIVenR/AjaGcU6HIHEK+oerpdB 90u8g915eNWDwU2tLQNielQfhsevF6IG2g+Jr//NuRHii+4/Guh1UBdtDDtwavXQunpCpaKQjf7m mm2EnEQIOcLXwVANIzST8AbIc9Yx4GBl/cXxX0jgCwl8IYEvJBBJ4P8CkLsiseCTLsQAAAAASUVO RK5CYII= ------_=_NextPart_001_01CBC497.A89AF3C1-- From rkoodli@cisco.com Fri Feb 4 10:18:36 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACA063A694A for ; Fri, 4 Feb 2011 10:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjOS-r+zZ+Sy for ; Fri, 4 Feb 2011 10:18:35 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C28A43A69DC for ; Fri, 4 Feb 2011 10:18:35 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJbSS02tJV2c/2dsb2JhbAClLXOeNJsfhVoEhHqGbYMzgwE Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 04 Feb 2011 18:21:59 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p14ILx7I013966; Fri, 4 Feb 2011 18:21:59 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Feb 2011 12:21:59 -0600 Received: from 10.21.72.163 ([10.21.72.163]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Fri, 4 Feb 2011 18:21:58 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Fri, 04 Feb 2011 10:40:30 -0800 From: Rajeev Koodli To: Julien Laganier Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvEmv90bEp5ceW2qkivD2WoLHf56A== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Feb 2011 18:21:59.0674 (UTC) FILETIME=[69A5D5A0:01CBC498] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 18:18:36 -0000 On 2/4/11 10:16 AM, "Julien Laganier" wrote: >> >> The LMA needs to provide the prefix info to the MAG. This can be either in >> PBA or in FMI (if not provided in PBA). > > The LMA can provide the prefix to the MAG at session creation, i.e., > in the PBU. This information does not need to be (re)conveyed at flow > movement. > If it was conveyed in PBA, surely you don't reconvey. If the prefix was not conveyed in PBA (as in the example we discussed y'day), you provide it in FMI. -Rajeev > --julien From sgundave@cisco.com Fri Feb 4 10:29:06 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EA293A67CC for ; Fri, 4 Feb 2011 10:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.999 X-Spam-Level: X-Spam-Status: No, score=-8.999 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dw4Yl-O8F6cE for ; Fri, 4 Feb 2011 10:28:46 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id D40B93A6A18 for ; Fri, 4 Feb 2011 10:28:45 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image.jpg, image.png : 722, 9011 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4BADLVS02rR7H+/2dsb2JhbACCRJQLQIYCAYczaHOeKpsiAoJ7ARmCQwSEeoIjhEqDM4MBhXE Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 04 Feb 2011 18:32:10 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p14IWAMk023742; Fri, 4 Feb 2011 18:32:10 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Feb 2011 10:32:10 -0800 Received: from 10.32.246.213 ([10.32.246.213]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Fri, 4 Feb 2011 18:32:09 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Fri, 04 Feb 2011 10:32:39 -0800 From: Sri Gundavelli To: Stefano Faccin , "Giaretta, Gerardo" , stefano faccin Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLwmpURzmRlysrlUidlexdQorGZJPuBh2AgAAR4ICAAAzJgIAACkaAgADJ5gCAAKKGAP//oT5wgAEpJLmAAAFP8IAAWrj+gADoOBCAAATfeA== In-Reply-To: <680854867F7FD04BB9B06EB8ACA8D5AC05E1F35A@XCH02DFW.rim.net> Mime-version: 1.0 Content-type: multipart/related; boundary="B_3379660361_91296327" X-OriginalArrivalTime: 04 Feb 2011 18:32:10.0424 (UTC) FILETIME=[D5AEE380:01CBC499] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 18:29:06 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3379660361_91296327 Content-type: multipart/alternative; boundary="B_3379660361_91284531" --B_3379660361_91284531 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Stefano, Ok. I don=B9t have a reference to the 3GPP specs, that such assumption is explicitly stated. I=B9m simply not clear, on the HA decision logic on when t= o accept/reject the flow policies in the request, or about trusting the policies sent by the UE, unless it has access to the same. Fair enough, we can leave it with this note. Regards Sri On 2/4/11 10:16 AM, "Stefano Faccin" wrote: > Sri, > I guess we need to agree to disagree. There is no such assumption in 3GPP= (if > there is a reference to where it is captured would be useful) on the fact= that > the HA has the same policies that the UE has. > =20 > I do not agree it is an administrative overhead, sorry. > Cheers, > Stefano Faccin Standards ManagerResearch In Motion Corporation > 5000 Riverside Drive > Building 6, Brazos East, Ste. 100Irving, Texas 75039 USA > Office: (972) 910 3451 Internal: 820.63451: (510) 230 8422www.rim.com > E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0= 000/w > ww.rim.com> ; www.blackberry.com > E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0= 000/w > ww.blackberry.com> > > =20 > P Consider the environment before printing. > =20 >=20 > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of > Sri Gundavelli > Sent: Thursday, February 03, 2011 8:24 PM > To: Giaretta, Gerardo; stefano faccin > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > Subject: Re: [netext] Consensus call to adopt I-D: > draft-bernardos-netext-pmipv6-flowmob as WG doc > =20 > Hi Gerardo/Stefano: >=20 > Not sure, if that is sufficient and how it fits into the current trend to= wards > supporting open client systems. We don=B9t have to agree on this. IMO, this= in > some form translates to an implicit assumption, of HA having access to so= me > policy, at least in some deployments, where the device qualification is n= ot > sufficient. In any case, where ever this is required, this is an > administrative over ahead. >=20 > Regards > Sri >=20 >=20 >=20 >=20 > On 2/3/11 3:00 PM, "Giaretta, Gerardo" wrote: > Hi Sri, > =20 > Conformance tests can be used to make sure the UE behaves accordingly. So= no > need for the PDN GW to perform any validation. > =20 > Cheers > Gerardo=20 > =20 >=20 > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Thursday, February 03, 2011 2:55 PM > To: Giaretta, Gerardo; stefano faccin > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > Subject: Re: [netext] Consensus call to adopt I-D: > draft-bernardos-netext-pmipv6-flowmob as WG doc >=20 > Hi Gerardo, >=20 > Sure, for supporting the specific scenario, the draft is making that > assumption. This does come at a cost for the operator having to ensure > synchronized policies between the ANDSF server and the PDN GW. But, my > question still remains, how in IFOM, a PDN GW can ever authorize and esta= blish > the flow policies requested by the UE. It needs the access to same policy= that > the operator configured on the ANDSF server. Else, its all in the mercy o= f the > UE with no network side validation. There can be all the needed informati= on > elements, around UE location, or network attachment in the protocol signa= ling, > directly from the UE in IFOM, but fundamentally the PDN GW needs access t= o the > same policy. I do agree, this assumption is an administrative overhead. >=20 >=20 > Regards > Sri=20 >=20 >=20 >=20 > On 2/2/11 9:13 PM, "Giaretta, Gerardo" wrote: > Hi Sri, > =20 > There is no implicit assumption of synchronized policies. A basic example= that > shows that there is no assumption is the following: ANDSF policies may be > based also on location of the UE. For example the UE should prefer WLAN o= nly > in a given location. When the UE is attached over WLAN there is no way fo= r the > PDNGW/HA to verify the location of the UE and therefore to verify UE acti= ons > based on policies. > =20 > The assumption on synchronization of policies is only applicable to this = draft > and I think it is a wrong one. > =20 > Cheers > Gerardo > =20 >=20 > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of > Sri Gundavelli > Sent: Wednesday, February 02, 2011 6:50 PM > To: stefano faccin > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > Subject: Re: [netext] Consensus call to adopt I-D: > draft-bernardos-netext-pmipv6-flowmob as WG doc >=20 > Hi Stefano, >=20 > One comment. >=20 > Agree with you there is no ANDSF interface to the network node, but the > assumption of synchronized policies between the ANDSF server and the PDN = GW/HA > is there, implicitly IMO. With out this assumption, I do not know, how th= e HA > can ever validate the flow mobility options received in the BU. If the > operator requires any control on enforcing a flow policy rule, the PDN GW= /HA > needs to have synchronized policies, without which its always the client > decision. I=B9m not sure, operators in 3GPP would like that :) >=20 > No doubt, the lack of MN-AR interface is surely an issue for supporting > complex flow policies. I realize the issues and I agree with you. But, th= e > assumption of synchronized policies can offer some solution with some > configuration requirement on the HA (assuming there are no other issues). > There are also the proposals on flow mirroring on the UE ..., requiring n= o > flow policies. I=B9ve not evaluated this, however. Folks can comment on thi= s. >=20 > It is also to be noted, for some of the scenarios such, there is no flow > policy interface needed. We can identify what scenarios create any > configuration limitations on the HA and which one=B9s do not . As I=B9ve note= d > earlier, this is surely an open issue, that we need to discuss in the WG. >=20 >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 > =20 >=20 >=20 > On 2/2/11 9:08 AM, "stefano faccin" wrote: > Sri, > thanks for the reply. Can you clarify in which system or scenario ANDSF i= s > available to network entities as well? There is no such availability in 3= GPP, > and making such information available would require considerable architec= tural > changes, therefore the applicability of this solution to what seems to be= the > only realistic scenario hinges on 3GPP making considerable architectural > changes. I would therefore not be so hastily concluding that the ANDSF > information is available to the LMA and underestimate what it would reall= y > take to make the solution applicable. >=20 > If we cannot guarantee that there is at least one realistic solution to h= ave > the MNa nd LMA in synch, how do we expect that this solution is applicabl= e at > all? In 3GPP there is no need to have such implicit assumption, be cause = 1) > the MN is provided policies explicitly through the ANDSF, and 2) it is th= e MN > and only the MN that makes IP flow mobility decisions and communicates th= em > explicitly (with well defined signalling) to the LMA, and therefore no ma= gic > is needed. There is no need in 3GPP to have the ANDSF and PDN GW policies > synchronized, since the PDN GW does not use such policies. >=20 > Sri, in the end it is a matter of whether we develop a solution that will= rely > on some unknown magic to be deployed, or a solution that we know can be > deployed in at least one way because there are solutions to what I consid= er > major open issues. >=20 > Cheers, > Stefano >=20 > On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli wrote= : > Hi Stefano, >=20 > Thanks for the discussion. >=20 > As you say, the ANDSF policies are allowing the MN a.) to make the right > network attachment decision and b.) make the access selection on a flow b= asis. > This same policy that is present in the ANDSF server, is available for th= e > network nodes as well. I=B9m not sure, with out this assumption the solutio= n can > work for all currently listed cases. We clearly need the MN and the LMA t= o be > in synch with respect to the configured policy. How, that is done, I gues= s we > will not try to know. I thought even in 3GPP, this is the implied assump= tion > ? But, this is for you to clarify. Not specifically for IFOM where UE and= PDN > GW/HA are negotiating the flow policies, but generally that the PDN GW an= d the > ANDSF policy server will have synchronized policies. The MAG and the LMA = have > the ability to carry this flow policy information in signaling messages a= nd > influence the access selection. The policy is a opaque object, with exten= sible > formats, when carried in the signaling plane, should allow the LMA/MAG to > apply those access policies, while assuming MN is following the same rule= s. > These policies can surely reflect the specific WLAN access/operator speci= fic > rule. I=B9m surely with you, the lack of MN-AR interface is surely an issue= and > I see that. But, we need to understand, what are the limitations with the > approach of out of band policy interfaces and what will be the solution > limitations. If we need to tie the flow movement at the prefix granularit= y and > rely on the natural ND interface in the form of RA PIO option, more like = PDN > offload in MAPCON, or at the granularity of a flow level, is open for > discussion. I want to simplify this draft for sure, we can surely discuss= each > of these issues on the WG draft. >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 >=20 >=20 > On 2/1/11 8:29 PM, "stefano faccin" > wrote: > Sri, > thanks for the reply. >=20 > I'd like to comment on the "the flow policy decisions need not be based o= n the > specific WLAN network". Does it mean, as I believe it does, that the curr= ent > solution would not allow an operator deploying such solution to decide to > route flows over a specific WLAN or not depending on which specific WLAN = the > MN is connected to? E.g. the operator or the entity in control of the > decisions for the routing may want to direct certain traffic always over = WLANs > that the operator deploys, and instead route only some of the traffic ove= r > WLANs of roaming partners or of the MN user home. How does this solution > support that scenario if the LMA is not told specifically which WLAN the = MN is > connected to? From a deployment point of view, I do not believe we can af= ford > to leave out this scenario. Please note that the establishment of a secur= ity > relationship between the MN and the MAG, and a specific MAG identity, can= not > guarantee that the LMA knows which specific WLAN access network the MN is > connected to. Assuming that would severely restrict the deployment scenar= ios. >=20 > As for the MN and the LMA being magically in synch, I am very concerned a= bout > a "glass ball" solution. You mention ANDSF defined by 3GPP as a solution = for > this "out of band" delivery of policy. Fair enough, however there is an i= ssue > with that. ANDSF is designed specific to be a MN-centric solution where > policies are provisioned in the MN and the MN decides which network > technologies and access networks it needs to connect to, under what > conditions, and which IP traffic needs to be routed on such accesses. No = IP > point of attachment in the network (i.e. the PDN GW in 3GPP that is the L= MA in > PMIPv6) is aware under any conditions of such policy. Therefore, even if = in > order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would > unfortunately not provide a solution unless the MN can communicate to the= MAG > and the LMA the decisions the MN has taken based on the ANDSF policies. >=20 > I believe the key point here is that we need to understand how the soluti= on > can be realistically applied to a real scenario, and that we need to ensu= re > that important and realistic deployment scenarios are not excluded by the > solution. >=20 > Cheers, > Stefano >=20 > On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli > wrote: > Hi Stefano: >=20 > These are valid points and some good comments. Let me share my thoughts. >=20 > Carlo=B9s draft is not assuming any new MN-AR interface. Its going with the > assumption there is established policy on the mobile and on the LMA, whic= h > allows the mobile to select the access network at a flow level granularit= y, > without requiring any explicit signaling between the MAG and the MN. To l= arge > part this is all about out of band policy interface, such as ANDSF, towar= ds > the UE, leading to the assumption that magically the MN and the LMA are i= n > sync with respect to flow policies, access selection and they will make t= he > right forwarding decision. Secondly, the flow policy decisions need not b= e > based on the specific WLAN network, but it is implicitly driven by the MA= G =AD > LMA security relation, where the MAG attachment to the WLAN network > transitively allows the LMA to make the flow policy decisions based on th= e MAG > identity. If the WLAN network is not trusted, there is truly no MAG in th= at > network, where the LMA shares a security relation with that node. >=20 > There are still some open issues on this draft that needs to be discussed= in > the WG. On the approaches to allow more a flow aggregate movement, that = is a > discussion point. There are issues that we need to discuss, supporting sp= lit > link model, or eliminating some favorite brand of signaling message (FMA)= and > riding on PBU/PBA and just with one FMI trigger, and on the aspects aroun= d MN > applying the flow policies by flow mirroring. We have no agreement on tho= se > issues yet. >=20 > Its just a base draft, for further discussion and resolving those issues.= But, > hope that is not a stopper for base draft selection. >=20 >=20 > Sri >=20 >=20 >=20 >=20 >=20 >=20 > On 2/1/11 6:39 PM, "stefano faccin" > wrote: > Raj, > thanks for the email. >=20 > I need to apologize in advance if my questions have already been answered > before (though I cannot find a conclusive answer anywhere). >=20 > I think that a protocol that is developed in NETEXT (or other groups) sho= uld > have at least a potential realistic scenario for applicability. >=20 > In terms of applicability, though it is not part of the protocol definiti= on > per se, unless there are solutions in place for either the host to indica= te to > the network where the flows should be routed or for the LMA to receive so= mehow > from somewhere some policies, the solution cannot really provide flow mob= ility > since there is no way to decide which flows are routed where. If we are > thinking about a host-based solution, I have not yet seen a solution as t= o how > the host can indicate to the MAG and ultimately to the MAG which flows sh= ould > be routed on each access. If we are relying on modifications of layer 2 > protocols, aren't we defining a solution that works only with some > technologies (since for other access technologies it is rather unrealisti= c to > modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-ba= sed > solution, can we hear of at least one example of a real-life scenario whe= re > the LMA would receive such policies, and how such delivery would happen? = Also, > should there be a solution to have policies in the LMA, how does the LMA > actually decide to route flows on one access or the other? E.g., if some = flows > need to be routed on certain WLAN networks, but shall not be routed on ot= her > WLAN networks, how does the LMA know which specific WLAN network the host= is > connected to? Perhaps I missed the ability for the MAG to know e.g. the W= LAN > SSID and provide it to the LMA, in which case I would appreciate if someb= ody > could highlight to me where that is defined. >=20 > I think that, though not integral to the protocol specification, understa= nding > what framework the protocol would/needs to fit in is rather important. >=20 > Cheers, > Stefano >=20 >=20 > On Tue, Feb 1, 2011 at 3:47 PM, > > wrote: >=20 > Hello, >=20 > We have discussed the flow mobility solutions for Proxy MIP6 previously a= t > IETFs 78 and 79. > This is a consensus call for adopting this I-D: > draft-bernardos-netext-pmipv6-flowmob-02 > as the working group document. > I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt >=20 > The consensus call will expire on Feb 15th, 2011. Please indicate your > support or concerns in adopting this I-D as the WG baseline document on > the mailing list. >=20 > Please note that this I-D will serve as the baseline in the WG and will b= e > developed further based on input and feedback from WG members. >=20 > -Basavaraj >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext >=20 > =20 > =20 > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-publi= c > information. Any use of this information by anyone other than the intende= d > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from y= our > system. Use, dissemination, distribution, or reproduction of this transmi= ssion > by unintended recipients is not authorized and may be unlawful. --B_3379660361_91284531 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmi= pv6-flowmob as WG doc Hi Stefano,

Ok. I don’t have a reference to the 3GPP specs, that such assumption = is explicitly stated. I’m simply not clear, on the HA decision logic o= n when to accept/reject the flow policies in the request, or about trusting = the policies sent by the UE, unless it has access to the same. Fair enough, = we can leave it with this note.

Regards
Sri





On 2/4/11 10:16 AM, "Stefano Faccin" <sfaccin@rim.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Sri,
I guess we need to agree to disagree. There is no such assumption in 3GPP (= if there is a reference to where it is captured would be useful) on the fact= that the HA has the same policies that the UE has.
 
I do not agree it is an administrative overhead, sorry.
Cheers,
Stefano Faccin Standards ManagerResearch In Motion Corporation
5000 Riverside Drive
Building 6, Brazos East, Ste. 100Irving, Texas 75039 USA
Office: (972) 910 3451  Internal: 820.63451: (510) 230 8422www.rim.com <outbind://28-= 00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB= 000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.rim.com= > ; www.blackberry.com <outbind://28-0000= 0000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB0000= 01B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.blackberry.= com>
<http://www.blackberry.com/>

P Consider the environment before printing.

From: netext-bounces@ietf.org [mailt= o:netext-bounces@ietf.org] On Behalf Of Sri Gundavelli
Sent: Thursday, February 03, 2011 8:24 PM
To: Giaretta, Gerardo; stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-n= etext-pmipv6-flowmob as WG doc
Hi Gerardo/Stefano:

Not sure, if that is sufficient and how it fits into the current trend towa= rds supporting open client systems. We don’t have to agree on this. IM= O, this in some form translates to an implicit assumption, of HA having acce= ss to some policy, at least in some deployments, where the device qualificat= ion is not sufficient. In any case, where ever this is required, this is an = administrative over ahead.

Regards
Sri




On 2/3/11 3:00 PM, "Giaretta, Gerardo" <gerardog@qualcomm.com> wrote:
Hi Sri,
 
Conformance tests can be used to make sure the UE behaves accordingly. So n= o need for the PDN GW to perform any validation.
 
Cheers
Gerardo
 

From: Sri Gundave= lli [mailto:sgundave@cisco.com]
Sent: Thursday, February 03, 2011 2:55 PM
To: Giaretta, Gerardo; stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-n= etext-pmipv6-flowmob as WG doc

Hi Gerardo,

Sure, for supporting the specific scenario, the draft is making that assump= tion. This does come at a cost for the operator having to ensure synchronize= d policies between the ANDSF server and the PDN GW. But, my question still r= emains, how in IFOM, a PDN GW can ever authorize and establish the flow poli= cies requested by the UE. It needs the access to same policy that the operat= or configured on the ANDSF server. Else, its all in the mercy of the UE with= no network side validation. There can be all the needed information element= s, around UE location, or network attachment in the protocol signaling, dire= ctly from the UE in IFOM, but fundamentally the PDN GW needs access to the s= ame policy. I do agree, this assumption is an administrative overhead.


Regards
Sri



On 2/2/11 9:13 PM, "Giaretta, Gerardo" <gerardog@qualcomm.com> wrote:
Hi Sri,
 
There is no implicit assumption of synchronized policies. A basic example t= hat shows that there is no assumption is the following: ANDSF policies may b= e based also on location of the UE. For example the UE should prefer WLAN on= ly in a given location. When the UE is attached over WLAN there is no way fo= r the PDNGW/HA to verify the location of the UE and therefore to verify UE a= ctions based on policies.
 
The assumption on synchronization of policies is only applicable to this dr= aft and I think it is a wrong one.
 
Cheers
Gerardo
 

From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Sri= Gundavelli
Sent: Wednesday, February 02, 2011 6:50 PM
To: stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-n= etext-pmipv6-flowmob as WG doc

Hi Stefano,

One comment.

Agree with you there is no ANDSF interface to the network node, but the ass= umption of synchronized policies between the ANDSF server and the PDN GW/HA = is there, implicitly IMO. With out this assumption, I do not know, how the H= A can ever validate the flow mobility options received in the BU. If the ope= rator requires any control on enforcing a flow policy rule, the PDN GW/HA ne= eds to have synchronized policies, without which its always the client decis= ion. I’m not sure, operators in 3GPP would like that :)

No doubt, the lack of MN-AR interface is surely an issue for supporting com= plex flow policies. I realize the issues and I agree with you. But, the assu= mption of synchronized policies can offer some solution with some configurat= ion requirement on the HA (assuming there are no other issues). There are al= so the proposals on flow mirroring on the UE ..., requiring no flow policies= . I’ve not evaluated this, however. Folks can comment on this.

It is also to be noted, for some of the scenarios such, there is no flow po= licy interface needed. We can identify what scenarios create any configurati= on limitations on the HA and which one’s do not . As I’ve noted = earlier, this is surely an open issue, that we need to discuss in the WG.


Regards
Sri




 


On 2/2/11 9:08 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:
Sri,
thanks for the reply. Can you clarify in which system or scenario ANDSF is = available to network entities as well? There is no such availability in 3GPP= , and making such information available would require considerable architect= ural changes, therefore the applicability of this solution to what seems to = be the only realistic scenario hinges on 3GPP making considerable architectu= ral changes. I would therefore not be so hastily concluding that the ANDSF i= nformation is available to the LMA and underestimate what it would really ta= ke to make the solution applicable.

If we cannot guarantee that there is at least one realistic solution to hav= e the MNa nd LMA in synch, how do we expect that this solution is applicable= at all? In 3GPP there is no need to have such implicit assumption, be cause= 1) the MN is provided policies explicitly through the ANDSF, and 2) it is t= he MN and only the MN that makes IP flow mobility decisions and communicates= them explicitly (with well defined signalling) to the LMA, and therefore no= magic is needed. There is no need in 3GPP to have the ANDSF and PDN GW poli= cies synchronized, since the PDN GW does not use such policies.

Sri, in the end it is a matter of whether we develop a solution that will r= ely on some unknown magic to be deployed, or a solution that we know can be = deployed in at least one way because there are solutions to what I consider = major open issues.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli <sgundave@cisco.com> wrote:
Hi Stefano,

Thanks for the discussion.

As you say, the ANDSF policies are allowing the MN a.) to make the right ne= twork attachment decision and b.) make the access selection on a flow basis.= This same policy that is present in the ANDSF server, is available for the = network nodes as well. I’m not sure, with out this assumption the solu= tion can work for all currently listed cases. We clearly need the MN and the= LMA to be in synch with respect to the configured policy. How, that is done= , I guess we will not try to know.  I thought even in 3GPP, this is the= implied assumption ? But, this is for you to clarify. Not specifically for = IFOM where UE and PDN GW/HA are negotiating the flow policies, but generally= that the PDN GW and the ANDSF policy server will have synchronized policies= . The MAG and the LMA have the ability to carry this flow policy information= in signaling messages and influence the access selection. The policy is a o= paque object, with extensible formats, when carried in the signaling plane, = should allow the LMA/MAG to apply those access policies, while assuming MN i= s following the same rules. These policies can surely reflect the specific W= LAN access/operator specific rule. I’m surely with you, the lack of MN= -AR interface is surely an issue and I see that. But, we need to understand,= what are the limitations with the approach of  out of band policy inte= rfaces and what will be the solution limitations. If we need to tie the flow= movement at the prefix granularity and rely on the natural ND interface in = the form of RA PIO option, more like PDN offload in MAPCON, or at the granul= arity of a flow level, is open for discussion. I want to simplify this draft= for sure, we can surely discuss each of these issues on the WG draft.


Regards
Sri






On 2/1/11 8:29 PM, "stefano faccin" <sfaccinstd@gmail.com <htt= p://sfaccinstd@gmail.com> > wrote:
Sri,
thanks for the reply.

I'd like to comment on the "the flow policy decisions need not be base= d on the specific WLAN network". Does it mean, as I believe it does, th= at the current solution would not allow an operator deploying such solution = to decide to route flows over a specific WLAN or not depending on which spec= ific WLAN the MN is connected to? E.g. the operator or the entity in control= of the decisions for the routing may want to direct certain traffic always = over WLANs that the operator deploys, and instead route only some of the tra= ffic over WLANs of roaming partners or of the MN user home. How does this so= lution support that scenario if the LMA is not told specifically which WLAN = the MN is connected to? From a deployment point of view, I do not believe we= can afford to leave out this scenario. Please note that the establishment o= f a security relationship between the MN and the MAG, and a specific MAG ide= ntity, cannot guarantee that the LMA knows which specific WLAN access networ= k the MN is connected to. Assuming that would severely restrict the deployme= nt scenarios.

As for the MN and the LMA being magically in synch, I am very concerned abo= ut a "glass ball" solution. You mention ANDSF defined by 3GPP as a= solution for this "out of band" delivery of policy. Fair enough, = however there is an issue with that. ANDSF is designed specific to be a MN-c= entric solution where policies are provisioned in the MN and the MN decides = which network technologies and access networks it needs to connect to, under= what conditions, and which IP traffic needs to be routed on such accesses. = No IP point of attachment in the network (i.e. the PDN GW in 3GPP that is th= e LMA in PMIPv6) is aware under any conditions of such policy. Therefore, ev= en if in order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF = would unfortunately not provide a solution unless the MN can communicate to = the MAG and the LMA the decisions the MN has taken based on the ANDSF polici= es.

I believe the key point here is that we need to understand how the solution= can be realistically applied to a real scenario, and that we need to ensure= that important and realistic deployment scenarios are not excluded by the s= olution.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli <sgundave@cisco.com <http://s= gundave@cisco.com> > wrote:
Hi Stefano:

These are valid points and some good comments. Let me share my thoughts.
Carlo’s draft is not assuming any new MN-AR interface. Its going with= the assumption there is established policy on the mobile and on the LMA, wh= ich allows the mobile to select the access network at a flow level granulari= ty, without requiring any explicit signaling between the MAG and the MN. To = large part this is all about out of band policy interface, such as ANDSF, to= wards the UE, leading to the assumption that magically the MN and the LMA ar= e in sync with respect to flow policies, access selection and they will make= the right forwarding decision. Secondly, the flow policy decisions need not= be based on the specific WLAN network, but it is implicitly driven by the M= AG – LMA security relation, where the MAG attachment to the WLAN netwo= rk transitively allows the LMA to make the flow policy decisions based on th= e MAG identity. If the WLAN network is not trusted, there is truly no MAG in= that network, where the LMA shares a security relation with that node.

There are still some open issues on this draft that needs to be discussed i= n the WG.  On the approaches to allow more a flow aggregate movement, t= hat is a discussion point. There are issues that we need to discuss, support= ing split link model, or eliminating some favorite brand of signaling messag= e (FMA) and riding on PBU/PBA and just with one FMI trigger, and on the aspe= cts around MN applying the flow policies by flow mirroring. We have no agree= ment on those issues yet.

Its just a base draft, for further discussion and resolving those issues. B= ut, hope that is not a stopper for base draft selection.


Sri






On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <htt= p://sfaccinstd@gmail.com>  <http://sfaccinstd@gmail.com> > wrote:
Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicate= to the network where the flows should be routed or for the LMA to receive s= omehow from somewhere some policies, the solution cannot really provide flow= mobility since there is no way to decide which flows are routed where. If w= e are thinking about a host-based solution, I have not yet seen a solution a= s to how the host can indicate to the MAG and ultimately to the MAG which fl= ows should be routed on each access. If we are relying on modifications of l= ayer 2 protocols, aren't we defining a solution that works only with some te= chnologies (since for other access technologies it is rather unrealistic to = modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-based= solution, can we hear of at least one example of a real-life scenario where= the LMA would receive such policies, and how such delivery would happen? Al= so, should there be a solution to have policies in the LMA, how does the LMA= actually decide to route flows on one access or the other? E.g., if some fl= ows need to be routed on certain WLAN networks, but shall not be routed on o= ther WLAN networks, how does the LMA know which specific WLAN network the ho= st is connected to? Perhaps I missed the ability for the MAG to know e.g. th= e WLAN SSID and provide it to the LMA, in which case I would appreciate if s= omebody could highlight to me where that is defined.

I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important. <= BR>
Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM,  <Basavaraj.Patil@nokia.com <http://Basavaraj.Patil@nokia.com>  <http://Basavaraj.Patil@nokia.com> > wrote:
Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= BR> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt<= /a>

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= BR> developed further based on input and feedback from WG members.

-Basavaraj

_______________________________________________
netext mailing list
netext@ietf.org <http://netext@ietf.org>  <http://netext@ietf.org>
https://www.ietf.org= /mailman/listinfo/netext
  
 
------------------------------------------------------------= ---------
This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor-= client or other applicable privileges), or constitute non-public information= . Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use, = dissemination, distribution, or reproduction of this transmission by uninten= ded recipients is not authorized and may be unlawful.
--B_3379660361_91284531-- --B_3379660361_91296327 Content-Type: image/jpeg; name="image.jpg" Content-ID: <3379660359_91335988> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8l JCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIo Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAAR CAAKAA4DASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDSu9NvV0vVpbjQL2KfU7xR5T6qqmRclsrn hecDFbGl6hqL69Noem63ZRQ6faops5Y2mmiYBQdz8BuSR1qD4pxpLdeHo5UV0N2cqwyD93tX exW0ELtJFBGjv95lQAt9T3oA/9k= --B_3379660361_91296327 Content-Type: image/png; name="image.png" Content-ID: <3379660359_91319314> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAIoAAAA+CAIAAAB7vhRQAAAAAXNSR0IArs4c6QAAAAlwSFlz AAAOxAAADsQBlSsOGwAAIthJREFUeF7tfAeYHdWV5q1b8eXXudXKoAyIIH1IgESwMTKDSDZe bNKsZa8/xh8MNgxj1mYxLGZtgseDDcwABsb2YH9ggglDMAiEyCIMEkkSCOWW1Orw8qt0b+1/ ql4/tbJEN9t8OxSPp3rVFc+555z//OfcUtjwLZyxAB/8I8ObUMLfGmNCYYES/Yq+63/ETyz1 LdH6Hvbh4RXCwxX8I2vrOH3tSNqK1W2X7j/78Ill4JWj5x2epaaeSPZ1qdPPUKpDs9TUs93J drhcXflDc8X/T8+CAQ65QWef7dJ/DbV+mf4hqjO2beNnexP7evbhtJ6d7xGOLc30pKpLJjh5 nMEtsBw1kIH0hfRZUGXS7fejkUMV0elxVfyQpBts9wZ3zaE9etAiGPTtbIsciqIFwXg1Mbtp kukFYkj8mxJIJv1AQtt24FUDv2rbObfQy7xe6Zajm4dawrj0OXRyw68euBQasByxm9RzmN5w ZHysXvZ2Np4IBezPgt0FziMVnFuRipRcVVTF80XOlJ1Bpada6HKKBSagGjjW2ngYkmGxP3e5 h32H2dlCfpFrCWOOYgTsEKO1mZmKH4TOTYm+EZbqPyHpaAtW9rBPwBQ1YDzA3gHgGcdvEQRC qjLgMlClbFStsWa2XUvEGPdEFffgq5zJz5Ny9ns4DtGgqJ0GFiOZyZgD7xJ6mIRkp6cnZ3wd GovA9iAWIHboxYdiAtK1VELpS5iKpsSEwt1wi8bzOlsjc+9UOrtxB3VXO4gLD+Ghw2o9oavC Hfj0D9lDo9QPNVpMH0Kt+5pP+bBwaQFXuEwF3GO8wgKLC2jLNgwWuDGcXdU8FQZIMc5PGNaI RNat5l0W+NGVDTJqstPo+vQP7pTEFW4kkBnZfKTQMEnAV/jvtsM+5c3XDxtu9URZYaSeIGhX E1P0BtUVUuHkmsLH/bQfWA9XpMG5w3mF+xlViWvcF76tsWygWK6iicDAh3ELu5k8meXpXr+U IzkbiFdhwqzhJAFpJfSoFMLwk/TCSUHQN6kpUlWo1iH2jcOnnn43su2BJBsXbxwDD+d6gabC fsIIM7gPsxVeIbGKRilMRfV9WRIycPA//Qefx6AxSL3ienHDsiXbKMsMcI90QzKHa+y3EODw SAF0y+H2yHhgaBBjDaX32xp8Nv40WA+9n1BosMa60/EDfD0g3DGZ8Qfb8ELMh3qG4FqQshuo NqEJdxzQhuQbmjsc3/cRegLmqTBSSBF64tyHm1OCSlJ9Nd/TY4uqChjJkH9BC+CYYNyBp1Rt GFWAw30xUPCRkgaqB9oibipy24NZhlU90cX7zadZs2anx4wra1wEQ6QeISFftQwHJbyRrl9o G1ued1qHLXPkqHTJJf4AyStCCkVVgRrcGN/Iq1vsfCEIDENTfYGI5UFRAVd9U2B3qZYroq9Q 6S3wrm73veV9FQCbmslggJnYVVFsYMTBaKV+7LCqZ8ATYLCNt1IzzI4OV/dcT+j6oK1HQKaA 0KriBBwDPuspXVOP8A6dAyvqczyLKSaoPWgoCuTwcnBkUmM2l+vL+T78TSXlQTVkPdAwTDGk alVV182UZLphGlXbXdvtvfpm5ePldsmDyQB7AhpWB6a6g9HT8MWe7UeIxdhIJd6hpmMe/AYH 6Br0wAkQtxURI96Ae8DWUs1PODiebMhJ3ZXCkkEyCDRIWUodbiwI9EDRmQBE0asiKApfKpoC G0A2S7icQADpDw7LF7YD8qFUKuZ5UMlkxWEHJVoam/K91VK5CtRJHhPLYOMOneNzpJ7RVqZN TZquj2GKYABRcNFPXRMHF3lBCH27TzjoMbjDuE0SQcZEcEKEyEqVJlMxlitSqJrFD5jabCSQ gSIrtSBvsgYcgDPjULg7rGOroRY1v1faPiwa8JwjRgUCvo3DlkhfgiuGYZIqQ3ARuKJcqI4e bY4+INFbKG/tiTBBPNTPYIHccKonKihEfiCl8AOtxgbgYMQLxdAgD8arhi9U6MV3VaEHXpwM S0V8hyGE3xwUgIbwLuHpdQQRgW0QvYqggi8SO4Vw7CVjbuClmt2JByX0uOv7psI5Zy6cFwcg QKzDChcC+ADy17ijyB7XJkRNtAQCIWmcSV1wrGnwb67nwbp0AyRUoPksnmQ9hUos5s6c0dy9 2d7SjcdKhuigPy59Wgc3aA//aS/cH05rxycUtYHFFV8Knfu6qgeq5SvIUDyOtF94ug8MnILi yEoge8QDaIf8Hwa3RtEBnBoxOIFKPo1clMI0IQIV5J3p+yMVpsazRT21STEKwquqVO7TVaFx MAdCVel0+EAd+AluSbU8FhPc8EjthkcFKD1wLGHrim0EXkwNDEjOR/YMolCtYucYCxzJ8uUz Tkq0QjWspCiDhW3D7NxqGV2Irdu4OUrPxMD7g/lHFAiEJjFylbSjxzyzymI+h7tgtpn3NN/T hVB9T3U9zXORXKq+JRwdQV1xFcVD+AZdI7jucoOrCDMSwVyyraMPVEaNM1y/xJGH1vJ/KBXA TYXwWYDBrsPwYLalwO/yq74BuEAWFLIE8Lak0uiDhf5FPoXxIaFr7EjUkRRBIq1WpbFqjT0k zm04rYd8M54vhKAZNW4oOp5cwsErAnIXGtM8riNmMAPS9aRflkKr6pqrKRUDOhS26dsxz447 +Pa49FWiviEWTxGu6vlGVcR9G5ahStf1PSeTbGZ+UlbjikyhxsAk4K8bSA80HOAD0aZS00AH BEDjvkdWqbrIh8APMFWDqYa8QY3TIe3U2AJKU8MclaIY94uFypSpMQMYe7tM6FM6mV3HnjBM 7t8y8JD9PRxjZHK8oVVJaJTBBxY4A6l1uvl8YPeygs2KCVMkY7aluczVbGFrgYEYA0emBDrk hKFb1dQi1GUqqZhiqm5cF5bhW7qIm25Mh3SrmUbnoMMbzWSFaDfdZLxk6GVVRX5FsYch52S+ DACqwTKIQmB3o0JkIPIjlCkYJwQa4P52LGiQI4U/hFtEhFQQmngAbWcakytXy3x+CJzbbtVw ySWXnHvuucuWLbvyyis3b968V11FKom+ETCj/esr9cN1Xfc87/jjj7/22muF5137s58tfO45 uK1TUpNbhaa5wtWVmMs3id5JX/nKOddcVu3deufPfsRWvP+tL83u9HuThx1+0FFz0uMPhC8K wDyHIAkykqZR2fTxsof+zV2zrNkSik+igWB9jsCD8CBEbOv0WY026wJe84HoRIoJi7wnRC8V DArHAVz2pes7rreqVFleZFqCIfkC6PbhvuC5iELYUVxECwmDaa7PmerD0MkejWzmwSe8d5ZW 9iq0ve6w3fXqwh05cuSGDRuig2+//fYLL7xwdyci/xsqIzoWgEgigMOlAzgRbagIsYv8edGi Rccddxz2f/fdd08+dX7v2nXfaj4sWXA0wSqQh+0lJh1w5ZN/yh7QhH1eeeTeRy757twJDelj jpn1kztNI7u7mym889Qj/7igI+GbQGUE2zSHJRSNV7zubIeceEhDNegBVgMhEAYScNXEe4Ll ZICCBOXBw6LOwPLSX1u0t/ZWK4WgDHSQYm5UaoiiDT1tffzBh4XqUeGKgScxZmRgJha/pS5c VNir9Pe6w65jz4QJE3Ck4xAuPO200/ZwloGGgnUoA9/QDQ1eKXepG/zJNMEYMtfxJk6YOHnS BHCKloockGhI7gc5Zp/ygwXQjY0kL2CZTEvLyLEl3z/2ssugm4rwkTaWA4YPUhhHSlfKcohg Y9kW3UggaxeSu4HuKDGQXhwkmV1pa0xRsMAVgIwlyn40rNCIQBgQJ2BVIcuBKMqgLJSCqdlT WpMzxzbMmtg4MqOVy6RtSrAoSwrNtT/ehAEozD/DqhKNT8L+pOohWbZTDyQbGUEk30j0kSh3 ucyePfsPf/jDzTfffMcdd8BfYZ9Jkyb95je/ufXWW2+77bYzzjhj5yA00PsZJjJ2ZCe8mSWE 42JEAgP1+bmDTjnuhL/7ZgkZkabi6Tdt3NKzsThu9ldYehJaOpBn6lxJKLALFuPM5MBnPEH3 6L/86P0lpxRoBhg0Qm4YzcB1fgWxJdVgSkgf8iMyvErx3wdmxpBA6FJNRdNBgRKoJmihigpz +jKB0Z6MHz65beqkNLIk4YZZrI6UGfKJKGtKlQNVEMGNcwVSU6TnMcM0C7khCDx4JAS97ZZI MdFioHTV77UG7qRpGjgsbDn77LPPO++86E8IVIlEAkq66KKLoi3z589/++23161bVz82Cjx1 xVNXIIjgwBtjNRgeYJPquU4P87932/XYBzaR0Hi5u/D23XePMTZZo1sYa3Q4s+CNyptfeuwP aQvjGDCaiqJm38auF1/rW782kY2XNLNBagm7xPXNuZjVUI7HzSY37sVk0VOa/HJb0vogxpSy lq3qNpQUVxJWscLUWNnwdIyIKugcoSRcUbGkV0ynSoc3j2hLO++95+Rd7qLcITQL+yHN8TQJ t2YGvNJgsRxXBQxXseJVuOgqPbQK2Bj6dpgTlkho9QE6bty4fD7vum61Gu7dbxUDRb0nYL1D nK8fFl0Gy5w5c+obFy5ciPW5c+fWt7zzzju5XA66TKfTqVQqmUxGutm2UAWOJZAwuj4GpC3F Srbm76+/vnXMKOG7CYWw7FO33LVy2ZKxIxvdCkVancHI8izoefa6f1zyq58sv/nKVb/6nx/8 85Vv/flud8P77UY1w6oqnQnQwRRmCsEMGVRGr8TMXNlk6P4wp33VaZjRR56oL+EmY46le8W+ WLkczyUwImzdaxhlN4+WBnPVzbrWKxxghc0dCeewqUaGx5Uyg2eErbsurMTlQQz9Pp7EcwW+ w0gXaDXx+KYuWCF+CoSGY489FoO+Pu6jaB2LxW666aYHH3zwlltuwfpAqxgooR2tZzvx7eZH HQ7g7I899hi0tWXLlieeeAK7P/7442vWrMFtwWgQ/wuFwr333nvggQdCMbAtgMBot9pC0TZo DCyffFDQ7RemHTj3lEu/g3IPfpoKy6/e+O//++eHTWowdQr1OKqiaCkFoTirptvMVFzzqokA 7t7xrSAh/JhbQRZKgV5Nu0q8RyDB8SiRSsIdFvq4Vu7155zw7U9eNzZteauD61rVBYODQJVv yoh8YSxT8pVKZvp3M+MnrH70iga9YCpBoZKwjfZ4blU2npk2ofn1FR/mcn4CBJHoyeWDRMIz YJEcdgluuyHQSoKXN2+NdedqTuiCCy4oFouLFy+GAqAGGEqkCQgNIeDQQw+1bZtUvSsvRRt3 qQIYAc4YhaLe3t6mJkJQ9YX4qtAS68a7B6UOxNZQ3qmnnoqdX3755aOPPhor0N8V37jA+evb qCav93v++ZGHDp5/fCGoJDxTNdSfnblgyV/uOWPGxI50Z/vJ3zrk8ju3IoEFBPCdJX+5N2Px JDyG43dvXP3BS/e1F3qaglLJ8h0lqYlMsSLTR88YP+uYl//XT6af9VUj/Xyx7cBEdsS4Gdcr pTVaKub16B8+d1mu9PERx/46M+O0/IcfaIl1nyy86oDjb0uMP6n02vc+WHhnE+oLjceMPnFB 570XNZzw3arrP3rfnbNPvPjIs35Y6vn4X2+4elP3m9847+pXX/9d58fvn3POL99a+uC6zldf eNl8+XX1xUULm9qypmn97ne/++lPf3r55ZffcMMNn3zyCXz+hx9+WA8QkWIiSe6ch+zJue3O 4iLdnHDCCRgCOCOW9evXYyN8XfQTC1IlGE2kSFwYS7lcBo4YqEg4Hl3T04GV4tYWN/e1y34A 3TghSwrdPPfHp/7jL7+fbna0N8UAq4SmIoVuQwLjVZmoHnnWeZPnnz/yb84de+aCGRdd+zfX 3r3V7OjjTdJooEIA/IePdLaYPOLY9JxTpl1xV3r838Wbz40Zh6DMU8h3Lbn9HN+0EtNOGTfl v8cPmvv6Lcd0vnd7YswpxULQu3zh+rVvvfPSbxMNqoyxiuUnRx+/SfG9bCbPqvNO/f7EE753 yYJZD/715n+4/r687Y8Ye6QWz6LY0zhqrpYcnSuZi1+177jt1s7ujZMnT8HDwGK++c1vfv/7 34carr76aviPMWPGQHRQSSQNiCuS5M6jfO+xZ+djopg0b968+p9GjRrV0dGBGFPf0tbWdtBB B0E9wA5nnnkmQAT2uf/++weeDXEUi6mpfTI/8uBpZ//wQoAFz7PhvsrrCndcedME1pYwAyvm oXsmRN2oNIBh1oQWp/zRd8pS5hl6A5hvtPBMu6PFcoBdqgGA35JJbl21lBV6R8w/3+9cGp84 L94wS65eCdY1t+lD1tnj51ZypzvR0rJl49LCx8tXvPGIw7oVUZGsV7ELdhFZglJBkNVitm30 BAkHVIWTz04ZtfI/n1j60ab/WPgo4mZTi1IpF+ySU0AEEjyRbHn6GYo6X5p3wrL/XIqVp556 Kh6PT548GYEAP//85z9/9NFHSCujUbtXemW/Obco5cTZx44di2/YxIoVK6677rrOzs6pU6di S6lU6uvru+qqq3BnEydOhG/FMOnq6gJMqOumPlKASU3V/JB1XXzlFU0jWtELnQDKZcojt99T Wd0VY2oyGVNiPgqXUXW4rGkO131gaSOua3GD63HGE4B5ne/yYpcKrg68CogWsJzg4PxqYfOa w78yb91jv060x9rHN9tbl6LFIBMXforlWNrPWqs7l7ccMKX5qIOnzV9gsGQllgaCzCTTHdlp nqubpsoKWjyZnTLrghEjTner0worlh4ye+bXvnzet8+6xS/1yl6eSKgHHzF35qy5B0467LXX tq5cRff51LNPzvvqScfOnXvWWWfBMpB9A9lGXAnG8fLly7EC5LZLixk4gveknl0eXM+NAKBh EFDAUUcdhZiPkyIBymaz7e3tuDAuj4j34x//+IEHHsCQQST75S9/GV0YRgYUhxWPCVPVenq7 jxs5e/rZJ/fYZQd2oirvvrj44d/8FrpJK4lsOmNTxT9MMZC9BgJsqKmUtix51l72vL76VfXV h1645m8X/uryRGltIy/rYFXIm2sYFvFEYuVLi9gnL/nFNyufPCr7Him6a7n/hsx3gSYz3bfH VlZobz5eevP+w8++qjE1RikuzijehvWLY8m+KV/+uiurSECLq97a+swVo0YHPfm3mrPjVr/5 l+L7//L3V19+4kktN143R69WH/njvx4/98QfXn7PrTf+/JZbHgjrV+kf/cOljltF9vfGG29g vD700EN4/Oeff/7EE0/8+te/juGL7x0i+s5eClt2hAYRKhsIDXp6epqbm3c4uJ7BDNyOkQL1 YAvs6cUXX2xsbIRW4OKifXCLuCestLS0ANRNnTLV4Uo1l7vizPNu/OOf0iNSwDQxeDCVXXHo 8SuXLZtgzBLuu0d9mTU2+ZVNW1pPv/jIy35dCWQcBOTWj6+YPXF8BmQKM5PMSmttaCSE/nxW VlFBQx+BAWYNjQOb7E0dY+MTJigAyEBLqay+vttrzqRjmlLOF7knsxljfc6l3ilTR3xpbNMK KP9t9VWdNbQhX4kVS23ZcUcEo8eNGTdh9dNP+92Luyt9z77FPiqw0WNYm2n2BtbmnurjT7o9 pagTOR6yCvtEuNUx8C51g43bWc8Oe0dObMdkJTwTNkZhPyLWsAJ/et99990ZLtAKgBlsCx7v 1XB58sknr7nmmugmIuwABxTOVgsuvOonqZZ4gN4k4UM3z/zT799ZtqQ51l4RjmUAOVSRigeg qsGWIO8BTEaJLmmMSLJRjfrYDpZJQw16V9HvdrUcHKOCD4KsCHCY5G1ZbcKYrK5a7UmtIROD 7Y1psgxe8AKU5rjerBe4bGrVW8arrR2ydQyqgDyjqa3tjAakx3wH8xrySDvNwF/5/MPFrkUG z3e0xKcfmjh4mtbYmGbxRE+X+GCZki9FbW0GSNJ91E0kit0pJtq+nfUQVxQu8JKwRMQuhA3Y JkIL4lvtgDD2gMl++OGHB0I74EXkQPWLwVBgLplMJmJIK5VKhFVwTqSosC1A/kqAZmque4p0 XMQczrXeTZtPPXhmk6eaepoXrAmZLXPmsVhQLazrbv3ad+Zc+lsknEhhVLf04M8vb08GpvT8 wLLVpK76xc2rty5/O6N5BuoC0A9IHcn1ZG7q9HY0gQhWRo2Oghh1doBfhixR3AE/SLRtWGkj n4jqAkSiSir3oNMObQ/CMHNVTzPigeJlFAdO2U8k3umyXl/lbtiiLH+/vHK1ADVIsiZ2G54N KerQdFHtQj1021IioqxcuTJaj6xkhwXbH330UUCy+vbzzz//4osvBlIAkQoG4cYbb6z/qW6U dZcIjzxz5kyU16AuI6x0+YjyjJ9+xunPPvJoFnWYAKVKeXIzP+OkJtfOeT2lscd89ZjrnvQk s9FfoCmGhwozckFwXgbqAzT9I8i998Bti3/7i7Y4GhDQpqHagTZiUmXC1IRQ4HeIXkG3GjVE oREIoAktOCCow1776AnBMAUijoInNutIVtFT4NpqApexHbB4fialVCt9+U1+6sEl+r2Lentt aidFGtbfUQNelmrtdbEOnhfdbb3nvffeQ9iArDHksURmCFVFJFKE2feMC+vZK8HnfrwX6eyu u+5asGCBg9ovknwfHWM6fN3d/3bPd769AGVGjSlVXIqJi6am5s1q7c11qV6p4mS/8/RaxlO4 gSoGuIJ+DrR84MZQmoPrY+iYEl1v3vnd+RmlZKGsoXBHGplGnkqDHi0rHNU2dG7gQmCqHfTd EIEJSyIvS2U3PA1WoEEk26iwGS4VSVFj9aQjuOchkpXjQamMaxWsjj8tk0+v2KQoTeSlyW6g mGpYZajVTfu7RAeroN2qB0wR3BfC+86mE2154YUXIpZ6v5aoIATQ8sorr4Derh/712eeOeec b/V09/T3iNGsrF/NbxqnWbbmgKdcv6Y8/Rs/+NKlNyHFpmaz/gkDEcePb5TVVj1z5+M3/ag9 IQ3pUREUNuamBNqq0UtFHVGWRCeQgokj0Ca0r1OhFW3yYUEP56BWQ7UY6BW063Cpc4E+RSpK U+sPlYKAN6pcV/qsUfcuLT+zYiPjiHugjKAbKnyE56g/ECh03ONgvdyeitbTp09HugvcjJrC QEYPtwC68xe/+EVEFuzXUudukaldfullM2bOqLru66+/dt11/6d761aiOjCqkUVLFRbw+79t T26WOQ3NNiVDptcV5ZTj5h987MnZtjEoJWH8U3CFQUNhQm54/9XXHrpHK3VlkZgi+aSeNNgh XJbLVJe601CLkEZoRqH5hX+l6BwW2cLm26jPEBaEPyFOGqizRlP4EaE0VuKihDvsMttuXbT5 7S0guUP5R1oJvzG2+gn/qEvsM7OeutCBlevOLdqIxwDaxgoqDhGdt+8Ljo3AXkR7t7a2wllF Z7NUtNVIZhmq7XgBnzxaufFL6dQGc2tS2mYhBipfFD1cT0tyoxFhwlKQ4viOqrhaTPVB9FQ1 5sdVtHNgRJOQMewD1ZMK2jYdKIZLdIaaauDBmKgHETMLSC31MR92LUjM/DJRoGZalfw5tgBN SLRjQ1ueGbhcMzay5hueXr2aGIVIKaSc2hQT8NaRTrazpH0Xz4577rYNMUJx2B35HVijHZZI xDCpvULDHS6I0UeSC102QFKpXI6qHXA0VMDEwIVZcBPczdwpqUOTLvcMYTLHLVgq8lRmIV5w jeYOeI4mweej3uMrvp3Ah8uYTsM/RCLRKKKCBbXUUhMHSqNgFKi8GfXcADsQwUCSDGNjBN5g jGFPPOKNROGWurDJ0+G+0HmCmamSW6tyyqKPAQvgvgwUW8Nz4BqYCUTqrdlLZDyDXnarnj3L vU597u8NRBqlZfv7h0+oEbbkX1AIFd8Ynx6ZopmFQeAkwcVxboOhpuY3TP2BP0OER20aokSh E3CZOtSonR1yrk0oDZEYNRBCC4C8YeCGUqhmjvYb2nFgX1RtKhXabRBLaGTi7CgQoaSAO9Ax prioAGmLVPq1TnfJRqQ5uKhHo6HmxFCKGzAxdSh0A9nuN+e2v/r4NPsHTloLWhujgEfN52Hv X1hLpr4NiL023CF9GAT1SpMxh/ImkWMc1z7hBsqAqameWgFqT0wH7HLaHTWbUgsp4TuGVkgX GB1pEGVCMClNL0tjyXJyxeGJqLf3M10+l+phTmNcTxqqcF2yFgx/ShbDcBItxDhEGqhJPPRR tclq0Xr9U1ujM0TaCw/ejVAx0xRXJI9I14QloU0XU1DRJEzsMo8n31tXWVFEuAV2qKGG/4Lq Ye1JNaa6od9AdzqaLWha2mcqCDo58jD0g8LOwuhIU63IdNBaj0urwkxWldSTb28Jx0RUZaZb +kxv6/NoPYiHk9tT8cCl8Rm2n5GtgEUboilnu1dzNIuHSGFUMAAQwDPZmM5jWGVulszWB1/b sryMGIM/omJO0/2HYg7Pnkbd51E9lspGpDCp2oagPLAzJLLIi4Vpyf43GO+32RHAI0LB9QMt noIz09PNS9fbr3ycD0+F8QP/9v/i5TufR/XENK0xoWnCQcZBegnn54KWq01Tp7ewRO2A+/DZ jesByhrwGZhAApeHs+AolGmaZRVtv3lEx5othftfWdtFExl1pmtoBKYes5qqPkN88HlUT3NS bUxgZrTqCY8SFHr/HmgwmuVObTlIt8IZBXv9EK+w42Q6aubEpDbCz9SESA6M3jyBJQSJ4QxT miCEpnaUbm0/iDV3vPJ+5x1PdXZiAiQQgRrH/Iloqnyolv4JJfttoft0wGeo+X24PooUrop3 2eAfglOwFhwkTplk/Y8jUlUPbZmUH9IMjoi/IcQcvVxg7wuxcEBp1Ly5484wPw0MOSZUQTFq 2N4JIhA6ozQV/W0o2pTjeM9OLF7Umx/+yPvTErSbQyMRP0K4IZLaPt3H3u90T3sMr3ow4Zfm tuE5Q+4QFRZ6v9cPDmv8b1PNzlzJMjC/wKf5GSGpFQIq6h/Z90f2qId6Z0GG7dUhpRBOHg1n FRGYVgi7SdVMpnwttryr+tLyvufWlqm3g6ZoDZbf3Pfbru+5H4/6Kc6+50MigVMUpv2QSSgW CDHGrjmxfXqjV3YEKnSkHnRab+MYIvZx7wsN7ZChJG3Wx3nt0MAHhw1DpDwWhTcYKOgZaujW rVhFUzeUtcffLby+BjVYcmJgb3CCWqPt3q88lHvs06MO5QUHnAtPDgGGAAhvhkJRi2azYWbU P51/gOl2YtYvKmIh/4XcEEA2OpLKnbu5n+3MJFKjRTMUIo9U90Y0KnSwAGin51rALa6iO8A0 Y0m7ai9b37ukq7hso7MW0+dIL8hv/BhoHsyG+IyksMfTDqd6UEvB5UOPjrFrYaaHIpzpTea1 Z01XeteB90eiDhqSwvu2F+aCAcP+FMe38fgDifxI2VFdAKQYAj0B8tCWAAKiCEYgA3K3XKb1 VN28p27I2R+u71m9tbwRE7BCeYVnxz7Ru1eiK/6Xc241QYbCQzEGz+8fPSZz5swDZK4rbBbp b9uKvFOIssMpCdgzfBsBRaSQ8yfJh6/tILlGTg1/V3y814o8WFgbQPSXCtJMcPA9Za/L0fpc pTufhwvDZJV+Ugi0JyIizu/0GyPOhgkNOM8+Nd8MrY0Np/VQGQE1mfBdkf20vEhREIBDq72F Y9foaHtfVauGRd6r7uFCnUQGSm/co76J6N0U9IGJbHvlAM2BDKdqI/5jwjFKqVToxFyV/rYB GhAYDUMzZWe/9De86kG8wTsd0BZDEYjIf4A3VEprXPIu4Wu9PNnvgequaNtK/cC6A4xkQtoj o8MXiG56HxL4NUzLA69G7zUIVenR/AjaGcU6HIHEK+oerpdB90u8g915eNWDwU2tLQNielQf hsevF6IG2g+Jr//NuRHii+4/Guh1UBdtDDtwavXQunpCpaKQjf7mmm2EnEQIOcLXwVANIzST 8AbIc9Yx4GBl/cXxX0jgCwl8IYEvJBBJ4P8CkLsiseCTLsQAAAAASUVORK5CYII= --B_3379660361_91296327-- From sgundave@cisco.com Fri Feb 4 10:43:39 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC8433A69CF for ; Fri, 4 Feb 2011 10:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.014 X-Spam-Level: X-Spam-Status: No, score=-9.014 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJSpVJMoGAGD for ; Fri, 4 Feb 2011 10:43:16 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 611623A67CC for ; Fri, 4 Feb 2011 10:43:16 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4BAPvXS02rR7H+/2dsb2JhbACCRJQLQIYCAYczaHOeIJsign0BGYJDBIR6hm2DM4MBhXE Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 04 Feb 2011 18:46:40 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p14Ike6w006539; Fri, 4 Feb 2011 18:46:40 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Feb 2011 10:46:40 -0800 Received: from 10.32.246.213 ([10.32.246.213]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Fri, 4 Feb 2011 18:46:40 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Fri, 04 Feb 2011 10:47:10 -0800 From: Sri Gundavelli To: "Zuniga, Juan Carlos" , , Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLwmpURzmRlysrlUidlexdQorGZJPuBh2AgAAR4ICAAAzJgIAACkaAgADJ5gCAAKKGAP//oT5wgAAf2NyAAIzc8IAA5pGygAC5E2CAACn5ng== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3379661231_91326133" X-OriginalArrivalTime: 04 Feb 2011 18:46:40.0843 (UTC) FILETIME=[DC7E49B0:01CBC49B] Cc: netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 18:43:39 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3379661231_91326133 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Juan Carlos, Please see inline ... On 2/4/11 8:34 AM, "Zuniga, Juan Carlos" wrote: > Sri, Pierrick, Carlos, all, > =20 > Please see inline: > =20 > =20 >=20 > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of > Sri Gundavelli > Sent: February 4, 2011 12:15 AM > To: pierrick.seite@orange-ftgroup.com; sfaccin@rim.com; gerardog@qualcomm= .com; > sfaccinstd@gmail.com > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > Subject: Re: [netext] Consensus call to adopt > I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc > =20 > Hi Pierrick: >=20 > I agree with lot of points. > * Yes, its all about handover execution. This is the key point. A PBU mes= sage > from the MN can be the first step towards activating the handover process= . Or > a FMI trigger from the LMA, may itself be the pre-trigger for PBU message= from > the MAG. At the end of the day, the LMA applies the policy and provides t= he > set of prefixes to the MAG. MAG will continue to behave as in 5213. The > decision logic, or the granularity of the policy rule applicability on th= e LMA > can be out of scope > [JCZ] I would add the case in which the prefixes are pre-assigned and the= flow > movement is started from the MN by simply sending packets to the new inte= rface > =B3for instance=B2 based on MN policies. This case would require no MN/MAG/LM= A > signaling and would satisfy the 3GPP/ANDSF concerns that have been raised > without defining any policy management, network selection, etc in this dr= aft. > We just need to state in the draft that, if the LMA starts receiving pack= ets > over a different interface, it would understand this as an implicit IP Fl= ow > mobility change. In this case, the LMA should start using the same interf= ace > on which the uplink packets were received for subsequent downlink packets= . >=20 > [Sri] If I followed this correctly, I=B9m just not sure about the triggers = on > the UE end, as when it will use a prefix, received over on RA on one > interface, and decide to move it to a different interface. Even if the ou= t of > band policy assumption is there, the triggers are critical, IMO. If this = is > about flow mirroring with no out of band policy interface, not sure, on t= he > functional requirements on the UE for such case. DPI ? >=20 >=20 > * Policy synchronization is an issue, for the case where the UE=B9s forward= ing > decision is based on the policy and not based on the ND messages from the > attached interface. It is very well may be that, we have the same issue f= or > IFOM as well, IMO, but that=B9s beside the point for now. The policy activ= ation > on the UE, and the associated issues should be discussed in this context = and > as needed.=20 > * This draft should not deal with flow policies, how they are applied and= what > granularity can be out of scope, IMO. These policies need not be carried = in > PMIP signaling place, unless we have MN-AR interface > * I=B9m not clear on the policy management though, before we say, it can be > separate thread. The whole approach seems to be out of band at this point= and > not sure what can be specified on the PMIP signaling plane with respect t= o > policy.=20 > [JCZ] For these last three points, I agree with Pierrick that this draft > should concentrate on the PMIP flow movement and not on the policy manage= ment. > To me clarifying all the above points and cleaning up the wording and > scenarios order would make the draft good enough for group=B9s adoption. >=20 > [Sri] Agree. The draft appears to touch lot of aspects. In reality, if we= get > rid of flow templates from signaling, only deal with the approach of carr= ying > prefixes as in base spec, with the assumptions on out of band flow policy > interfaces, will simplify lot of things, will leave specific issues to de= al > with. >=20 > =20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 2/3/11 7:35 AM, "pierrick.seite@orange-ftgroup.com" > wrote: > Hello, > =20 > This is an interesting discussion, thanks for bringing the ANDSF issues o= n the > table. Effectively, mobility control, i.e. access selection, is a key poi= nt > for an operator. From an operator point of view, criteria for selection i= s not > only RAT type or SSID; we can imagine plenty of other criteria. Different > mobility control models can be envisaged such as Network controlled or > terminal controlled and so on... For sure, in PMIP context, policies > synchronization can be an issue and how decision made on the terminal can > interact with network managed mobility should be discussed. But, I don't = think > draft-bernardos should go in this space. I think, we should clearly > distinguish mobility functions. IMHO, draft-bernardos should not be expec= ted > to deal with selection management, or mobility triggers, but only on the > handover execution. In other words, the draft should assume that handover > decision has been made (how decision is made is out of scope) and, then, = only > focus on mechanism allowing the LMA to transfer flow(s). Although related= , > mobility decision management, e.g. policy based, should be discussed in a > separated thread. > =20 > BR, > Pierrick >=20 > =20 >=20 >=20 > De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part = de > Stefano Faccin > Envoy=E9 : jeudi 3 f=E9vrier 2011 08:05 > =C0 : gerardog@qualcomm.com; sgundave@cisco.com; sfaccinstd@gmail.com > Cc : netext@ietf.org; Basavaraj.Patil@nokia.com > Objet : Re: [netext] Consensus call to adopt > I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc >=20 > Hello Sri, > From a point of view of applicability of the solution, I must agree with > Gerardo that assuming synchronization of policies is an issue of this sol= ution > since it comes with a set of restrictions on how the solution can be appl= ied. > Cheers, > Stefano >=20 > Stefano=20 > Stefano M. Faccin >=20 > Standards Manager > Research In Motion > 122 West John Carpenter Parkway > Irving, TX 75039=20 > Internal: 820 63451 > Desk: +1 972 910 3451 > BlackBerry: +1 510 230 8422 > sfaccin@rim.com=20 > Time zone: PST (GMT -8) >=20 >=20 > From: Giaretta, Gerardo [mailto:gerardog@qualcomm.com] > Sent: Wednesday, February 02, 2011 11:13 PM > To: Sri Gundavelli ; stefano faccin > Cc: netext@ietf.org ; Basavaraj.Patil@nokia.com > > Subject: Re: [netext] Consensus call to adopt I-D: > draft-bernardos-netext-pmipv6-flowmob as WG doc >=20 > Hi Sri, > =20 > There is no implicit assumption of synchronized policies. A basic example= that > shows that there is no assumption is the following: ANDSF policies may be > based also on location of the UE. For example the UE should prefer WLAN o= nly > in a given location. When the UE is attached over WLAN there is no way fo= r the > PDNGW/HA to verify the location of the UE and therefore to verify UE acti= ons > based on policies. > =20 > The assumption on synchronization of policies is only applicable to this = draft > and I think it is a wrong one. > =20 > Cheers > Gerardo > =20 >=20 > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of > Sri Gundavelli > Sent: Wednesday, February 02, 2011 6:50 PM > To: stefano faccin > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > Subject: Re: [netext] Consensus call to adopt I-D: > draft-bernardos-netext-pmipv6-flowmob as WG doc >=20 > Hi Stefano, >=20 > One comment. >=20 > Agree with you there is no ANDSF interface to the network node, but the > assumption of synchronized policies between the ANDSF server and the PDN = GW/HA > is there, implicitly IMO. With out this assumption, I do not know, how th= e HA > can ever validate the flow mobility options received in the BU. If the > operator requires any control on enforcing a flow policy rule, the PDN GW= /HA > needs to have synchronized policies, without which its always the client > decision. I=B9m not sure, operators in 3GPP would like that :) >=20 > No doubt, the lack of MN-AR interface is surely an issue for supporting > complex flow policies. I realize the issues and I agree with you. But, th= e > assumption of synchronized policies can offer some solution with some > configuration requirement on the HA (assuming there are no other issues). > There are also the proposals on flow mirroring on the UE ..., requiring n= o > flow policies. I=B9ve not evaluated this, however. Folks can comment on thi= s. >=20 > It is also to be noted, for some of the scenarios such, there is no flow > policy interface needed. We can identify what scenarios create any > configuration limitations on the HA and which one=B9s do not . As I=B9ve note= d > earlier, this is surely an open issue, that we need to discuss in the WG. >=20 >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 > =20 >=20 >=20 > On 2/2/11 9:08 AM, "stefano faccin" wrote: > Sri, > thanks for the reply. Can you clarify in which system or scenario ANDSF i= s > available to network entities as well? There is no such availability in 3= GPP, > and making such information available would require considerable architec= tural > changes, therefore the applicability of this solution to what seems to be= the > only realistic scenario hinges on 3GPP making considerable architectural > changes. I would therefore not be so hastily concluding that the ANDSF > information is available to the LMA and underestimate what it would reall= y > take to make the solution applicable. >=20 > If we cannot guarantee that there is at least one realistic solution to h= ave > the MNa nd LMA in synch, how do we expect that this solution is applicabl= e at > all? In 3GPP there is no need to have such implicit assumption, be cause = 1) > the MN is provided policies explicitly through the ANDSF, and 2) it is th= e MN > and only the MN that makes IP flow mobility decisions and communicates th= em > explicitly (with well defined signalling) to the LMA, and therefore no ma= gic > is needed. There is no need in 3GPP to have the ANDSF and PDN GW policies > synchronized, since the PDN GW does not use such policies. >=20 > Sri, in the end it is a matter of whether we develop a solution that will= rely > on some unknown magic to be deployed, or a solution that we know can be > deployed in at least one way because there are solutions to what I consid= er > major open issues. >=20 > Cheers, > Stefano >=20 > On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli wrote= : > Hi Stefano, >=20 > Thanks for the discussion. >=20 > As you say, the ANDSF policies are allowing the MN a.) to make the right > network attachment decision and b.) make the access selection on a flow b= asis. > This same policy that is present in the ANDSF server, is available for th= e > network nodes as well. I=B9m not sure, with out this assumption the solutio= n can > work for all currently listed cases. We clearly need the MN and the LMA t= o be > in synch with respect to the configured policy. How, that is done, I gues= s we > will not try to know. I thought even in 3GPP, this is the implied assump= tion > ? But, this is for you to clarify. Not specifically for IFOM where UE and= PDN > GW/HA are negotiating the flow policies, but generally that the PDN GW an= d the > ANDSF policy server will have synchronized policies. The MAG and the LMA = have > the ability to carry this flow policy information in signaling messages a= nd > influence the access selection. The policy is a opaque object, with exten= sible > formats, when carried in the signaling plane, should allow the LMA/MAG to > apply those access policies, while assuming MN is following the same rule= s. > These policies can surely reflect the specific WLAN access/operator speci= fic > rule. I=B9m surely with you, the lack of MN-AR interface is surely an issue= and > I see that. But, we need to understand, what are the limitations with the > approach of out of band policy interfaces and what will be the solution > limitations. If we need to tie the flow movement at the prefix granularit= y and > rely on the natural ND interface in the form of RA PIO option, more like = PDN > offload in MAPCON, or at the granularity of a flow level, is open for > discussion. I want to simplify this draft for sure, we can surely discuss= each > of these issues on the WG draft. >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 >=20 >=20 > On 2/1/11 8:29 PM, "stefano faccin" > wrote: > Sri, > thanks for the reply. >=20 > I'd like to comment on the "the flow policy decisions need not be based o= n the > specific WLAN network". Does it mean, as I believe it does, that the curr= ent > solution would not allow an operator deploying such solution to decide to > route flows over a specific WLAN or not depending on which specific WLAN = the > MN is connected to? E.g. the operator or the entity in control of the > decisions for the routing may want to direct certain traffic always over = WLANs > that the operator deploys, and instead route only some of the traffic ove= r > WLANs of roaming partners or of the MN user home. How does this solution > support that scenario if the LMA is not told specifically which WLAN the = MN is > connected to? From a deployment point of view, I do not believe we can af= ford > to leave out this scenario. Please note that the establishment of a secur= ity > relationship between the MN and the MAG, and a specific MAG identity, can= not > guarantee that the LMA knows which specific WLAN access network the MN is > connected to. Assuming that would severely restrict the deployment scenar= ios. >=20 > As for the MN and the LMA being magically in synch, I am very concerned a= bout > a "glass ball" solution. You mention ANDSF defined by 3GPP as a solution = for > this "out of band" delivery of policy. Fair enough, however there is an i= ssue > with that. ANDSF is designed specific to be a MN-centric solution where > policies are provisioned in the MN and the MN decides which network > technologies and access networks it needs to connect to, under what > conditions, and which IP traffic needs to be routed on such accesses. No = IP > point of attachment in the network (i.e. the PDN GW in 3GPP that is the L= MA in > PMIPv6) is aware under any conditions of such policy. Therefore, even if = in > order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would > unfortunately not provide a solution unless the MN can communicate to the= MAG > and the LMA the decisions the MN has taken based on the ANDSF policies. >=20 > I believe the key point here is that we need to understand how the soluti= on > can be realistically applied to a real scenario, and that we need to ensu= re > that important and realistic deployment scenarios are not excluded by the > solution. >=20 > Cheers, > Stefano >=20 > On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli > wrote: > Hi Stefano: >=20 > These are valid points and some good comments. Let me share my thoughts. >=20 > Carlo=B9s draft is not assuming any new MN-AR interface. Its going with the > assumption there is established policy on the mobile and on the LMA, whic= h > allows the mobile to select the access network at a flow level granularit= y, > without requiring any explicit signaling between the MAG and the MN. To l= arge > part this is all about out of band policy interface, such as ANDSF, towar= ds > the UE, leading to the assumption that magically the MN and the LMA are i= n > sync with respect to flow policies, access selection and they will make t= he > right forwarding decision. Secondly, the flow policy decisions need not b= e > based on the specific WLAN network, but it is implicitly driven by the MA= G =AD > LMA security relation, where the MAG attachment to the WLAN network > transitively allows the LMA to make the flow policy decisions based on th= e MAG > identity. If the WLAN network is not trusted, there is truly no MAG in th= at > network, where the LMA shares a security relation with that node. >=20 > There are still some open issues on this draft that needs to be discussed= in > the WG. On the approaches to allow more a flow aggregate movement, that = is a > discussion point. There are issues that we need to discuss, supporting sp= lit > link model, or eliminating some favorite brand of signaling message (FMA)= and > riding on PBU/PBA and just with one FMI trigger, and on the aspects aroun= d MN > applying the flow policies by flow mirroring. We have no agreement on tho= se > issues yet. >=20 > Its just a base draft, for further discussion and resolving those issues.= But, > hope that is not a stopper for base draft selection. >=20 >=20 > Sri >=20 >=20 >=20 >=20 >=20 >=20 > On 2/1/11 6:39 PM, "stefano faccin" > wrote: > Raj, > thanks for the email. >=20 > I need to apologize in advance if my questions have already been answered > before (though I cannot find a conclusive answer anywhere). >=20 > I think that a protocol that is developed in NETEXT (or other groups) sho= uld > have at least a potential realistic scenario for applicability. >=20 > In terms of applicability, though it is not part of the protocol definiti= on > per se, unless there are solutions in place for either the host to indica= te to > the network where the flows should be routed or for the LMA to receive so= mehow > from somewhere some policies, the solution cannot really provide flow mob= ility > since there is no way to decide which flows are routed where. If we are > thinking about a host-based solution, I have not yet seen a solution as t= o how > the host can indicate to the MAG and ultimately to the MAG which flows sh= ould > be routed on each access. If we are relying on modifications of layer 2 > protocols, aren't we defining a solution that works only with some > technologies (since for other access technologies it is rather unrealisti= c to > modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-ba= sed > solution, can we hear of at least one example of a real-life scenario whe= re > the LMA would receive such policies, and how such delivery would happen? = Also, > should there be a solution to have policies in the LMA, how does the LMA > actually decide to route flows on one access or the other? E.g., if some = flows > need to be routed on certain WLAN networks, but shall not be routed on ot= her > WLAN networks, how does the LMA know which specific WLAN network the host= is > connected to? Perhaps I missed the ability for the MAG to know e.g. the W= LAN > SSID and provide it to the LMA, in which case I would appreciate if someb= ody > could highlight to me where that is defined. >=20 > I think that, though not integral to the protocol specification, understa= nding > what framework the protocol would/needs to fit in is rather important. >=20 > Cheers, > Stefano >=20 >=20 > On Tue, Feb 1, 2011 at 3:47 PM, > > wrote: >=20 > Hello, >=20 > We have discussed the flow mobility solutions for Proxy MIP6 previously a= t > IETFs 78 and 79. > This is a consensus call for adopting this I-D: > draft-bernardos-netext-pmipv6-flowmob-02 > as the working group document. > I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt >=20 > The consensus call will expire on Feb 15th, 2011. Please indicate your > support or concerns in adopting this I-D as the WG baseline document on > the mailing list. >=20 > Please note that this I-D will serve as the baseline in the WG and will b= e > developed further based on input and feedback from WG members. >=20 > -Basavaraj >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext >=20 > =20 > =20 > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-publi= c > information. Any use of this information by anyone other than the intende= d > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from y= our > system. Use, dissemination, distribution, or reproduction of this transmi= ssion > by unintended recipients is not authorized and may be unlawful. >=20 --B_3379661231_91326133 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmip= v6-flowmob as WG doc Hi Juan Carlos,

Please see inline ...


On 2/4/11 8:34 AM, "Zuniga, Juan Carlos" <JuanCarlos.Zuniga@InterDigital.com> wrote:
<= SPAN STYLE=3D'font-size:11pt'>Sri, Pierrick, Carlos, all= ,
 
Please see inline:
 
 

From: netext-bounces@ietf.org [mailt= o:netext-bounces@ietf.org] On Behalf Of Sri Gundavelli
Sent: February 4, 2011 12:15 AM
To: pierrick.seite@orang= e-ftgroup.com; sfaccin@rim.com; gerardog@qualcomm.com; sfaccinstd@gmail.com
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-ne= text-pmipv6-flowmob as WG doc
Hi Pierrick:

I agree with lot of points.
  • Yes, its all about handover execution. This is the k= ey point. A PBU message from the MN can be the first step towards activating= the handover process. Or a FMI trigger from the LMA, may itself be the pre-= trigger for PBU message from the MAG. At the end of the day, the LMA applies= the policy and provides the set of prefixes to the MAG. MAG will continue t= o behave as in 5213. The decision logic, or the granularity of the policy ru= le applicability on the LMA can be out of scope
[JCZ] I would add the case in whi= ch the prefixes are pre-assigned and the flow movement is started from the M= N by simply sending packets to the new interface “for instance” = based on MN policies. This case would require no MN/MAG/LMA signaling and wo= uld satisfy the 3GPP/ANDSF concerns that have been raised without defining a= ny policy management, network selection, etc in this draft.
We just need to state in the draft that, if the LMA starts receiving packet= s over a different interface, it would understand this as an implicit IP Flo= w mobility change. In this case, the LMA should start using the same interfa= ce on which the uplink packets were received for subsequent downlink packets= .

[Sri] If I followed this correctly, I’m just not sure about th= e triggers on the UE end, as when it will use a prefix, received over on RA = on one interface, and decide to move it to a different interface. Even if th= e out of band policy assumption is there, the triggers are critical, IMO. If= this is about flow mirroring with no out of band policy interface, not sure= , on the functional requirements on the UE for such case. DPI ?

  • Policy synchronization is an issue, for the case whe= re the UE’s forwarding decision is based on the policy and not based o= n the ND messages from the attached interface. It is very well may be that, = we have the same issue for IFOM as well, IMO, but that’s beside the po= int for now.  The policy activation on the UE, and the associated issue= s should be discussed in this context and as needed.=20
  • This draft should not deal with flow policies, how they = are applied and what granularity can be out of scope, IMO. These policies ne= ed not be carried in PMIP signaling place, unless we have MN-AR interface=20
  • I’m not clear on the policy management though, bef= ore we say, it can be separate thread. The whole approach seems to be out of= band at this point and not sure what can be specified on the PMIP signaling= plane with respect to policy.
[JCZ] For these last three points= , I agree with Pierrick that this draft should concentrate on the PMIP flow = movement and not on the policy management.
To me clarifying all the above points and cleaning up the wording and scena= rios order would make the draft good enough for group’s adoption.

[Sri] Agree. The draft appears to touch lot of aspects. In reality, if we g= et rid of flow templates from signaling, only deal with the approach of carr= ying prefixes as in base spec, with the assumptions on out of band flow poli= cy interfaces, will simplify lot of things, will leave specific issues to de= al with.

 

Regards
Sri







On 2/3/11 7:35 AM, "pierri= ck.seite@orange-ftgroup.com" <pierrick.seite@orange-ftgroup.com> wrote:
Hello,
 
This is an interesting discussion, thanks for bringing the ANDSF issues on = the table. Effectively, mobility control, i.e. access selection, is a key po= int for an operator. From an operator point of view, criteria for selection = is not only RAT type or SSID; we can imagine plenty of other criteria. Diffe= rent mobility control models can be envisaged such as Network controlled or = terminal controlled and so on... For sure, in PMIP context, policies synchro= nization can be an issue and how decision made on the terminal can interact = with network managed mobility should be discussed. But, I don't think draft-= bernardos should go in this space. I think, we should clearly distinguish mo= bility functions. IMHO, draft-bernardos should not be expected to deal with = selection management, or mobility triggers, but only on the handover executi= on. In other words, the draft should assume that handover decision has been = made (how decision is made is out of scope) and, then, only focus on mechani= sm allowing the LMA to transfer flow(s). Although related, mobility decision= management, e.g. policy based, should be discussed in a separated thread.  
BR,
Pierrick

 


De : = netext-bounces@ietf.org [mailto= :netext-bounces@ietf.org] De la part de Stefano Faccin
Envoyé : jeudi 3 février 2011 08:05
À : gerardog@qualcomm.com= ; sgundave@cisco.com; sfaccinstd@gmail.com
Cc : netext@ietf.org; Basavaraj.Patil@nokia.com
Objet : Re: [netext] Consensus call to adopt I-D:draft-bernardos-net= ext-pmipv6-flowmob as WG doc

Hello Sri,
>From a point of view of applicability of the solution, I must agree with Ge= rardo that assuming synchronization of policies is an issue of this solution= since it comes with a set of restrictions on how the solution can be applie= d.
Cheers,
Stefano

Stefano
Stefano M. Faccin

Standards Manager
Research In Motion
122 West John Carpenter Parkway
Irving, TX 75039
Internal: 820 63451
Desk: +1 972 910 3451
BlackBerry: +1 510 230 8422
sfaccin@rim.com
Time zone: PST (GMT -8)


From: Giaretta, Gerardo [mailto:gerardog@qualcomm.com]
Sent: Wednesday, February 02, 2011 11:13 PM
To: Sri Gundavelli <sgundave@cisco.c= om>; stefano faccin <sfaccinstd@gma= il.com>
Cc: netext@ietf.org <netext@ietf.org>; Bas= avaraj.Patil@nokia.com <Basavaraj= .Patil@nokia.com>
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-n= etext-pmipv6-flowmob as WG doc

Hi Sri,
 
There is no implicit assumption of synchronized policies. A basic example t= hat shows that there is no assumption is the following: ANDSF policies may b= e based also on location of the UE. For example the UE should prefer WLAN on= ly in a given location. When the UE is attached over WLAN there is no way fo= r the PDNGW/HA to verify the location of the UE and therefore to verify UE a= ctions based on policies.
 
The assumption on synchronization of policies is only applicable to this dr= aft and I think it is a wrong one.
 
Cheers
Gerardo
 

From: netext-bounces@ietf.org [mailt= o:netext-bounces@ietf.org] On Behalf Of Sri Gundavelli
Sent: Wednesday, February 02, 2011 6:50 PM
To: stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-n= etext-pmipv6-flowmob as WG doc

Hi Stefano,

One comment.

Agree with you there is no ANDSF interface to the network node, but the ass= umption of synchronized policies between the ANDSF server and the PDN GW/HA = is there, implicitly IMO. With out this assumption, I do not know, how the H= A can ever validate the flow mobility options received in the BU. If the ope= rator requires any control on enforcing a flow policy rule, the PDN GW/HA ne= eds to have synchronized policies, without which its always the client decis= ion. I’m not sure, operators in 3GPP would like that :)

No doubt, the lack of MN-AR interface is surely an issue for supporting com= plex flow policies. I realize the issues and I agree with you. But, the assu= mption of synchronized policies can offer some solution with some configurat= ion requirement on the HA (assuming there are no other issues). There are al= so the proposals on flow mirroring on the UE ..., requiring no flow policies= . I’ve not evaluated this, however. Folks can comment on this.

It is also to be noted, for some of the scenarios such, there is no flow po= licy interface needed. We can identify what scenarios create any configurati= on limitations on the HA and which one’s do not . As I’ve noted = earlier, this is surely an open issue, that we need to discuss in the WG.


Regards
Sri




 


On 2/2/11 9:08 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:
Sri,
thanks for the reply. Can you clarify in which system or scenario ANDSF is = available to network entities as well? There is no such availability in 3GPP= , and making such information available would require considerable architect= ural changes, therefore the applicability of this solution to what seems to = be the only realistic scenario hinges on 3GPP making considerable architectu= ral changes. I would therefore not be so hastily concluding that the ANDSF i= nformation is available to the LMA and underestimate what it would really ta= ke to make the solution applicable.

If we cannot guarantee that there is at least one realistic solution to hav= e the MNa nd LMA in synch, how do we expect that this solution is applicable= at all? In 3GPP there is no need to have such implicit assumption, be cause= 1) the MN is provided policies explicitly through the ANDSF, and 2) it is t= he MN and only the MN that makes IP flow mobility decisions and communicates= them explicitly (with well defined signalling) to the LMA, and therefore no= magic is needed. There is no need in 3GPP to have the ANDSF and PDN GW poli= cies synchronized, since the PDN GW does not use such policies.

Sri, in the end it is a matter of whether we develop a solution that will r= ely on some unknown magic to be deployed, or a solution that we know can be = deployed in at least one way because there are solutions to what I consider = major open issues.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli <sgundave@cisco.com> wrote:
Hi Stefano,

Thanks for the discussion.

As you say, the ANDSF policies are allowing the MN a.) to make the right ne= twork attachment decision and b.) make the access selection on a flow basis.= This same policy that is present in the ANDSF server, is available for the = network nodes as well. I’m not sure, with out this assumption the solu= tion can work for all currently listed cases. We clearly need the MN and the= LMA to be in synch with respect to the configured policy. How, that is done= , I guess we will not try to know.  I thought even in 3GPP, this is the= implied assumption ? But, this is for you to clarify. Not specifically for = IFOM where UE and PDN GW/HA are negotiating the flow policies, but generally= that the PDN GW and the ANDSF policy server will have synchronized policies= . The MAG and the LMA have the ability to carry this flow policy information= in signaling messages and influence the access selection. The policy is a o= paque object, with extensible formats, when carried in the signaling plane, = should allow the LMA/MAG to apply those access policies, while assuming MN i= s following the same rules. These policies can surely reflect the specific W= LAN access/operator specific rule. I’m surely with you, the lack of MN= -AR interface is surely an issue and I see that. But, we need to understand,= what are the limitations with the approach of  out of band policy inte= rfaces and what will be the solution limitations. If we need to tie the flow= movement at the prefix granularity and rely on the natural ND interface in = the form of RA PIO option, more like PDN offload in MAPCON, or at the granul= arity of a flow level, is open for discussion. I want to simplify this draft= for sure, we can surely discuss each of these issues on the WG draft.


Regards
Sri






On 2/1/11 8:29 PM, "stefano faccin" <sfaccinstd@gmail.com <htt= p://sfaccinstd@gmail.com> > wrote:
Sri,
thanks for the reply.

I'd like to comment on the "the flow policy decisions n= eed not be based on the specific WLAN network". Does it mean, as I beli= eve it does, that the current solution would not allow an operator deploying= such solution to decide to route flows over a specific WLAN or not dependin= g on which specific WLAN the MN is connected to? E.g. the operator or the en= tity in control of the decisions for the routing may want to direct certain = traffic always over WLANs that the operator deploys, and instead route only = some of the traffic over WLANs of roaming partners or of the MN user home. H= ow does this solution support that scenario if the LMA is not told specifica= lly which WLAN the MN is connected to? From a deployment point of view, I do= not believe we can afford to leave out this scenario. Please note that the = establishment of a security relationship between the MN and the MAG, and a s= pecific MAG identity, cannot guarantee that the LMA knows which specific WLA= N access network the MN is connected to. Assuming that would severely restri= ct the deployment scenarios.

As for the MN and the LMA being magically in synch, I am very concerned abo= ut a "glass ball" solution. You mention ANDSF defined by 3GPP as a= solution for this "out of band" delivery of policy. Fair enough, = however there is an issue with that. ANDSF is designed specific to be a MN-c= entric solution where policies are provisioned in the MN and the MN decides = which network technologies and access networks it needs to connect to, under= what conditions, and which IP traffic needs to be routed on such accesses. = No IP point of attachment in the network (i.e. the PDN GW in 3GPP that is th= e LMA in PMIPv6) is aware under any conditions of such policy. Therefore, ev= en if in order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF = would unfortunately not provide a solution unless the MN can communicate to = the MAG and the LMA the decisions the MN has taken based on the ANDSF polici= es.

I believe the key point here is that we need to understand how the solution= can be realistically applied to a real scenario, and that we need to ensure= that important and realistic deployment scenarios are not excluded by the s= olution.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli <sgundave@cisco.com <http://s= gundave@cisco.com> > wrote:
Hi Stefano:

These are valid points and some good comments. Let me share my thoughts.
Carlo’s draft is not assuming any new MN-AR interface. Its going with= the assumption there is established policy on the mobile and on the LMA, wh= ich allows the mobile to select the access network at a flow level granulari= ty, without requiring any explicit signaling between the MAG and the MN. To = large part this is all about out of band policy interface, such as ANDSF, to= wards the UE, leading to the assumption that magically the MN and the LMA ar= e in sync with respect to flow policies, access selection and they will make= the right forwarding decision. Secondly, the flow policy decisions need not= be based on the specific WLAN network, but it is implicitly driven by the M= AG – LMA security relation, where the MAG attachment to the WLAN netwo= rk transitively allows the LMA to make the flow policy decisions based on th= e MAG identity. If the WLAN network is not trusted, there is truly no MAG in= that network, where the LMA shares a security relation with that node.

There are still some open issues on this draft that needs to be discussed i= n the WG.  On the approaches to allow more a flow aggregate movement, t= hat is a discussion point. There are issues that we need to discuss, support= ing split link model, or eliminating some favorite brand of signaling messag= e (FMA) and riding on PBU/PBA and just with one FMI trigger, and on the aspe= cts around MN applying the flow policies by flow mirroring. We have no agree= ment on those issues yet.

Its just a base draft, for further discussion and resolving those issues. B= ut, hope that is not a stopper for base draft selection.


Sri






On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <htt= p://sfaccinstd@gmail.com>  <http://sfaccinstd@gmail.com> > wrote:
Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicate= to the network where the flows should be routed or for the LMA to receive s= omehow from somewhere some policies, the solution cannot really provide flow= mobility since there is no way to decide which flows are routed where. If w= e are thinking about a host-based solution, I have not yet seen a solution a= s to how the host can indicate to the MAG and ultimately to the MAG which fl= ows should be routed on each access. If we are relying on modifications of l= ayer 2 protocols, aren't we defining a solution that works only with some te= chnologies (since for other access technologies it is rather unrealistic to = modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-based= solution, can we hear of at least one example of a real-life scenario where= the LMA would receive such policies, and how such delivery would happen? Al= so, should there be a solution to have policies in the LMA, how does the LMA= actually decide to route flows on one access or the other? E.g., if some fl= ows need to be routed on certain WLAN networks, but shall not be routed on o= ther WLAN networks, how does the LMA know which specific WLAN network the ho= st is connected to? Perhaps I missed the ability for the MAG to know e.g. th= e WLAN SSID and provide it to the LMA, in which case I would appreciate if s= omebody could highlight to me where that is defined.

I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important. <= BR>
Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM,  <Basavaraj.Patil@nokia.com <http://Basavaraj.Patil@nokia.com>  <http://Basavaraj.Patil@nokia.com> > wrote:
Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= BR> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt<= /a>

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= BR> developed further based on input and feedback from WG members.

-Basavaraj

_______________________________________________
netext mailing list
netext@ietf.org <http://netext@ietf.org>  <http://netext@ietf.org>
https://www.ietf.org= /mailman/listinfo/netext
  
 
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor-= client or other applicable privileges), or constitute non-public information= . Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use, = dissemination, distribution, or reproduction of this transmission by uninten= ded recipients is not authorized and may be unlawful.

--B_3379661231_91326133-- From JuanCarlos.Zuniga@InterDigital.com Fri Feb 4 11:52:23 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB7993A69A9 for ; Fri, 4 Feb 2011 11:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enu7kvJaLdqs for ; Fri, 4 Feb 2011 11:51:58 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 5B6113A676A for ; Fri, 4 Feb 2011 11:51:54 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Feb 2011 14:55:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBC4A5.73402304" Date: Fri, 4 Feb 2011 14:55:18 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLwmpURzmRlysrlUidlexdQorGZJPuBh2AgAAR4ICAAAzJgIAACkaAgADJ5gCAAKKGAP//oT5wgAAf2NyAAIzc8IAA5pGygAC5E2CAACn5noAAD0rg References: From: "Zuniga, Juan Carlos" To: "Sri Gundavelli" , , X-OriginalArrivalTime: 04 Feb 2011 19:55:19.0400 (UTC) FILETIME=[73583680:01CBC4A5] Cc: netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 19:52:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC4A5.73402304 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Sri, =20 Some explanation below: =20 From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 Sent: February 4, 2011 1:47 PM To: Zuniga, Juan Carlos; pierrick.seite@orange-ftgroup.com; = cjbc@it.uc3m.es Cc: netext@ietf.org Subject: Re: [netext] Consensus call to adopt = I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc =20 Hi Juan Carlos, Please see inline ... On 2/4/11 8:34 AM, "Zuniga, Juan Carlos" = wrote: Sri, Pierrick, Carlos, all, =20 Please see inline: =20 =20 From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of Sri Gundavelli Sent: February 4, 2011 12:15 AM To: pierrick.seite@orange-ftgroup.com; sfaccin@rim.com; = gerardog@qualcomm.com; sfaccinstd@gmail.com Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt = I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Hi Pierrick: I agree with lot of points. * Yes, its all about handover execution. This is the key point. A PBU = message from the MN can be the first step towards activating the = handover process. Or a FMI trigger from the LMA, may itself be the = pre-trigger for PBU message from the MAG. At the end of the day, the LMA = applies the policy and provides the set of prefixes to the MAG. MAG will = continue to behave as in 5213. The decision logic, or the granularity of = the policy rule applicability on the LMA can be out of scope=20 [JCZ] I would add the case in which the prefixes are pre-assigned and = the flow movement is started from the MN by simply sending packets to = the new interface "for instance" based on MN policies. This case would = require no MN/MAG/LMA signaling and would satisfy the 3GPP/ANDSF = concerns that have been raised without defining any policy management, = network selection, etc in this draft.=20 We just need to state in the draft that, if the LMA starts receiving = packets over a different interface, it would understand this as an = implicit IP Flow mobility change. In this case, the LMA should start = using the same interface on which the uplink packets were received for = subsequent downlink packets. [Sri] If I followed this correctly, I'm just not sure about the triggers = on the UE end, as when it will use a prefix, received over on RA on one = interface, and decide to move it to a different interface. Even if the = out of band policy assumption is there, the triggers are critical, IMO. = If this is about flow mirroring with no out of band policy interface, = not sure, on the functional requirements on the UE for such case. DPI ?=20 [JCZ] The case when different prefixes are used on different interfaces = is a different one, and it is still valid. I'm assuming here what is = mentioned in section 3.2 of the document, when the LMA "assigns a common = prefix (or set of prefixes) to the different physical interfaces = attached to the domain, then all the MAGs have already all the routing = knowledge required to forward packets to the mobile node, and the LMA = does not need to perform any kind of signaling in order to move flows = across the different physical interfaces."=20 All I'm saying is that in this configuration the MN could take the lead = and move the flow, based "for example" on an ANDSF policy rule stating = that a certain flow or application should use certain access (e.g. when = the access becomes available, or goes away) . Since the prefix has = already been assigned, this can be done with no extra signaling. No need = to dig too deep in the definition of how the trigger happens, as that is = out of scope. The only thing we need to specify is the requirement on = the LMA to mirror packets on the DL.=20 =20 * Policy synchronization is an issue, for the case where the UE's = forwarding decision is based on the policy and not based on the ND = messages from the attached interface. It is very well may be that, we = have the same issue for IFOM as well, IMO, but that's beside the point = for now. The policy activation on the UE, and the associated issues = should be discussed in this context and as needed.=20 * This draft should not deal with flow policies, how they are applied = and what granularity can be out of scope, IMO. These policies need not = be carried in PMIP signaling place, unless we have MN-AR interface=20 * I'm not clear on the policy management though, before we say, it can = be separate thread. The whole approach seems to be out of band at this = point and not sure what can be specified on the PMIP signaling plane = with respect to policy.=20 [JCZ] For these last three points, I agree with Pierrick that this draft = should concentrate on the PMIP flow movement and not on the policy = management. To me clarifying all the above points and cleaning up the wording and = scenarios order would make the draft good enough for group's adoption. [Sri] Agree. The draft appears to touch lot of aspects. In reality, if = we get rid of flow templates from signaling, only deal with the approach = of carrying prefixes as in base spec, with the assumptions on out of = band flow policy interfaces, will simplify lot of things, will leave = specific issues to deal with. =20 Regards Sri On 2/3/11 7:35 AM, "pierrick.seite@orange-ftgroup.com" = wrote: Hello, =20 This is an interesting discussion, thanks for bringing the ANDSF issues = on the table. Effectively, mobility control, i.e. access selection, is a = key point for an operator. From an operator point of view, criteria for = selection is not only RAT type or SSID; we can imagine plenty of other = criteria. Different mobility control models can be envisaged such as = Network controlled or terminal controlled and so on... For sure, in PMIP = context, policies synchronization can be an issue and how decision made = on the terminal can interact with network managed mobility should be = discussed. But, I don't think draft-bernardos should go in this space. I = think, we should clearly distinguish mobility functions. IMHO, = draft-bernardos should not be expected to deal with selection = management, or mobility triggers, but only on the handover execution. In = other words, the draft should assume that handover decision has been = made (how decision is made is out of scope) and, then, only focus on = mechanism allowing the LMA to transfer flow(s). Although related, = mobility decision management, e.g. policy based, should be discussed in = a separated thread. =20 BR, Pierrick =20 ________________________________ De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part = de Stefano Faccin Envoy=E9 : jeudi 3 f=E9vrier 2011 08:05 =C0 : gerardog@qualcomm.com; sgundave@cisco.com; sfaccinstd@gmail.com Cc : netext@ietf.org; Basavaraj.Patil@nokia.com Objet : Re: [netext] Consensus call to adopt = I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Hello Sri, >From a point of view of applicability of the solution, I must agree with = Gerardo that assuming synchronization of policies is an issue of this = solution since it comes with a set of restrictions on how the solution = can be applied. Cheers, Stefano Stefano=20 Stefano M. Faccin=20 Standards Manager=20 Research In Motion=20 122 West John Carpenter Parkway=20 Irving, TX 75039=20 Internal: 820 63451=20 Desk: +1 972 910 3451=20 BlackBerry: +1 510 230 8422=20 sfaccin@rim.com=20 Time zone: PST (GMT -8) From: Giaretta, Gerardo [mailto:gerardog@qualcomm.com]=20 Sent: Wednesday, February 02, 2011 11:13 PM To: Sri Gundavelli ; stefano faccin = =20 Cc: netext@ietf.org ; Basavaraj.Patil@nokia.com = =20 Subject: Re: [netext] Consensus call to adopt I-D: = draft-bernardos-netext-pmipv6-flowmob as WG doc=20 Hi Sri, =20 There is no implicit assumption of synchronized policies. A basic = example that shows that there is no assumption is the following: ANDSF = policies may be based also on location of the UE. For example the UE = should prefer WLAN only in a given location. When the UE is attached = over WLAN there is no way for the PDNGW/HA to verify the location of the = UE and therefore to verify UE actions based on policies. =20 The assumption on synchronization of policies is only applicable to this = draft and I think it is a wrong one.=20 =20 Cheers Gerardo =20 From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of Sri Gundavelli Sent: Wednesday, February 02, 2011 6:50 PM To: stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: = draft-bernardos-netext-pmipv6-flowmob as WG doc Hi Stefano, One comment. Agree with you there is no ANDSF interface to the network node, but the = assumption of synchronized policies between the ANDSF server and the PDN = GW/HA is there, implicitly IMO. With out this assumption, I do not know, = how the HA can ever validate the flow mobility options received in the = BU. If the operator requires any control on enforcing a flow policy = rule, the PDN GW/HA needs to have synchronized policies, without which = its always the client decision. I'm not sure, operators in 3GPP would = like that :)=20 No doubt, the lack of MN-AR interface is surely an issue for supporting = complex flow policies. I realize the issues and I agree with you. But, = the assumption of synchronized policies can offer some solution with = some configuration requirement on the HA (assuming there are no other = issues). There are also the proposals on flow mirroring on the UE ..., = requiring no flow policies. I've not evaluated this, however. Folks can = comment on this. It is also to be noted, for some of the scenarios such, there is no flow = policy interface needed. We can identify what scenarios create any = configuration limitations on the HA and which one's do not . As I've = noted earlier, this is surely an open issue, that we need to discuss in = the WG.=20 Regards Sri =20 On 2/2/11 9:08 AM, "stefano faccin" wrote: Sri, thanks for the reply. Can you clarify in which system or scenario ANDSF = is available to network entities as well? There is no such availability = in 3GPP, and making such information available would require = considerable architectural changes, therefore the applicability of this = solution to what seems to be the only realistic scenario hinges on 3GPP = making considerable architectural changes. I would therefore not be so = hastily concluding that the ANDSF information is available to the LMA = and underestimate what it would really take to make the solution = applicable. If we cannot guarantee that there is at least one realistic solution to = have the MNa nd LMA in synch, how do we expect that this solution is = applicable at all? In 3GPP there is no need to have such implicit = assumption, be cause 1) the MN is provided policies explicitly through = the ANDSF, and 2) it is the MN and only the MN that makes IP flow = mobility decisions and communicates them explicitly (with well defined = signalling) to the LMA, and therefore no magic is needed. There is no = need in 3GPP to have the ANDSF and PDN GW policies synchronized, since = the PDN GW does not use such policies.=20 Sri, in the end it is a matter of whether we develop a solution that = will rely on some unknown magic to be deployed, or a solution that we = know can be deployed in at least one way because there are solutions to = what I consider major open issues. Cheers, Stefano On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli = wrote: Hi Stefano, Thanks for the discussion. As you say, the ANDSF policies are allowing the MN a.) to make the right = network attachment decision and b.) make the access selection on a flow = basis. This same policy that is present in the ANDSF server, is = available for the network nodes as well. I'm not sure, with out this = assumption the solution can work for all currently listed cases. We = clearly need the MN and the LMA to be in synch with respect to the = configured policy. How, that is done, I guess we will not try to know. = I thought even in 3GPP, this is the implied assumption ? But, this is = for you to clarify. Not specifically for IFOM where UE and PDN GW/HA are = negotiating the flow policies, but generally that the PDN GW and the = ANDSF policy server will have synchronized policies. The MAG and the LMA = have the ability to carry this flow policy information in signaling = messages and influence the access selection. The policy is a opaque = object, with extensible formats, when carried in the signaling plane, = should allow the LMA/MAG to apply those access policies, while assuming = MN is following the same rules. These policies can surely reflect the = specific WLAN access/operator specific rule. I'm surely with you, the = lack of MN-AR interface is surely an issue and I see that. But, we need = to understand, what are the limitations with the approach of out of = band policy interfaces and what will be the solution limitations. If we = need to tie the flow movement at the prefix granularity and rely on the = natural ND interface in the form of RA PIO option, more like PDN offload = in MAPCON, or at the granularity of a flow level, is open for = discussion. I want to simplify this draft for sure, we can surely = discuss each of these issues on the WG draft. Regards Sri On 2/1/11 8:29 PM, "stefano faccin" > wrote: Sri, thanks for the reply. I'd like to comment on the "the flow policy decisions need not be based = on the specific WLAN network". Does it mean, as I believe it does, that = the current solution would not allow an operator deploying such solution = to decide to route flows over a specific WLAN or not depending on which = specific WLAN the MN is connected to? E.g. the operator or the entity in = control of the decisions for the routing may want to direct certain = traffic always over WLANs that the operator deploys, and instead route = only some of the traffic over WLANs of roaming partners or of the MN = user home. How does this solution support that scenario if the LMA is = not told specifically which WLAN the MN is connected to? From a = deployment point of view, I do not believe we can afford to leave out = this scenario. Please note that the establishment of a security = relationship between the MN and the MAG, and a specific MAG identity, = cannot guarantee that the LMA knows which specific WLAN access network = the MN is connected to. Assuming that would severely restrict the = deployment scenarios. As for the MN and the LMA being magically in synch, I am very concerned = about a "glass ball" solution. You mention ANDSF defined by 3GPP as a = solution for this "out of band" delivery of policy. Fair enough, however = there is an issue with that. ANDSF is designed specific to be a = MN-centric solution where policies are provisioned in the MN and the MN = decides which network technologies and access networks it needs to = connect to, under what conditions, and which IP traffic needs to be = routed on such accesses. No IP point of attachment in the network (i.e. = the PDN GW in 3GPP that is the LMA in PMIPv6) is aware under any = conditions of such policy. Therefore, even if in order to apply this = solution to 3GPP we wanted to use ANDSF, ANDSF would unfortunately not = provide a solution unless the MN can communicate to the MAG and the LMA = the decisions the MN has taken based on the ANDSF policies. I believe the key point here is that we need to understand how the = solution can be realistically applied to a real scenario, and that we = need to ensure that important and realistic deployment scenarios are not = excluded by the solution. Cheers, Stefano On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli > wrote: Hi Stefano: These are valid points and some good comments. Let me share my thoughts. Carlo's draft is not assuming any new MN-AR interface. Its going with = the assumption there is established policy on the mobile and on the LMA, = which allows the mobile to select the access network at a flow level = granularity, without requiring any explicit signaling between the MAG = and the MN. To large part this is all about out of band policy = interface, such as ANDSF, towards the UE, leading to the assumption that = magically the MN and the LMA are in sync with respect to flow policies, = access selection and they will make the right forwarding decision. = Secondly, the flow policy decisions need not be based on the specific = WLAN network, but it is implicitly driven by the MAG - LMA security = relation, where the MAG attachment to the WLAN network transitively = allows the LMA to make the flow policy decisions based on the MAG = identity. If the WLAN network is not trusted, there is truly no MAG in = that network, where the LMA shares a security relation with that node. There are still some open issues on this draft that needs to be = discussed in the WG. On the approaches to allow more a flow aggregate = movement, that is a discussion point. There are issues that we need to = discuss, supporting split link model, or eliminating some favorite brand = of signaling message (FMA) and riding on PBU/PBA and just with one FMI = trigger, and on the aspects around MN applying the flow policies by flow = mirroring. We have no agreement on those issues yet. Its just a base draft, for further discussion and resolving those = issues. But, hope that is not a stopper for base draft selection. Sri On 2/1/11 6:39 PM, "stefano faccin" > wrote: Raj, thanks for the email. I need to apologize in advance if my questions have already been = answered before (though I cannot find a conclusive answer anywhere). I think that a protocol that is developed in NETEXT (or other groups) = should have at least a potential realistic scenario for applicability. In terms of applicability, though it is not part of the protocol = definition per se, unless there are solutions in place for either the = host to indicate to the network where the flows should be routed or for = the LMA to receive somehow from somewhere some policies, the solution = cannot really provide flow mobility since there is no way to decide = which flows are routed where. If we are thinking about a host-based = solution, I have not yet seen a solution as to how the host can indicate = to the MAG and ultimately to the MAG which flows should be routed on = each access. If we are relying on modifications of layer 2 protocols, = aren't we defining a solution that works only with some technologies = (since for other access technologies it is rather unrealistic to modify = L2 for IP flow mobility purposes)? If we are thinking of an LMA-based = solution, can we hear of at least one example of a real-life scenario = where the LMA would receive such policies, and how such delivery would = happen? Also, should there be a solution to have policies in the LMA, = how does the LMA actually decide to route flows on one access or the = other? E.g., if some flows need to be routed on certain WLAN networks, = but shall not be routed on other WLAN networks, how does the LMA know = which specific WLAN network the host is connected to? Perhaps I missed = the ability for the MAG to know e.g. the WLAN SSID and provide it to the = LMA, in which case I would appreciate if somebody could highlight to me = where that is defined. I think that, though not integral to the protocol specification, = understanding what framework the protocol would/needs to fit in is = rather important.=20 Cheers, Stefano On Tue, Feb 1, 2011 at 3:47 PM, > = wrote: Hello, We have discussed the flow mobility solutions for Proxy MIP6 previously = at IETFs 78 and 79. This is a consensus call for adopting this I-D: draft-bernardos-netext-pmipv6-flowmob-02 as the working group document. I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt The consensus call will expire on Feb 15th, 2011. Please indicate your support or concerns in adopting this I-D as the WG baseline document on the mailing list. Please note that this I-D will serve as the baseline in the WG and will = be developed further based on input and feedback from WG members. -Basavaraj _______________________________________________ netext mailing list netext@ietf.org =20 https://www.ietf.org/mailman/listinfo/netext =20 =20 ---------------------------------------------------------------------=20 This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this = transmission in error, please immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be unlawful.=20 ------_=_NextPart_001_01CBC4A5.73402304 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc

Hi Sri,

 

Some explanation below:

 

From:= Sri = Gundavelli [mailto:sgundave@cisco.com]
Sent: February 4, 2011 1:47 PM
To: Zuniga, Juan Carlos; pierrick.seite@orange-ftgroup.com; cjbc@it.uc3m.es
Cc: netext@ietf.org
Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG = doc

 

Hi Juan Carlos,

Please see inline ...


On 2/4/11 8:34 AM, "Zuniga, Juan Carlos" <JuanCarlos.Zuniga@InterDigita= l.com> wrote:

Sri, Pierrick, Carlos, all,
 
Please see inline:
 
 

From:= netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Sri Gundavelli
Sent: February 4, 2011 12:15 AM
To: pierrick.seite@orange-ftgroup.= com; sfaccin@rim.com; gerardog@qualcomm.com; sfaccinstd@gmail.com
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc

Hi = Pierrick:

I agree with lot of points.

  • Yes, its all about handover execution. This is the key point. A PBU = message from the MN can be the first step towards activating the handover = process. Or a FMI trigger from the LMA, may itself be the pre-trigger for = PBU message from the MAG. At the end of the day, the LMA applies the = policy and provides the set of prefixes to the MAG. MAG will continue to = behave as in 5213. The decision logic, or the granularity of the policy rule applicability on the LMA can be out of scope =

[JCZ] I would add the = case in which the prefixes are pre-assigned and the flow movement is started = from the MN by simply sending packets to the new interface “for = instance” based on MN policies. This case would require no MN/MAG/LMA signaling = and would satisfy the 3GPP/ANDSF concerns that have been raised without defining = any policy management, network selection, etc in this draft.
We just need to state in the draft that, if the LMA starts receiving = packets over a different interface, it would understand this as an implicit IP = Flow mobility change. In this case, the LMA should start using the same = interface on which the uplink packets were received for subsequent downlink = packets.

[Sri] If I followed this correctly, I’m just not sure about the triggers = on the UE end, as when it will use a prefix, received over on RA on one = interface, and decide to move it to a different interface. Even if the out of band = policy assumption is there, the triggers are critical, IMO. If this is about = flow mirroring with no out of band policy interface, not sure, on the = functional requirements on the UE for such case. DPI ?

[JCZ] The case when = different prefixes are used on different interfaces is a different one, and it is = still valid. I’m assuming here what is mentioned in section 3.2 of the = document, when the LMA “assigns a common prefix (or set of prefixes) to the different physical interfaces attached to the domain, then all the MAGs = have already all the routing knowledge required to forward packets to the = mobile node, and the LMA does not need to perform any kind of signaling in order to = move flows across the different physical interfaces.” =

All I’m saying = is that in this configuration the MN could take the lead and move the flow, = based “for example” on an ANDSF policy rule stating that a certain flow or = application should use certain access (e.g. when the access becomes available, or = goes away) . Since the prefix has already been assigned, this can be done with no = extra signaling. No need to dig too deep in the definition of how the trigger happens, as = that is out of scope. The only thing we need to specify is the requirement on = the LMA to mirror packets on the DL.

 

  • Policy synchronization is an issue, for the case where the UE’s = forwarding decision is based on the policy and not based on the ND messages = from the attached interface. It is very well may be that, we have the same = issue for IFOM as well, IMO, but that’s beside the point for now.  The policy activation on the UE, and the associated issues = should be discussed in this context and as needed.
  • This draft should not deal with flow policies, how they are applied and = what granularity can be out of scope, IMO. These policies need not be = carried in PMIP signaling place, unless we have MN-AR interface =
  • I’m not clear on the policy management though, before we say, it can be separate thread. The whole approach seems to be out of band at this = point and not sure what can be specified on the PMIP signaling plane with respect to policy.

[JCZ] For these last three points, I agree with Pierrick = that this draft should concentrate on the PMIP flow movement and not on the = policy management.
To me clarifying all the above points and cleaning up the wording and = scenarios order would make the draft good enough for group’s adoption.

[Sri] Agree. The draft appears to touch lot of aspects. In reality, if = we get rid of flow templates from signaling, only deal with the approach of = carrying prefixes as in base spec, with the assumptions on out of band flow = policy interfaces, will simplify lot of things, will leave specific issues to = deal with.

 

Regards
Sri







On 2/3/11 7:35 AM, "pierrick.seite@orange-ftgroup.= com" <pierrick.seite@orange-ftgroup.= com> wrote:
Hello,
 
This is an interesting discussion, thanks for bringing the ANDSF issues = on the table. Effectively, mobility control, i.e. access selection, is a key = point for an operator. From an operator point of view, criteria for selection is = not only RAT type or SSID; we can imagine plenty of other criteria. Different = mobility control models can be envisaged such as Network controlled or terminal controlled and so on... For sure, in PMIP context, policies = synchronization can be an issue and how decision made on the terminal can interact with = network managed mobility should be discussed. But, I don't think draft-bernardos = should go in this space. I think, we should clearly distinguish mobility = functions. IMHO, draft-bernardos should not be expected to deal with selection = management, or mobility triggers, but only on the handover execution. In other = words, the draft should assume that handover decision has been made (how decision = is made is out of scope) and, then, only focus on mechanism allowing the LMA to transfer flow(s). Although related, mobility decision management, e.g. = policy based, should be discussed in a separated thread.
 
BR,
Pierrick

 


De = : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part de Stefano Faccin
Envoy=E9 : jeudi 3 f=E9vrier 2011 08:05
=C0 : gerardog@qualcomm.com; sgundave@cisco.com; sfaccinstd@gmail.com
Cc : netext@ietf.org; Basavaraj.Patil@nokia.com
Objet : Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc

Hello Sri,
>From a point of view of applicability of the solution, I must agree with Gerardo that assuming synchronization of policies is an issue of this = solution since it comes with a set of restrictions on how the solution can be = applied.
Cheers,
Stefano

Stefano
Stefano M. Faccin

Standards Manager
Research In Motion
122 West John Carpenter Parkway
Irving, TX 75039
Internal: 820 63451
Desk: +1 972 910 3451
BlackBerry: +1 510 230 8422
sfaccin@rim.com
Time zone: PST (GMT -8)


From<= /b>: Giaretta, = Gerardo [mailto:gerardog@qualcomm.com] =
Sent: Wednesday, February 02, 2011 11:13 PM
To: Sri Gundavelli <sgundave@cisco.com>; stefano faccin <sfaccinstd@gmail.com>
Cc: netext@ietf.org <netext@ietf.org>; Basavaraj.Patil@nokia.com <Basavaraj.Patil@nokia.com> =
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

Hi Sri,
 
There is no implicit assumption of synchronized policies. A basic = example that shows that there is no assumption is the following: ANDSF policies may = be based also on location of the UE. For example the UE should prefer WLAN only = in a given location. When the UE is attached over WLAN there is no way for = the PDNGW/HA to verify the location of the UE and therefore to verify UE = actions based on policies.
 
The assumption on synchronization of policies is only applicable to this = draft and I think it is a wrong one.
 
Cheers
Gerardo
 

From:= netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Sri Gundavelli
Sent: Wednesday, February 02, 2011 6:50 PM
To: stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

Hi = Stefano,

One comment.

Agree with you there is no ANDSF interface to the network node, but the assumption of synchronized policies between the ANDSF server and the PDN = GW/HA is there, implicitly IMO. With out this assumption, I do not know, how = the HA can ever validate the flow mobility options received in the BU. If the = operator requires any control on enforcing a flow policy rule, the PDN GW/HA = needs to have synchronized policies, without which its always the client = decision. I’m not sure, operators in 3GPP would like that :)

No doubt, the lack of MN-AR interface is surely an issue for supporting = complex flow policies. I realize the issues and I agree with you. But, the = assumption of synchronized policies can offer some solution with some configuration requirement on the HA (assuming there are no other issues). There are = also the proposals on flow mirroring on the UE ..., requiring no flow policies. I’ve not evaluated this, however. Folks can comment on this.

It is also to be noted, for some of the scenarios such, there is no flow = policy interface needed. We can identify what scenarios create any = configuration limitations on the HA and which one’s do not . As I’ve noted earlier, this is surely an open issue, that we need to discuss in the = WG.



Regards
Sri




 


On 2/2/11 9:08 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:
Sri,
thanks for the reply. Can you clarify in which system or scenario ANDSF = is available to network entities as well? There is no such availability in = 3GPP, and making such information available would require considerable = architectural changes, therefore the applicability of this solution to what seems to = be the only realistic scenario hinges on 3GPP making considerable architectural changes. I would therefore not be so hastily concluding that the ANDSF information is available to the LMA and underestimate what it would = really take to make the solution applicable.

If we cannot guarantee that there is at least one realistic solution to = have the MNa nd LMA in synch, how do we expect that this solution is = applicable at all? In 3GPP there is no need to have such implicit assumption, be cause = 1) the MN is provided policies explicitly through the ANDSF, and 2) it is the = MN and only the MN that makes IP flow mobility decisions and communicates them explicitly (with well defined signalling) to the LMA, and therefore no = magic is needed. There is no need in 3GPP to have the ANDSF and PDN GW policies synchronized, since the PDN GW does not use such policies.

Sri, in the end it is a matter of whether we develop a solution that = will rely on some unknown magic to be deployed, or a solution that we know can be = deployed in at least one way because there are solutions to what I consider major = open issues.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli <sgundave@cisco.com> wrote:
Hi Stefano,

Thanks for the discussion.

As you say, the ANDSF policies are allowing the MN a.) to make the right network attachment decision and b.) make the access selection on a flow = basis. This same policy that is present in the ANDSF server, is available for = the network nodes as well. I’m not sure, with out this assumption the solution can work for all currently listed cases. We clearly need the MN = and the LMA to be in synch with respect to the configured policy. How, that = is done, I guess we will not try to know.  I thought even in 3GPP, = this is the implied assumption ? But, this is for you to clarify. Not = specifically for IFOM where UE and PDN GW/HA are negotiating the flow policies, but = generally that the PDN GW and the ANDSF policy server will have synchronized = policies. The MAG and the LMA have the ability to carry this flow policy = information in signaling messages and influence the access selection. The policy is a = opaque object, with extensible formats, when carried in the signaling plane, = should allow the LMA/MAG to apply those access policies, while assuming MN is following the same rules. These policies can surely reflect the specific = WLAN access/operator specific rule. I’m surely with you, the lack of = MN-AR interface is surely an issue and I see that. But, we need to understand, = what are the limitations with the approach of  out of band policy = interfaces and what will be the solution limitations. If we need to tie the flow = movement at the prefix granularity and rely on the natural ND interface in the = form of RA PIO option, more like PDN offload in MAPCON, or at the granularity of = a flow level, is open for discussion. I want to simplify this draft for sure, = we can surely discuss each of these issues on the WG draft.


Regards
Sri






On 2/1/11 8:29 PM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com> > wrote:
Sri,
thanks for the reply.

I'd like to comment on the "the flow policy decisions need not = be based on the specific WLAN network". Does it mean, as I believe it does, = that the current solution would not allow an operator deploying such solution = to decide to route flows over a specific WLAN or not depending on which = specific WLAN the MN is connected to? E.g. the operator or the entity in control = of the decisions for the routing may want to direct certain traffic always over = WLANs that the operator deploys, and instead route only some of the traffic = over WLANs of roaming partners or of the MN user home. How does this solution = support that scenario if the LMA is not told specifically which WLAN the MN is connected to? From a deployment point of view, I do not believe we can = afford to leave out this scenario. Please note that the establishment of a = security relationship between the MN and the MAG, and a specific MAG identity, = cannot guarantee that the LMA knows which specific WLAN access network the MN = is connected to. Assuming that would severely restrict the deployment = scenarios.

As for the MN and the LMA being magically in synch, I am very concerned = about a "glass ball" solution. You mention ANDSF defined by 3GPP as a solution for this "out of band" delivery of policy. Fair = enough, however there is an issue with that. ANDSF is designed specific to be a MN-centric solution where policies are provisioned in the MN and the MN = decides which network technologies and access networks it needs to connect to, = under what conditions, and which IP traffic needs to be routed on such = accesses. No IP point of attachment in the network (i.e. the PDN GW in 3GPP that is = the LMA in PMIPv6) is aware under any conditions of such policy. Therefore, even = if in order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would unfortunately not provide a solution unless the MN can communicate to = the MAG and the LMA the decisions the MN has taken based on the ANDSF policies.

I believe the key point here is that we need to understand how the = solution can be realistically applied to a real scenario, and that we need to ensure = that important and realistic deployment scenarios are not excluded by the = solution.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli <sgundave@cisco.com <http://sgundave@cisco.com> = > wrote:
Hi Stefano:

These are valid points and some good comments. Let me share my = thoughts.

Carlo’s draft is not assuming any new MN-AR interface. Its going = with the assumption there is established policy on the mobile and on the LMA, = which allows the mobile to select the access network at a flow level = granularity, without requiring any explicit signaling between the MAG and the MN. To = large part this is all about out of band policy interface, such as ANDSF, = towards the UE, leading to the assumption that magically the MN and the LMA are in = sync with respect to flow policies, access selection and they will make the = right forwarding decision. Secondly, the flow policy decisions need not be = based on the specific WLAN network, but it is implicitly driven by the MAG = – LMA security relation, where the MAG attachment to the WLAN network = transitively allows the LMA to make the flow policy decisions based on the MAG = identity. If the WLAN network is not trusted, there is truly no MAG in that network, = where the LMA shares a security relation with that node.

There are still some open issues on this draft that needs to be = discussed in the WG.  On the approaches to allow more a flow aggregate movement, = that is a discussion point. There are issues that we need to discuss, = supporting split link model, or eliminating some favorite brand of signaling = message (FMA) and riding on PBU/PBA and just with one FMI trigger, and on the aspects = around MN applying the flow policies by flow mirroring. We have no agreement on = those issues yet.

Its just a base draft, for further discussion and resolving those = issues. But, hope that is not a stopper for base draft selection.


Sri






On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com>  <http://sfaccinstd@gmail.com> > wrote:
Raj,
thanks for the email.

I need to apologize in advance if my questions have already been = answered before (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) = should have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol = definition per se, unless there are solutions in place for either the host to indicate = to the network where the flows should be routed or for the LMA to receive = somehow from somewhere some policies, the solution cannot really provide flow = mobility since there is no way to decide which flows are routed where. If we are = thinking about a host-based solution, I have not yet seen a solution as to how = the host can indicate to the MAG and ultimately to the MAG which flows should be = routed on each access. If we are relying on modifications of layer 2 protocols, = aren't we defining a solution that works only with some technologies (since for = other access technologies it is rather unrealistic to modify L2 for IP flow = mobility purposes)? If we are thinking of an LMA-based solution, can we hear of = at least one example of a real-life scenario where the LMA would receive such = policies, and how such delivery would happen? Also, should there be a solution to = have policies in the LMA, how does the LMA actually decide to route flows on = one access or the other? E.g., if some flows need to be routed on certain = WLAN networks, but shall not be routed on other WLAN networks, how does the = LMA know which specific WLAN network the host is connected to? Perhaps I missed = the ability for the MAG to know e.g. the WLAN SSID and provide it to the = LMA, in which case I would appreciate if somebody could highlight to me where = that is defined.

I think that, though not integral to the protocol specification, = understanding what framework the protocol would/needs to fit in is rather important. =

Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM,  <Basavaraj.Patil@nokia.com <http://Basavaraj.Patil@nokia.co= m>  <http://Basavaraj.Patil@nokia.co= m> > wrote:

Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously = at
IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt

The consensus call will expire on Feb 15th, 2011. Please indicate = your
support or concerns in adopting this I-D as the WG baseline document = on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will = be
developed further based on input and feedback from WG members.

-Basavaraj

_______________________________________________
netext mailing list
netext@ietf.org <http://netext@ietf.org> =  <http://netext@ietf.org>
https://www.ietf.or= g/mailman/listinfo/netext

 
 
--------------------------------------------------------------------- =
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than the = intended recipient is prohibited. If you have received this transmission in = error, please immediately reply to the sender and delete this information from = your system. Use, dissemination, distribution, or reproduction of this = transmission by unintended recipients is not authorized and may be unlawful. =

------_=_NextPart_001_01CBC4A5.73402304-- From julien.ietf@gmail.com Fri Feb 4 12:53:24 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 840383A6AA1 for ; Fri, 4 Feb 2011 12:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.572 X-Spam-Level: X-Spam-Status: No, score=-3.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lppMfIlHyV+y for ; Fri, 4 Feb 2011 12:53:23 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 529103A6A73 for ; Fri, 4 Feb 2011 12:53:23 -0800 (PST) Received: by fxm9 with SMTP id 9so3016667fxm.31 for ; Fri, 04 Feb 2011 12:56:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vy0a8EnGAGYOAtJ3JOzyp1Z8vbghvsZPARIiTtZnNvo=; b=EnBDLxuCBpIHjS+hFaeuBetJGtPu0SB0EgUa6ZuHlUX0XgzS6hIPSMAqkPOXkzaLMO 8wKNy1Nj/khvY+3OImdLMForwybhERVzAviRLod5PeFndkZol7l4CS7eTksC7NttWMzz JQk2HiwcX7U7sB/mlSNj9S5U1efF7IeFDCXCg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=byeFvajbscjokRX0KGPabG1isoGfmNgFniEWrLbZ619LBSUYrZrotLj7YcxEcmfjzg /YVTPVoprcmTgxMkUQcrWDzGQ52uWNJRiCUgUm1j5BGTiakdhlPZwbAdz76mMO014jMO scPqmJjJOF/tEktNVMitV4s4eue8vd4968Oc4= MIME-Version: 1.0 Received: by 10.103.192.12 with SMTP id u12mr5214305mup.75.1296853008347; Fri, 04 Feb 2011 12:56:48 -0800 (PST) Received: by 10.103.221.9 with HTTP; Fri, 4 Feb 2011 12:56:48 -0800 (PST) In-Reply-To: References: Date: Fri, 4 Feb 2011 12:56:48 -0800 Message-ID: From: Julien Laganier To: Sri Gundavelli Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org, "Zuniga, Juan Carlos" Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 20:53:24 -0000 Hi Sri, I just want to react to one of your comment which I'm quoting below: On Fri, Feb 4, 2011 at 10:47 AM, Sri Gundavelli wrote: > > [...] > [Sri] If I followed this correctly, I=92m just not sure about the trigger= s on > the UE end, as when it will use a prefix, received over on RA on one > interface, and decide to move it to a different interface. Even if the ou= t > of band policy assumption is there, the triggers are critical, IMO. If th= is > is about flow mirroring with no out of band policy interface, not sure, o= n > the functional requirements on the UE for such case. DPI ? This WG needs not to be concerned with triggers on the UE end, however critical they might be. When this effort started we all agreed the IP layer is unmodified, and whatever magic is required, it happens below IP, and thus is out of scope for this WG. --julien From julien.ietf@gmail.com Fri Feb 4 12:56:03 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 622F53A67C1 for ; Fri, 4 Feb 2011 12:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJVxO8Yb4VCj for ; Fri, 4 Feb 2011 12:56:02 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 588D43A69A9 for ; Fri, 4 Feb 2011 12:56:02 -0800 (PST) Received: by fxm9 with SMTP id 9so3019054fxm.31 for ; Fri, 04 Feb 2011 12:59:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Iu0AWAkxeZQ4N0NMhKlEyUtHjgnTh+lG+YOPoN5azmk=; b=xTIdNMXjIP8izePvFgPfZL/qTTreZHxhs+KaV+61b7qGXnJN/M6FUI8MiFeiUZD/zU ZWwI5VV6jtHoR3gsc6MFbD9wQKEbtqqJGhSrljwRTVQGur/i+/vNuTs7npCYVBGNag93 Cr7t9w1zRWat5tkklZVt9ihqkisgZ0M8GC/Dc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=D3hs45ZrSS1lY+loFzmWElrPghOYq9x1rUWVTnyE585YwFGdebO5nLNtXqXpKL0uO1 QOWPY3hd1XwLru/LAiegrXURnnU4QyoPrNhr9f0XX6XpdpatiDO6CAOWns0ul0w7wpZI Vd9btKkNCEtKn3RkRQHROf5J4kPR9ufNBrzcA= MIME-Version: 1.0 Received: by 10.103.12.14 with SMTP id p14mr4005037mui.39.1296853167557; Fri, 04 Feb 2011 12:59:27 -0800 (PST) Received: by 10.103.221.9 with HTTP; Fri, 4 Feb 2011 12:59:27 -0800 (PST) In-Reply-To: References: Date: Fri, 4 Feb 2011 12:59:27 -0800 Message-ID: From: Julien Laganier To: Rajeev Koodli Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 20:56:03 -0000 On Fri, Feb 4, 2011 at 10:40 AM, Rajeev Koodli wrote: > > > On 2/4/11 10:16 AM, "Julien Laganier" wrote: > >>> >>> The LMA needs to provide the prefix info to the MAG. This can be either in >>> PBA or in FMI (if not provided in PBA). >> >> The LMA can provide the prefix to the MAG at session creation, i.e., >> in the PBU. This information does not need to be (re)conveyed at flow >> movement. >> > > If it was conveyed in PBA, surely you don't reconvey. > If the prefix was not conveyed in PBA (as in the example we discussed > y'day), you provide it in FMI. IMO the prefix can always be conveyed in the PBA that is received in response to the PBU attaching an interface to a PMIPv6 flow mobility session. --julien From Basavaraj.Patil@nokia.com Fri Feb 4 13:26:37 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 814EF3A69D4 for ; Fri, 4 Feb 2011 13:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.807 X-Spam-Level: X-Spam-Status: No, score=-103.807 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdqnFgh9ob+T for ; Fri, 4 Feb 2011 13:26:35 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id B3F0E3A67C1 for ; Fri, 4 Feb 2011 13:26:35 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p14LTsMA013835; Fri, 4 Feb 2011 23:29:58 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Feb 2011 23:29:51 +0200 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 4 Feb 2011 22:29:50 +0100 Received: from 008-AM1MPN1-005.mgdnok.nokia.com ([169.254.4.149]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi; Fri, 4 Feb 2011 22:29:50 +0100 From: To: , Thread-Topic: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLxJv6njeeP1atYk+7WhcurxqeTJPxwhgA//+kooA= Date: Fri, 4 Feb 2011 21:29:47 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7d49c34e-6daa-4571-8e4f-dac22021734b> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Feb 2011 21:29:51.0442 (UTC) FILETIME=[A8252320:01CBC4B2] X-Nokia-AV: Clean Cc: netext@ietf.org, JuanCarlos.Zuniga@interdigital.com Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 21:26:37 -0000 On 2/4/11 2:56 PM, "ext Julien Laganier" wrote: >Hi Sri, > >I just want to react to one of your comment which I'm quoting below: > >On Fri, Feb 4, 2011 at 10:47 AM, Sri Gundavelli >wrote: >> >> [...] >> [Sri] If I followed this correctly, I=B9m just not sure about the >>triggers on >> the UE end, as when it will use a prefix, received over on RA on one >> interface, and decide to move it to a different interface. Even if the >>out >> of band policy assumption is there, the triggers are critical, IMO. If >>this >> is about flow mirroring with no out of band policy interface, not sure, >>on >> the functional requirements on the UE for such case. DPI ? > >This WG needs not to be concerned with triggers on the UE end, however >critical they might be. > >When this effort started we all agreed the IP layer is unmodified, and >whatever magic is required, it happens below IP, and thus is out of >scope for this WG. Correct.=20 There is no expectation of changes on the UE at the IP layer. Or for that matter any MN-AR(MAG) signaling at the IP layer. The only assumption regarding flow mobility is the existence of the logical interface on the MN. -Raj > >--julien >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext From trungtm2909@gmail.com Fri Feb 4 14:22:54 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57A1C3A69D4 for ; Fri, 4 Feb 2011 14:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dnPLlUxWitC for ; Fri, 4 Feb 2011 14:22:53 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 6C5943A69C1 for ; Fri, 4 Feb 2011 14:22:53 -0800 (PST) Received: by iym1 with SMTP id 1so2293753iym.31 for ; Fri, 04 Feb 2011 14:26:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nfEoAQoqCvwkkjPY4ZOQqwgtXk1fdvkyMvvd0tgeC5k=; b=x001K181nghvm6NZMt6RARjsYRj6azHJn5YSnz/2qQ6bU9cA8+0gdOcZMZovsD3ToB o2ybWtkYiROPDRcQpnHaWN0vxRbApNJODBWTcbAqCG8Xkbk7u3jDr+NxE6vbfJs7TEJ3 RH9XE31z8fU4L7Lp44EGS2iNq3yygvtRNxTfw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XoxkPAkAlkMp8KX0o3REYDZkFG8qqr2hrTVu1wCiVdbvxfSp2jPqIqkf75p+7ZiFy5 D0HoRN6DL/jFCr7VcJqdrL12aCUYpCig6RNjS+FmZBs5WqDvX07EIOjrPo5p8iIvfwWo MUsAKHZ5kwsgL8tz89PUi40JMF/FzK0oaSoMA= MIME-Version: 1.0 Received: by 10.42.167.7 with SMTP id q7mr4322303icy.454.1296858379214; Fri, 04 Feb 2011 14:26:19 -0800 (PST) Received: by 10.42.162.195 with HTTP; Fri, 4 Feb 2011 14:26:19 -0800 (PST) In-Reply-To: References: Date: Sat, 5 Feb 2011 07:26:19 +0900 Message-ID: From: Tran Minh Trung To: Julien Laganier Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 22:22:54 -0000 On Sat, Feb 5, 2011 at 5:59 AM, Julien Laganier wro= te: > On Fri, Feb 4, 2011 at 10:40 AM, Rajeev Koodli wrote: >> >> >> On 2/4/11 10:16 AM, "Julien Laganier" wrote: >> >>>> >>>> The LMA needs to provide the prefix info to the MAG. This can be eithe= r in >>>> PBA or in FMI (if not provided in PBA). >>> >>> The LMA can provide the prefix to the MAG at session creation, i.e., >>> in the PBU. This information does not need to be (re)conveyed at flow >>> movement. >>> >> >> If it was conveyed in PBA, surely you don't reconvey. >> If the prefix was not conveyed in PBA (as in the example we discussed >> y'day), you provide it in FMI. > > IMO the prefix can always be conveyed in the PBA that is received in > response to the PBU attaching an interface to a PMIPv6 flow mobility > session. > If so, how does MAG know when the interface is attached to a new mobility session to send PBU to the LMA?. It may need a new trigger message sent from LMA to MAG or the LMA can send prefix in FMI message whenever it attaches an interface to a new mobility session as described in the draft. Regards, TrungTM > --julien > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 From cjbc@it.uc3m.es Sat Feb 5 07:37:24 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E5C73A6956 for ; Sat, 5 Feb 2011 07:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iusJKUIurLzM for ; Sat, 5 Feb 2011 07:37:23 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id BD0BE3A6951 for ; Sat, 5 Feb 2011 07:37:21 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.0.11] (82.158.169.178.dyn.user.ono.com [82.158.169.178]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 19A5D710260; Sat, 5 Feb 2011 16:40:44 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Tran Minh Trung In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-fbW3GOgcP3KpCZ7TWokA" Organization: Universidad Carlos III de Madrid Date: Sat, 05 Feb 2011 16:41:48 +0100 Message-ID: <1296920508.3773.24.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17938.000 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 05 Feb 2011 15:37:24 -0000 --=-fbW3GOgcP3KpCZ7TWokA Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Dear Trung, Current draft already does this. No need to change it, just to rewrite some parts so it is more clear and to remove some optional features that are not required. Thanks, Carlos On Fri, 2011-02-04 at 12:04 +0900, Tran Minh Trung wrote: > Hi Julien and Raij, Sri, Carlos and all, >=20 > Sorry for jumping in the middle. > It is holiday time in some Asia country now ^^. >=20 > Back to the discussion on use-case scenarios. > I agree with Julien that we do not need to discuss about different > use-cases scenarios. >=20 > What we need to do is extending PMIPv6 to support flow mobility, not > extending PMIPv6 to support different use-cases scenarios. >=20 > Let's start from the basic scenario (new prefix(es) for a new > attachment) of the PMIPv6 and then extend it to support flow mobility. >=20 > The question now is that is the right model for supporting flow mobility? >=20 > IMHO, the flowing model is the right one, which reflects both Julien > comments and what we have in the current draft. >=20 > (1) A sigle mobile node has multiple sessions > (2) Each session is associated with a distinct set of prefixes. > (3) Interfaces are attached to/de-attached from the session. > (4) Each interface can be attached to multiple session at a time. >=20 > There is one question left from the discussion between Julien and > Rajeev is that: > Should LMA need to tell the MAG about new prefix(es) of the session > that the interface attach to?. >=20 > My answer is YES!. > The MAG needs to know which prefixes are newly assigned to a MN > attachment to send RA. > Without this step, how can the MN know the right attachment to send a pac= ket? >=20 >=20 > Happy Lunar New Year! > Regards, > TrungTM > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-fbW3GOgcP3KpCZ7TWokA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1Nb7wACgkQNdy6TdFwT2cMKwCfdqNvYhd2pG00+blphV0QAFJm xmkAnjHs84V4l+k/FDrRxblPyBSfM7g/ =u71R -----END PGP SIGNATURE----- --=-fbW3GOgcP3KpCZ7TWokA-- From cjbc@it.uc3m.es Sat Feb 5 07:37:26 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E8283A6970 for ; Sat, 5 Feb 2011 07:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZgY6IDBL3pH for ; Sat, 5 Feb 2011 07:37:25 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 289D83A6951 for ; Sat, 5 Feb 2011 07:37:25 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.0.11] (82.158.169.178.dyn.user.ono.com [82.158.169.178]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id E18BCBF33C0; Sat, 5 Feb 2011 16:40:51 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Julien Laganier In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-eXzkX2UBxwHZL7DDASeS" Organization: Universidad Carlos III de Madrid Date: Sat, 05 Feb 2011 16:41:51 +0100 Message-ID: <1296920511.3773.25.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17938.000 Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 05 Feb 2011 15:37:26 -0000 --=-eXzkX2UBxwHZL7DDASeS Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable On Fri, 2011-02-04 at 10:16 -0800, Julien Laganier wrote: > On Thu, Feb 3, 2011 at 8:22 PM, Rajeev Koodli wrote: > > > > > > > > On 2/3/11 7:10 PM, "Tran Minh Trung" wrote: > > > >> There is one question left from the discussion between Julien and > >> Rajeev is that: > >> Should LMA need to tell the MAG about new prefix(es) of the session > >> that the interface attach to?. > >> > >> My answer is YES!. > >> The MAG needs to know which prefixes are newly assigned to a MN > >> attachment to send RA. > >> Without this step, how can the MN know the right attachment to send a = packet? > >> > > > > The LMA needs to provide the prefix info to the MAG. This can be either= in > > PBA or in FMI (if not provided in PBA). >=20 > The LMA can provide the prefix to the MAG at session creation, i.e., > in the PBU. This information does not need to be (re)conveyed at flow > movement. If different prefixes are assigned for different sessions, and we want to move flows across interfaces, we need some kind of signaling to make the MAG aware of the prefixes. It cannot be done at session creation, since not all the interfaces necessarily attach simultaneously, Carlos >=20 > --julien > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-eXzkX2UBxwHZL7DDASeS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1Nb78ACgkQNdy6TdFwT2e32wCfe03FmrpFVkZZE5Do1lMjc1uE 9YMAoMiqJBLXsuzHNQQX6QVgvtYaNITy =6I4Z -----END PGP SIGNATURE----- --=-eXzkX2UBxwHZL7DDASeS-- From cjbc@it.uc3m.es Sat Feb 5 07:37:33 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3EB43A6956 for ; Sat, 5 Feb 2011 07:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymXwSTNgcJde for ; Sat, 5 Feb 2011 07:37:32 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 7D8AC3A6801 for ; Sat, 5 Feb 2011 07:37:32 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.0.11] (82.158.169.178.dyn.user.ono.com [82.158.169.178]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 1ED288722C7; Sat, 5 Feb 2011 16:40:58 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Julien Laganier In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-tyfYWVn+Aqh9zaRNBvW7" Organization: Universidad Carlos III de Madrid Date: Sat, 05 Feb 2011 16:41:54 +0100 Message-ID: <1296920514.3773.26.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17938.000 Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 05 Feb 2011 15:37:33 -0000 --=-tyfYWVn+Aqh9zaRNBvW7 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable On Fri, 2011-02-04 at 12:59 -0800, Julien Laganier wrote: > On Fri, Feb 4, 2011 at 10:40 AM, Rajeev Koodli wrote: > > > > > > On 2/4/11 10:16 AM, "Julien Laganier" wrote: > > > >>> > >>> The LMA needs to provide the prefix info to the MAG. This can be eith= er in > >>> PBA or in FMI (if not provided in PBA). > >> > >> The LMA can provide the prefix to the MAG at session creation, i.e., > >> in the PBU. This information does not need to be (re)conveyed at flow > >> movement. > >> > > > > If it was conveyed in PBA, surely you don't reconvey. > > If the prefix was not conveyed in PBA (as in the example we discussed > > y'day), you provide it in FMI. >=20 > IMO the prefix can always be conveyed in the PBA that is received in > response to the PBU attaching an interface to a PMIPv6 flow mobility > session. What about the following scenario: MN has two interfaces: if1 and if2. if1 attaches to MAG1, a mobility session is created, pref1 is delegated. Some point in time later, if2 attaches to MAG2, new mobility sesison created, pref2 is delegated. flowX addressed to pref2 wants to be moved to if1. In this case we need some signaling from LMA to MAG1 that cannot be conveted in PBA. Carlos >=20 > --julien > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-tyfYWVn+Aqh9zaRNBvW7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1Nb8IACgkQNdy6TdFwT2cOVwCgm909xb0s9x7X4sALXc+P55fy nT8AnRYU5BEevVveAOXCfBI+mxjwvBf6 =ZVAt -----END PGP SIGNATURE----- --=-tyfYWVn+Aqh9zaRNBvW7-- From julien.ietf@gmail.com Sun Feb 6 10:11:54 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BBCF3A6985 for ; Sun, 6 Feb 2011 10:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0Foqq99VU6p for ; Sun, 6 Feb 2011 10:11:53 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 42A193A68CB for ; Sun, 6 Feb 2011 10:11:53 -0800 (PST) Received: by fxm9 with SMTP id 9so4418508fxm.31 for ; Sun, 06 Feb 2011 10:11:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mgoDRzVzP86TlOD/U5wpT7jEX46Pv9x/BgHZxUzStVY=; b=aQvc0knRcDcKbaI5pQgs0SSYIr+IgpDE1Hq/lBQSZewfQdroPd7RfjRss/TFQjrH4C j/Xplw7hcs54bl4xr3FxpKKQnmNzy+PO7fRO9HXtFIPqv3nPVt6uwmg8vd4Ky+F8VtOy SucUj7u87YNIcMqo/Vc6k7I9HfSVy78ZpH22M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Mz1B//zA1QN28uqHenL82IhPe5DvthmPxVFloqURIdl32oGp/NO0hTTChVNGW0rs8d 293Ji5MX0KkuTBI/L+8WBwxfmbqrQndnCuijQXbOm4cvbg+06jtD7PEHWFzioUOCpkLm 7yg9PrDUMMjMS4BM8Q2a8JTeOdEm5YKP4Q72U= MIME-Version: 1.0 Received: by 10.103.233.4 with SMTP id k4mr9813072mur.129.1297015914454; Sun, 06 Feb 2011 10:11:54 -0800 (PST) Received: by 10.103.221.9 with HTTP; Sun, 6 Feb 2011 10:11:54 -0800 (PST) In-Reply-To: <1296920514.3773.26.camel@acorde.it.uc3m.es> References: <1296920514.3773.26.camel@acorde.it.uc3m.es> Date: Sun, 6 Feb 2011 10:11:54 -0800 Message-ID: From: Julien Laganier To: cjbc@it.uc3m.es Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 18:11:54 -0000 2011/2/5 Carlos Jes=FAs Bernardos Cano : > On Fri, 2011-02-04 at 12:59 -0800, Julien Laganier wrote: >> On Fri, Feb 4, 2011 at 10:40 AM, Rajeev Koodli wrote= : >> > >> > >> > On 2/4/11 10:16 AM, "Julien Laganier" wrote: >> > >> >>> >> >>> The LMA needs to provide the prefix info to the MAG. This can be eit= her in >> >>> PBA or in FMI (if not provided in PBA). >> >> >> >> The LMA can provide the prefix to the MAG at session creation, i.e., >> >> in the PBU. This information does not need to be (re)conveyed at flow >> >> movement. >> > >> > If it was conveyed in PBA, surely you don't reconvey. >> > If the prefix was not conveyed in PBA (as in the example we discussed >> > y'day), you provide it in FMI. >> >> IMO the prefix can always be conveyed in the PBA that is received in >> response to the PBU attaching an interface to a PMIPv6 flow mobility >> session. > > What about the following scenario: > > MN has two interfaces: if1 and if2. if1 attaches to MAG1, a mobility > session is created, pref1 is delegated. Some point in time later, if2 > attaches to MAG2, new mobility sesison created, pref2 is delegated. > flowX addressed to pref2 wants to be moved to if1. In this case we need > some signaling from LMA to MAG1 that cannot be conveted in PBA. If flow X addresssed to pref2 wants to be moved to if1, first thing to do is to attach the if1 to the session corresponding to pref2, so MAG1 sends a PBU, and LMA sends back a PBA with the prefix set of the session (pref2.) Then at flow movement no prefix to be sent, no? --julien From cjbc@it.uc3m.es Sun Feb 6 10:37:25 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EE523A69A7 for ; Sun, 6 Feb 2011 10:37:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.056 X-Spam-Level: X-Spam-Status: No, score=-4.056 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bs1IodNigSIp for ; Sun, 6 Feb 2011 10:37:23 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 034103A6949 for ; Sun, 6 Feb 2011 10:37:22 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.3] (213.37.82.169.static.user.ono.com [213.37.82.169]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 607FC87234E; Sun, 6 Feb 2011 19:37:23 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Julien Laganier In-Reply-To: References: <1296920514.3773.26.camel@acorde.it.uc3m.es> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-CTPmFFsJaMfFHA8O95YD" Organization: Universidad Carlos III de Madrid Date: Sun, 06 Feb 2011 19:38:21 +0100 Message-ID: <1297017501.4715.2.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17940.000 Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 06 Feb 2011 18:37:25 -0000 --=-CTPmFFsJaMfFHA8O95YD Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Julien, On Sun, 2011-02-06 at 10:11 -0800, Julien Laganier wrote: > 2011/2/5 Carlos Jes=FAs Bernardos Cano : > > On Fri, 2011-02-04 at 12:59 -0800, Julien Laganier wrote: > >> On Fri, Feb 4, 2011 at 10:40 AM, Rajeev Koodli wro= te: > >> > > >> > > >> > On 2/4/11 10:16 AM, "Julien Laganier" wrote: > >> > > >> >>> > >> >>> The LMA needs to provide the prefix info to the MAG. This can be e= ither in > >> >>> PBA or in FMI (if not provided in PBA). > >> >> > >> >> The LMA can provide the prefix to the MAG at session creation, i.e.= , > >> >> in the PBU. This information does not need to be (re)conveyed at fl= ow > >> >> movement. > >> > > >> > If it was conveyed in PBA, surely you don't reconvey. > >> > If the prefix was not conveyed in PBA (as in the example we discusse= d > >> > y'day), you provide it in FMI. > >> > >> IMO the prefix can always be conveyed in the PBA that is received in > >> response to the PBU attaching an interface to a PMIPv6 flow mobility > >> session. > > > > What about the following scenario: > > > > MN has two interfaces: if1 and if2. if1 attaches to MAG1, a mobility > > session is created, pref1 is delegated. Some point in time later, if2 > > attaches to MAG2, new mobility sesison created, pref2 is delegated. > > flowX addressed to pref2 wants to be moved to if1. In this case we need > > some signaling from LMA to MAG1 that cannot be conveted in PBA. >=20 > If flow X addresssed to pref2 wants to be moved to if1, first thing to > do is to attach the if1 to the session corresponding to pref2, so MAG1 > sends a PBU, and LMA sends back a PBA with the prefix set of the > session (pref2.) if1 was previously attached to MAG1 (and LMA delegated pref1). How can MAG1 know when LMA wants to move flow X to if1 (to send a PBU)? Some signaling is needed there. Kind Regards, Carlos >=20 > Then at flow movement no prefix to be sent, no? >=20 > --julien --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-CTPmFFsJaMfFHA8O95YD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1O6pgACgkQNdy6TdFwT2cU3QCdEy5O9RkOuQtXZEtiIjcxKnmJ vBYAoOW5bbCYHDsNXvY4Q6dY/jnf+Qje =FSeb -----END PGP SIGNATURE----- --=-CTPmFFsJaMfFHA8O95YD-- From julien.ietf@gmail.com Sun Feb 6 10:56:31 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B2CD3A69A7 for ; Sun, 6 Feb 2011 10:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYmTS0-r-Rap for ; Sun, 6 Feb 2011 10:56:29 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 90C6A3A6970 for ; Sun, 6 Feb 2011 10:56:29 -0800 (PST) Received: by fxm9 with SMTP id 9so4443756fxm.31 for ; Sun, 06 Feb 2011 10:56:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=M529q5SvnzntmGjCHXosNIosgJ5oo0xdrhyOjK3c+j4=; b=XRqojg+ojBj+Vi0LMeWYQ/n/HJvCj81/FeWpMs3i8oVV6XyB9mAS5r/XjyjLcjW3wl XUlNBeDdjQ7bZpU0RCN2SW1LF6RzHprjyojIEo3pRRoezUJwca+ChcTRek9GJ+JoouLM SojQn/KeLX5zDD9AEGa2MOwZnbYoQNBOms7xI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xoCcz360npGZHLyVLP6K6xbjkRrifcTRiWXMiU8SSamadPnqOPx3Bjh1yQ09xNMhmO rQ/dmqV5M1wbw4ww+Q0ZdieEfpBdrHaT2LHkt00Iz4b8X+uSdf08DC1vqcYcgYJaCq4d QaXXEmWl+95A6pJ57ruCRjX+lGq9wK1Acz50M= MIME-Version: 1.0 Received: by 10.103.12.14 with SMTP id p14mr5969089mui.39.1297018590709; Sun, 06 Feb 2011 10:56:30 -0800 (PST) Received: by 10.103.221.9 with HTTP; Sun, 6 Feb 2011 10:56:30 -0800 (PST) In-Reply-To: <1297017501.4715.2.camel@acorde.it.uc3m.es> References: <1296920514.3773.26.camel@acorde.it.uc3m.es> <1297017501.4715.2.camel@acorde.it.uc3m.es> Date: Sun, 6 Feb 2011 10:56:30 -0800 Message-ID: From: Julien Laganier To: cjbc@it.uc3m.es Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 18:56:31 -0000 Hi Carlos, 2011/2/6 Carlos Jes=FAs Bernardos Cano : > Hi Julien, > > On Sun, 2011-02-06 at 10:11 -0800, Julien Laganier wrote: >> 2011/2/5 Carlos Jes=FAs Bernardos Cano : >> > On Fri, 2011-02-04 at 12:59 -0800, Julien Laganier wrote: >> >> On Fri, Feb 4, 2011 at 10:40 AM, Rajeev Koodli wr= ote: >> >> > >> >> > >> >> > On 2/4/11 10:16 AM, "Julien Laganier" wrote= : >> >> > >> >> >>> >> >> >>> The LMA needs to provide the prefix info to the MAG. This can be = either in >> >> >>> PBA or in FMI (if not provided in PBA). >> >> >> >> >> >> The LMA can provide the prefix to the MAG at session creation, i.e= ., >> >> >> in the PBU. This information does not need to be (re)conveyed at f= low >> >> >> movement. >> >> > >> >> > If it was conveyed in PBA, surely you don't reconvey. >> >> > If the prefix was not conveyed in PBA (as in the example we discuss= ed >> >> > y'day), you provide it in FMI. >> >> >> >> IMO the prefix can always be conveyed in the PBA that is received in >> >> response to the PBU attaching an interface to a PMIPv6 flow mobility >> >> session. >> > >> > What about the following scenario: >> > >> > MN has two interfaces: if1 and if2. if1 attaches to MAG1, a mobility >> > session is created, pref1 is delegated. Some point in time later, if2 >> > attaches to MAG2, new mobility sesison created, pref2 is delegated. >> > flowX addressed to pref2 wants to be moved to if1. In this case we nee= d >> > some signaling from LMA to MAG1 that cannot be conveted in PBA. >> >> If flow X addresssed to pref2 wants to be moved to if1, first thing to >> do is to attach the if1 to the session corresponding to pref2, so MAG1 >> sends a PBU, and LMA sends back a PBA with the prefix set of the >> session (pref2.) > > if1 was previously attached to MAG1 (and LMA delegated pref1). How can > MAG1 know when LMA wants to move flow X to if1 (to send a PBU)? Some > signaling is needed there. if1 was attached to MAG1 and had session S1 with prefix pref1. When if2 is attached to MAG2, if a different prefix pref2 is allocated, that is a different session S2. LMA cannot move a flow from session S2 to a MAG that isn't part of that session. So first thing to do after S2 is created, if there's a desire to move flows across other MAGs, is to attach other interfaces to the session, i.e., MAG1 sends a PBU to attach if1 to S2, too (althout if1 is also attached to session S1.) --julien From cjbc@it.uc3m.es Sun Feb 6 11:14:00 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AD943A69A7 for ; Sun, 6 Feb 2011 11:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.056 X-Spam-Level: X-Spam-Status: No, score=-4.056 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQZWZTxxCQFI for ; Sun, 6 Feb 2011 11:13:59 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 6EC653A6949 for ; Sun, 6 Feb 2011 11:13:58 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.3] (213.37.82.169.static.user.ono.com [213.37.82.169]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 8BA34BF82D4; Sun, 6 Feb 2011 20:13:55 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Julien Laganier In-Reply-To: References: <1296920514.3773.26.camel@acorde.it.uc3m.es> <1297017501.4715.2.camel@acorde.it.uc3m.es> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-0vbPqgOc/ul5FwPRkV+4" Organization: Universidad Carlos III de Madrid Date: Sun, 06 Feb 2011 20:14:56 +0100 Message-ID: <1297019696.4715.5.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17940.000 Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 06 Feb 2011 19:14:00 -0000 --=-0vbPqgOc/ul5FwPRkV+4 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Julien, On Sun, 2011-02-06 at 10:56 -0800, Julien Laganier wrote: > Hi Carlos, >=20 > 2011/2/6 Carlos Jes=FAs Bernardos Cano : > > Hi Julien, > > > > On Sun, 2011-02-06 at 10:11 -0800, Julien Laganier wrote: > >> 2011/2/5 Carlos Jes=FAs Bernardos Cano : > >> > On Fri, 2011-02-04 at 12:59 -0800, Julien Laganier wrote: > >> >> On Fri, Feb 4, 2011 at 10:40 AM, Rajeev Koodli = wrote: > >> >> > > >> >> > > >> >> > On 2/4/11 10:16 AM, "Julien Laganier" wro= te: > >> >> > > >> >> >>> > >> >> >>> The LMA needs to provide the prefix info to the MAG. This can b= e either in > >> >> >>> PBA or in FMI (if not provided in PBA). > >> >> >> > >> >> >> The LMA can provide the prefix to the MAG at session creation, i= .e., > >> >> >> in the PBU. This information does not need to be (re)conveyed at= flow > >> >> >> movement. > >> >> > > >> >> > If it was conveyed in PBA, surely you don't reconvey. > >> >> > If the prefix was not conveyed in PBA (as in the example we discu= ssed > >> >> > y'day), you provide it in FMI. > >> >> > >> >> IMO the prefix can always be conveyed in the PBA that is received i= n > >> >> response to the PBU attaching an interface to a PMIPv6 flow mobilit= y > >> >> session. > >> > > >> > What about the following scenario: > >> > > >> > MN has two interfaces: if1 and if2. if1 attaches to MAG1, a mobility > >> > session is created, pref1 is delegated. Some point in time later, if= 2 > >> > attaches to MAG2, new mobility sesison created, pref2 is delegated. > >> > flowX addressed to pref2 wants to be moved to if1. In this case we n= eed > >> > some signaling from LMA to MAG1 that cannot be conveted in PBA. > >> > >> If flow X addresssed to pref2 wants to be moved to if1, first thing to > >> do is to attach the if1 to the session corresponding to pref2, so MAG1 > >> sends a PBU, and LMA sends back a PBA with the prefix set of the > >> session (pref2.) > > > > if1 was previously attached to MAG1 (and LMA delegated pref1). How can > > MAG1 know when LMA wants to move flow X to if1 (to send a PBU)? Some > > signaling is needed there. >=20 > if1 was attached to MAG1 and had session S1 with prefix pref1. When > if2 is attached to MAG2, if a different prefix pref2 is allocated, > that is a different session S2. LMA cannot move a flow from session S2 > to a MAG that isn't part of that session. So first thing to do after > S2 is created, if there's a desire to move flows across other MAGs, is Right, our draft uses FMI signalling to add if1 to the session (we use the flowmob cache structure of this purpose). We are discussing about two ways of doing exactly the same thing. However, in yours, you need the MAG to take the initiative, while ours also supports the LMA initiate the flow movement. Carlos > to attach other interfaces to the session, i.e., MAG1 sends a PBU to > attach if1 to S2, too (althout if1 is also attached to session S1.) >=20 > --julien --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-0vbPqgOc/ul5FwPRkV+4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1O8zAACgkQNdy6TdFwT2duOwCgv01BtKxV6sw+DA0LX4jUKRCy fjMAoI6WxKp4fRUw6Q8GpqQdcqUmdXq5 =o9fl -----END PGP SIGNATURE----- --=-0vbPqgOc/ul5FwPRkV+4-- From julien.ietf@gmail.com Mon Feb 7 12:43:55 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3A0B3A6E94 for ; Mon, 7 Feb 2011 12:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPVR98gLfcf9 for ; Mon, 7 Feb 2011 12:43:54 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id C0CB83A69C0 for ; Mon, 7 Feb 2011 12:43:53 -0800 (PST) Received: by eyd10 with SMTP id 10so2859988eyd.31 for ; Mon, 07 Feb 2011 12:43:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1aggJJTCmrTDfCLPOrJrXXCf+O2aIzwSwrpvAL+mGxw=; b=Drr/KmhRoRvODlbdjs3Xjnq2RaBTqP2BlLPWRKl/UZmYaWDg1koNf1Y6cpX70fnBRR Qs6yA6edgFzJzKH9hgaeAol4StfscKRIzoOb+tnOlCgzgddKRi2ud2QASWj9lTMxS+CN YoSqqrhUtSArjJ18/NnrWfds5xAoWHvw69UQ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rooy/qSwtU4NZ3vH7oIBUc/CbaDHuW4d6NSulSmV4PQJPVlSS7EsiFAMFXc08zA4Jg VUMALxjfRcBajneur7L0aeRJxVbiKkDuRc61NLzVq1k3yQL6gbSzjxTQR76EoDDd2XRt N0/UK1DOTwPv4XyhRcw+p+dn6eReg1qoJUTzw= MIME-Version: 1.0 Received: by 10.103.199.18 with SMTP id b18mr11389382muq.21.1297111437679; Mon, 07 Feb 2011 12:43:57 -0800 (PST) Received: by 10.103.221.9 with HTTP; Mon, 7 Feb 2011 12:43:57 -0800 (PST) In-Reply-To: <1297019696.4715.5.camel@acorde.it.uc3m.es> References: <1296920514.3773.26.camel@acorde.it.uc3m.es> <1297017501.4715.2.camel@acorde.it.uc3m.es> <1297019696.4715.5.camel@acorde.it.uc3m.es> Date: Mon, 7 Feb 2011 12:43:57 -0800 Message-ID: From: Julien Laganier To: cjbc@it.uc3m.es Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 20:43:55 -0000 Hi Carlos, 2011/2/6 Carlos Jes=FAs Bernardos Cano : > Hi Julien, > > On Sun, 2011-02-06 at 10:56 -0800, Julien Laganier wrote: >> Hi Carlos, >> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : >> > Hi Julien, >> > >> > On Sun, 2011-02-06 at 10:11 -0800, Julien Laganier wrote: >> >> 2011/2/5 Carlos Jes=FAs Bernardos Cano : >> >> > On Fri, 2011-02-04 at 12:59 -0800, Julien Laganier wrote: >> >> >> On Fri, Feb 4, 2011 at 10:40 AM, Rajeev Koodli = wrote: >> >> >> > >> >> >> > >> >> >> > On 2/4/11 10:16 AM, "Julien Laganier" wr= ote: >> >> >> > >> >> >> >>> >> >> >> >>> The LMA needs to provide the prefix info to the MAG. This can = be either in >> >> >> >>> PBA or in FMI (if not provided in PBA). >> >> >> >> >> >> >> >> The LMA can provide the prefix to the MAG at session creation, = i.e., >> >> >> >> in the PBU. This information does not need to be (re)conveyed a= t flow >> >> >> >> movement. >> >> >> > >> >> >> > If it was conveyed in PBA, surely you don't reconvey. >> >> >> > If the prefix was not conveyed in PBA (as in the example we disc= ussed >> >> >> > y'day), you provide it in FMI. >> >> >> >> >> >> IMO the prefix can always be conveyed in the PBA that is received = in >> >> >> response to the PBU attaching an interface to a PMIPv6 flow mobili= ty >> >> >> session. >> >> > >> >> > What about the following scenario: >> >> > >> >> > MN has two interfaces: if1 and if2. if1 attaches to MAG1, a mobilit= y >> >> > session is created, pref1 is delegated. Some point in time later, i= f2 >> >> > attaches to MAG2, new mobility sesison created, pref2 is delegated. >> >> > flowX addressed to pref2 wants to be moved to if1. In this case we = need >> >> > some signaling from LMA to MAG1 that cannot be conveted in PBA. >> >> >> >> If flow X addresssed to pref2 wants to be moved to if1, first thing t= o >> >> do is to attach the if1 to the session corresponding to pref2, so MAG= 1 >> >> sends a PBU, and LMA sends back a PBA with the prefix set of the >> >> session (pref2.) >> > >> > if1 was previously attached to MAG1 (and LMA delegated pref1). How can >> > MAG1 know when LMA wants to move flow X to if1 (to send a PBU)? Some >> > signaling is needed there. >> >> if1 was attached to MAG1 and had session S1 with prefix pref1. When >> if2 is attached to MAG2, if a different prefix pref2 is allocated, >> that is a different session S2. LMA cannot move a flow from session S2 >> to a MAG that isn't part of that session. So first thing to do after >> S2 is created, if there's a desire to move flows across other MAGs, is > > Right, our draft uses FMI signalling to add if1 to the session (we use > the flowmob cache structure of this purpose). We are discussing about > two ways of doing exactly the same thing. However, in yours, you need > the MAG to take the initiative, while ours also supports the LMA > initiate the flow movement. You seem to be conflating session management and flow movement. In my approach, session management is MAG initiated, as it has been in the past with PMIPv6. Once a session exists across an interface set, flow movement can be LMA-initiated at any time from one interface in the set to another. I do not see a reason to depart from RFC 5213 and allow the LMA to initiate session management (except for purposes of revocation but that is supported already.) --julien From cjbc@it.uc3m.es Mon Feb 7 13:51:58 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E71973A6E3B for ; Mon, 7 Feb 2011 13:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.056 X-Spam-Level: X-Spam-Status: No, score=-4.056 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XN516Nvo-9xP for ; Mon, 7 Feb 2011 13:51:57 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 256DD3A69AE for ; Mon, 7 Feb 2011 13:51:56 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.3] (213.37.82.169.static.user.ono.com [213.37.82.169]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id EA864BF7D04; Mon, 7 Feb 2011 22:51:54 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Julien Laganier In-Reply-To: References: <1296920514.3773.26.camel@acorde.it.uc3m.es> <1297017501.4715.2.camel@acorde.it.uc3m.es> <1297019696.4715.5.camel@acorde.it.uc3m.es> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-hTFjPbStvcCo5aHoVM6H" Organization: Universidad Carlos III de Madrid Date: Mon, 07 Feb 2011 22:52:54 +0100 Message-ID: <1297115574.3099.3.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17942.000 Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 21:51:59 -0000 --=-hTFjPbStvcCo5aHoVM6H Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Julien, On Mon, 2011-02-07 at 12:43 -0800, Julien Laganier wrote: > Hi Carlos, >=20 > 2011/2/6 Carlos Jes=FAs Bernardos Cano : > > Hi Julien, > > > > On Sun, 2011-02-06 at 10:56 -0800, Julien Laganier wrote: > >> Hi Carlos, > >> > >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : > >> > Hi Julien, > >> > > >> > On Sun, 2011-02-06 at 10:11 -0800, Julien Laganier wrote: > >> >> 2011/2/5 Carlos Jes=FAs Bernardos Cano : > >> >> > On Fri, 2011-02-04 at 12:59 -0800, Julien Laganier wrote: > >> >> >> On Fri, Feb 4, 2011 at 10:40 AM, Rajeev Koodli wrote: > >> >> >> > > >> >> >> > > >> >> >> > On 2/4/11 10:16 AM, "Julien Laganier" = wrote: > >> >> >> > > >> >> >> >>> > >> >> >> >>> The LMA needs to provide the prefix info to the MAG. This ca= n be either in > >> >> >> >>> PBA or in FMI (if not provided in PBA). > >> >> >> >> > >> >> >> >> The LMA can provide the prefix to the MAG at session creation= , i.e., > >> >> >> >> in the PBU. This information does not need to be (re)conveyed= at flow > >> >> >> >> movement. > >> >> >> > > >> >> >> > If it was conveyed in PBA, surely you don't reconvey. > >> >> >> > If the prefix was not conveyed in PBA (as in the example we di= scussed > >> >> >> > y'day), you provide it in FMI. > >> >> >> > >> >> >> IMO the prefix can always be conveyed in the PBA that is receive= d in > >> >> >> response to the PBU attaching an interface to a PMIPv6 flow mobi= lity > >> >> >> session. > >> >> > > >> >> > What about the following scenario: > >> >> > > >> >> > MN has two interfaces: if1 and if2. if1 attaches to MAG1, a mobil= ity > >> >> > session is created, pref1 is delegated. Some point in time later,= if2 > >> >> > attaches to MAG2, new mobility sesison created, pref2 is delegate= d. > >> >> > flowX addressed to pref2 wants to be moved to if1. In this case w= e need > >> >> > some signaling from LMA to MAG1 that cannot be conveted in PBA. > >> >> > >> >> If flow X addresssed to pref2 wants to be moved to if1, first thing= to > >> >> do is to attach the if1 to the session corresponding to pref2, so M= AG1 > >> >> sends a PBU, and LMA sends back a PBA with the prefix set of the > >> >> session (pref2.) > >> > > >> > if1 was previously attached to MAG1 (and LMA delegated pref1). How c= an > >> > MAG1 know when LMA wants to move flow X to if1 (to send a PBU)? Some > >> > signaling is needed there. > >> > >> if1 was attached to MAG1 and had session S1 with prefix pref1. When > >> if2 is attached to MAG2, if a different prefix pref2 is allocated, > >> that is a different session S2. LMA cannot move a flow from session S2 > >> to a MAG that isn't part of that session. So first thing to do after > >> S2 is created, if there's a desire to move flows across other MAGs, is > > > > Right, our draft uses FMI signalling to add if1 to the session (we use > > the flowmob cache structure of this purpose). We are discussing about > > two ways of doing exactly the same thing. However, in yours, you need > > the MAG to take the initiative, while ours also supports the LMA > > initiate the flow movement. >=20 > You seem to be conflating session management and flow movement. >=20 > In my approach, session management is MAG initiated, as it has been in > the past with PMIPv6. Once a session exists across an interface set, > flow movement can be LMA-initiated at any time from one interface in > the set to another. >=20 > I do not see a reason to depart from RFC 5213 and allow the LMA to > initiate session management (except for purposes of revocation but > that is supported already.) I see the reason to add it in order to support the scenarios I mentioned in my example. Those cannot be supported with RFC5213 model, as they require first the MAG to send a PBU. We need either new signaling from the LMA to the MAG to make the MAG aware of the required prefixes to support flow mobility, or a trigger from the LMA to the MAG, so the MAG can send a PBU and then follow your model. Carlos >=20 > --julien --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-hTFjPbStvcCo5aHoVM6H Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1QabEACgkQNdy6TdFwT2cDnQCcDVbYauE2c8wc51ih+al7SLEj +UUAoK1IIBp3lcUhxfQZMTvxcQZbto3i =7X4i -----END PGP SIGNATURE----- --=-hTFjPbStvcCo5aHoVM6H-- From julien.ietf@gmail.com Mon Feb 7 15:56:31 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4EC13A6FD3 for ; Mon, 7 Feb 2011 15:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAdG-CSf1A-Z for ; Mon, 7 Feb 2011 15:56:30 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id D84B63A6FCF for ; Mon, 7 Feb 2011 15:56:29 -0800 (PST) Received: by fxm9 with SMTP id 9so5841881fxm.31 for ; Mon, 07 Feb 2011 15:56:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8OW116h1xmJEnHaOQqUKpdx0A0/rlHfUTdaOSyEwThA=; b=VijZLBBpD7PaGmgZbAy/VzfZaWL06Z/0QMvrzG2+3z6kwcvEdNpqBlXxRlgUhHE+ez eFOgJa827bdRgTdS3skQU3QGzm7WRSSWuXlcSOGEXWIjxKKZV+MbA2B+61RE4xkQgcUH raakI1lfh62ZD1IwukOPhSsKOcqtuzeck79NU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=PgZUbnqN7DJv/IOMbBfZh2LMaiJ9bE1/fZJYDuoF0jjcKeHbM95hvt9IcrZ7W+kdvD 48RYZSe5rEZkUNreOu2ZXhRG8P9K8zjRAt/tBf9c5saCfdOQaM2t/7kJmfW63oxXbpnj Juuz+kRY1YAmJnWbLW4o84Ouu0WVKWuEfH3Mk= MIME-Version: 1.0 Received: by 10.103.243.16 with SMTP id v16mr11622295mur.57.1297122993901; Mon, 07 Feb 2011 15:56:33 -0800 (PST) Received: by 10.103.221.9 with HTTP; Mon, 7 Feb 2011 15:56:33 -0800 (PST) In-Reply-To: <1297115574.3099.3.camel@acorde.it.uc3m.es> References: <1296920514.3773.26.camel@acorde.it.uc3m.es> <1297017501.4715.2.camel@acorde.it.uc3m.es> <1297019696.4715.5.camel@acorde.it.uc3m.es> <1297115574.3099.3.camel@acorde.it.uc3m.es> Date: Mon, 7 Feb 2011 15:56:33 -0800 Message-ID: From: Julien Laganier To: cjbc@it.uc3m.es Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 23:56:31 -0000 Hi Carlos, 2011/2/7 Carlos Jes=FAs Bernardos Cano : > Hi Julien, > > On Mon, 2011-02-07 at 12:43 -0800, Julien Laganier wrote: >> Hi Carlos, >> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : >> > Hi Julien, >> > >> > On Sun, 2011-02-06 at 10:56 -0800, Julien Laganier wrote: >> >> Hi Carlos, >> >> >> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : >> >> > Hi Julien, >> >> > >> >> > On Sun, 2011-02-06 at 10:11 -0800, Julien Laganier wrote: >> >> >> 2011/2/5 Carlos Jes=FAs Bernardos Cano : >> >> >> > On Fri, 2011-02-04 at 12:59 -0800, Julien Laganier wrote: >> >> >> >> On Fri, Feb 4, 2011 at 10:40 AM, Rajeev Koodli wrote: >> >> >> >> > >> >> >> >> > >> >> >> >> > On 2/4/11 10:16 AM, "Julien Laganier" = wrote: >> >> >> >> > >> >> >> >> >>> >> >> >> >> >>> The LMA needs to provide the prefix info to the MAG. This c= an be either in >> >> >> >> >>> PBA or in FMI (if not provided in PBA). >> >> >> >> >> >> >> >> >> >> The LMA can provide the prefix to the MAG at session creatio= n, i.e., >> >> >> >> >> in the PBU. This information does not need to be (re)conveye= d at flow >> >> >> >> >> movement. >> >> >> >> > >> >> >> >> > If it was conveyed in PBA, surely you don't reconvey. >> >> >> >> > If the prefix was not conveyed in PBA (as in the example we d= iscussed >> >> >> >> > y'day), you provide it in FMI. >> >> >> >> >> >> >> >> IMO the prefix can always be conveyed in the PBA that is receiv= ed in >> >> >> >> response to the PBU attaching an interface to a PMIPv6 flow mob= ility >> >> >> >> session. >> >> >> > >> >> >> > What about the following scenario: >> >> >> > >> >> >> > MN has two interfaces: if1 and if2. if1 attaches to MAG1, a mobi= lity >> >> >> > session is created, pref1 is delegated. Some point in time later= , if2 >> >> >> > attaches to MAG2, new mobility sesison created, pref2 is delegat= ed. >> >> >> > flowX addressed to pref2 wants to be moved to if1. In this case = we need >> >> >> > some signaling from LMA to MAG1 that cannot be conveted in PBA. >> >> >> >> >> >> If flow X addresssed to pref2 wants to be moved to if1, first thin= g to >> >> >> do is to attach the if1 to the session corresponding to pref2, so = MAG1 >> >> >> sends a PBU, and LMA sends back a PBA with the prefix set of the >> >> >> session (pref2.) >> >> > >> >> > if1 was previously attached to MAG1 (and LMA delegated pref1). How = can >> >> > MAG1 know when LMA wants to move flow X to if1 (to send a PBU)? Som= e >> >> > signaling is needed there. >> >> >> >> if1 was attached to MAG1 and had session S1 with prefix pref1. When >> >> if2 is attached to MAG2, if a different prefix pref2 is allocated, >> >> that is a different session S2. LMA cannot move a flow from session S= 2 >> >> to a MAG that isn't part of that session. So first thing to do after >> >> S2 is created, if there's a desire to move flows across other MAGs, i= s >> > >> > Right, our draft uses FMI signalling to add if1 to the session (we use >> > the flowmob cache structure of this purpose). We are discussing about >> > two ways of doing exactly the same thing. However, in yours, you need >> > the MAG to take the initiative, while ours also supports the LMA >> > initiate the flow movement. >> >> You seem to be conflating session management and flow movement. >> >> In my approach, session management is MAG initiated, as it has been in >> the past with PMIPv6. Once a session exists across an interface set, >> flow movement can be LMA-initiated at any time from one interface in >> the set to another. >> >> I do not see a reason to depart from RFC 5213 and allow the LMA to >> initiate session management (except for purposes of revocation but >> that is supported already.) > > I see the reason to add it in order to support the scenarios I mentioned > in my example. Those cannot be supported with RFC5213 model, as they > require first the MAG to send a PBU. We need either new signaling from > the LMA to the MAG to make the MAG aware of the required prefixes to > support flow mobility, or a trigger from the LMA to the MAG, so the MAG > can send a PBU and then follow your model. In the systems I know the MAG is the entity that creates attaches a MN interface to a session and therefore I do not understand why you would need the LMA to attach an interface to a session. The LMA has no interface with the interface... That's a MAG duty. In which system is the scenario you're outlining useful? --julien From sgundave@cisco.com Mon Feb 7 16:30:45 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A34883A6FE2 for ; Mon, 7 Feb 2011 16:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLBfqrsR3mTm for ; Mon, 7 Feb 2011 16:30:44 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id DADFE3A6B0A for ; Mon, 7 Feb 2011 16:30:44 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAweUE2rR7H+/2dsb2JhbAClJnOeYpsQhVoEhHqGbYM0 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 08 Feb 2011 00:30:45 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p180Uj4b027190; Tue, 8 Feb 2011 00:30:45 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Feb 2011 16:30:45 -0800 Received: from 10.32.246.213 ([10.32.246.213]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Tue, 8 Feb 2011 00:30:45 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Mon, 07 Feb 2011 16:31:18 -0800 From: Sri Gundavelli To: Julien Laganier , Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvHJ4BHd+4aYlQ74kCYCouM5YCrRg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 08 Feb 2011 00:30:45.0778 (UTC) FILETIME=[6D129F20:01CBC727] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 00:30:45 -0000 >> >> Right, our draft uses FMI signalling to add if1 to the session (we use >> the flowmob cache structure of this purpose). We are discussing about >> two ways of doing exactly the same thing. However, in yours, you need >> the MAG to take the initiative, while ours also supports the LMA >> initiate the flow movement. > > You seem to be conflating session management and flow movement. > > In my approach, session management is MAG initiated, as it has been in > the past with PMIPv6. Once a session exists across an interface set, > flow movement can be LMA-initiated at any time from one interface in > the set to another. > > I do not see a reason to depart from RFC 5213 and allow the LMA to > initiate session management (except for purposes of revocation but > that is supported already.) > Thank you. I cannot emphasize more than this. We are not looking at flow management as an extended state of BCE entry, rather as some thing new. BCE state is different and flow mobility state is different. We want to define our own brand of messages. MAG is responsible for creating the session state and the request for flow mobility is carried right in that PBU message. The trigger from LMA to MAG is needed when policy changes and that is when it can send an FMI trigger. No need for FMA, session management is always initiated by MAG. The trigger in 99.99% of the times is coming from MAG. MN brings up an interface/pulls down an interface and that triggers the LMA to apply a flow policy rules. But, the MAG sending a PBU is the trigger for flow mobility. LMA in most cases is learning the triggers from MAG, which is attached to MN, except for reasons of policy change, where there is a need to send a trigger to MAG to send a PBU and that is FMI message. Hope we can get some sense into this draft. Sri From cjbc@it.uc3m.es Mon Feb 7 16:55:16 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3CD03A6B0A for ; Mon, 7 Feb 2011 16:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.056 X-Spam-Level: X-Spam-Status: No, score=-4.056 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNdRNdKMDBPR for ; Mon, 7 Feb 2011 16:55:14 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id BA1223A6E29 for ; Mon, 7 Feb 2011 16:55:13 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.3] (213.37.82.169.static.user.ono.com [213.37.82.169]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 420D19C52B0; Tue, 8 Feb 2011 01:55:17 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Julien Laganier In-Reply-To: References: <1296920514.3773.26.camel@acorde.it.uc3m.es> <1297017501.4715.2.camel@acorde.it.uc3m.es> <1297019696.4715.5.camel@acorde.it.uc3m.es> <1297115574.3099.3.camel@acorde.it.uc3m.es> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-aTcRC5F1g8QrEZTYTdex" Organization: Universidad Carlos III de Madrid Date: Tue, 08 Feb 2011 01:56:24 +0100 Message-ID: <1297126584.3099.96.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17942.003 Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 08 Feb 2011 00:55:16 -0000 --=-aTcRC5F1g8QrEZTYTdex Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Julien, On Mon, 2011-02-07 at 15:56 -0800, Julien Laganier wrote: > Hi Carlos, >=20 > 2011/2/7 Carlos Jes=FAs Bernardos Cano : > > Hi Julien, > > > > On Mon, 2011-02-07 at 12:43 -0800, Julien Laganier wrote: > >> Hi Carlos, > >> > >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : > >> > Hi Julien, > >> > > >> > On Sun, 2011-02-06 at 10:56 -0800, Julien Laganier wrote: > >> >> Hi Carlos, > >> >> > >> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : > >> >> > Hi Julien, > >> >> > > >> >> > On Sun, 2011-02-06 at 10:11 -0800, Julien Laganier wrote: > >> >> >> 2011/2/5 Carlos Jes=FAs Bernardos Cano : > >> >> >> > On Fri, 2011-02-04 at 12:59 -0800, Julien Laganier wrote: > >> >> >> >> On Fri, Feb 4, 2011 at 10:40 AM, Rajeev Koodli wrote: > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > On 2/4/11 10:16 AM, "Julien Laganier" wrote: > >> >> >> >> > > >> >> >> >> >>> > >> >> >> >> >>> The LMA needs to provide the prefix info to the MAG. This= can be either in > >> >> >> >> >>> PBA or in FMI (if not provided in PBA). > >> >> >> >> >> > >> >> >> >> >> The LMA can provide the prefix to the MAG at session creat= ion, i.e., > >> >> >> >> >> in the PBU. This information does not need to be (re)conve= yed at flow > >> >> >> >> >> movement. > >> >> >> >> > > >> >> >> >> > If it was conveyed in PBA, surely you don't reconvey. > >> >> >> >> > If the prefix was not conveyed in PBA (as in the example we= discussed > >> >> >> >> > y'day), you provide it in FMI. > >> >> >> >> > >> >> >> >> IMO the prefix can always be conveyed in the PBA that is rece= ived in > >> >> >> >> response to the PBU attaching an interface to a PMIPv6 flow m= obility > >> >> >> >> session. > >> >> >> > > >> >> >> > What about the following scenario: > >> >> >> > > >> >> >> > MN has two interfaces: if1 and if2. if1 attaches to MAG1, a mo= bility > >> >> >> > session is created, pref1 is delegated. Some point in time lat= er, if2 > >> >> >> > attaches to MAG2, new mobility sesison created, pref2 is deleg= ated. > >> >> >> > flowX addressed to pref2 wants to be moved to if1. In this cas= e we need > >> >> >> > some signaling from LMA to MAG1 that cannot be conveted in PBA= . > >> >> >> > >> >> >> If flow X addresssed to pref2 wants to be moved to if1, first th= ing to > >> >> >> do is to attach the if1 to the session corresponding to pref2, s= o MAG1 > >> >> >> sends a PBU, and LMA sends back a PBA with the prefix set of the > >> >> >> session (pref2.) > >> >> > > >> >> > if1 was previously attached to MAG1 (and LMA delegated pref1). Ho= w can > >> >> > MAG1 know when LMA wants to move flow X to if1 (to send a PBU)? S= ome > >> >> > signaling is needed there. > >> >> > >> >> if1 was attached to MAG1 and had session S1 with prefix pref1. When > >> >> if2 is attached to MAG2, if a different prefix pref2 is allocated, > >> >> that is a different session S2. LMA cannot move a flow from session= S2 > >> >> to a MAG that isn't part of that session. So first thing to do afte= r > >> >> S2 is created, if there's a desire to move flows across other MAGs,= is > >> > > >> > Right, our draft uses FMI signalling to add if1 to the session (we u= se > >> > the flowmob cache structure of this purpose). We are discussing abou= t > >> > two ways of doing exactly the same thing. However, in yours, you nee= d > >> > the MAG to take the initiative, while ours also supports the LMA > >> > initiate the flow movement. > >> > >> You seem to be conflating session management and flow movement. > >> > >> In my approach, session management is MAG initiated, as it has been in > >> the past with PMIPv6. Once a session exists across an interface set, > >> flow movement can be LMA-initiated at any time from one interface in > >> the set to another. > >> > >> I do not see a reason to depart from RFC 5213 and allow the LMA to > >> initiate session management (except for purposes of revocation but > >> that is supported already.) > > > > I see the reason to add it in order to support the scenarios I mentione= d > > in my example. Those cannot be supported with RFC5213 model, as they > > require first the MAG to send a PBU. We need either new signaling from > > the LMA to the MAG to make the MAG aware of the required prefixes to > > support flow mobility, or a trigger from the LMA to the MAG, so the MAG > > can send a PBU and then follow your model. >=20 > In the systems I know the MAG is the entity that creates attaches a MN > interface to a session and therefore I do not understand why you would > need the LMA to attach an interface to a session. The LMA has no > interface with the interface... That's a MAG duty. >=20 > In which system is the scenario you're outlining useful? I must be really bad at explaining this... Lets consider the following scenario: - MN attaches if1 to MAG1. As a result, if1 is attached to the session with MAG1. Pref1::/64 is delegated to if1. - Later on, MN attaches if2 to MAG2. As a result if2 is attached to the session with MAG2. Pref2::/64 is delegated to if2. (nothing new so far, no flow mobility) - Some point in time later, LMA wants to move a flow X, addressed to pref2::/64 to if1. MAG1 cannot send a PBU at that particular moment (how can it know it has to?) to make MAG1 attach if1 to session with pref2. Therefore, we need some signaling, initiated by the LMA, to make that flow movement happen. How can this scenario be supported with your approach? I fail to see it. Thanks, Carlos >=20 > --julien --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-aTcRC5F1g8QrEZTYTdex Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1QlLgACgkQNdy6TdFwT2eyxQCdHLO9xrjW7gAYY/jLBE8Ja87+ AkcAoIbDmQREPPWJX+FHuTozXM5IMe4h =P7Jz -----END PGP SIGNATURE----- --=-aTcRC5F1g8QrEZTYTdex-- From cjbc@it.uc3m.es Mon Feb 7 16:56:03 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58A713A6E29 for ; Mon, 7 Feb 2011 16:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.056 X-Spam-Level: X-Spam-Status: No, score=-4.056 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LF8XMg4zPvUB for ; Mon, 7 Feb 2011 16:56:02 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 1E6163A6B0A for ; Mon, 7 Feb 2011 16:56:02 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.3] (213.37.82.169.static.user.ono.com [213.37.82.169]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 085256551EF; Tue, 8 Feb 2011 01:56:05 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Sri Gundavelli In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-NVCXapZFa0tZXefXsfYc" Organization: Universidad Carlos III de Madrid Date: Tue, 08 Feb 2011 01:57:12 +0100 Message-ID: <1297126632.3099.97.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17942.003 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 08 Feb 2011 00:56:03 -0000 --=-NVCXapZFa0tZXefXsfYc Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable On Mon, 2011-02-07 at 16:31 -0800, Sri Gundavelli wrote: >=20 > >>=20 > >> Right, our draft uses FMI signalling to add if1 to the session (we use > >> the flowmob cache structure of this purpose). We are discussing about > >> two ways of doing exactly the same thing. However, in yours, you need > >> the MAG to take the initiative, while ours also supports the LMA > >> initiate the flow movement. > >=20 > > You seem to be conflating session management and flow movement. > >=20 > > In my approach, session management is MAG initiated, as it has been in > > the past with PMIPv6. Once a session exists across an interface set, > > flow movement can be LMA-initiated at any time from one interface in > > the set to another. > >=20 > > I do not see a reason to depart from RFC 5213 and allow the LMA to > > initiate session management (except for purposes of revocation but > > that is supported already.) > >=20 >=20 > Thank you. >=20 > I cannot emphasize more than this. We are not looking at flow management = as > an extended state of BCE entry, rather as some thing new. BCE state is > different and flow mobility state is different. We want to define our own > brand of messages.=20 >=20 > MAG is responsible for creating the session state and the request for flo= w > mobility is carried right in that PBU message. The trigger from LMA to MA= G > is needed when policy changes and that is when it can send an FMI trigger= . > No need for FMA, session management is always initiated by MAG. >=20 > The trigger in 99.99% of the times is coming from MAG. MN brings up an > interface/pulls down an interface and that triggers the LMA to apply a fl= ow > policy rules. But, the MAG sending a PBU is the trigger for flow mobility= . > LMA in most cases is learning the triggers from MAG, which is attached to > MN, except for reasons of policy change, where there is a need to send a > trigger to MAG to send a PBU and that is FMI message. So we need to support both cases, agree? Carlos >=20 > Hope we can get some sense into this draft. >=20 >=20 > Sri >=20 >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-NVCXapZFa0tZXefXsfYc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1QlOgACgkQNdy6TdFwT2eOYgCgmDjyNc575Eu6KNURZV47RRoa f9YAn231+HSYQG5Agq7GNL+VxWfML7Y9 =7yJ5 -----END PGP SIGNATURE----- --=-NVCXapZFa0tZXefXsfYc-- From rkoodli@cisco.com Mon Feb 7 17:07:50 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E55BD3A6FB4 for ; Mon, 7 Feb 2011 17:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-iaZ-yvraks for ; Mon, 7 Feb 2011 17:07:50 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 01FDF3A6E29 for ; Mon, 7 Feb 2011 17:07:48 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEAmUE2tJV2b/2dsb2JhbAClJ3OefZsShVoEhHqGbYM0 Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-2.cisco.com with ESMTP; 08 Feb 2011 01:07:51 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p1817pvN016820; Tue, 8 Feb 2011 01:07:51 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Feb 2011 19:07:50 -0600 Received: from 10.21.89.15 ([10.21.89.15]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Tue, 8 Feb 2011 01:07:49 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Mon, 07 Feb 2011 17:26:31 -0800 From: Rajeev Koodli To: , Julien Laganier Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvHLzb6xXQbGdWhAkqdHw8sKV2h1Q== In-Reply-To: <1297115574.3099.3.camel@acorde.it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 08 Feb 2011 01:07:50.0600 (UTC) FILETIME=[9B2B8480:01CBC72C] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 01:07:51 -0000 On 2/7/11 1:52 PM, "Carlos Jes=FAs Bernardos Cano" wrote: >>=20 >> You seem to be conflating session management and flow movement. >>=20 >> In my approach, session management is MAG initiated, as it has been in >> the past with PMIPv6. Once a session exists across an interface set, >> flow movement can be LMA-initiated at any time from one interface in >> the set to another. >>=20 >> I do not see a reason to depart from RFC 5213 and allow the LMA to >> initiate session management (except for purposes of revocation but >> that is supported already.) >=20 > I see the reason to add it in order to support the scenarios I mentioned > in my example. Those cannot be supported with RFC5213 model, as they > require first the MAG to send a PBU. We need either new signaling from > the LMA to the MAG to make the MAG aware of the required prefixes to > support flow mobility, or a trigger from the LMA to the MAG, so the MAG > can send a PBU and then follow your model. >=20 =20 Right. The LMA adding a prefix to an existing session should be supported. It's no= t very different from a router advertising a new prefix on an interface to it= s host.=20 I might still be missing something here.. =20 MAG initiates a new session at attach. To me, this is a new session at LMA with its own prefix (p1 on if1 in my previous example). You can argue that at the time of attach, the LMA *can* assign all available prefix(es). That'= s option A). As I have mentioned earlier, I would like to be able to assign a prefix (e.g., p1) for the new session at attach, and add a different prefix (e.g., p0) at any time. This is option B). I don't want to be forced to do only A).=20 -Rajeev > Carlos >=20 >>=20 >> --julien From trungtm2909@gmail.com Mon Feb 7 17:08:10 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD06B3A6F66 for ; Mon, 7 Feb 2011 17:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2lBcAGpFx25 for ; Mon, 7 Feb 2011 17:08:09 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 250523A6E29 for ; Mon, 7 Feb 2011 17:08:09 -0800 (PST) Received: by qwi2 with SMTP id 2so4053516qwi.31 for ; Mon, 07 Feb 2011 17:08:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=m0wzMhA+P0nDni16scKaaHzlGW5DJ3q94WeVAdj8tMM=; b=kN/mVYveUD9LqpyPs4ynTr7KbrpCWVZQ9KHYEVA1F5V/DCXaCn1WoRzj8T9Tq7AUiD jUwYV2jv6qr3ak+o95dOmgJcXY8vIkrReNXtqxxfVSCxyo7tETsYKTfMxue6tX18oj3f 2IdyeP54WOJcoLbt7qHjxH7AqklzH2estWg2E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=R6Xr1NYr54qqH6AVzAXtr51VEDNF754CB30tPa9OSbdLQhquEyX9sziewta2M7UXy/ julhOBao752Zf38Q2XuNahvZvrKU8O9TyWXWGR+L+/x1/YDFwXQCJCdIjZA4RlkfdhxB /J4XWx67ZaHbvGPkMhcuR2gJsRdn3hfzChOA0= MIME-Version: 1.0 Received: by 10.224.20.2 with SMTP id d2mr14608212qab.300.1297127293055; Mon, 07 Feb 2011 17:08:13 -0800 (PST) Received: by 10.224.89.11 with HTTP; Mon, 7 Feb 2011 17:08:13 -0800 (PST) In-Reply-To: <1297126584.3099.96.camel@acorde.it.uc3m.es> References: <1296920514.3773.26.camel@acorde.it.uc3m.es> <1297017501.4715.2.camel@acorde.it.uc3m.es> <1297019696.4715.5.camel@acorde.it.uc3m.es> <1297115574.3099.3.camel@acorde.it.uc3m.es> <1297126584.3099.96.camel@acorde.it.uc3m.es> Date: Tue, 8 Feb 2011 10:08:13 +0900 Message-ID: From: Tran Minh Trung To: cjbc@it.uc3m.es Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 01:08:11 -0000 Hi Carlos and Julien, 2011/2/8 Carlos Jes=FAs Bernardos Cano : > Hi Julien, > > On Mon, 2011-02-07 at 15:56 -0800, Julien Laganier wrote: >> Hi Carlos, >> >> 2011/2/7 Carlos Jes=FAs Bernardos Cano : >> > Hi Julien, >> > >> > On Mon, 2011-02-07 at 12:43 -0800, Julien Laganier wrote: >> >> Hi Carlos, >> >> >> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : >> >> > Hi Julien, >> >> > >> >> > On Sun, 2011-02-06 at 10:56 -0800, Julien Laganier wrote: >> >> >> Hi Carlos, >> >> >> >> >> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : >> >> >> > Hi Julien, >> >> >> > >> >> >> > On Sun, 2011-02-06 at 10:11 -0800, Julien Laganier wrote: >> >> >> >> 2011/2/5 Carlos Jes=FAs Bernardos Cano : >> >> >> >> > On Fri, 2011-02-04 at 12:59 -0800, Julien Laganier wrote: >> >> >> >> >> On Fri, Feb 4, 2011 at 10:40 AM, Rajeev Koodli wrote: >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > On 2/4/11 10:16 AM, "Julien Laganier" wrote: >> >> >> >> >> > >> >> >> >> >> >>> >> >> >> >> >> >>> The LMA needs to provide the prefix info to the MAG. Thi= s can be either in >> >> >> >> >> >>> PBA or in FMI (if not provided in PBA). >> >> >> >> >> >> >> >> >> >> >> >> The LMA can provide the prefix to the MAG at session crea= tion, i.e., >> >> >> >> >> >> in the PBU. This information does not need to be (re)conv= eyed at flow >> >> >> >> >> >> movement. >> >> >> >> >> > >> >> >> >> >> > If it was conveyed in PBA, surely you don't reconvey. >> >> >> >> >> > If the prefix was not conveyed in PBA (as in the example w= e discussed >> >> >> >> >> > y'day), you provide it in FMI. >> >> >> >> >> >> >> >> >> >> IMO the prefix can always be conveyed in the PBA that is rec= eived in >> >> >> >> >> response to the PBU attaching an interface to a PMIPv6 flow = mobility >> >> >> >> >> session. >> >> >> >> > >> >> >> >> > What about the following scenario: >> >> >> >> > >> >> >> >> > MN has two interfaces: if1 and if2. if1 attaches to MAG1, a m= obility >> >> >> >> > session is created, pref1 is delegated. Some point in time la= ter, if2 >> >> >> >> > attaches to MAG2, new mobility sesison created, pref2 is dele= gated. >> >> >> >> > flowX addressed to pref2 wants to be moved to if1. In this ca= se we need >> >> >> >> > some signaling from LMA to MAG1 that cannot be conveted in PB= A. >> >> >> >> >> >> >> >> If flow X addresssed to pref2 wants to be moved to if1, first t= hing to >> >> >> >> do is to attach the if1 to the session corresponding to pref2, = so MAG1 >> >> >> >> sends a PBU, and LMA sends back a PBA with the prefix set of th= e >> >> >> >> session (pref2.) >> >> >> > >> >> >> > if1 was previously attached to MAG1 (and LMA delegated pref1). H= ow can >> >> >> > MAG1 know when LMA wants to move flow X to if1 (to send a PBU)? = Some >> >> >> > signaling is needed there. >> >> >> >> >> >> if1 was attached to MAG1 and had session S1 with prefix pref1. Whe= n >> >> >> if2 is attached to MAG2, if a different prefix pref2 is allocated, >> >> >> that is a different session S2. LMA cannot move a flow from sessio= n S2 >> >> >> to a MAG that isn't part of that session. So first thing to do aft= er >> >> >> S2 is created, if there's a desire to move flows across other MAGs= , is >> >> > >> >> > Right, our draft uses FMI signalling to add if1 to the session (we = use >> >> > the flowmob cache structure of this purpose). We are discussing abo= ut >> >> > two ways of doing exactly the same thing. However, in yours, you ne= ed >> >> > the MAG to take the initiative, while ours also supports the LMA >> >> > initiate the flow movement. >> >> >> >> You seem to be conflating session management and flow movement. >> >> >> >> In my approach, session management is MAG initiated, as it has been i= n >> >> the past with PMIPv6. Once a session exists across an interface set, >> >> flow movement can be LMA-initiated at any time from one interface in >> >> the set to another. >> >> >> >> I do not see a reason to depart from RFC 5213 and allow the LMA to >> >> initiate session management (except for purposes of revocation but >> >> that is supported already.) >> > >> > I see the reason to add it in order to support the scenarios I mention= ed >> > in my example. Those cannot be supported with RFC5213 model, as they >> > require first the MAG to send a PBU. We need either new signaling from >> > the LMA to the MAG to make the MAG aware of the required prefixes to >> > support flow mobility, or a trigger from the LMA to the MAG, so the MA= G >> > can send a PBU and then follow your model. >> >> In the systems I know the MAG is the entity that creates attaches a MN >> interface to a session and therefore I do not understand why you would >> need the LMA to attach an interface to a session. The LMA has no >> interface with the interface... That's a MAG duty. >> >> In which system is the scenario you're outlining useful? > > I must be really bad at explaining this... > > Lets consider the following scenario: > > - MN attaches if1 to MAG1. As a result, if1 is attached to the session > with MAG1. Pref1::/64 is delegated to if1. > > - Later on, MN attaches if2 to MAG2. As a result if2 is attached to the > session with MAG2. Pref2::/64 is delegated to if2. > > (nothing new so far, no flow mobility) > > - Some point in time later, LMA wants to move a flow X, addressed to > pref2::/64 to if1. MAG1 cannot send a PBU at that particular moment (how > can it know it has to?) to make MAG1 attach if1 to session with pref2. > Therefore, we need some signaling, initiated by the LMA, to make that > flow movement happen. > > How can this scenario be supported with your approach? I fail to see it. > > Thanks, > > Carlos > I think you still mis-understand Julien solution. Let's see the following scenario: Step1: if1 is attached to MAG1, session 1 is created: Session1: [Pref1, MAG1, IF1] Step2: if2 is attached to MAG2, session 2 is created: Session2: [Pref2, MAG2, IF2] If we amuse that the MAG2 knows that IF2 and IF1 are hidden by a logical interface to support flow mobility -> MAGs send PBU messages to attaches IF1 to S2 and IF2 to S1. Then two sessions are updated as follow: Session1: [Pref1, MAG1, IF1, IF2] Session2: [Pref2, MAG2, IF2, IF1] After that flow can be moved freely without extra signaling messages in any-cases (eg. policy changes) My question to Julien is that: How can MAG1 know that Session 2 is created to attach IF1 to S2 in advance? Regards, TrungTM >> >> --julien > > -- > Carlos Jes=FAs Bernardos Cano =A0 =A0 http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA =A04D55 35DC BA4D D170 4F67 > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 From julien.ietf@gmail.com Mon Feb 7 17:13:57 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73B613A69FB for ; Mon, 7 Feb 2011 17:13:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DH4IJNrpVxJA for ; Mon, 7 Feb 2011 17:13:56 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id E2BE83A69D3 for ; Mon, 7 Feb 2011 17:13:55 -0800 (PST) Received: by fxm9 with SMTP id 9so5906682fxm.31 for ; Mon, 07 Feb 2011 17:14:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XBstx1PtOLPhz4H+rM5N68qnR7hJjAKNDITe2rj11gQ=; b=utIn1mIGBn2nKseDP+q1W5uy0Ru26r82uE/OWltRqJNphHHnJo20OVURDW8Md+HkeE N0BlqjNDLU6YNUtJD4aBMIDqkOXGy/0DfAZtljp9t/XvkL4Re4SeFLHy1zDsJE+CpwmU gLrAK+rdUFNMQLqwQ22gepsJenUUhcnLMZrEw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=nZvSn8ONSQ/s2JX00Zh49ZDsqdnKRXK6G7M8SAi+ISkAj/vbilhh1Nvn/DAmOFAY+u aUvVVv8N8BMY8CAVTjrW/AzBWUWd4PbSfKhxZmvTdvR3MjKsg3Fd0x+HJ716HAGhf5hc dIuUJH5vbLGkMEcriQqNTzdmH9mNlYxIxgfa0= MIME-Version: 1.0 Received: by 10.103.233.4 with SMTP id k4mr11674762mur.129.1297127640527; Mon, 07 Feb 2011 17:14:00 -0800 (PST) Received: by 10.103.221.9 with HTTP; Mon, 7 Feb 2011 17:14:00 -0800 (PST) In-Reply-To: <1297126584.3099.96.camel@acorde.it.uc3m.es> References: <1296920514.3773.26.camel@acorde.it.uc3m.es> <1297017501.4715.2.camel@acorde.it.uc3m.es> <1297019696.4715.5.camel@acorde.it.uc3m.es> <1297115574.3099.3.camel@acorde.it.uc3m.es> <1297126584.3099.96.camel@acorde.it.uc3m.es> Date: Mon, 7 Feb 2011 17:14:00 -0800 Message-ID: From: Julien Laganier To: cjbc@it.uc3m.es Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 01:13:57 -0000 Hi Carlos, 2011/2/7 Carlos Jes=FAs Bernardos Cano : > Hi Julien, > > On Mon, 2011-02-07 at 15:56 -0800, Julien Laganier wrote: >> Hi Carlos, >> >> 2011/2/7 Carlos Jes=FAs Bernardos Cano : >> > Hi Julien, >> > >> > On Mon, 2011-02-07 at 12:43 -0800, Julien Laganier wrote: >> >> Hi Carlos, >> >> >> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : >> >> > Hi Julien, >> >> > >> >> > On Sun, 2011-02-06 at 10:56 -0800, Julien Laganier wrote: >> >> >> Hi Carlos, >> >> >> >> >> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : >> >> >> > Hi Julien, >> >> >> > >> >> >> > On Sun, 2011-02-06 at 10:11 -0800, Julien Laganier wrote: >> >> >> >> 2011/2/5 Carlos Jes=FAs Bernardos Cano : >> >> >> >> > On Fri, 2011-02-04 at 12:59 -0800, Julien Laganier wrote: >> >> >> >> >> On Fri, Feb 4, 2011 at 10:40 AM, Rajeev Koodli wrote: >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > On 2/4/11 10:16 AM, "Julien Laganier" wrote: >> >> >> >> >> > >> >> >> >> >> >>> >> >> >> >> >> >>> The LMA needs to provide the prefix info to the MAG. Thi= s can be either in >> >> >> >> >> >>> PBA or in FMI (if not provided in PBA). >> >> >> >> >> >> >> >> >> >> >> >> The LMA can provide the prefix to the MAG at session crea= tion, i.e., >> >> >> >> >> >> in the PBU. This information does not need to be (re)conv= eyed at flow >> >> >> >> >> >> movement. >> >> >> >> >> > >> >> >> >> >> > If it was conveyed in PBA, surely you don't reconvey. >> >> >> >> >> > If the prefix was not conveyed in PBA (as in the example w= e discussed >> >> >> >> >> > y'day), you provide it in FMI. >> >> >> >> >> >> >> >> >> >> IMO the prefix can always be conveyed in the PBA that is rec= eived in >> >> >> >> >> response to the PBU attaching an interface to a PMIPv6 flow = mobility >> >> >> >> >> session. >> >> >> >> > >> >> >> >> > What about the following scenario: >> >> >> >> > >> >> >> >> > MN has two interfaces: if1 and if2. if1 attaches to MAG1, a m= obility >> >> >> >> > session is created, pref1 is delegated. Some point in time la= ter, if2 >> >> >> >> > attaches to MAG2, new mobility sesison created, pref2 is dele= gated. >> >> >> >> > flowX addressed to pref2 wants to be moved to if1. In this ca= se we need >> >> >> >> > some signaling from LMA to MAG1 that cannot be conveted in PB= A. >> >> >> >> >> >> >> >> If flow X addresssed to pref2 wants to be moved to if1, first t= hing to >> >> >> >> do is to attach the if1 to the session corresponding to pref2, = so MAG1 >> >> >> >> sends a PBU, and LMA sends back a PBA with the prefix set of th= e >> >> >> >> session (pref2.) >> >> >> > >> >> >> > if1 was previously attached to MAG1 (and LMA delegated pref1). H= ow can >> >> >> > MAG1 know when LMA wants to move flow X to if1 (to send a PBU)? = Some >> >> >> > signaling is needed there. >> >> >> >> >> >> if1 was attached to MAG1 and had session S1 with prefix pref1. Whe= n >> >> >> if2 is attached to MAG2, if a different prefix pref2 is allocated, >> >> >> that is a different session S2. LMA cannot move a flow from sessio= n S2 >> >> >> to a MAG that isn't part of that session. So first thing to do aft= er >> >> >> S2 is created, if there's a desire to move flows across other MAGs= , is >> >> > >> >> > Right, our draft uses FMI signalling to add if1 to the session (we = use >> >> > the flowmob cache structure of this purpose). We are discussing abo= ut >> >> > two ways of doing exactly the same thing. However, in yours, you ne= ed >> >> > the MAG to take the initiative, while ours also supports the LMA >> >> > initiate the flow movement. >> >> >> >> You seem to be conflating session management and flow movement. >> >> >> >> In my approach, session management is MAG initiated, as it has been i= n >> >> the past with PMIPv6. Once a session exists across an interface set, >> >> flow movement can be LMA-initiated at any time from one interface in >> >> the set to another. >> >> >> >> I do not see a reason to depart from RFC 5213 and allow the LMA to >> >> initiate session management (except for purposes of revocation but >> >> that is supported already.) >> > >> > I see the reason to add it in order to support the scenarios I mention= ed >> > in my example. Those cannot be supported with RFC5213 model, as they >> > require first the MAG to send a PBU. We need either new signaling from >> > the LMA to the MAG to make the MAG aware of the required prefixes to >> > support flow mobility, or a trigger from the LMA to the MAG, so the MA= G >> > can send a PBU and then follow your model. >> >> In the systems I know the MAG is the entity that creates attaches a MN >> interface to a session and therefore I do not understand why you would >> need the LMA to attach an interface to a session. The LMA has no >> interface with the interface... That's a MAG duty. >> >> In which system is the scenario you're outlining useful? > > I must be really bad at explaining this... > > Lets consider the following scenario: > > - MN attaches if1 to MAG1. As a result, if1 is attached to the session > with MAG1. Pref1::/64 is delegated to if1. > > - Later on, MN attaches if2 to MAG2. As a result if2 is attached to the > session with MAG2. Pref2::/64 is delegated to if2. > > (nothing new so far, no flow mobility) > > - Some point in time later, LMA wants to move a flow X, addressed to > pref2::/64 to if1. MAG1 cannot send a PBU at that particular moment (how > can it know it has to?) to make MAG1 attach if1 to session with pref2. > Therefore, we need some signaling, initiated by the LMA, to make that > flow movement happen. > > How can this scenario be supported with your approach? I fail to see it. This scenario can't be supported without if1 being part of session2 where the pref2 belongs. So what's needed is that if1 be attached to session2 such that flows bound to prefix2 can move between if1 and if2. As I've indicated to you in the systems I am familiar with the MAG is the entity that creates session, which results in this scenario: - MN attaches if1 to session1. As a result, MAG1 signals to LMA that if1 is attached to the session1. Pref1::/64 is delegated to session1. - Later on MN wants another session. As a result, MAG1 signals to LMA that if1 is attached to the session2. Pref2::/64 is delegated to session2. - Later on MN attaches if2 to session2. As a result, MAG2 signals to LMA that if2 is attached to the session2. Pref2::/64 is now valid over both if1 and if2 for session2. - Some point in time later, LMA wants to move a flow X, addressed to pref2::/64 to if1. It does so :-) That works well. Where is the system that requires supporting the scenario you outlined that can't be supported through the nominal RFC 5213 model? --julien From rkoodli@cisco.com Mon Feb 7 17:14:11 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55A583A6FD3 for ; Mon, 7 Feb 2011 17:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fwpbO0gf-Tn for ; Mon, 7 Feb 2011 17:14:10 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 7D9943A69FB for ; Mon, 7 Feb 2011 17:14:10 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGwnUE2tJV2Z/2dsb2JhbAClJ3OfBJsShVoEhHqGbYM0gwE Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-1.cisco.com with ESMTP; 08 Feb 2011 01:14:15 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p181EFgE018368; Tue, 8 Feb 2011 01:14:15 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Feb 2011 19:14:15 -0600 Received: from 10.21.89.15 ([10.21.89.15]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Tue, 8 Feb 2011 01:14:14 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Mon, 07 Feb 2011 17:32:56 -0800 From: Rajeev Koodli To: Julien Laganier Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvHMBx1br9uU1HGCEuKorXqeAmDHg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 08 Feb 2011 01:14:15.0088 (UTC) FILETIME=[8057BB00:01CBC72D] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 01:14:11 -0000 On 2/4/11 12:59 PM, "Julien Laganier" wrote: >> >> If it was conveyed in PBA, surely you don't reconvey. >> If the prefix was not conveyed in PBA (as in the example we discussed >> y'day), you provide it in FMI. > > IMO the prefix can always be conveyed in the PBA that is received in > response to the PBU attaching an interface to a PMIPv6 flow mobility > session. > I think I see an attach as an independent session at the LMA. This is not a departure from the existing PMIP6 model. The session can have whatever prefix, policy, accounting and so on. For our purposes here, I would like to be able to add/refresh/delete any arbitrary prefix (which is valid on some other attach/session) without being forced to assign that/those prefix(es) only at the time of attach. -Rajeev > --julien From julien.ietf@gmail.com Mon Feb 7 17:18:43 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE6913A6FB4 for ; Mon, 7 Feb 2011 17:18:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4cJY0s66mz8 for ; Mon, 7 Feb 2011 17:18:42 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 8FA893A6E29 for ; Mon, 7 Feb 2011 17:18:42 -0800 (PST) Received: by fxm9 with SMTP id 9so5911029fxm.31 for ; Mon, 07 Feb 2011 17:18:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GPy3N5f08qnIR2lYImI2yS/OLVKhvw49eY9JGVgxbG4=; b=Idq4TsmIUfDUI5b5IMcWOZIsN3gCk2liyr7zd2+CH/V2cS/oQNflDEsZm7cQ6jdYlI HfkmP64mUSb/EQ3ywExbS3H+USTFG+tvxnZuLHnQPEbrQ0e2nHRFvavG4BnG2x40ZIik AYqQIoDdNHePANOTAEaN/FvtLDAFO1rJBKPqI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=OONKFiIjao2Vb0SmulcT+EZsDinZ/Mqw9N+zTcA81632kK+Sv4fFfcDFbanfFmX9Uv NtQ0GnLcgnBLWmf4fto8NJMb0f1nPUOFfcDgeYBnBics7Cnn6aIQ96VOvzgYwXoUxrxb fREB2Cc6sX4XPnquy/jPkIXU87TQWdYmig0UQ= MIME-Version: 1.0 Received: by 10.103.108.10 with SMTP id k10mr186536mum.39.1297127927067; Mon, 07 Feb 2011 17:18:47 -0800 (PST) Received: by 10.103.221.9 with HTTP; Mon, 7 Feb 2011 17:18:47 -0800 (PST) In-Reply-To: References: <1297115574.3099.3.camel@acorde.it.uc3m.es> Date: Mon, 7 Feb 2011 17:18:47 -0800 Message-ID: From: Julien Laganier To: Rajeev Koodli Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 01:18:43 -0000 On Mon, Feb 7, 2011 at 5:26 PM, Rajeev Koodli wrote: > > On 2/7/11 1:52 PM, "Carlos Jes=FAs Bernardos Cano" wrot= e: > >>> >>> You seem to be conflating session management and flow movement. >>> >>> In my approach, session management is MAG initiated, as it has been in >>> the past with PMIPv6. Once a session exists across an interface set, >>> flow movement can be LMA-initiated at any time from one interface in >>> the set to another. >>> >>> I do not see a reason to depart from RFC 5213 and allow the LMA to >>> initiate session management (except for purposes of revocation but >>> that is supported already.) >> >> I see the reason to add it in order to support the scenarios I mentioned >> in my example. Those cannot be supported with RFC5213 model, as they >> require first the MAG to send a PBU. We need either new signaling from >> the LMA to the MAG to make the MAG aware of the required prefixes to >> support flow mobility, or a trigger from the LMA to the MAG, so the MAG >> can send a PBU and then follow your model. > > Right. > > The LMA adding a prefix to an existing session should be supported. It's = not > very different from a router advertising a new prefix on an interface to = its > host. > > I might still be missing something here.. I don't know why this should be supported... It is not supported in RFC 5213 and has nothing to do with flow mobility. I have shown how one can do flow mobility without this capability. What substantiates the claim that this should be supported? > MAG initiates a new session at attach. To me, this is a new session at LM= A > with its own prefix (p1 on if1 in my previous example). You can argue tha= t > at the time of attach, the LMA *can* assign all available prefix(es). Tha= t's > option A). As I have mentioned earlier, I would like to be able to assign= a > prefix (e.g., p1) for the new session at attach, and add a different pref= ix > (e.g., p0) at any time. This is option B). I don't want to be forced to d= o > only A). I don't understand how adding different prefix at any time is related to flow mobility, and I also don't know where an hypothetical requirement to support this comes from. Can you enlighten us? --julien From julien.ietf@gmail.com Mon Feb 7 17:22:49 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 949813A6FBB for ; Mon, 7 Feb 2011 17:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sg-xJeQyCo7R for ; Mon, 7 Feb 2011 17:22:38 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 229E03A6FB4 for ; Mon, 7 Feb 2011 17:22:37 -0800 (PST) Received: by fxm9 with SMTP id 9so5914096fxm.31 for ; Mon, 07 Feb 2011 17:22:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UoOqn54YCwI/n/LrFuJVcf6IxcXZEr2n9HnI3+C3XA4=; b=uRqD3VZDQ0KJEugJ1BJ873Bg3BTQUMNw6ioNzoGl5nVw0/P0V3D7/edOkWwM97Nb3p 5+HmWtchGwZkHvNIPeAvzrMSjjAfkctAKrFvhXSu6HD648so7lKT57cY6wOiNHPwFMFA XybDuXcdWreEEPA7C1y2YnT9aj2Ny6CllvQkI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=HQk80eECOHYQrtBljdMVmQS0PCrNwr+xV6bevhfnVIuFBoW472BZpJpwdJ29rvXR3g oQXai5W28134brqDh8gCdutRSCu7Yu3PvQfuXJbSScgwDsl6Zlj3AaR96sRQqAMr2f9k XxbcPs/o22YXgniN+aK/ssEHVBMpp5YfXksno= MIME-Version: 1.0 Received: by 10.103.199.3 with SMTP id b3mr613658muq.93.1297128162536; Mon, 07 Feb 2011 17:22:42 -0800 (PST) Received: by 10.103.221.9 with HTTP; Mon, 7 Feb 2011 17:22:42 -0800 (PST) In-Reply-To: References: <1296920514.3773.26.camel@acorde.it.uc3m.es> <1297017501.4715.2.camel@acorde.it.uc3m.es> <1297019696.4715.5.camel@acorde.it.uc3m.es> <1297115574.3099.3.camel@acorde.it.uc3m.es> <1297126584.3099.96.camel@acorde.it.uc3m.es> Date: Mon, 7 Feb 2011 17:22:42 -0800 Message-ID: From: Julien Laganier To: Tran Minh Trung Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 01:22:49 -0000 Hi Tran, On Mon, Feb 7, 2011 at 5:08 PM, Tran Minh Trung wro= te: > Hi Carlos and Julien, > > 2011/2/8 Carlos Jes=FAs Bernardos Cano : >> Hi Julien, >> >> On Mon, 2011-02-07 at 15:56 -0800, Julien Laganier wrote: >>> Hi Carlos, >>> >>> 2011/2/7 Carlos Jes=FAs Bernardos Cano : >>> > Hi Julien, >>> > >>> > On Mon, 2011-02-07 at 12:43 -0800, Julien Laganier wrote: >>> >> Hi Carlos, >>> >> >>> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : >>> >> > Hi Julien, >>> >> > >>> >> > On Sun, 2011-02-06 at 10:56 -0800, Julien Laganier wrote: >>> >> >> Hi Carlos, >>> >> >> >>> >> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : >>> >> >> > Hi Julien, >>> >> >> > >>> >> >> > On Sun, 2011-02-06 at 10:11 -0800, Julien Laganier wrote: >>> >> >> >> 2011/2/5 Carlos Jes=FAs Bernardos Cano : >>> >> >> >> > On Fri, 2011-02-04 at 12:59 -0800, Julien Laganier wrote: >>> >> >> >> >> On Fri, Feb 4, 2011 at 10:40 AM, Rajeev Koodli wrote: >>> >> >> >> >> > >>> >> >> >> >> > >>> >> >> >> >> > On 2/4/11 10:16 AM, "Julien Laganier" wrote: >>> >> >> >> >> > >>> >> >> >> >> >>> >>> >> >> >> >> >>> The LMA needs to provide the prefix info to the MAG. Th= is can be either in >>> >> >> >> >> >>> PBA or in FMI (if not provided in PBA). >>> >> >> >> >> >> >>> >> >> >> >> >> The LMA can provide the prefix to the MAG at session cre= ation, i.e., >>> >> >> >> >> >> in the PBU. This information does not need to be (re)con= veyed at flow >>> >> >> >> >> >> movement. >>> >> >> >> >> > >>> >> >> >> >> > If it was conveyed in PBA, surely you don't reconvey. >>> >> >> >> >> > If the prefix was not conveyed in PBA (as in the example = we discussed >>> >> >> >> >> > y'day), you provide it in FMI. >>> >> >> >> >> >>> >> >> >> >> IMO the prefix can always be conveyed in the PBA that is re= ceived in >>> >> >> >> >> response to the PBU attaching an interface to a PMIPv6 flow= mobility >>> >> >> >> >> session. >>> >> >> >> > >>> >> >> >> > What about the following scenario: >>> >> >> >> > >>> >> >> >> > MN has two interfaces: if1 and if2. if1 attaches to MAG1, a = mobility >>> >> >> >> > session is created, pref1 is delegated. Some point in time l= ater, if2 >>> >> >> >> > attaches to MAG2, new mobility sesison created, pref2 is del= egated. >>> >> >> >> > flowX addressed to pref2 wants to be moved to if1. In this c= ase we need >>> >> >> >> > some signaling from LMA to MAG1 that cannot be conveted in P= BA. >>> >> >> >> >>> >> >> >> If flow X addresssed to pref2 wants to be moved to if1, first = thing to >>> >> >> >> do is to attach the if1 to the session corresponding to pref2,= so MAG1 >>> >> >> >> sends a PBU, and LMA sends back a PBA with the prefix set of t= he >>> >> >> >> session (pref2.) >>> >> >> > >>> >> >> > if1 was previously attached to MAG1 (and LMA delegated pref1). = How can >>> >> >> > MAG1 know when LMA wants to move flow X to if1 (to send a PBU)?= Some >>> >> >> > signaling is needed there. >>> >> >> >>> >> >> if1 was attached to MAG1 and had session S1 with prefix pref1. Wh= en >>> >> >> if2 is attached to MAG2, if a different prefix pref2 is allocated= , >>> >> >> that is a different session S2. LMA cannot move a flow from sessi= on S2 >>> >> >> to a MAG that isn't part of that session. So first thing to do af= ter >>> >> >> S2 is created, if there's a desire to move flows across other MAG= s, is >>> >> > >>> >> > Right, our draft uses FMI signalling to add if1 to the session (we= use >>> >> > the flowmob cache structure of this purpose). We are discussing ab= out >>> >> > two ways of doing exactly the same thing. However, in yours, you n= eed >>> >> > the MAG to take the initiative, while ours also supports the LMA >>> >> > initiate the flow movement. >>> >> >>> >> You seem to be conflating session management and flow movement. >>> >> >>> >> In my approach, session management is MAG initiated, as it has been = in >>> >> the past with PMIPv6. Once a session exists across an interface set, >>> >> flow movement can be LMA-initiated at any time from one interface in >>> >> the set to another. >>> >> >>> >> I do not see a reason to depart from RFC 5213 and allow the LMA to >>> >> initiate session management (except for purposes of revocation but >>> >> that is supported already.) >>> > >>> > I see the reason to add it in order to support the scenarios I mentio= ned >>> > in my example. Those cannot be supported with RFC5213 model, as they >>> > require first the MAG to send a PBU. We need either new signaling fro= m >>> > the LMA to the MAG to make the MAG aware of the required prefixes to >>> > support flow mobility, or a trigger from the LMA to the MAG, so the M= AG >>> > can send a PBU and then follow your model. >>> >>> In the systems I know the MAG is the entity that creates attaches a MN >>> interface to a session and therefore I do not understand why you would >>> need the LMA to attach an interface to a session. The LMA has no >>> interface with the interface... That's a MAG duty. >>> >>> In which system is the scenario you're outlining useful? >> >> I must be really bad at explaining this... >> >> Lets consider the following scenario: >> >> - MN attaches if1 to MAG1. As a result, if1 is attached to the session >> with MAG1. Pref1::/64 is delegated to if1. >> >> - Later on, MN attaches if2 to MAG2. As a result if2 is attached to the >> session with MAG2. Pref2::/64 is delegated to if2. >> >> (nothing new so far, no flow mobility) >> >> - Some point in time later, LMA wants to move a flow X, addressed to >> pref2::/64 to if1. MAG1 cannot send a PBU at that particular moment (how >> can it know it has to?) to make MAG1 attach if1 to session with pref2. >> Therefore, we need some signaling, initiated by the LMA, to make that >> flow movement happen. >> >> How can this scenario be supported with your approach? I fail to see it. >> >> Thanks, >> >> Carlos >> > > I think you still mis-understand Julien solution. > > Let's see the following scenario: > > Step1: if1 is attached to MAG1, session 1 is created: > > =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] > > Step2: if2 is attached to MAG2, session 2 is created: > > =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2] > > If we amuse that the MAG2 knows that IF2 and IF1 are hidden by a > logical interface to support flow mobility -> MAGs send PBU messages > to attaches IF1 to S2 and IF2 to S1. Then two sessions are updated as > follow: > > =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] > =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2, IF1] > > After that flow can be moved freely without extra signaling messages > in any-cases (eg. policy changes) > > My question to Julien is that: How can MAG1 know that Session 2 is > created to attach IF1 to S2 in advance? I think the question is backward. The real question should be, if there's an intent that flows bound to prefix2 be able to move between if1 and if2, why on earth would session 2 be created without if1 attached to it? I see no reason. --julien From julien.ietf@gmail.com Mon Feb 7 17:26:51 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A5553A6FB4 for ; Mon, 7 Feb 2011 17:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ipdt1YmKVEo9 for ; Mon, 7 Feb 2011 17:26:50 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 814213A6E2B for ; Mon, 7 Feb 2011 17:26:50 -0800 (PST) Received: by fxm9 with SMTP id 9so5916736fxm.31 for ; Mon, 07 Feb 2011 17:26:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jfaFrlWsP2d3cZep4zBRu84nVF19pQr9a5XXi9JRGew=; b=S8EZXabMpLgH9yosuiIkW80mYJiHF0Qq8r2xyHuWmW7FJdQDXethIsJrnNKQTQKFqv 2C4RHix8xae0axwoWuXorYUf5DF/fCB4d61Woo2wnN3yUSzvjI/462VRDLcNKlF2DVQM c1vUMCdoIeSB4hGvxSbeu00WzDX35L4A6BBFM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MuLkFhrmqB//PSWJRNbM4J9bdjyQm6A4eYMAc1eRD8pPZbPpaSAfFhvUAz1sxEOrfl qfFLTPHAisOvFF/xoLa3BXGI97c+SWjDcQ9Vvm/jVx9jl8L7Db8qEJCj3ZWIRUMBoG+m j7TUY7p/D9HD9yfzHdEKUEwztfLmFpJf3C0JE= MIME-Version: 1.0 Received: by 10.103.226.2 with SMTP id d2mr11825000mur.111.1297128415143; Mon, 07 Feb 2011 17:26:55 -0800 (PST) Received: by 10.103.221.9 with HTTP; Mon, 7 Feb 2011 17:26:54 -0800 (PST) In-Reply-To: References: Date: Mon, 7 Feb 2011 17:26:54 -0800 Message-ID: From: Julien Laganier To: Rajeev Koodli Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 01:26:51 -0000 On Mon, Feb 7, 2011 at 5:32 PM, Rajeev Koodli wrote: > > > On 2/4/11 12:59 PM, "Julien Laganier" wrote: > >>> >>> If it was conveyed in PBA, surely you don't reconvey. >>> If the prefix was not conveyed in PBA (as in the example we discussed >>> y'day), you provide it in FMI. >> >> IMO the prefix can always be conveyed in the PBA that is received in >> response to the PBU attaching an interface to a PMIPv6 flow mobility >> session. >> > > I think I see an attach as an independent session at the LMA. This is not a > departure from the existing PMIP6 model. The session can have whatever > prefix, policy, accounting and so on. For our purposes here, I would like to > be able to add/refresh/delete any arbitrary prefix (which is valid on some > other attach/session) without being forced to assign that/those prefix(es) > only at the time of attach. Interfaces are attached to session. The flow mobility requires more than one interface to be attached to a session. The session has whatever prefix policy accounting color taste smell. The fact that you want to add/refresh/delete prefixes has nothing to do with flow mobility and is an inherent limitation of the RFC 5213 model. I see no reason to depart from that in the context of extending the protocol to support mobility, nor I am aware of any system architecture that would require this capability. If this is something really important, the WG can be rechartered to work on a different extension that would allow adding/removing prefixes from existing PMIPv6 sessions. --julien From rkoodli@cisco.com Mon Feb 7 17:36:00 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9DB53A6A32 for ; Mon, 7 Feb 2011 17:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRvDe+qZT-IG for ; Mon, 7 Feb 2011 17:35:59 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id F11693A69D6 for ; Mon, 7 Feb 2011 17:35:58 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEctUE2tJV2Z/2dsb2JhbAClJ3OfD5sThVoEhHqGbYM0gwE Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-1.cisco.com with ESMTP; 08 Feb 2011 01:36:03 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p181a3R2025027; Tue, 8 Feb 2011 01:36:03 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Feb 2011 19:36:03 -0600 Received: from 10.21.89.15 ([10.21.89.15]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Tue, 8 Feb 2011 01:36:03 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Mon, 07 Feb 2011 17:54:45 -0800 From: Rajeev Koodli To: Julien Laganier Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvHMyiuqcBhhUAyjkCMNUk2VBGrrQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 08 Feb 2011 01:36:03.0886 (UTC) FILETIME=[8C7274E0:01CBC730] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 01:36:00 -0000 On 2/7/11 5:18 PM, "Julien Laganier" wrote: >> >> Right. >> >> The LMA adding a prefix to an existing session should be supported. It's not >> very different from a router advertising a new prefix on an interface to its >> host. >> >> I might still be missing something here.. > > I don't know why this should be supported... It is not supported in > RFC 5213 and has nothing to do with flow mobility. I have shown how > one can do flow mobility without this capability. What substantiates > the claim that this should be supported? > Hmm.. I hope we are not making a requirement here that if something is not supported in RFC 5213, it should not be worked on here. Also, I don't think we are required to accept a single solution because it fits some pre-existing model; we are working to add new functions within some reasonable bounds which we all can agree on. Of course if the LMA assigns all prefixes at the time of a new attach, there is nothing do; this is already in the ID. And, I am okay with it. I am not okay with that being the only choice. >> MAG initiates a new session at attach. To me, this is a new session at LMA >> with its own prefix (p1 on if1 in my previous example). You can argue that >> at the time of attach, the LMA *can* assign all available prefix(es). That's >> option A). As I have mentioned earlier, I would like to be able to assign a >> prefix (e.g., p1) for the new session at attach, and add a different prefix >> (e.g., p0) at any time. This is option B). I don't want to be forced to do >> only A). > > I don't understand how adding different prefix at any time is related > to flow mobility, If the LMA does not add a prefix and signal to the MAG (which can then advertise the signaled prefix in an RA to the MN), how can I get prefix p0 (valid on if0) to be valid on if1? NOTE: MAG didn't receive p0 on MN's attach on if1. > and I also don't know where an hypothetical > requirement to support this comes from. Can you enlighten us? Which hypothetical requirement? I don't want to assign p0 to if1 at attach. I want to be able to assign p0 to if1 when I need to. Doesn't sound hypothetical to me. Just an operational choice. -Rajeev > > --julien From julien.ietf@gmail.com Mon Feb 7 17:51:16 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC0453A6FC6 for ; Mon, 7 Feb 2011 17:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IE9lwE46Rith for ; Mon, 7 Feb 2011 17:51:13 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 672C53A6A32 for ; Mon, 7 Feb 2011 17:51:13 -0800 (PST) Received: by fxm9 with SMTP id 9so5936111fxm.31 for ; Mon, 07 Feb 2011 17:51:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KQBzYP5XWEbG8QbsXZuAGFrYGVuylraAW6l8M/eyVbE=; b=REsch18DhScqK/0oOttgHfTBoiPM8Le89P6nqqvQ2SMLMWu/usA6dKZKr9XewdC18p jjpjZFSWq27IMzZaDpGk00uy0No0EZ2u004LXelMbsUMs0Y+MJUKCFrzN+K4zFVWZfLz tNoZXiZUdViXA3rP79MRkySvjkGQeiqhOKSDs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hlLSYwI2yKHVzXDYhjQv7QXgnLDambgUZttpnwKFYGhEch7peubQ40sQXGF3/iL14v d5/c/1f7119BdwJN48CFh2mBqa5b7JL7JFSERz+eq+azqw+PwSbq4xyJf3IY0I9FLzhc NZ5SkKld+vMHNsUp88tTdIUojSC083BeTRqcg= MIME-Version: 1.0 Received: by 10.103.199.18 with SMTP id b18mr11685363muq.21.1297129878034; Mon, 07 Feb 2011 17:51:18 -0800 (PST) Received: by 10.103.221.9 with HTTP; Mon, 7 Feb 2011 17:51:17 -0800 (PST) In-Reply-To: References: Date: Mon, 7 Feb 2011 17:51:17 -0800 Message-ID: From: Julien Laganier To: Rajeev Koodli Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 01:51:16 -0000 On Mon, Feb 7, 2011 at 5:54 PM, Rajeev Koodli wrote: > > > On 2/7/11 5:18 PM, "Julien Laganier" wrote: > >>> >>> Right. >>> >>> The LMA adding a prefix to an existing session should be supported. It's not >>> very different from a router advertising a new prefix on an interface to its >>> host. >>> >>> I might still be missing something here.. >> >> I don't know why this should be supported... It is not supported in >> RFC 5213 and has nothing to do with flow mobility. I have shown how >> one can do flow mobility without this capability. What substantiates >> the claim that this should be supported? >> > > Hmm.. I hope we are not making a requirement here that if something is not > supported in RFC 5213, it should not be worked on here. > Also, I don't think we are required to accept a single solution because it > fits some pre-existing model; we are working to add new functions within > some reasonable bounds which we all can agree on. Technically speaking dynamic prefix management is a different feature from flow mobility, thus if specified it should go in a different spec so that one can implement RFC 5213 with dynamic prefix management but without flow mobility. On a more procedural note, I hope we can all agree that there is indeed a charter that details what we are working on and that we are not packing arbitrary features that are not listed as deliverables into the protocol. We are chartered to do PMIPv6 flow mobility, not dynamic prefix management for PMIPv6. > Of course if the LMA assigns all prefixes at the time of a new attach, there > is nothing do; this is already in the ID. And, I am okay with it. > I am not okay with that being the only choice. Then explain to us who is the customer for PMIPv6 dynamic prefix management, and convince the community that this is important enough for this WG to be rechartered to do it. This is how the IETF work, WG are being rechartered all the time. >>> MAG initiates a new session at attach. To me, this is a new session at LMA >>> with its own prefix (p1 on if1 in my previous example). You can argue that >>> at the time of attach, the LMA *can* assign all available prefix(es). That's >>> option A). As I have mentioned earlier, I would like to be able to assign a >>> prefix (e.g., p1) for the new session at attach, and add a different prefix >>> (e.g., p0) at any time. This is option B). I don't want to be forced to do >>> only A). >> >> I don't understand how adding different prefix at any time is related >> to flow mobility, > > If the LMA does not add a prefix and signal to the MAG (which can then > advertise the signaled prefix in an RA to the MN), how can I get prefix p0 > (valid on if0) to be valid on if1? NOTE: MAG didn't receive p0 on MN's > attach on if1. > > >> and I also don't know where an hypothetical requirement to support > > this comes from. Can you enlighten us? > > Which hypothetical requirement? That of doing dynamic prefix management for PMIPv6. It's not clear that 3GPP needs a feature like that. Who needs it then? > I don't want to assign p0 to if1 at attach. I want to be able to assign p0 > to if1 when I need to. Doesn't sound hypothetical to me. Just an operational > choice. We discuss whether or not it's operational, but actually it is only possible via a function that is different from flow mobility, which I call dynamic prefix management, that hasn't been part of the original PMIPv6 model. It's not because you want something that it belongs to the flow mobility specification. --julien From trungtm2909@gmail.com Mon Feb 7 17:51:49 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9258B3A6FC6 for ; Mon, 7 Feb 2011 17:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ys-0Av1FudTs for ; Mon, 7 Feb 2011 17:51:48 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 237553A69D6 for ; Mon, 7 Feb 2011 17:51:48 -0800 (PST) Received: by qyk34 with SMTP id 34so28858qyk.10 for ; Mon, 07 Feb 2011 17:51:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Pn3cGZNpW1/imgT4H8U4Qn0WvwjxVcCYwE6KnDE26pI=; b=Cujxqk5urIlBLQA3p3frhti0Sw9RD4Kl15w4qpqaFXPsfrcGLh8BqZP/f8CP9Hao7R WjvoUhMjNewXhtWWW5tHBkCejse+K+TAE0+Aerrizu5XRFvlCUxSy0KfpahiduZ40VVI zbxMc7nh90VnDl20LJs2BmrUG03wRhJvV3vB8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=e+atCFjl+DN7FCgEiV2UU8VWc4KnPv+PV6YzypQ+MqlbDUIeI0mS72FaqRjZ26Ok6Q whbXdorGlnPi8uwYJNueqC/wV9uzdVgk+XCT/JW+Qc4dUnxVqPuH9eNSRWq3d2RCAUf4 oj1vlzoQAQaLiomEPIA4b9rYrnTAXJeqk8FrE= MIME-Version: 1.0 Received: by 10.224.20.71 with SMTP id e7mr14839134qab.150.1297129912811; Mon, 07 Feb 2011 17:51:52 -0800 (PST) Received: by 10.224.89.11 with HTTP; Mon, 7 Feb 2011 17:51:52 -0800 (PST) In-Reply-To: References: <1296920514.3773.26.camel@acorde.it.uc3m.es> <1297017501.4715.2.camel@acorde.it.uc3m.es> <1297019696.4715.5.camel@acorde.it.uc3m.es> <1297115574.3099.3.camel@acorde.it.uc3m.es> <1297126584.3099.96.camel@acorde.it.uc3m.es> Date: Tue, 8 Feb 2011 10:51:52 +0900 Message-ID: From: Tran Minh Trung To: Julien Laganier Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 01:51:49 -0000 On Tue, Feb 8, 2011 at 10:41 AM, Julien Laganier wr= ote: > On Mon, Feb 7, 2011 at 5:30 PM, Tran Minh Trung w= rote: >> On Tue, Feb 8, 2011 at 10:22 AM, Julien Laganier = wrote: >>> Hi Tran, >>> >>> On Mon, Feb 7, 2011 at 5:08 PM, Tran Minh Trung = wrote: >>>> Hi Carlos and Julien, >>>> >>>> 2011/2/8 Carlos Jes=FAs Bernardos Cano : >>>>> Hi Julien, >>>>> >>>>> On Mon, 2011-02-07 at 15:56 -0800, Julien Laganier wrote: >>>>>> Hi Carlos, >>>>>> >>>>>> 2011/2/7 Carlos Jes=FAs Bernardos Cano : >>>>>> > Hi Julien, >>>>>> > >>>>>> > On Mon, 2011-02-07 at 12:43 -0800, Julien Laganier wrote: >>>>>> >> Hi Carlos, >>>>>> >> >>>>>> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : >>>>>> >> > Hi Julien, >>>>>> >> > >>>>>> >> > On Sun, 2011-02-06 at 10:56 -0800, Julien Laganier wrote: >>>>>> >> >> Hi Carlos, >>>>>> >> >> >>>>>> >> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : >>>>>> >> >> > Hi Julien, >>>>>> >> >> > >>>>>> >> >> > On Sun, 2011-02-06 at 10:11 -0800, Julien Laganier wrote: >>>>>> >> >> >> 2011/2/5 Carlos Jes=FAs Bernardos Cano : >>>>>> >> >> >> > On Fri, 2011-02-04 at 12:59 -0800, Julien Laganier wrote: >>>>>> >> >> >> >> On Fri, Feb 4, 2011 at 10:40 AM, Rajeev Koodli wrote: >>>>>> >> >> >> >> > >>>>>> >> >> >> >> > >>>>>> >> >> >> >> > On 2/4/11 10:16 AM, "Julien Laganier" wrote: >>>>>> >> >> >> >> > >>>>>> >> >> >> >> >>> >>>>>> >> >> >> >> >>> The LMA needs to provide the prefix info to the MAG.= This can be either in >>>>>> >> >> >> >> >>> PBA or in FMI (if not provided in PBA). >>>>>> >> >> >> >> >> >>>>>> >> >> >> >> >> The LMA can provide the prefix to the MAG at session = creation, i.e., >>>>>> >> >> >> >> >> in the PBU. This information does not need to be (re)= conveyed at flow >>>>>> >> >> >> >> >> movement. >>>>>> >> >> >> >> > >>>>>> >> >> >> >> > If it was conveyed in PBA, surely you don't reconvey. >>>>>> >> >> >> >> > If the prefix was not conveyed in PBA (as in the examp= le we discussed >>>>>> >> >> >> >> > y'day), you provide it in FMI. >>>>>> >> >> >> >> >>>>>> >> >> >> >> IMO the prefix can always be conveyed in the PBA that is= received in >>>>>> >> >> >> >> response to the PBU attaching an interface to a PMIPv6 f= low mobility >>>>>> >> >> >> >> session. >>>>>> >> >> >> > >>>>>> >> >> >> > What about the following scenario: >>>>>> >> >> >> > >>>>>> >> >> >> > MN has two interfaces: if1 and if2. if1 attaches to MAG1,= a mobility >>>>>> >> >> >> > session is created, pref1 is delegated. Some point in tim= e later, if2 >>>>>> >> >> >> > attaches to MAG2, new mobility sesison created, pref2 is = delegated. >>>>>> >> >> >> > flowX addressed to pref2 wants to be moved to if1. In thi= s case we need >>>>>> >> >> >> > some signaling from LMA to MAG1 that cannot be conveted i= n PBA. >>>>>> >> >> >> >>>>>> >> >> >> If flow X addresssed to pref2 wants to be moved to if1, fir= st thing to >>>>>> >> >> >> do is to attach the if1 to the session corresponding to pre= f2, so MAG1 >>>>>> >> >> >> sends a PBU, and LMA sends back a PBA with the prefix set o= f the >>>>>> >> >> >> session (pref2.) >>>>>> >> >> > >>>>>> >> >> > if1 was previously attached to MAG1 (and LMA delegated pref1= ). How can >>>>>> >> >> > MAG1 know when LMA wants to move flow X to if1 (to send a PB= U)? Some >>>>>> >> >> > signaling is needed there. >>>>>> >> >> >>>>>> >> >> if1 was attached to MAG1 and had session S1 with prefix pref1.= When >>>>>> >> >> if2 is attached to MAG2, if a different prefix pref2 is alloca= ted, >>>>>> >> >> that is a different session S2. LMA cannot move a flow from se= ssion S2 >>>>>> >> >> to a MAG that isn't part of that session. So first thing to do= after >>>>>> >> >> S2 is created, if there's a desire to move flows across other = MAGs, is >>>>>> >> > >>>>>> >> > Right, our draft uses FMI signalling to add if1 to the session = (we use >>>>>> >> > the flowmob cache structure of this purpose). We are discussing= about >>>>>> >> > two ways of doing exactly the same thing. However, in yours, yo= u need >>>>>> >> > the MAG to take the initiative, while ours also supports the LM= A >>>>>> >> > initiate the flow movement. >>>>>> >> >>>>>> >> You seem to be conflating session management and flow movement. >>>>>> >> >>>>>> >> In my approach, session management is MAG initiated, as it has be= en in >>>>>> >> the past with PMIPv6. Once a session exists across an interface s= et, >>>>>> >> flow movement can be LMA-initiated at any time from one interface= in >>>>>> >> the set to another. >>>>>> >> >>>>>> >> I do not see a reason to depart from RFC 5213 and allow the LMA t= o >>>>>> >> initiate session management (except for purposes of revocation bu= t >>>>>> >> that is supported already.) >>>>>> > >>>>>> > I see the reason to add it in order to support the scenarios I men= tioned >>>>>> > in my example. Those cannot be supported with RFC5213 model, as th= ey >>>>>> > require first the MAG to send a PBU. We need either new signaling = from >>>>>> > the LMA to the MAG to make the MAG aware of the required prefixes = to >>>>>> > support flow mobility, or a trigger from the LMA to the MAG, so th= e MAG >>>>>> > can send a PBU and then follow your model. >>>>>> >>>>>> In the systems I know the MAG is the entity that creates attaches a = MN >>>>>> interface to a session and therefore I do not understand why you wou= ld >>>>>> need the LMA to attach an interface to a session. The LMA has no >>>>>> interface with the interface... That's a MAG duty. >>>>>> >>>>>> In which system is the scenario you're outlining useful? >>>>> >>>>> I must be really bad at explaining this... >>>>> >>>>> Lets consider the following scenario: >>>>> >>>>> - MN attaches if1 to MAG1. As a result, if1 is attached to the sessio= n >>>>> with MAG1. Pref1::/64 is delegated to if1. >>>>> >>>>> - Later on, MN attaches if2 to MAG2. As a result if2 is attached to t= he >>>>> session with MAG2. Pref2::/64 is delegated to if2. >>>>> >>>>> (nothing new so far, no flow mobility) >>>>> >>>>> - Some point in time later, LMA wants to move a flow X, addressed to >>>>> pref2::/64 to if1. MAG1 cannot send a PBU at that particular moment (= how >>>>> can it know it has to?) to make MAG1 attach if1 to session with pref2= . >>>>> Therefore, we need some signaling, initiated by the LMA, to make that >>>>> flow movement happen. >>>>> >>>>> How can this scenario be supported with your approach? I fail to see = it. >>>>> >>>>> Thanks, >>>>> >>>>> Carlos >>>>> >>>> >>>> I think you still mis-understand Julien solution. >>>> >>>> Let's see the following scenario: >>>> >>>> Step1: if1 is attached to MAG1, session 1 is created: >>>> >>>> =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] >>>> >>>> Step2: if2 is attached to MAG2, session 2 is created: >>>> >>>> =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2] >>>> >>>> If we amuse that the MAG2 knows that IF2 and IF1 are hidden by a >>>> logical interface to support flow mobility -> MAGs send PBU messages >>>> to attaches IF1 to S2 and IF2 to S1. Then two sessions are updated as >>>> follow: >>>> >>>> =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] >>>> =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2, IF1] >>>> >>>> After that flow can be moved freely without extra signaling messages >>>> in any-cases (eg. policy changes) >>>> >>>> My question to Julien is that: How can MAG1 know that Session 2 is >>>> created to attach IF1 to S2 in advance? >>> >>> I think the question is backward. The real question should be, if >>> there's an intent that flows bound to prefix2 be able to move between >>> if1 and if2, why on earth would session 2 be created without if1 >>> attached to it? I see no reason. >>> >> >> How can you create session 2 with IF1 without informing MAG1 about prefi= x2? >> I think the attachment is completed only when MAG1 is received PBA >> message including Prefix2. But it needs PBU messages from MAG1 first. > > Right so this what you do. If you want a session2 that allows to move > flows between if1 and if2, you attach both if1 and if2 to session2 > when the interfaces are brought up. > >> I sill do not understand how MAG1 can initiate PBU message to attach >> IF1 to session2. > > IF1 is brought up. There is a desire to have session2 encompassing > this interface. So, MAG1 sends a PBU to attach IF1 to session2. What > is complicated? > In the above scenario, the session 2 is created only after the IF2 is attached to MAG2. We can not attach IF1 to session 2 when it dose not exist. Is that right? Regards, TrungTM > --julien > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 From cjbc@it.uc3m.es Mon Feb 7 17:52:08 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E68B3A6FC6 for ; Mon, 7 Feb 2011 17:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.056 X-Spam-Level: X-Spam-Status: No, score=-4.056 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVVEV60b9ISJ for ; Mon, 7 Feb 2011 17:52:07 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id ACDDF3A6A32 for ; Mon, 7 Feb 2011 17:52:06 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.3] (213.37.82.169.static.user.ono.com [213.37.82.169]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 16E3F70D8EC; Tue, 8 Feb 2011 02:52:11 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Julien Laganier In-Reply-To: References: <1296920514.3773.26.camel@acorde.it.uc3m.es> <1297017501.4715.2.camel@acorde.it.uc3m.es> <1297019696.4715.5.camel@acorde.it.uc3m.es> <1297115574.3099.3.camel@acorde.it.uc3m.es> <1297126584.3099.96.camel@acorde.it.uc3m.es> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-K9IF5fyuJ1qtKhEp0XCi" Organization: Universidad Carlos III de Madrid Date: Tue, 08 Feb 2011 02:53:18 +0100 Message-ID: <1297129998.3099.140.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17942.003 Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 08 Feb 2011 01:52:08 -0000 --=-K9IF5fyuJ1qtKhEp0XCi Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Julien, On Mon, 2011-02-07 at 17:14 -0800, Julien Laganier wrote: > Hi Carlos, >=20 > 2011/2/7 Carlos Jes=FAs Bernardos Cano : > > Hi Julien, > > > > On Mon, 2011-02-07 at 15:56 -0800, Julien Laganier wrote: > >> Hi Carlos, > >> > >> 2011/2/7 Carlos Jes=FAs Bernardos Cano : > >> > Hi Julien, > >> > > >> > On Mon, 2011-02-07 at 12:43 -0800, Julien Laganier wrote: > >> >> Hi Carlos, > >> >> > >> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : > >> >> > Hi Julien, > >> >> > > >> >> > On Sun, 2011-02-06 at 10:56 -0800, Julien Laganier wrote: > >> >> >> Hi Carlos, > >> >> >> > >> >> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : > >> >> >> > Hi Julien, > >> >> >> > > >> >> >> > On Sun, 2011-02-06 at 10:11 -0800, Julien Laganier wrote: > >> >> >> >> 2011/2/5 Carlos Jes=FAs Bernardos Cano : > >> >> >> >> > On Fri, 2011-02-04 at 12:59 -0800, Julien Laganier wrote: > >> >> >> >> >> On Fri, Feb 4, 2011 at 10:40 AM, Rajeev Koodli wrote: > >> >> >> >> >> > > >> >> >> >> >> > > >> >> >> >> >> > On 2/4/11 10:16 AM, "Julien Laganier" wrote: > >> >> >> >> >> > > >> >> >> >> >> >>> > >> >> >> >> >> >>> The LMA needs to provide the prefix info to the MAG. T= his can be either in > >> >> >> >> >> >>> PBA or in FMI (if not provided in PBA). > >> >> >> >> >> >> > >> >> >> >> >> >> The LMA can provide the prefix to the MAG at session cr= eation, i.e., > >> >> >> >> >> >> in the PBU. This information does not need to be (re)co= nveyed at flow > >> >> >> >> >> >> movement. > >> >> >> >> >> > > >> >> >> >> >> > If it was conveyed in PBA, surely you don't reconvey. > >> >> >> >> >> > If the prefix was not conveyed in PBA (as in the example= we discussed > >> >> >> >> >> > y'day), you provide it in FMI. > >> >> >> >> >> > >> >> >> >> >> IMO the prefix can always be conveyed in the PBA that is r= eceived in > >> >> >> >> >> response to the PBU attaching an interface to a PMIPv6 flo= w mobility > >> >> >> >> >> session. > >> >> >> >> > > >> >> >> >> > What about the following scenario: > >> >> >> >> > > >> >> >> >> > MN has two interfaces: if1 and if2. if1 attaches to MAG1, a= mobility > >> >> >> >> > session is created, pref1 is delegated. Some point in time = later, if2 > >> >> >> >> > attaches to MAG2, new mobility sesison created, pref2 is de= legated. > >> >> >> >> > flowX addressed to pref2 wants to be moved to if1. In this = case we need > >> >> >> >> > some signaling from LMA to MAG1 that cannot be conveted in = PBA. > >> >> >> >> > >> >> >> >> If flow X addresssed to pref2 wants to be moved to if1, first= thing to > >> >> >> >> do is to attach the if1 to the session corresponding to pref2= , so MAG1 > >> >> >> >> sends a PBU, and LMA sends back a PBA with the prefix set of = the > >> >> >> >> session (pref2.) > >> >> >> > > >> >> >> > if1 was previously attached to MAG1 (and LMA delegated pref1).= How can > >> >> >> > MAG1 know when LMA wants to move flow X to if1 (to send a PBU)= ? Some > >> >> >> > signaling is needed there. > >> >> >> > >> >> >> if1 was attached to MAG1 and had session S1 with prefix pref1. W= hen > >> >> >> if2 is attached to MAG2, if a different prefix pref2 is allocate= d, > >> >> >> that is a different session S2. LMA cannot move a flow from sess= ion S2 > >> >> >> to a MAG that isn't part of that session. So first thing to do a= fter > >> >> >> S2 is created, if there's a desire to move flows across other MA= Gs, is > >> >> > > >> >> > Right, our draft uses FMI signalling to add if1 to the session (w= e use > >> >> > the flowmob cache structure of this purpose). We are discussing a= bout > >> >> > two ways of doing exactly the same thing. However, in yours, you = need > >> >> > the MAG to take the initiative, while ours also supports the LMA > >> >> > initiate the flow movement. > >> >> > >> >> You seem to be conflating session management and flow movement. > >> >> > >> >> In my approach, session management is MAG initiated, as it has been= in > >> >> the past with PMIPv6. Once a session exists across an interface set= , > >> >> flow movement can be LMA-initiated at any time from one interface i= n > >> >> the set to another. > >> >> > >> >> I do not see a reason to depart from RFC 5213 and allow the LMA to > >> >> initiate session management (except for purposes of revocation but > >> >> that is supported already.) > >> > > >> > I see the reason to add it in order to support the scenarios I menti= oned > >> > in my example. Those cannot be supported with RFC5213 model, as they > >> > require first the MAG to send a PBU. We need either new signaling fr= om > >> > the LMA to the MAG to make the MAG aware of the required prefixes to > >> > support flow mobility, or a trigger from the LMA to the MAG, so the = MAG > >> > can send a PBU and then follow your model. > >> > >> In the systems I know the MAG is the entity that creates attaches a MN > >> interface to a session and therefore I do not understand why you would > >> need the LMA to attach an interface to a session. The LMA has no > >> interface with the interface... That's a MAG duty. > >> > >> In which system is the scenario you're outlining useful? > > > > I must be really bad at explaining this... > > > > Lets consider the following scenario: > > > > - MN attaches if1 to MAG1. As a result, if1 is attached to the session > > with MAG1. Pref1::/64 is delegated to if1. > > > > - Later on, MN attaches if2 to MAG2. As a result if2 is attached to the > > session with MAG2. Pref2::/64 is delegated to if2. > > > > (nothing new so far, no flow mobility) > > > > - Some point in time later, LMA wants to move a flow X, addressed to > > pref2::/64 to if1. MAG1 cannot send a PBU at that particular moment (ho= w > > can it know it has to?) to make MAG1 attach if1 to session with pref2. > > Therefore, we need some signaling, initiated by the LMA, to make that > > flow movement happen. > > > > How can this scenario be supported with your approach? I fail to see it= . >=20 > This scenario can't be supported without if1 being part of session2 > where the pref2 belongs. So what's needed is that if1 be attached to > session2 such that flows bound to prefix2 can move between if1 and > if2. As I've indicated to you in the systems I am familiar with the > MAG is the entity that creates session, which results in this > scenario: >=20 > - MN attaches if1 to session1. As a result, MAG1 signals to LMA that > if1 is attached to the session1. Pref1::/64 is delegated to session1. >=20 > - Later on MN wants another session. As a result, MAG1 signals to LMA > that if1 is attached to the session2. Pref2::/64 is delegated to > session2. How does the MN express that "desire of another session"? Besides, how does the MN knows that it'd require that session, before even considering attaching the second interface if2? With current RFC5213, I don't know how two different mobility sessions referring to the same interface of the MN can be created. I see how different prefixes can belong to the same mobility sessions, though. Are you already referring here to an extension to current PMIPv6? >=20 > - Later on MN attaches if2 to session2. As a result, MAG2 signals to > LMA that if2 is attached to the session2. Pref2::/64 is now valid over > both if1 and if2 for session2. >=20 MN cannot really "attach" anything, it is unaware of PMIPv6 operations (at least its IP stack). How could the MAGs know what interfaces should be added to which sessions? I'm really sorry that I still don't get your point, but in your reasoning it seems that events just occur in the right order to support flow mobility, but in reality MAGs do not know about all the interfaces a MN has, which ones are attached to the same PMIPv6 domain, and so on and so forth. Flow mobility should be controlled by the LMA, which is the only entity that can understand triggers (PBUs can be used as triggers as well) and "add" interfaces to mobility sessions. Thanks, Carlos > - Some point in time later, LMA wants to move a flow X, addressed to > pref2::/64 to if1. It does so :-) >=20 > That works well. Where is the system that requires supporting the > scenario you outlined that can't be supported through the nominal RFC > 5213 model? >=20 > --julien --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-K9IF5fyuJ1qtKhEp0XCi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1Qog4ACgkQNdy6TdFwT2c4zACgxX0m8jGA/63zCe1B9Wz6mkMa p70An3jdTUt+60W6/WjvvFt6sxDAaq8n =8zdg -----END PGP SIGNATURE----- --=-K9IF5fyuJ1qtKhEp0XCi-- From cjbc@it.uc3m.es Mon Feb 7 17:52:15 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 886263A69D6 for ; Mon, 7 Feb 2011 17:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.056 X-Spam-Level: X-Spam-Status: No, score=-4.056 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-QXKbGfF6Uo for ; Mon, 7 Feb 2011 17:52:14 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 405923A6A32 for ; Mon, 7 Feb 2011 17:52:13 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.3] (213.37.82.169.static.user.ono.com [213.37.82.169]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 782D6BF34D7; Tue, 8 Feb 2011 02:52:17 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Julien Laganier In-Reply-To: References: <1296920514.3773.26.camel@acorde.it.uc3m.es> <1297017501.4715.2.camel@acorde.it.uc3m.es> <1297019696.4715.5.camel@acorde.it.uc3m.es> <1297115574.3099.3.camel@acorde.it.uc3m.es> <1297126584.3099.96.camel@acorde.it.uc3m.es> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-NuKg4FjXitvP12/QpI9f" Organization: Universidad Carlos III de Madrid Date: Tue, 08 Feb 2011 02:53:24 +0100 Message-ID: <1297130004.3099.141.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17942.003 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 08 Feb 2011 01:52:15 -0000 --=-NuKg4FjXitvP12/QpI9f Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Julien, On Mon, 2011-02-07 at 17:22 -0800, Julien Laganier wrote: > Hi Tran, >=20 > On Mon, Feb 7, 2011 at 5:08 PM, Tran Minh Trung w= rote: > > Hi Carlos and Julien, > > > > 2011/2/8 Carlos Jes=FAs Bernardos Cano : > >> Hi Julien, > >> > >> On Mon, 2011-02-07 at 15:56 -0800, Julien Laganier wrote: > >>> Hi Carlos, > >>> > >>> 2011/2/7 Carlos Jes=FAs Bernardos Cano : > >>> > Hi Julien, > >>> > > >>> > On Mon, 2011-02-07 at 12:43 -0800, Julien Laganier wrote: > >>> >> Hi Carlos, > >>> >> > >>> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : > >>> >> > Hi Julien, > >>> >> > > >>> >> > On Sun, 2011-02-06 at 10:56 -0800, Julien Laganier wrote: > >>> >> >> Hi Carlos, > >>> >> >> > >>> >> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : > >>> >> >> > Hi Julien, > >>> >> >> > > >>> >> >> > On Sun, 2011-02-06 at 10:11 -0800, Julien Laganier wrote: > >>> >> >> >> 2011/2/5 Carlos Jes=FAs Bernardos Cano : > >>> >> >> >> > On Fri, 2011-02-04 at 12:59 -0800, Julien Laganier wrote: > >>> >> >> >> >> On Fri, Feb 4, 2011 at 10:40 AM, Rajeev Koodli wrote: > >>> >> >> >> >> > > >>> >> >> >> >> > > >>> >> >> >> >> > On 2/4/11 10:16 AM, "Julien Laganier" wrote: > >>> >> >> >> >> > > >>> >> >> >> >> >>> > >>> >> >> >> >> >>> The LMA needs to provide the prefix info to the MAG. = This can be either in > >>> >> >> >> >> >>> PBA or in FMI (if not provided in PBA). > >>> >> >> >> >> >> > >>> >> >> >> >> >> The LMA can provide the prefix to the MAG at session c= reation, i.e., > >>> >> >> >> >> >> in the PBU. This information does not need to be (re)c= onveyed at flow > >>> >> >> >> >> >> movement. > >>> >> >> >> >> > > >>> >> >> >> >> > If it was conveyed in PBA, surely you don't reconvey. > >>> >> >> >> >> > If the prefix was not conveyed in PBA (as in the exampl= e we discussed > >>> >> >> >> >> > y'day), you provide it in FMI. > >>> >> >> >> >> > >>> >> >> >> >> IMO the prefix can always be conveyed in the PBA that is = received in > >>> >> >> >> >> response to the PBU attaching an interface to a PMIPv6 fl= ow mobility > >>> >> >> >> >> session. > >>> >> >> >> > > >>> >> >> >> > What about the following scenario: > >>> >> >> >> > > >>> >> >> >> > MN has two interfaces: if1 and if2. if1 attaches to MAG1, = a mobility > >>> >> >> >> > session is created, pref1 is delegated. Some point in time= later, if2 > >>> >> >> >> > attaches to MAG2, new mobility sesison created, pref2 is d= elegated. > >>> >> >> >> > flowX addressed to pref2 wants to be moved to if1. In this= case we need > >>> >> >> >> > some signaling from LMA to MAG1 that cannot be conveted in= PBA. > >>> >> >> >> > >>> >> >> >> If flow X addresssed to pref2 wants to be moved to if1, firs= t thing to > >>> >> >> >> do is to attach the if1 to the session corresponding to pref= 2, so MAG1 > >>> >> >> >> sends a PBU, and LMA sends back a PBA with the prefix set of= the > >>> >> >> >> session (pref2.) > >>> >> >> > > >>> >> >> > if1 was previously attached to MAG1 (and LMA delegated pref1)= . How can > >>> >> >> > MAG1 know when LMA wants to move flow X to if1 (to send a PBU= )? Some > >>> >> >> > signaling is needed there. > >>> >> >> > >>> >> >> if1 was attached to MAG1 and had session S1 with prefix pref1. = When > >>> >> >> if2 is attached to MAG2, if a different prefix pref2 is allocat= ed, > >>> >> >> that is a different session S2. LMA cannot move a flow from ses= sion S2 > >>> >> >> to a MAG that isn't part of that session. So first thing to do = after > >>> >> >> S2 is created, if there's a desire to move flows across other M= AGs, is > >>> >> > > >>> >> > Right, our draft uses FMI signalling to add if1 to the session (= we use > >>> >> > the flowmob cache structure of this purpose). We are discussing = about > >>> >> > two ways of doing exactly the same thing. However, in yours, you= need > >>> >> > the MAG to take the initiative, while ours also supports the LMA > >>> >> > initiate the flow movement. > >>> >> > >>> >> You seem to be conflating session management and flow movement. > >>> >> > >>> >> In my approach, session management is MAG initiated, as it has bee= n in > >>> >> the past with PMIPv6. Once a session exists across an interface se= t, > >>> >> flow movement can be LMA-initiated at any time from one interface = in > >>> >> the set to another. > >>> >> > >>> >> I do not see a reason to depart from RFC 5213 and allow the LMA to > >>> >> initiate session management (except for purposes of revocation but > >>> >> that is supported already.) > >>> > > >>> > I see the reason to add it in order to support the scenarios I ment= ioned > >>> > in my example. Those cannot be supported with RFC5213 model, as the= y > >>> > require first the MAG to send a PBU. We need either new signaling f= rom > >>> > the LMA to the MAG to make the MAG aware of the required prefixes t= o > >>> > support flow mobility, or a trigger from the LMA to the MAG, so the= MAG > >>> > can send a PBU and then follow your model. > >>> > >>> In the systems I know the MAG is the entity that creates attaches a M= N > >>> interface to a session and therefore I do not understand why you woul= d > >>> need the LMA to attach an interface to a session. The LMA has no > >>> interface with the interface... That's a MAG duty. > >>> > >>> In which system is the scenario you're outlining useful? > >> > >> I must be really bad at explaining this... > >> > >> Lets consider the following scenario: > >> > >> - MN attaches if1 to MAG1. As a result, if1 is attached to the session > >> with MAG1. Pref1::/64 is delegated to if1. > >> > >> - Later on, MN attaches if2 to MAG2. As a result if2 is attached to th= e > >> session with MAG2. Pref2::/64 is delegated to if2. > >> > >> (nothing new so far, no flow mobility) > >> > >> - Some point in time later, LMA wants to move a flow X, addressed to > >> pref2::/64 to if1. MAG1 cannot send a PBU at that particular moment (h= ow > >> can it know it has to?) to make MAG1 attach if1 to session with pref2. > >> Therefore, we need some signaling, initiated by the LMA, to make that > >> flow movement happen. > >> > >> How can this scenario be supported with your approach? I fail to see i= t. > >> > >> Thanks, > >> > >> Carlos > >> > > > > I think you still mis-understand Julien solution. > > > > Let's see the following scenario: > > > > Step1: if1 is attached to MAG1, session 1 is created: > > > > Session1: [Pref1, MAG1, IF1] > > > > Step2: if2 is attached to MAG2, session 2 is created: > > > > Session2: [Pref2, MAG2, IF2] > > > > If we amuse that the MAG2 knows that IF2 and IF1 are hidden by a > > logical interface to support flow mobility -> MAGs send PBU messages > > to attaches IF1 to S2 and IF2 to S1. Then two sessions are updated as > > follow: > > > > Session1: [Pref1, MAG1, IF1, IF2] > > Session2: [Pref2, MAG2, IF2, IF1] > > > > After that flow can be moved freely without extra signaling messages > > in any-cases (eg. policy changes) > > > > My question to Julien is that: How can MAG1 know that Session 2 is > > created to attach IF1 to S2 in advance? >=20 > I think the question is backward. The real question should be, if > there's an intent that flows bound to prefix2 be able to move between > if1 and if2, why on earth would session 2 be created without if1 > attached to it? I see no reason. Because the MAGs are not aware in advance of how the LMA wants to move flows, nor about how many interfaces the MN has attached to the same domain. Only the LMA knows that. >=20 > --julien --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-NuKg4FjXitvP12/QpI9f Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1QohQACgkQNdy6TdFwT2fDTACfUb6i7Mz8CB7XykIoFaAHSirh Ia4AnApti6/5m3V6bHMSZSYp41j9NzPP =X77k -----END PGP SIGNATURE----- --=-NuKg4FjXitvP12/QpI9f-- From rkoodli@cisco.com Mon Feb 7 17:56:18 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 976003A6FE8 for ; Mon, 7 Feb 2011 17:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NysbqNxEOzek for ; Mon, 7 Feb 2011 17:56:17 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id AEE493A6FE4 for ; Mon, 7 Feb 2011 17:56:17 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPgxUE2tJV2Z/2dsb2JhbAClJ3OfDJsXhVoEhHqGbYM0gwE Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-1.cisco.com with ESMTP; 08 Feb 2011 01:56:22 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p181uMSc032028; Tue, 8 Feb 2011 01:56:22 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Feb 2011 19:56:22 -0600 Received: from 10.21.89.15 ([10.21.89.15]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Tue, 8 Feb 2011 01:56:22 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Mon, 07 Feb 2011 18:15:03 -0800 From: Rajeev Koodli To: Julien Laganier Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvHNf6qlk4573J+306beWzO449RwQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 08 Feb 2011 01:56:22.0605 (UTC) FILETIME=[62DC37D0:01CBC733] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 01:56:19 -0000 If flow mobility has nothing do with prefix management, I am lost. Or, I am being forced to accept a model as the only way to do flow mobility, which I cannot. On 2/7/11 5:26 PM, "Julien Laganier" wrote: > > Interfaces are attached to session. The flow mobility requires more > than one interface to be attached to a session. The session has > whatever prefix policy accounting color taste smell. Session is created upon attach which can happen when a MN attaches to an interface. "Interfaces are attached to a session" is right, there is ATT in the BCE (and PBU); so is the prefix assigned assigned to the session. > > The fact that you want to add/refresh/delete prefixes has nothing to > do with flow mobility and is an inherent limitation of the RFC 5213 > model. See previous note. If I cannot add a prefix (which is not valid on an interface), I don't know how I can move a flow (Carlos has shown this scenario as well). > I see no reason to depart from that in the context of extending > the protocol to support mobility, nor I am aware of any system > architecture that would require this capability. Okay, see your position. I see it differently. I don't need to be bound by some "presumed implementation model" of PMIP6 and limit myself *only* to a prefix assignment model you are imagining. > > If this is something really important, the WG can be rechartered to > work on a different extension that would allow adding/removing > prefixes from existing PMIPv6 sessions. > Huh.. What in the current charter forces us not to have the LMA add/refresh/delete a prefix on-demand? -Rajeev > --julien From cjbc@it.uc3m.es Mon Feb 7 17:58:58 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6369E3A6FEE for ; Mon, 7 Feb 2011 17:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.056 X-Spam-Level: X-Spam-Status: No, score=-4.056 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u14EZ3mrtjga for ; Mon, 7 Feb 2011 17:58:57 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id CFAFC3A6FF3 for ; Mon, 7 Feb 2011 17:58:56 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.3] (213.37.82.169.static.user.ono.com [213.37.82.169]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 24C897F2DCD; Tue, 8 Feb 2011 02:59:01 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Julien Laganier In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-ajnmSOmKDjQkKFVtPt4m" Organization: Universidad Carlos III de Madrid Date: Tue, 08 Feb 2011 03:00:08 +0100 Message-ID: <1297130408.3099.144.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17942.003 Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 08 Feb 2011 01:58:58 -0000 --=-ajnmSOmKDjQkKFVtPt4m Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Julien, On Mon, 2011-02-07 at 17:51 -0800, Julien Laganier wrote: > On Mon, Feb 7, 2011 at 5:54 PM, Rajeev Koodli wrote: > > > > > > On 2/7/11 5:18 PM, "Julien Laganier" wrote: > > > >>> > >>> Right. > >>> > >>> The LMA adding a prefix to an existing session should be supported. I= t's not > >>> very different from a router advertising a new prefix on an interface= to its > >>> host. > >>> > >>> I might still be missing something here.. > >> > >> I don't know why this should be supported... It is not supported in > >> RFC 5213 and has nothing to do with flow mobility. I have shown how > >> one can do flow mobility without this capability. What substantiates > >> the claim that this should be supported? > >> > > > > Hmm.. I hope we are not making a requirement here that if something is = not > > supported in RFC 5213, it should not be worked on here. > > Also, I don't think we are required to accept a single solution because= it > > fits some pre-existing model; we are working to add new functions withi= n > > some reasonable bounds which we all can agree on. >=20 > Technically speaking dynamic prefix management is a different feature > from flow mobility, thus if specified it should go in a different spec > so that one can implement RFC 5213 with dynamic prefix management but > without flow mobility. >=20 > On a more procedural note, I hope we can all agree that there is > indeed a charter that details what we are working on and that we are > not packing arbitrary features that are not listed as deliverables > into the protocol. We are chartered to do PMIPv6 flow mobility, not > dynamic prefix management for PMIPv6. I'm sorry, but solution described in our draft (of course you may like it or not, we can agree/disagree on its technical approach, etc.) is perfectly within the scope of the charter. It is not fair you consider it out of scope. Thanks, Carlos >=20 > > Of course if the LMA assigns all prefixes at the time of a new attach, = there > > is nothing do; this is already in the ID. And, I am okay with it. > > I am not okay with that being the only choice. >=20 > Then explain to us who is the customer for PMIPv6 dynamic prefix > management, and convince the community that this is important enough > for this WG to be rechartered to do it. This is how the IETF work, WG > are being rechartered all the time. >=20 > >>> MAG initiates a new session at attach. To me, this is a new session a= t LMA > >>> with its own prefix (p1 on if1 in my previous example). You can argue= that > >>> at the time of attach, the LMA *can* assign all available prefix(es).= That's > >>> option A). As I have mentioned earlier, I would like to be able to as= sign a > >>> prefix (e.g., p1) for the new session at attach, and add a different = prefix > >>> (e.g., p0) at any time. This is option B). I don't want to be forced = to do > >>> only A). > >> > >> I don't understand how adding different prefix at any time is related > >> to flow mobility, > > > > If the LMA does not add a prefix and signal to the MAG (which can then > > advertise the signaled prefix in an RA to the MN), how can I get prefix= p0 > > (valid on if0) to be valid on if1? NOTE: MAG didn't receive p0 on MN's > > attach on if1. > > > > > >> and I also don't know where an hypothetical requirement to support > > > this comes from. Can you enlighten us? > > > > Which hypothetical requirement? >=20 > That of doing dynamic prefix management for PMIPv6. It's not clear > that 3GPP needs a feature like that. Who needs it then? >=20 > > I don't want to assign p0 to if1 at attach. I want to be able to assign= p0 > > to if1 when I need to. Doesn't sound hypothetical to me. Just an operat= ional > > choice. >=20 > We discuss whether or not it's operational, but actually it is only > possible via a function that is different from flow mobility, which I > call dynamic prefix management, that hasn't been part of the original > PMIPv6 model. It's not because you want something that it belongs to > the flow mobility specification. >=20 > --julien --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-ajnmSOmKDjQkKFVtPt4m Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1Qo6gACgkQNdy6TdFwT2eJAgCg5ffMn02HC/+sGAYvcQvSMtiX CXUAoMMdD0LVYprqGzWM3TO7fXO2BCz7 =ql93 -----END PGP SIGNATURE----- --=-ajnmSOmKDjQkKFVtPt4m-- From rkoodli@cisco.com Mon Feb 7 18:14:57 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0445B3A7006 for ; Mon, 7 Feb 2011 18:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLr0Lzh8ahn2 for ; Mon, 7 Feb 2011 18:14:56 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 1D1C73A6B14 for ; Mon, 7 Feb 2011 18:14:56 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHs1UE2tJV2a/2dsb2JhbAClJ3OfHpsbhVoEhHqGbYM0gwE Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 08 Feb 2011 02:15:01 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p182F1mL032130; Tue, 8 Feb 2011 02:15:01 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Feb 2011 20:15:00 -0600 Received: from 10.21.89.15 ([10.21.89.15]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Tue, 8 Feb 2011 02:15:00 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Mon, 07 Feb 2011 18:33:42 -0800 From: Rajeev Koodli To: Julien Laganier Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvHOJmkW9kqlG/NwUaCXusLZBdppg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 08 Feb 2011 02:15:00.0947 (UTC) FILETIME=[FD71AA30:01CBC735] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 02:14:57 -0000 On 2/7/11 5:51 PM, "Julien Laganier" wrote: >> >> Hmm.. I hope we are not making a requirement here that if something is not >> supported in RFC 5213, it should not be worked on here. >> Also, I don't think we are required to accept a single solution because it >> fits some pre-existing model; we are working to add new functions within >> some reasonable bounds which we all can agree on. > > Technically speaking dynamic prefix management is a different feature > from flow mobility, thus if specified it should go in a different spec > so that one can implement RFC 5213 with dynamic prefix management but > without flow mobility. You can call it what you want, but that's the scenario I would like to be supported. Just because some folks have some implementation assumptions in RFC 5213 does not mean that we cannot do something different here. > > On a more procedural note, I hope we can all agree that there is > indeed a charter that details what we are working on and that we are > not packing arbitrary features that are not listed as deliverables > into the protocol. We are chartered to do PMIPv6 flow mobility, not > dynamic prefix management for PMIPv6. > To me this is not technical discussion. I see it perfectly under the current charter, and frankly not interested in this discussion. >> Of course if the LMA assigns all prefixes at the time of a new attach, there >> is nothing do; this is already in the ID. And, I am okay with it. >> I am not okay with that being the only choice. > > Then explain to us who is the customer for PMIPv6 dynamic prefix > management, and convince the community that this is important enough > for this WG to be rechartered to do it. This is how the IETF work, WG > are being rechartered all the time. > I didn't call it "PMIPv6 dynamic prefix management", you did. I see it no different from the overall network-based flow mobility problem we are working on. >> I don't want to assign p0 to if1 at attach. I want to be able to assign p0 >> to if1 when I need to. Doesn't sound hypothetical to me. Just an operational >> choice. > > We discuss whether or not it's operational, but actually it is only > possible via a function that is different from flow mobility, which I > call dynamic prefix management, that hasn't been part of the original > PMIPv6 model. It's not because you want something that it belongs to > the flow mobility specification. We can call it whatever. I don't see how *flow mobility* can be done for the scenarios I (and Carlos, Trung) have been referring to. And, just because RFC 5213 has certain limitation (on when a prefix is assigned), doesn't mean that we cannot extend it. -Rajeev > > --julien From julien.ietf@gmail.com Mon Feb 7 20:24:42 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 271EE3A6C8E for ; Mon, 7 Feb 2011 20:24:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AcFMcxundrp for ; Mon, 7 Feb 2011 20:24:40 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 48E4E3A6C79 for ; Mon, 7 Feb 2011 20:24:40 -0800 (PST) Received: by fxm9 with SMTP id 9so6041623fxm.31 for ; Mon, 07 Feb 2011 20:24:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=v1AfSOHN/bthCWeYNcnXa7R4b81NSDShU2nftyU+V/k=; b=nLds4ShdXpvnjKprBAE4Q4txirfZPdfM3Pp/K0ggfeU27M82UtFNf95zD9PwsStXie 8sbVOQxUGgKSgCaxNPkkWVJxuTPOZoyPsqBr4FjBHiUoZVpJGjYVle3nmW0AeZ7SB1Q/ PMyQ57qMx2AykltiiguK8rHe3qAL1K4FId7ZU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DC8nfEplFy48hsYyiiXSAFQXgpmsFRXFBNDL29qejy4TltOoqLuI5Z14EBuO2TQeLt 6cuPnhMz4Q/q0KoaqGb/7P9Q7wq6EmyU8pTSA7f1+rNDGdt43HzXuLH6LvI6j/eGtogy BAwRl1LqNVcAk/is2FZXyP8FGe/Dz5lXW9Dh4= MIME-Version: 1.0 Received: by 10.103.124.3 with SMTP id b3mr11087304mun.3.1297139085424; Mon, 07 Feb 2011 20:24:45 -0800 (PST) Received: by 10.103.221.9 with HTTP; Mon, 7 Feb 2011 20:24:45 -0800 (PST) In-Reply-To: <1297129998.3099.140.camel@acorde.it.uc3m.es> References: <1296920514.3773.26.camel@acorde.it.uc3m.es> <1297017501.4715.2.camel@acorde.it.uc3m.es> <1297019696.4715.5.camel@acorde.it.uc3m.es> <1297115574.3099.3.camel@acorde.it.uc3m.es> <1297126584.3099.96.camel@acorde.it.uc3m.es> <1297129998.3099.140.camel@acorde.it.uc3m.es> Date: Mon, 7 Feb 2011 20:24:45 -0800 Message-ID: From: Julien Laganier To: cjbc@it.uc3m.es Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 04:24:42 -0000 2011/2/7 Carlos Jes=FAs Bernardos Cano : > Hi Julien, > > On Mon, 2011-02-07 at 17:14 -0800, Julien Laganier wrote: >> Hi Carlos, >> >> 2011/2/7 Carlos Jes=FAs Bernardos Cano : >> > Hi Julien, >> > >> > On Mon, 2011-02-07 at 15:56 -0800, Julien Laganier wrote: >> >> Hi Carlos, >> >> >> >> 2011/2/7 Carlos Jes=FAs Bernardos Cano : >> >> > Hi Julien, >> >> > >> >> > On Mon, 2011-02-07 at 12:43 -0800, Julien Laganier wrote: >> >> >> Hi Carlos, >> >> >> >> >> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : >> >> >> > Hi Julien, >> >> >> > >> >> >> > On Sun, 2011-02-06 at 10:56 -0800, Julien Laganier wrote: >> >> >> >> Hi Carlos, >> >> >> >> >> >> >> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : >> >> >> >> > Hi Julien, >> >> >> >> > >> >> >> >> > On Sun, 2011-02-06 at 10:11 -0800, Julien Laganier wrote: >> >> >> >> >> 2011/2/5 Carlos Jes=FAs Bernardos Cano : >> >> >> >> >> > On Fri, 2011-02-04 at 12:59 -0800, Julien Laganier wrote: >> >> >> >> >> >> On Fri, Feb 4, 2011 at 10:40 AM, Rajeev Koodli wrote: >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > On 2/4/11 10:16 AM, "Julien Laganier" wrote: >> >> >> >> >> >> > >> >> >> >> >> >> >>> >> >> >> >> >> >> >>> The LMA needs to provide the prefix info to the MAG. = This can be either in >> >> >> >> >> >> >>> PBA or in FMI (if not provided in PBA). >> >> >> >> >> >> >> >> >> >> >> >> >> >> The LMA can provide the prefix to the MAG at session c= reation, i.e., >> >> >> >> >> >> >> in the PBU. This information does not need to be (re)c= onveyed at flow >> >> >> >> >> >> >> movement. >> >> >> >> >> >> > >> >> >> >> >> >> > If it was conveyed in PBA, surely you don't reconvey. >> >> >> >> >> >> > If the prefix was not conveyed in PBA (as in the exampl= e we discussed >> >> >> >> >> >> > y'day), you provide it in FMI. >> >> >> >> >> >> >> >> >> >> >> >> IMO the prefix can always be conveyed in the PBA that is = received in >> >> >> >> >> >> response to the PBU attaching an interface to a PMIPv6 fl= ow mobility >> >> >> >> >> >> session. >> >> >> >> >> > >> >> >> >> >> > What about the following scenario: >> >> >> >> >> > >> >> >> >> >> > MN has two interfaces: if1 and if2. if1 attaches to MAG1, = a mobility >> >> >> >> >> > session is created, pref1 is delegated. Some point in time= later, if2 >> >> >> >> >> > attaches to MAG2, new mobility sesison created, pref2 is d= elegated. >> >> >> >> >> > flowX addressed to pref2 wants to be moved to if1. In this= case we need >> >> >> >> >> > some signaling from LMA to MAG1 that cannot be conveted in= PBA. >> >> >> >> >> >> >> >> >> >> If flow X addresssed to pref2 wants to be moved to if1, firs= t thing to >> >> >> >> >> do is to attach the if1 to the session corresponding to pref= 2, so MAG1 >> >> >> >> >> sends a PBU, and LMA sends back a PBA with the prefix set of= the >> >> >> >> >> session (pref2.) >> >> >> >> > >> >> >> >> > if1 was previously attached to MAG1 (and LMA delegated pref1)= . How can >> >> >> >> > MAG1 know when LMA wants to move flow X to if1 (to send a PBU= )? Some >> >> >> >> > signaling is needed there. >> >> >> >> >> >> >> >> if1 was attached to MAG1 and had session S1 with prefix pref1. = When >> >> >> >> if2 is attached to MAG2, if a different prefix pref2 is allocat= ed, >> >> >> >> that is a different session S2. LMA cannot move a flow from ses= sion S2 >> >> >> >> to a MAG that isn't part of that session. So first thing to do = after >> >> >> >> S2 is created, if there's a desire to move flows across other M= AGs, is >> >> >> > >> >> >> > Right, our draft uses FMI signalling to add if1 to the session (= we use >> >> >> > the flowmob cache structure of this purpose). We are discussing = about >> >> >> > two ways of doing exactly the same thing. However, in yours, you= need >> >> >> > the MAG to take the initiative, while ours also supports the LMA >> >> >> > initiate the flow movement. >> >> >> >> >> >> You seem to be conflating session management and flow movement. >> >> >> >> >> >> In my approach, session management is MAG initiated, as it has bee= n in >> >> >> the past with PMIPv6. Once a session exists across an interface se= t, >> >> >> flow movement can be LMA-initiated at any time from one interface = in >> >> >> the set to another. >> >> >> >> >> >> I do not see a reason to depart from RFC 5213 and allow the LMA to >> >> >> initiate session management (except for purposes of revocation but >> >> >> that is supported already.) >> >> > >> >> > I see the reason to add it in order to support the scenarios I ment= ioned >> >> > in my example. Those cannot be supported with RFC5213 model, as the= y >> >> > require first the MAG to send a PBU. We need either new signaling f= rom >> >> > the LMA to the MAG to make the MAG aware of the required prefixes t= o >> >> > support flow mobility, or a trigger from the LMA to the MAG, so the= MAG >> >> > can send a PBU and then follow your model. >> >> >> >> In the systems I know the MAG is the entity that creates attaches a M= N >> >> interface to a session and therefore I do not understand why you woul= d >> >> need the LMA to attach an interface to a session. The LMA has no >> >> interface with the interface... That's a MAG duty. >> >> >> >> In which system is the scenario you're outlining useful? >> > >> > I must be really bad at explaining this... >> > >> > Lets consider the following scenario: >> > >> > - MN attaches if1 to MAG1. As a result, if1 is attached to the session >> > with MAG1. Pref1::/64 is delegated to if1. >> > >> > - Later on, MN attaches if2 to MAG2. As a result if2 is attached to th= e >> > session with MAG2. Pref2::/64 is delegated to if2. >> > >> > (nothing new so far, no flow mobility) >> > >> > - Some point in time later, LMA wants to move a flow X, addressed to >> > pref2::/64 to if1. MAG1 cannot send a PBU at that particular moment (h= ow >> > can it know it has to?) to make MAG1 attach if1 to session with pref2. >> > Therefore, we need some signaling, initiated by the LMA, to make that >> > flow movement happen. >> > >> > How can this scenario be supported with your approach? I fail to see i= t. >> >> This scenario can't be supported without if1 being part of session2 >> where the pref2 belongs. So what's needed is that if1 be attached to >> session2 such that flows bound to prefix2 can move between if1 and >> if2. As I've indicated to you in the systems I am familiar with the >> MAG is the entity that creates session, which results in this >> scenario: >> >> - MN attaches if1 to session1. As a result, MAG1 signals to LMA that >> if1 is attached to the session1. Pref1::/64 is delegated to session1. >> >> - Later on MN wants another session. As a result, MAG1 signals to LMA >> that if1 is attached to the session2. Pref2::/64 is delegated to >> session2. > > How does the MN express that "desire of another session"? L2 triggers. As per RFC 5213. > Besides, how does the MN knows that it'd require that session, before eve= n > considering attaching the second interface if2? The trigger to session2 creation is not attachment of a second interface, it's the will of having a different session from the one that existed in the first place, session1 aka default session. If there will be flows in session2 that will need to get on if1 or if2 at some point, you can simply create session2 whenever the first interface in the set is brought up. Conversely, you can tear down the session whenever both interfaces are down. Not sure what is so complex. > With current RFC5213, I don't know how two different mobility sessions > referring to the same interface of the MN can be created. I see how > different prefixes can belong to the same mobility sessions, though. Are > you already referring here to an extension to current PMIPv6? Yes. You define a session as a set of prefixes that are valid over a set of interfaces. This is the only thing that you need to do to support flow mobility, no need for FMI/FMA and LMA initiated signaling. >> - Later on MN attaches if2 to session2. As a result, MAG2 signals to >> LMA that if2 is attached to the session2. Pref2::/64 is now valid over >> both if1 and if2 for session2. >> > > MN cannot really "attach" anything, it is unaware of PMIPv6 operations > (at least its IP stack). Right, layer 3 of the MN is unaware. Layer 2 (virtual interfaces etc.) is, otherwise none of that can possibly work. > How could the MAGs know what interfaces should be added to which > sessions? A MAG attaches interfaces to session based on the policy profile or L2 triggers. If neither the policy profile nor L2 triggers says anything about multiple session, then I guess the MAG simply attaches whatever interfaces comes up to the only session that the MN has. We do not need to make this more complicated than needed to be. > I'm really sorry that I still don't get your point, but in > your reasoning it seems that events just occur in the right order to > support flow mobility, but in reality MAGs do not know about all the > interfaces a MN has, which ones are attached to the same PMIPv6 domain, > and so on and so forth. In reality MAG doesn't need to know about all the interfaces the MN has. MAG simply need to knows what interface should be attached to which session. It knows this via L2 triggers or policy profile. > Flow mobility should be controlled by the LMA, > which is the only entity that can understand triggers (PBUs can be used > as triggers as well) and "add" interfaces to mobility sessions. Interface being attached to a session is controlled by the MAG which is the only entity that knows that an interface is actually attached. Flow mobility decision can be taken entirely at LMA and the MAG needs not to know. --julien From julien.ietf@gmail.com Mon Feb 7 20:37:29 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 753133A6C93 for ; Mon, 7 Feb 2011 20:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CY4yiE+iynna for ; Mon, 7 Feb 2011 20:37:28 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 2EE1C3A6C86 for ; Mon, 7 Feb 2011 20:37:28 -0800 (PST) Received: by fxm9 with SMTP id 9so6049502fxm.31 for ; Mon, 07 Feb 2011 20:37:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0/lieDh0Vwp1ocF5J1LuwZMQqpE8L/S8PFgsKjG7BDU=; b=TPIfiDcn3gI7tP3TF9G8DqPf7tzZwgyoGelo0crfYghCSbFX0Zmip6LyFcHP3n3b9N LpMeJpzdq8BChKl87j/9qAMWH5kU7UomFsddTDVJ9/0WqQ3tmvv51VXszZsShmmvjFko UWB7C38GZ60kApe+WDc3WbNZA8wmAkPPmTphw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=o3UpZcPEF8YDGWMB8eX4CP9r5XjQmgzmypr7t8saRDiz4+SB0v8VZZ9c2Eb2XhWy9U tZdvJtrz1+q/F7hnFUpAj6q2UUlekX6J9EH6nrFU3APf5AlsPsXSFEwg8lRjmwceq1k7 bFhbRjqsQ24Zt03cp8MD9d71gLqHt3pJudrTk= MIME-Version: 1.0 Received: by 10.103.199.18 with SMTP id b18mr11795942muq.21.1297139853296; Mon, 07 Feb 2011 20:37:33 -0800 (PST) Received: by 10.103.221.9 with HTTP; Mon, 7 Feb 2011 20:37:33 -0800 (PST) In-Reply-To: References: Date: Mon, 7 Feb 2011 20:37:33 -0800 Message-ID: From: Julien Laganier To: Rajeev Koodli Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 04:37:29 -0000 On Mon, Feb 7, 2011 at 6:15 PM, Rajeev Koodli wrote: > > If flow mobility has nothing do with prefix management, I am lost. No reason to be lost: Prefix management is how do I get prefix for the MN. Flow mobility is how to I move flows across interfaces. The two needs not to be intertwined together, as I've shown in my other notes. E.g., I can do flow mobility without adding/deleting prefixes from sessions, and vice versa. > Or, I am being forced to accept a model as the only way to do flow mobility, > which I cannot. Quoting RFC 1958: "3.2 If there are several ways of doing the same thing, choose one." Is this something you can't accept? > On 2/7/11 5:26 PM, "Julien Laganier" wrote: >> >> Interfaces are attached to session. The flow mobility requires more >> than one interface to be attached to a session. The session has >> whatever prefix policy accounting color taste smell. > > Session is created upon attach which can happen when a MN attaches to an > interface. "Interfaces are attached to a session" is right, there is ATT in > the BCE (and PBU); so is the prefix assigned assigned to the session. Haven't said something different. Session has prefix set, and interface set. >> The fact that you want to add/refresh/delete prefixes has nothing to >> do with flow mobility and is an inherent limitation of the RFC 5213 >> model. > > See previous note. If I cannot add a prefix (which is not valid on an > interface), I don't know how I can move a flow (Carlos has shown this > scenario as well). You add the interface to the session, then you can move the flow to that interface... >> I see no reason to depart from that in the context of extending >> the protocol to support mobility, nor I am aware of any system >> architecture that would require this capability. > > Okay, see your position. I see it differently. I don't need to be bound by > some "presumed implementation model" of PMIP6 and limit myself *only* to a > prefix assignment model you are imagining. It's not an implementation model, it is a protocol model, and it's not imaginary. Implementation has nothing to do with this. There's no reason to extend prefix assignment model to do flow mobility unless you can point me out in which real world context your scenario actually happens. Absent that, the only imaginary thing is your scenario. >> If this is something really important, the WG can be rechartered to >> work on a different extension that would allow adding/removing >> prefixes from existing PMIPv6 sessions. > > Huh.. What in the current charter forces us not to have the LMA > add/refresh/delete a prefix on-demand? Engineering is about finding a solution to a problem. Adding/deleting prefix on-demand is not a solution to flow mobility. I've shown you how to do flow mobility without this capability. Now a different engineering problem would be: how to add/delete prefixes to a PMIPv6 session, and that would be useful for e.g. renumbering. This is a different problem that we haven't been chartered to work on. --julien From julien.ietf@gmail.com Mon Feb 7 20:40:37 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9252A3A6C93 for ; Mon, 7 Feb 2011 20:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNQIzRNEtZnK for ; Mon, 7 Feb 2011 20:40:36 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 7BD743A6C86 for ; Mon, 7 Feb 2011 20:40:36 -0800 (PST) Received: by fxm9 with SMTP id 9so6051676fxm.31 for ; Mon, 07 Feb 2011 20:40:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QJTpwjAAtwtaahRkX/0j6hliMk75DbumQKVya1XLnZE=; b=XlFPJygkHsMdK7FdgPSXNJlgRl4Ug1afXV/O98lzoWYHY+Ep09ETNz3y3PIvue6ogy /pVtwZ/NCkzj5Vy33c+wd0oTy2meaJukCLZbWhAo63puliRvoEVVeC6hu5vJuJiG97nd FKJWeTiimJb9doKcb6MGOEuc5DNRGAevcz6PI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=A0JIWPIuY4wGcuX2ft0GE58BbkI5dpUtjm1AbR+R6B59c77EY6tvzHTt9cjGufPt7R eKSG+zYEoh6J+JXAQ/ujpB49ezTg7GCQuljuOEk4T+afM5IHWRLTCVVWhl0pDKu1fYc4 87I3EfjomHG02pRiu1sT84r9QroAvmyOwjhGI= MIME-Version: 1.0 Received: by 10.103.192.12 with SMTP id u12mr9154445mup.75.1297140041495; Mon, 07 Feb 2011 20:40:41 -0800 (PST) Received: by 10.103.221.9 with HTTP; Mon, 7 Feb 2011 20:40:41 -0800 (PST) In-Reply-To: <1297130408.3099.144.camel@acorde.it.uc3m.es> References: <1297130408.3099.144.camel@acorde.it.uc3m.es> Date: Mon, 7 Feb 2011 20:40:41 -0800 Message-ID: From: Julien Laganier To: cjbc@it.uc3m.es Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 04:40:37 -0000 2011/2/7 Carlos Jes=FAs Bernardos Cano : > Hi Julien, > > On Mon, 2011-02-07 at 17:51 -0800, Julien Laganier wrote: >> On Mon, Feb 7, 2011 at 5:54 PM, Rajeev Koodli wrote: >> > >> > >> > On 2/7/11 5:18 PM, "Julien Laganier" wrote: >> > >> >>> >> >>> Right. >> >>> >> >>> The LMA adding a prefix to an existing session should be supported. = It's not >> >>> very different from a router advertising a new prefix on an interfac= e to its >> >>> host. >> >>> >> >>> I might still be missing something here.. >> >> >> >> I don't know why this should be supported... It is not supported in >> >> RFC 5213 and has nothing to do with flow mobility. I have shown how >> >> one can do flow mobility without this capability. What substantiates >> >> the claim that this should be supported? >> >> >> > >> > Hmm.. I hope we are not making a requirement here that if something is= not >> > supported in RFC 5213, it should not be worked on here. >> > Also, I don't think we are required to accept a single solution becaus= e it >> > fits some pre-existing model; we are working to add new functions with= in >> > some reasonable bounds which we all can agree on. >> >> Technically speaking dynamic prefix management is a different feature >> from flow mobility, thus if specified it should go in a different spec >> so that one can implement RFC 5213 with dynamic prefix management but >> without flow mobility. >> >> On a more procedural note, I hope we can all agree that there is >> indeed a charter that details what we are working on and that we are >> not packing arbitrary features that are not listed as deliverables >> into the protocol. We are chartered to do PMIPv6 flow mobility, not >> dynamic prefix management for PMIPv6. > > I'm sorry, but solution described in our draft (of course you may like > it or not, we can agree/disagree on its technical approach, etc.) is > perfectly within the scope of the charter. It is not fair you consider > it out of scope. You are mixing dynamic prefix management with flow mobility into one protocol extensions where they are not required to. Can you point me to a real world usecase where you actually need to add/delete prefixes to do prefix management? I read 3GPP specs but I don't know where this is needed. Is this needed somewhere else? --julien From julien.ietf@gmail.com Mon Feb 7 20:44:53 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 312663A6C9E for ; Mon, 7 Feb 2011 20:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quT5F7iSEkp9 for ; Mon, 7 Feb 2011 20:44:52 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id E1EC33A6C86 for ; Mon, 7 Feb 2011 20:44:51 -0800 (PST) Received: by fxm9 with SMTP id 9so6053980fxm.31 for ; Mon, 07 Feb 2011 20:44:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fgV1oN+IHbyuIOGaK3impqik8+CU7jYkFLzpfnWrOdo=; b=iPRgWT/1iFQBMSdWVczp378mCPSUQ9P+ZSrF9b1cJvtTQYYCAkL78B0nwf6sU9RR4B 1uX0oyuHijgff8mtG+T8IfubQFsG+m24SR+XoR8ZfKcWR6c/3swNex8kI85VoiHrgIAB maq0Tok6AKNOM1nnMuyM/javWc0e2FDjFYJrg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uWdGW6eXJM+wl9/LV10b6Nj1dCFvgYdo02bX4JLZZq40ImIXLJ7ZyjiRlFOsG2lwQu 7GD+XgdFlPOlNqccJ5sDMfQQij2P5L5AzUin6t4hBhrBJn0exwgtY0bMlschIyqV8iqi H2Yp+JqpnfmCrcfqM+jb+hpxzHnvjVFeRpHcs= MIME-Version: 1.0 Received: by 10.103.124.3 with SMTP id b3mr11100373mun.3.1297140297047; Mon, 07 Feb 2011 20:44:57 -0800 (PST) Received: by 10.103.221.9 with HTTP; Mon, 7 Feb 2011 20:44:56 -0800 (PST) In-Reply-To: References: Date: Mon, 7 Feb 2011 20:44:56 -0800 Message-ID: From: Julien Laganier To: Rajeev Koodli Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 04:44:53 -0000 On Mon, Feb 7, 2011 at 6:33 PM, Rajeev Koodli wrote: > > > On 2/7/11 5:51 PM, "Julien Laganier" wrote: > >>> >>> Hmm.. I hope we are not making a requirement here that if something is not >>> supported in RFC 5213, it should not be worked on here. >>> Also, I don't think we are required to accept a single solution because it >>> fits some pre-existing model; we are working to add new functions within >>> some reasonable bounds which we all can agree on. >> >> Technically speaking dynamic prefix management is a different feature >> from flow mobility, thus if specified it should go in a different spec >> so that one can implement RFC 5213 with dynamic prefix management but >> without flow mobility. > > You can call it what you want, but that's the scenario I would like to be > supported. Just because some folks have some implementation assumptions in > RFC 5213 does not mean that we cannot do something different here. There are no implementations assumptions, there's a protocol function that exists and you haven't made a convincing argument about why it needs to be extended with adding/removing prefixes to support flow mobility. Real world examples please. [...] >>> Of course if the LMA assigns all prefixes at the time of a new attach, there >>> is nothing do; this is already in the ID. And, I am okay with it. >>> I am not okay with that being the only choice. >> >> Then explain to us who is the customer for PMIPv6 dynamic prefix >> management, and convince the community that this is important enough >> for this WG to be rechartered to do it. This is how the IETF work, WG >> are being rechartered all the time. > > I didn't call it "PMIPv6 dynamic prefix management", you did. I indeed did, because this is what it is. > I see it no different from the overall network-based flow mobility problem > we are working on. It is different. It's a renumbering function that does not exist, is not required for flow mobility, and would be useful for non-flow mobility RFC 5213. >>> I don't want to assign p0 to if1 at attach. I want to be able to assign p0 >>> to if1 when I need to. Doesn't sound hypothetical to me. Just an operational >>> choice. >> >> We discuss whether or not it's operational, but actually it is only >> possible via a function that is different from flow mobility, which I >> call dynamic prefix management, that hasn't been part of the original >> PMIPv6 model. It's not because you want something that it belongs to >> the flow mobility specification. > > We can call it whatever. I don't see how *flow mobility* can be done for the > scenarios I (and Carlos, Trung) have been referring to. > And, just because RFC 5213 has certain limitation (on when a prefix is > assigned), doesn't mean that we cannot extend it. Your scenario doesn't happen in the real world. What is the usecase you're addressing?! --julien From trungtm2909@gmail.com Mon Feb 7 21:03:50 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A6873A6CA3 for ; Mon, 7 Feb 2011 21:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCrZiLxhAP4K for ; Mon, 7 Feb 2011 21:03:48 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 968CC3A6C95 for ; Mon, 7 Feb 2011 21:03:48 -0800 (PST) Received: by iwc10 with SMTP id 10so5875571iwc.31 for ; Mon, 07 Feb 2011 21:03:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9zMjjW2bvYL4XyRQH2V2qmh2wUwi9MipOeh/AnN9HWo=; b=UnbekS4WfhnLAPnyIKuxIaQjk59iIX/RGZY7Ar1pQ93+kOtP3MTAsG1Klo2DYgtFVG 6A0hjS5R0FWqYdrdgo4naSZF7O5VMsGohhZAnWryGQhmY0S0Z7c00UFRr9h1TMG5aQwX cUwrUzwDz0UIP6dGnJZ+2FdWeYCeyL4x+aHZ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZIQWjilGOYiOi1sD5LzFRTFh+e+Lgek9HqYY3wf1u2qWyEclBjypONKz9Vv26Z0F8D Dvhk7bTViCByPsuxN0xop8hZiSGmfkKCsNlXvxhOd/2w+Y7RZd+agRoAkaiYU1FogUW1 CehwgLawq4P0hsJLIEURL7UoFtFviVyTCk3sA= MIME-Version: 1.0 Received: by 10.42.220.8 with SMTP id hw8mr5742272icb.111.1297141433991; Mon, 07 Feb 2011 21:03:53 -0800 (PST) Received: by 10.42.171.4 with HTTP; Mon, 7 Feb 2011 21:03:53 -0800 (PST) In-Reply-To: References: <1296920514.3773.26.camel@acorde.it.uc3m.es> <1297017501.4715.2.camel@acorde.it.uc3m.es> <1297019696.4715.5.camel@acorde.it.uc3m.es> <1297115574.3099.3.camel@acorde.it.uc3m.es> <1297126584.3099.96.camel@acorde.it.uc3m.es> Date: Tue, 8 Feb 2011 14:03:53 +0900 Message-ID: From: Tran Minh Trung To: Julien Laganier Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 05:03:50 -0000 On Tue, Feb 8, 2011 at 1:12 PM, Julien Laganier wro= te: > On Mon, Feb 7, 2011 at 5:51 PM, Tran Minh Trung w= rote: >> On Tue, Feb 8, 2011 at 10:41 AM, Julien Laganier = wrote: >>> On Mon, Feb 7, 2011 at 5:30 PM, Tran Minh Trung = wrote: >>>> On Tue, Feb 8, 2011 at 10:22 AM, Julien Laganier wrote: >>>>> Hi Tran, >>>>> >>>>> On Mon, Feb 7, 2011 at 5:08 PM, Tran Minh Trung wrote: >>>>>> Hi Carlos and Julien, >>>>>> >>>>>> 2011/2/8 Carlos Jes=FAs Bernardos Cano : >>>>>>> Hi Julien, >>>>>>> >>>>>>> On Mon, 2011-02-07 at 15:56 -0800, Julien Laganier wrote: >>>>>>>> Hi Carlos, >>>>>>>> >>>>>>>> 2011/2/7 Carlos Jes=FAs Bernardos Cano : >>>>>>>> > Hi Julien, >>>>>>>> > >>>>>>>> > On Mon, 2011-02-07 at 12:43 -0800, Julien Laganier wrote: >>>>>>>> >> Hi Carlos, >>>>>>>> >> >>>>>>>> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : >>>>>>>> >> > Hi Julien, >>>>>>>> >> > >>>>>>>> >> > On Sun, 2011-02-06 at 10:56 -0800, Julien Laganier wrote: >>>>>>>> >> >> Hi Carlos, >>>>>>>> >> >> >>>>>>>> >> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : >>>>>>>> >> >> > Hi Julien, >>>>>>>> >> >> > >>>>>>>> >> >> > On Sun, 2011-02-06 at 10:11 -0800, Julien Laganier wrote: >>>>>>>> >> >> >> 2011/2/5 Carlos Jes=FAs Bernardos Cano : >>>>>>>> >> >> >> > On Fri, 2011-02-04 at 12:59 -0800, Julien Laganier wrot= e: >>>>>>>> >> >> >> >> On Fri, Feb 4, 2011 at 10:40 AM, Rajeev Koodli wrote: >>>>>>>> >> >> >> >> > >>>>>>>> >> >> >> >> > >>>>>>>> >> >> >> >> > On 2/4/11 10:16 AM, "Julien Laganier" wrote: >>>>>>>> >> >> >> >> > >>>>>>>> >> >> >> >> >>> >>>>>>>> >> >> >> >> >>> The LMA needs to provide the prefix info to the MA= G. This can be either in >>>>>>>> >> >> >> >> >>> PBA or in FMI (if not provided in PBA). >>>>>>>> >> >> >> >> >> >>>>>>>> >> >> >> >> >> The LMA can provide the prefix to the MAG at sessio= n creation, i.e., >>>>>>>> >> >> >> >> >> in the PBU. This information does not need to be (r= e)conveyed at flow >>>>>>>> >> >> >> >> >> movement. >>>>>>>> >> >> >> >> > >>>>>>>> >> >> >> >> > If it was conveyed in PBA, surely you don't reconvey= . >>>>>>>> >> >> >> >> > If the prefix was not conveyed in PBA (as in the exa= mple we discussed >>>>>>>> >> >> >> >> > y'day), you provide it in FMI. >>>>>>>> >> >> >> >> >>>>>>>> >> >> >> >> IMO the prefix can always be conveyed in the PBA that = is received in >>>>>>>> >> >> >> >> response to the PBU attaching an interface to a PMIPv6= flow mobility >>>>>>>> >> >> >> >> session. >>>>>>>> >> >> >> > >>>>>>>> >> >> >> > What about the following scenario: >>>>>>>> >> >> >> > >>>>>>>> >> >> >> > MN has two interfaces: if1 and if2. if1 attaches to MAG= 1, a mobility >>>>>>>> >> >> >> > session is created, pref1 is delegated. Some point in t= ime later, if2 >>>>>>>> >> >> >> > attaches to MAG2, new mobility sesison created, pref2 i= s delegated. >>>>>>>> >> >> >> > flowX addressed to pref2 wants to be moved to if1. In t= his case we need >>>>>>>> >> >> >> > some signaling from LMA to MAG1 that cannot be conveted= in PBA. >>>>>>>> >> >> >> >>>>>>>> >> >> >> If flow X addresssed to pref2 wants to be moved to if1, f= irst thing to >>>>>>>> >> >> >> do is to attach the if1 to the session corresponding to p= ref2, so MAG1 >>>>>>>> >> >> >> sends a PBU, and LMA sends back a PBA with the prefix set= of the >>>>>>>> >> >> >> session (pref2.) >>>>>>>> >> >> > >>>>>>>> >> >> > if1 was previously attached to MAG1 (and LMA delegated pre= f1). How can >>>>>>>> >> >> > MAG1 know when LMA wants to move flow X to if1 (to send a = PBU)? Some >>>>>>>> >> >> > signaling is needed there. >>>>>>>> >> >> >>>>>>>> >> >> if1 was attached to MAG1 and had session S1 with prefix pref= 1. When >>>>>>>> >> >> if2 is attached to MAG2, if a different prefix pref2 is allo= cated, >>>>>>>> >> >> that is a different session S2. LMA cannot move a flow from = session S2 >>>>>>>> >> >> to a MAG that isn't part of that session. So first thing to = do after >>>>>>>> >> >> S2 is created, if there's a desire to move flows across othe= r MAGs, is >>>>>>>> >> > >>>>>>>> >> > Right, our draft uses FMI signalling to add if1 to the sessio= n (we use >>>>>>>> >> > the flowmob cache structure of this purpose). We are discussi= ng about >>>>>>>> >> > two ways of doing exactly the same thing. However, in yours, = you need >>>>>>>> >> > the MAG to take the initiative, while ours also supports the = LMA >>>>>>>> >> > initiate the flow movement. >>>>>>>> >> >>>>>>>> >> You seem to be conflating session management and flow movement. >>>>>>>> >> >>>>>>>> >> In my approach, session management is MAG initiated, as it has = been in >>>>>>>> >> the past with PMIPv6. Once a session exists across an interface= set, >>>>>>>> >> flow movement can be LMA-initiated at any time from one interfa= ce in >>>>>>>> >> the set to another. >>>>>>>> >> >>>>>>>> >> I do not see a reason to depart from RFC 5213 and allow the LMA= to >>>>>>>> >> initiate session management (except for purposes of revocation = but >>>>>>>> >> that is supported already.) >>>>>>>> > >>>>>>>> > I see the reason to add it in order to support the scenarios I m= entioned >>>>>>>> > in my example. Those cannot be supported with RFC5213 model, as = they >>>>>>>> > require first the MAG to send a PBU. We need either new signalin= g from >>>>>>>> > the LMA to the MAG to make the MAG aware of the required prefixe= s to >>>>>>>> > support flow mobility, or a trigger from the LMA to the MAG, so = the MAG >>>>>>>> > can send a PBU and then follow your model. >>>>>>>> >>>>>>>> In the systems I know the MAG is the entity that creates attaches = a MN >>>>>>>> interface to a session and therefore I do not understand why you w= ould >>>>>>>> need the LMA to attach an interface to a session. The LMA has no >>>>>>>> interface with the interface... That's a MAG duty. >>>>>>>> >>>>>>>> In which system is the scenario you're outlining useful? >>>>>>> >>>>>>> I must be really bad at explaining this... >>>>>>> >>>>>>> Lets consider the following scenario: >>>>>>> >>>>>>> - MN attaches if1 to MAG1. As a result, if1 is attached to the sess= ion >>>>>>> with MAG1. Pref1::/64 is delegated to if1. >>>>>>> >>>>>>> - Later on, MN attaches if2 to MAG2. As a result if2 is attached to= the >>>>>>> session with MAG2. Pref2::/64 is delegated to if2. >>>>>>> >>>>>>> (nothing new so far, no flow mobility) >>>>>>> >>>>>>> - Some point in time later, LMA wants to move a flow X, addressed t= o >>>>>>> pref2::/64 to if1. MAG1 cannot send a PBU at that particular moment= (how >>>>>>> can it know it has to?) to make MAG1 attach if1 to session with pre= f2. >>>>>>> Therefore, we need some signaling, initiated by the LMA, to make th= at >>>>>>> flow movement happen. >>>>>>> >>>>>>> How can this scenario be supported with your approach? I fail to se= e it. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Carlos >>>>>>> >>>>>> >>>>>> I think you still mis-understand Julien solution. >>>>>> >>>>>> Let's see the following scenario: >>>>>> >>>>>> Step1: if1 is attached to MAG1, session 1 is created: >>>>>> >>>>>> =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] >>>>>> >>>>>> Step2: if2 is attached to MAG2, session 2 is created: >>>>>> >>>>>> =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2] >>>>>> >>>>>> If we amuse that the MAG2 knows that IF2 and IF1 are hidden by a >>>>>> logical interface to support flow mobility -> MAGs send PBU messages >>>>>> to attaches IF1 to S2 and IF2 to S1. Then two sessions are updated a= s >>>>>> follow: >>>>>> >>>>>> =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] >>>>>> =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2, IF1] >>>>>> >>>>>> After that flow can be moved freely without extra signaling messages >>>>>> in any-cases (eg. policy changes) >>>>>> >>>>>> My question to Julien is that: How can MAG1 know that Session 2 is >>>>>> created to attach IF1 to S2 in advance? >>>>> >>>>> I think the question is backward. The real question should be, if >>>>> there's an intent that flows bound to prefix2 be able to move between >>>>> if1 and if2, why on earth would session 2 be created without if1 >>>>> attached to it? I see no reason. >>>>> >>>> >>>> How can you create session 2 with IF1 without informing MAG1 about pre= fix2? >>>> I think the attachment is completed only when MAG1 is received PBA >>>> message including Prefix2. But it needs PBU messages from MAG1 first. >>> >>> Right so this what you do. If you want a session2 that allows to move >>> flows between if1 and if2, you attach both if1 and if2 to session2 >>> when the interfaces are brought up. >>> >>>> I sill do not understand how MAG1 can initiate PBU message to attach >>>> IF1 to session2. >>> >>> IF1 is brought up. There is a desire to have session2 encompassing >>> this interface. So, MAG1 sends a PBU to attach IF1 to session2. What >>> is complicated? >>> >> >> In the above scenario, the session 2 is created only after the IF2 is >> attached to MAG2. We can not attach IF1 to session 2 when it dose not >> exist. > > If session2 will at some point requires having flow sent to if1, why > can't session2 be created when if1 brought up? > Because the MAG1 can not know all prefix(es) that will be assigned to the sessions that will be created in the future. In the above example, MAG1 can not know that prefix2 will be assigned to session 2 when the IF2 is up. Regards, TrungTM > --julien > From julien.ietf@gmail.com Mon Feb 7 21:10:23 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E67BB3A7012 for ; Mon, 7 Feb 2011 21:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MeVXYJkfXG6 for ; Mon, 7 Feb 2011 21:10:22 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id EC74F3A6C9A for ; Mon, 7 Feb 2011 21:10:21 -0800 (PST) Received: by fxm9 with SMTP id 9so6070380fxm.31 for ; Mon, 07 Feb 2011 21:10:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=82rwCsA3ys8W3o9kz4sNQKWK5+UKO/yt7lmyNdRLCv0=; b=F/KSgrrVp40uYssqYG/RnneXklajwYZ9JWUUR7yKFzdwq2krLM4CkwKWIYiP8vdtaY uLXNd/niA1+MZ9nawLsPlhQb17kt4hkAySlSLN4KKAnSx68DPWt/GYEhUn3CnorLo7TK oYvqSiNDJVnyFrP41GzxjS16TiyLZDFnhrgSU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YVf6m9SNyv/eTGpGiNf2XeFBml3mpxs3yL657leMxRYWH4M97PBqmMUIXqeTriXhCU +SoaY2USFXM/8F83sHevCV1mvv6wXOKMrN8yChssl6rQ1T3BTpQ5A7FNFGakAg1FZQVh r0jOXXJTRKJvlYgm7Ry9MMPycLlvysYccpKzk= MIME-Version: 1.0 Received: by 10.103.226.2 with SMTP id d2mr11973773mur.111.1297141827202; Mon, 07 Feb 2011 21:10:27 -0800 (PST) Received: by 10.103.221.9 with HTTP; Mon, 7 Feb 2011 21:10:27 -0800 (PST) In-Reply-To: References: <1296920514.3773.26.camel@acorde.it.uc3m.es> <1297017501.4715.2.camel@acorde.it.uc3m.es> <1297019696.4715.5.camel@acorde.it.uc3m.es> <1297115574.3099.3.camel@acorde.it.uc3m.es> <1297126584.3099.96.camel@acorde.it.uc3m.es> Date: Mon, 7 Feb 2011 21:10:27 -0800 Message-ID: From: Julien Laganier To: Tran Minh Trung Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 05:10:24 -0000 On Mon, Feb 7, 2011 at 9:03 PM, Tran Minh Trung wro= te: > On Tue, Feb 8, 2011 at 1:12 PM, Julien Laganier w= rote: >> On Mon, Feb 7, 2011 at 5:51 PM, Tran Minh Trung = wrote: >>> On Tue, Feb 8, 2011 at 10:41 AM, Julien Laganier wrote: >>>> On Mon, Feb 7, 2011 at 5:30 PM, Tran Minh Trung wrote: >>>>> On Tue, Feb 8, 2011 at 10:22 AM, Julien Laganier wrote: >>>>>> Hi Tran, >>>>>> >>>>>> On Mon, Feb 7, 2011 at 5:08 PM, Tran Minh Trung wrote: >>>>>>> Hi Carlos and Julien, >>>>>>> >>>>>>> 2011/2/8 Carlos Jes=FAs Bernardos Cano : >>>>>>>> Hi Julien, >>>>>>>> >>>>>>>> On Mon, 2011-02-07 at 15:56 -0800, Julien Laganier wrote: >>>>>>>>> Hi Carlos, >>>>>>>>> >>>>>>>>> 2011/2/7 Carlos Jes=FAs Bernardos Cano : >>>>>>>>> > Hi Julien, >>>>>>>>> > >>>>>>>>> > On Mon, 2011-02-07 at 12:43 -0800, Julien Laganier wrote: >>>>>>>>> >> Hi Carlos, >>>>>>>>> >> >>>>>>>>> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : >>>>>>>>> >> > Hi Julien, >>>>>>>>> >> > >>>>>>>>> >> > On Sun, 2011-02-06 at 10:56 -0800, Julien Laganier wrote: >>>>>>>>> >> >> Hi Carlos, >>>>>>>>> >> >> >>>>>>>>> >> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : >>>>>>>>> >> >> > Hi Julien, >>>>>>>>> >> >> > >>>>>>>>> >> >> > On Sun, 2011-02-06 at 10:11 -0800, Julien Laganier wrote: >>>>>>>>> >> >> >> 2011/2/5 Carlos Jes=FAs Bernardos Cano = : >>>>>>>>> >> >> >> > On Fri, 2011-02-04 at 12:59 -0800, Julien Laganier wro= te: >>>>>>>>> >> >> >> >> On Fri, Feb 4, 2011 at 10:40 AM, Rajeev Koodli wrote: >>>>>>>>> >> >> >> >> > >>>>>>>>> >> >> >> >> > >>>>>>>>> >> >> >> >> > On 2/4/11 10:16 AM, "Julien Laganier" wrote: >>>>>>>>> >> >> >> >> > >>>>>>>>> >> >> >> >> >>> >>>>>>>>> >> >> >> >> >>> The LMA needs to provide the prefix info to the M= AG. This can be either in >>>>>>>>> >> >> >> >> >>> PBA or in FMI (if not provided in PBA). >>>>>>>>> >> >> >> >> >> >>>>>>>>> >> >> >> >> >> The LMA can provide the prefix to the MAG at sessi= on creation, i.e., >>>>>>>>> >> >> >> >> >> in the PBU. This information does not need to be (= re)conveyed at flow >>>>>>>>> >> >> >> >> >> movement. >>>>>>>>> >> >> >> >> > >>>>>>>>> >> >> >> >> > If it was conveyed in PBA, surely you don't reconve= y. >>>>>>>>> >> >> >> >> > If the prefix was not conveyed in PBA (as in the ex= ample we discussed >>>>>>>>> >> >> >> >> > y'day), you provide it in FMI. >>>>>>>>> >> >> >> >> >>>>>>>>> >> >> >> >> IMO the prefix can always be conveyed in the PBA that= is received in >>>>>>>>> >> >> >> >> response to the PBU attaching an interface to a PMIPv= 6 flow mobility >>>>>>>>> >> >> >> >> session. >>>>>>>>> >> >> >> > >>>>>>>>> >> >> >> > What about the following scenario: >>>>>>>>> >> >> >> > >>>>>>>>> >> >> >> > MN has two interfaces: if1 and if2. if1 attaches to MA= G1, a mobility >>>>>>>>> >> >> >> > session is created, pref1 is delegated. Some point in = time later, if2 >>>>>>>>> >> >> >> > attaches to MAG2, new mobility sesison created, pref2 = is delegated. >>>>>>>>> >> >> >> > flowX addressed to pref2 wants to be moved to if1. In = this case we need >>>>>>>>> >> >> >> > some signaling from LMA to MAG1 that cannot be convete= d in PBA. >>>>>>>>> >> >> >> >>>>>>>>> >> >> >> If flow X addresssed to pref2 wants to be moved to if1, = first thing to >>>>>>>>> >> >> >> do is to attach the if1 to the session corresponding to = pref2, so MAG1 >>>>>>>>> >> >> >> sends a PBU, and LMA sends back a PBA with the prefix se= t of the >>>>>>>>> >> >> >> session (pref2.) >>>>>>>>> >> >> > >>>>>>>>> >> >> > if1 was previously attached to MAG1 (and LMA delegated pr= ef1). How can >>>>>>>>> >> >> > MAG1 know when LMA wants to move flow X to if1 (to send a= PBU)? Some >>>>>>>>> >> >> > signaling is needed there. >>>>>>>>> >> >> >>>>>>>>> >> >> if1 was attached to MAG1 and had session S1 with prefix pre= f1. When >>>>>>>>> >> >> if2 is attached to MAG2, if a different prefix pref2 is all= ocated, >>>>>>>>> >> >> that is a different session S2. LMA cannot move a flow from= session S2 >>>>>>>>> >> >> to a MAG that isn't part of that session. So first thing to= do after >>>>>>>>> >> >> S2 is created, if there's a desire to move flows across oth= er MAGs, is >>>>>>>>> >> > >>>>>>>>> >> > Right, our draft uses FMI signalling to add if1 to the sessi= on (we use >>>>>>>>> >> > the flowmob cache structure of this purpose). We are discuss= ing about >>>>>>>>> >> > two ways of doing exactly the same thing. However, in yours,= you need >>>>>>>>> >> > the MAG to take the initiative, while ours also supports the= LMA >>>>>>>>> >> > initiate the flow movement. >>>>>>>>> >> >>>>>>>>> >> You seem to be conflating session management and flow movement= . >>>>>>>>> >> >>>>>>>>> >> In my approach, session management is MAG initiated, as it has= been in >>>>>>>>> >> the past with PMIPv6. Once a session exists across an interfac= e set, >>>>>>>>> >> flow movement can be LMA-initiated at any time from one interf= ace in >>>>>>>>> >> the set to another. >>>>>>>>> >> >>>>>>>>> >> I do not see a reason to depart from RFC 5213 and allow the LM= A to >>>>>>>>> >> initiate session management (except for purposes of revocation= but >>>>>>>>> >> that is supported already.) >>>>>>>>> > >>>>>>>>> > I see the reason to add it in order to support the scenarios I = mentioned >>>>>>>>> > in my example. Those cannot be supported with RFC5213 model, as= they >>>>>>>>> > require first the MAG to send a PBU. We need either new signali= ng from >>>>>>>>> > the LMA to the MAG to make the MAG aware of the required prefix= es to >>>>>>>>> > support flow mobility, or a trigger from the LMA to the MAG, so= the MAG >>>>>>>>> > can send a PBU and then follow your model. >>>>>>>>> >>>>>>>>> In the systems I know the MAG is the entity that creates attaches= a MN >>>>>>>>> interface to a session and therefore I do not understand why you = would >>>>>>>>> need the LMA to attach an interface to a session. The LMA has no >>>>>>>>> interface with the interface... That's a MAG duty. >>>>>>>>> >>>>>>>>> In which system is the scenario you're outlining useful? >>>>>>>> >>>>>>>> I must be really bad at explaining this... >>>>>>>> >>>>>>>> Lets consider the following scenario: >>>>>>>> >>>>>>>> - MN attaches if1 to MAG1. As a result, if1 is attached to the ses= sion >>>>>>>> with MAG1. Pref1::/64 is delegated to if1. >>>>>>>> >>>>>>>> - Later on, MN attaches if2 to MAG2. As a result if2 is attached t= o the >>>>>>>> session with MAG2. Pref2::/64 is delegated to if2. >>>>>>>> >>>>>>>> (nothing new so far, no flow mobility) >>>>>>>> >>>>>>>> - Some point in time later, LMA wants to move a flow X, addressed = to >>>>>>>> pref2::/64 to if1. MAG1 cannot send a PBU at that particular momen= t (how >>>>>>>> can it know it has to?) to make MAG1 attach if1 to session with pr= ef2. >>>>>>>> Therefore, we need some signaling, initiated by the LMA, to make t= hat >>>>>>>> flow movement happen. >>>>>>>> >>>>>>>> How can this scenario be supported with your approach? I fail to s= ee it. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Carlos >>>>>>>> >>>>>>> >>>>>>> I think you still mis-understand Julien solution. >>>>>>> >>>>>>> Let's see the following scenario: >>>>>>> >>>>>>> Step1: if1 is attached to MAG1, session 1 is created: >>>>>>> >>>>>>> =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] >>>>>>> >>>>>>> Step2: if2 is attached to MAG2, session 2 is created: >>>>>>> >>>>>>> =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2] >>>>>>> >>>>>>> If we amuse that the MAG2 knows that IF2 and IF1 are hidden by a >>>>>>> logical interface to support flow mobility -> MAGs send PBU message= s >>>>>>> to attaches IF1 to S2 and IF2 to S1. Then two sessions are updated = as >>>>>>> follow: >>>>>>> >>>>>>> =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] >>>>>>> =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2, IF1] >>>>>>> >>>>>>> After that flow can be moved freely without extra signaling message= s >>>>>>> in any-cases (eg. policy changes) >>>>>>> >>>>>>> My question to Julien is that: How can MAG1 know that Session 2 is >>>>>>> created to attach IF1 to S2 in advance? >>>>>> >>>>>> I think the question is backward. The real question should be, if >>>>>> there's an intent that flows bound to prefix2 be able to move betwee= n >>>>>> if1 and if2, why on earth would session 2 be created without if1 >>>>>> attached to it? I see no reason. >>>>>> >>>>> >>>>> How can you create session 2 with IF1 without informing MAG1 about pr= efix2? >>>>> I think the attachment is completed only when MAG1 is received PBA >>>>> message including Prefix2. But it needs PBU messages from MAG1 first. >>>> >>>> Right so this what you do. If you want a session2 that allows to move >>>> flows between if1 and if2, you attach both if1 and if2 to session2 >>>> when the interfaces are brought up. >>>> >>>>> I sill do not understand how MAG1 can initiate PBU message to attach >>>>> IF1 to session2. >>>> >>>> IF1 is brought up. There is a desire to have session2 encompassing >>>> this interface. So, MAG1 sends a PBU to attach IF1 to session2. What >>>> is complicated? >>>> >>> >>> In the above scenario, the session 2 is created only after the IF2 is >>> attached to MAG2. We can not attach IF1 to session 2 when it dose not >>> exist. >> >> If session2 will at some point requires having flow sent to if1, why >> can't session2 be created when if1 brought up? >> > > Because the MAG1 can not know all prefix(es) that will be assigned to > the sessions that will be created in the future. > > In the above example, MAG1 can not know that prefix2 will be assigned > to session 2 when the IF2 is up. All I'm saying is, if at some point flows from session2 have to go on interface1, you create session2 when interface1 or interface2 comes up, whichever happens first. --julien From trungtm2909@gmail.com Mon Feb 7 22:26:49 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E4443A6B69 for ; Mon, 7 Feb 2011 22:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJFqedfjNjzw for ; Mon, 7 Feb 2011 22:26:46 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 4E3593A7029 for ; Mon, 7 Feb 2011 22:26:38 -0800 (PST) Received: by iym1 with SMTP id 1so5347652iym.31 for ; Mon, 07 Feb 2011 22:26:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vRSNOTIBZZGm0WIdDnbdJZeoKqeJbDXZ1Dq2dGerEYo=; b=og99ALYNnrUH0m2BQXUTwa7q5XzOYQ+IoDuCTEXpFX6XuQ45AmKqvtu6W/CrcU4ieO JVnPJAxkMOErkfww+iO9iuZnBPZgH/IlgdvVhiUkimHqJnMV1FIRQj/1Egwsd7HyBqCM I6L4rVTh3mZ1i2/dsFZzBwLJWoyhlQLGJJcPU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Z6h7ztz64ioKP/snD6pG3ZwoB0nw92CCfijR5u5X8E9Rd8cWgE+IyYd63HrnGtoKCS hNk4iTRITUAE0lxHp8g49FocRWbxjjHCA4Cx+UxtjjAbyxJRhVP+AxesDol429A/PJoG O3Tm5t2qq9JRKY6wQzK8yeDXR3EPZ+/5RvqZs= MIME-Version: 1.0 Received: by 10.42.220.8 with SMTP id hw8mr5821140icb.111.1297146403500; Mon, 07 Feb 2011 22:26:43 -0800 (PST) Received: by 10.42.171.4 with HTTP; Mon, 7 Feb 2011 22:26:43 -0800 (PST) In-Reply-To: References: <1296920514.3773.26.camel@acorde.it.uc3m.es> <1297017501.4715.2.camel@acorde.it.uc3m.es> <1297019696.4715.5.camel@acorde.it.uc3m.es> <1297115574.3099.3.camel@acorde.it.uc3m.es> <1297126584.3099.96.camel@acorde.it.uc3m.es> Date: Tue, 8 Feb 2011 15:26:43 +0900 Message-ID: From: Tran Minh Trung To: Julien Laganier Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 06:26:49 -0000 On Tue, Feb 8, 2011 at 2:10 PM, Julien Laganier wro= te: > On Mon, Feb 7, 2011 at 9:03 PM, Tran Minh Trung w= rote: >> On Tue, Feb 8, 2011 at 1:12 PM, Julien Laganier = wrote: >>> On Mon, Feb 7, 2011 at 5:51 PM, Tran Minh Trung = wrote: >>>> On Tue, Feb 8, 2011 at 10:41 AM, Julien Laganier wrote: >>>>> On Mon, Feb 7, 2011 at 5:30 PM, Tran Minh Trung wrote: >>>>>> On Tue, Feb 8, 2011 at 10:22 AM, Julien Laganier wrote: >>>>>>> Hi Tran, >>>>>>> >>>>>>> On Mon, Feb 7, 2011 at 5:08 PM, Tran Minh Trung wrote: >>>>>>>> Hi Carlos and Julien, >>>>>>>> >>>>>>>> 2011/2/8 Carlos Jes=FAs Bernardos Cano : >>>>>>>>> Hi Julien, >>>>>>>>> >>>>>>>>> On Mon, 2011-02-07 at 15:56 -0800, Julien Laganier wrote: >>>>>>>>>> Hi Carlos, >>>>>>>>>> >>>>>>>>>> 2011/2/7 Carlos Jes=FAs Bernardos Cano : >>>>>>>>>> > Hi Julien, >>>>>>>>>> > >>>>>>>>>> > On Mon, 2011-02-07 at 12:43 -0800, Julien Laganier wrote: >>>>>>>>>> >> Hi Carlos, >>>>>>>>>> >> >>>>>>>>>> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : >>>>>>>>>> >> > Hi Julien, >>>>>>>>>> >> > >>>>>>>>>> >> > On Sun, 2011-02-06 at 10:56 -0800, Julien Laganier wrote: >>>>>>>>>> >> >> Hi Carlos, >>>>>>>>>> >> >> >>>>>>>>>> >> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : >>>>>>>>>> >> >> > Hi Julien, >>>>>>>>>> >> >> > >>>>>>>>>> >> >> > On Sun, 2011-02-06 at 10:11 -0800, Julien Laganier wrote= : >>>>>>>>>> >> >> >> 2011/2/5 Carlos Jes=FAs Bernardos Cano : >>>>>>>>>> >> >> >> > On Fri, 2011-02-04 at 12:59 -0800, Julien Laganier wr= ote: >>>>>>>>>> >> >> >> >> On Fri, Feb 4, 2011 at 10:40 AM, Rajeev Koodli wrote: >>>>>>>>>> >> >> >> >> > >>>>>>>>>> >> >> >> >> > >>>>>>>>>> >> >> >> >> > On 2/4/11 10:16 AM, "Julien Laganier" wrote: >>>>>>>>>> >> >> >> >> > >>>>>>>>>> >> >> >> >> >>> >>>>>>>>>> >> >> >> >> >>> The LMA needs to provide the prefix info to the = MAG. This can be either in >>>>>>>>>> >> >> >> >> >>> PBA or in FMI (if not provided in PBA). >>>>>>>>>> >> >> >> >> >> >>>>>>>>>> >> >> >> >> >> The LMA can provide the prefix to the MAG at sess= ion creation, i.e., >>>>>>>>>> >> >> >> >> >> in the PBU. This information does not need to be = (re)conveyed at flow >>>>>>>>>> >> >> >> >> >> movement. >>>>>>>>>> >> >> >> >> > >>>>>>>>>> >> >> >> >> > If it was conveyed in PBA, surely you don't reconv= ey. >>>>>>>>>> >> >> >> >> > If the prefix was not conveyed in PBA (as in the e= xample we discussed >>>>>>>>>> >> >> >> >> > y'day), you provide it in FMI. >>>>>>>>>> >> >> >> >> >>>>>>>>>> >> >> >> >> IMO the prefix can always be conveyed in the PBA tha= t is received in >>>>>>>>>> >> >> >> >> response to the PBU attaching an interface to a PMIP= v6 flow mobility >>>>>>>>>> >> >> >> >> session. >>>>>>>>>> >> >> >> > >>>>>>>>>> >> >> >> > What about the following scenario: >>>>>>>>>> >> >> >> > >>>>>>>>>> >> >> >> > MN has two interfaces: if1 and if2. if1 attaches to M= AG1, a mobility >>>>>>>>>> >> >> >> > session is created, pref1 is delegated. Some point in= time later, if2 >>>>>>>>>> >> >> >> > attaches to MAG2, new mobility sesison created, pref2= is delegated. >>>>>>>>>> >> >> >> > flowX addressed to pref2 wants to be moved to if1. In= this case we need >>>>>>>>>> >> >> >> > some signaling from LMA to MAG1 that cannot be convet= ed in PBA. >>>>>>>>>> >> >> >> >>>>>>>>>> >> >> >> If flow X addresssed to pref2 wants to be moved to if1,= first thing to >>>>>>>>>> >> >> >> do is to attach the if1 to the session corresponding to= pref2, so MAG1 >>>>>>>>>> >> >> >> sends a PBU, and LMA sends back a PBA with the prefix s= et of the >>>>>>>>>> >> >> >> session (pref2.) >>>>>>>>>> >> >> > >>>>>>>>>> >> >> > if1 was previously attached to MAG1 (and LMA delegated p= ref1). How can >>>>>>>>>> >> >> > MAG1 know when LMA wants to move flow X to if1 (to send = a PBU)? Some >>>>>>>>>> >> >> > signaling is needed there. >>>>>>>>>> >> >> >>>>>>>>>> >> >> if1 was attached to MAG1 and had session S1 with prefix pr= ef1. When >>>>>>>>>> >> >> if2 is attached to MAG2, if a different prefix pref2 is al= located, >>>>>>>>>> >> >> that is a different session S2. LMA cannot move a flow fro= m session S2 >>>>>>>>>> >> >> to a MAG that isn't part of that session. So first thing t= o do after >>>>>>>>>> >> >> S2 is created, if there's a desire to move flows across ot= her MAGs, is >>>>>>>>>> >> > >>>>>>>>>> >> > Right, our draft uses FMI signalling to add if1 to the sess= ion (we use >>>>>>>>>> >> > the flowmob cache structure of this purpose). We are discus= sing about >>>>>>>>>> >> > two ways of doing exactly the same thing. However, in yours= , you need >>>>>>>>>> >> > the MAG to take the initiative, while ours also supports th= e LMA >>>>>>>>>> >> > initiate the flow movement. >>>>>>>>>> >> >>>>>>>>>> >> You seem to be conflating session management and flow movemen= t. >>>>>>>>>> >> >>>>>>>>>> >> In my approach, session management is MAG initiated, as it ha= s been in >>>>>>>>>> >> the past with PMIPv6. Once a session exists across an interfa= ce set, >>>>>>>>>> >> flow movement can be LMA-initiated at any time from one inter= face in >>>>>>>>>> >> the set to another. >>>>>>>>>> >> >>>>>>>>>> >> I do not see a reason to depart from RFC 5213 and allow the L= MA to >>>>>>>>>> >> initiate session management (except for purposes of revocatio= n but >>>>>>>>>> >> that is supported already.) >>>>>>>>>> > >>>>>>>>>> > I see the reason to add it in order to support the scenarios I= mentioned >>>>>>>>>> > in my example. Those cannot be supported with RFC5213 model, a= s they >>>>>>>>>> > require first the MAG to send a PBU. We need either new signal= ing from >>>>>>>>>> > the LMA to the MAG to make the MAG aware of the required prefi= xes to >>>>>>>>>> > support flow mobility, or a trigger from the LMA to the MAG, s= o the MAG >>>>>>>>>> > can send a PBU and then follow your model. >>>>>>>>>> >>>>>>>>>> In the systems I know the MAG is the entity that creates attache= s a MN >>>>>>>>>> interface to a session and therefore I do not understand why you= would >>>>>>>>>> need the LMA to attach an interface to a session. The LMA has no >>>>>>>>>> interface with the interface... That's a MAG duty. >>>>>>>>>> >>>>>>>>>> In which system is the scenario you're outlining useful? >>>>>>>>> >>>>>>>>> I must be really bad at explaining this... >>>>>>>>> >>>>>>>>> Lets consider the following scenario: >>>>>>>>> >>>>>>>>> - MN attaches if1 to MAG1. As a result, if1 is attached to the se= ssion >>>>>>>>> with MAG1. Pref1::/64 is delegated to if1. >>>>>>>>> >>>>>>>>> - Later on, MN attaches if2 to MAG2. As a result if2 is attached = to the >>>>>>>>> session with MAG2. Pref2::/64 is delegated to if2. >>>>>>>>> >>>>>>>>> (nothing new so far, no flow mobility) >>>>>>>>> >>>>>>>>> - Some point in time later, LMA wants to move a flow X, addressed= to >>>>>>>>> pref2::/64 to if1. MAG1 cannot send a PBU at that particular mome= nt (how >>>>>>>>> can it know it has to?) to make MAG1 attach if1 to session with p= ref2. >>>>>>>>> Therefore, we need some signaling, initiated by the LMA, to make = that >>>>>>>>> flow movement happen. >>>>>>>>> >>>>>>>>> How can this scenario be supported with your approach? I fail to = see it. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Carlos >>>>>>>>> >>>>>>>> >>>>>>>> I think you still mis-understand Julien solution. >>>>>>>> >>>>>>>> Let's see the following scenario: >>>>>>>> >>>>>>>> Step1: if1 is attached to MAG1, session 1 is created: >>>>>>>> >>>>>>>> =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] >>>>>>>> >>>>>>>> Step2: if2 is attached to MAG2, session 2 is created: >>>>>>>> >>>>>>>> =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2] >>>>>>>> >>>>>>>> If we amuse that the MAG2 knows that IF2 and IF1 are hidden by a >>>>>>>> logical interface to support flow mobility -> MAGs send PBU messag= es >>>>>>>> to attaches IF1 to S2 and IF2 to S1. Then two sessions are updated= as >>>>>>>> follow: >>>>>>>> >>>>>>>> =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] >>>>>>>> =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2, IF1] >>>>>>>> >>>>>>>> After that flow can be moved freely without extra signaling messag= es >>>>>>>> in any-cases (eg. policy changes) >>>>>>>> >>>>>>>> My question to Julien is that: How can MAG1 know that Session 2 is >>>>>>>> created to attach IF1 to S2 in advance? >>>>>>> >>>>>>> I think the question is backward. The real question should be, if >>>>>>> there's an intent that flows bound to prefix2 be able to move betwe= en >>>>>>> if1 and if2, why on earth would session 2 be created without if1 >>>>>>> attached to it? I see no reason. >>>>>>> >>>>>> >>>>>> How can you create session 2 with IF1 without informing MAG1 about p= refix2? >>>>>> I think the attachment is completed only when MAG1 is received PBA >>>>>> message including Prefix2. But it needs PBU messages from MAG1 first= . >>>>> >>>>> Right so this what you do. If you want a session2 that allows to move >>>>> flows between if1 and if2, you attach both if1 and if2 to session2 >>>>> when the interfaces are brought up. >>>>> >>>>>> I sill do not understand how MAG1 can initiate PBU message to attach >>>>>> IF1 to session2. >>>>> >>>>> IF1 is brought up. There is a desire to have session2 encompassing >>>>> this interface. So, MAG1 sends a PBU to attach IF1 to session2. What >>>>> is complicated? >>>>> >>>> >>>> In the above scenario, the session 2 is created only after the IF2 is >>>> attached to MAG2. We can not attach IF1 to session 2 when it dose not >>>> exist. >>> >>> If session2 will at some point requires having flow sent to if1, why >>> can't session2 be created when if1 brought up? >>> >> >> Because the MAG1 can not know all prefix(es) that will be assigned to >> the sessions that will be created in the future. >> >> In the above example, MAG1 can not know that prefix2 will be assigned >> to session 2 when the IF2 is up. > > All I'm saying is, if at some point flows from session2 have to go on > interface1, you create session2 when interface1 or interface2 comes > up, whichever happens first. > Well, I have simpler questions. A new session can be created at any time, right? Now, assume that session N is created when interface1,2 are already working= . How to attach both interface 1 and 2 to the new session N? IMHO, when a new session is created for an interface, we need signaling messages to attach another working interfaces in the set to that new session. Thank you, TrungTM > --julien > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 From julien.ietf@gmail.com Mon Feb 7 23:12:12 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B460E3A7046 for ; Mon, 7 Feb 2011 23:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOuzVq39RwWb for ; Mon, 7 Feb 2011 23:11:50 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id CB7873A7040 for ; Mon, 7 Feb 2011 23:11:34 -0800 (PST) Received: by fxm9 with SMTP id 9so6150941fxm.31 for ; Mon, 07 Feb 2011 23:11:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UsBqogvYG/+CgoR/+3F7NaLLrqMzW/W6akAgD7mQOf4=; b=BQ+VFXzXlsqYUJDExLpdbLULxWg9CST0R5lFvS28bmUOGYUfN4rP/k5aY+cA9Or8ou QzZe+9bW7bvAZkhsNugPN0AEA1sE8ZDGn/w5kG7HyHRpjNvoo8WTqIqJGW3x5TX95KOn yiYY9xHYvMl7fLUQ+VLaMjRNa4CZENN7NjzfU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qgvqjhdWAp3qIYnhxkJc+t/rX86Wrh3v5XmkswSah1tUwoohU8R5UWRnJIq12kCK4t OemQvfaLtlVxK/YRcKX+ZcVVgKwq7OyWz+UcG3B4YlCG22tKsruZOCXb32oJ15MkO86l ULIQhKuVxav082c8TWK+1p1qAz/PDSips1V2A= MIME-Version: 1.0 Received: by 10.103.199.3 with SMTP id b3mr873830muq.93.1297149093829; Mon, 07 Feb 2011 23:11:33 -0800 (PST) Received: by 10.103.221.9 with HTTP; Mon, 7 Feb 2011 23:11:33 -0800 (PST) In-Reply-To: References: <1296920514.3773.26.camel@acorde.it.uc3m.es> <1297017501.4715.2.camel@acorde.it.uc3m.es> <1297019696.4715.5.camel@acorde.it.uc3m.es> <1297115574.3099.3.camel@acorde.it.uc3m.es> <1297126584.3099.96.camel@acorde.it.uc3m.es> Date: Mon, 7 Feb 2011 23:11:33 -0800 Message-ID: From: Julien Laganier To: Tran Minh Trung Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 07:12:12 -0000 On Mon, Feb 7, 2011 at 10:26 PM, Tran Minh Trung wr= ote: > On Tue, Feb 8, 2011 at 2:10 PM, Julien Laganier w= rote: >> On Mon, Feb 7, 2011 at 9:03 PM, Tran Minh Trung = wrote: >>> On Tue, Feb 8, 2011 at 1:12 PM, Julien Laganier = wrote: >>>> On Mon, Feb 7, 2011 at 5:51 PM, Tran Minh Trung wrote: >>>>> On Tue, Feb 8, 2011 at 10:41 AM, Julien Laganier wrote: >>>>>> On Mon, Feb 7, 2011 at 5:30 PM, Tran Minh Trung wrote: >>>>>>> On Tue, Feb 8, 2011 at 10:22 AM, Julien Laganier wrote: >>>>>>>> Hi Tran, >>>>>>>> >>>>>>>> On Mon, Feb 7, 2011 at 5:08 PM, Tran Minh Trung wrote: >>>>>>>>> Hi Carlos and Julien, >>>>>>>>> >>>>>>>>> 2011/2/8 Carlos Jes=FAs Bernardos Cano : >>>>>>>>>> Hi Julien, >>>>>>>>>> >>>>>>>>>> On Mon, 2011-02-07 at 15:56 -0800, Julien Laganier wrote: >>>>>>>>>>> Hi Carlos, >>>>>>>>>>> >>>>>>>>>>> 2011/2/7 Carlos Jes=FAs Bernardos Cano : >>>>>>>>>>> > Hi Julien, >>>>>>>>>>> > >>>>>>>>>>> > On Mon, 2011-02-07 at 12:43 -0800, Julien Laganier wrote: >>>>>>>>>>> >> Hi Carlos, >>>>>>>>>>> >> >>>>>>>>>>> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : >>>>>>>>>>> >> > Hi Julien, >>>>>>>>>>> >> > >>>>>>>>>>> >> > On Sun, 2011-02-06 at 10:56 -0800, Julien Laganier wrote: >>>>>>>>>>> >> >> Hi Carlos, >>>>>>>>>>> >> >> >>>>>>>>>>> >> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : >>>>>>>>>>> >> >> > Hi Julien, >>>>>>>>>>> >> >> > >>>>>>>>>>> >> >> > On Sun, 2011-02-06 at 10:11 -0800, Julien Laganier wrot= e: >>>>>>>>>>> >> >> >> 2011/2/5 Carlos Jes=FAs Bernardos Cano : >>>>>>>>>>> >> >> >> > On Fri, 2011-02-04 at 12:59 -0800, Julien Laganier w= rote: >>>>>>>>>>> >> >> >> >> On Fri, Feb 4, 2011 at 10:40 AM, Rajeev Koodli wrote: >>>>>>>>>>> >> >> >> >> > >>>>>>>>>>> >> >> >> >> > >>>>>>>>>>> >> >> >> >> > On 2/4/11 10:16 AM, "Julien Laganier" wrote: >>>>>>>>>>> >> >> >> >> > >>>>>>>>>>> >> >> >> >> >>> >>>>>>>>>>> >> >> >> >> >>> The LMA needs to provide the prefix info to the= MAG. This can be either in >>>>>>>>>>> >> >> >> >> >>> PBA or in FMI (if not provided in PBA). >>>>>>>>>>> >> >> >> >> >> >>>>>>>>>>> >> >> >> >> >> The LMA can provide the prefix to the MAG at ses= sion creation, i.e., >>>>>>>>>>> >> >> >> >> >> in the PBU. This information does not need to be= (re)conveyed at flow >>>>>>>>>>> >> >> >> >> >> movement. >>>>>>>>>>> >> >> >> >> > >>>>>>>>>>> >> >> >> >> > If it was conveyed in PBA, surely you don't recon= vey. >>>>>>>>>>> >> >> >> >> > If the prefix was not conveyed in PBA (as in the = example we discussed >>>>>>>>>>> >> >> >> >> > y'day), you provide it in FMI. >>>>>>>>>>> >> >> >> >> >>>>>>>>>>> >> >> >> >> IMO the prefix can always be conveyed in the PBA th= at is received in >>>>>>>>>>> >> >> >> >> response to the PBU attaching an interface to a PMI= Pv6 flow mobility >>>>>>>>>>> >> >> >> >> session. >>>>>>>>>>> >> >> >> > >>>>>>>>>>> >> >> >> > What about the following scenario: >>>>>>>>>>> >> >> >> > >>>>>>>>>>> >> >> >> > MN has two interfaces: if1 and if2. if1 attaches to = MAG1, a mobility >>>>>>>>>>> >> >> >> > session is created, pref1 is delegated. Some point i= n time later, if2 >>>>>>>>>>> >> >> >> > attaches to MAG2, new mobility sesison created, pref= 2 is delegated. >>>>>>>>>>> >> >> >> > flowX addressed to pref2 wants to be moved to if1. I= n this case we need >>>>>>>>>>> >> >> >> > some signaling from LMA to MAG1 that cannot be conve= ted in PBA. >>>>>>>>>>> >> >> >> >>>>>>>>>>> >> >> >> If flow X addresssed to pref2 wants to be moved to if1= , first thing to >>>>>>>>>>> >> >> >> do is to attach the if1 to the session corresponding t= o pref2, so MAG1 >>>>>>>>>>> >> >> >> sends a PBU, and LMA sends back a PBA with the prefix = set of the >>>>>>>>>>> >> >> >> session (pref2.) >>>>>>>>>>> >> >> > >>>>>>>>>>> >> >> > if1 was previously attached to MAG1 (and LMA delegated = pref1). How can >>>>>>>>>>> >> >> > MAG1 know when LMA wants to move flow X to if1 (to send= a PBU)? Some >>>>>>>>>>> >> >> > signaling is needed there. >>>>>>>>>>> >> >> >>>>>>>>>>> >> >> if1 was attached to MAG1 and had session S1 with prefix p= ref1. When >>>>>>>>>>> >> >> if2 is attached to MAG2, if a different prefix pref2 is a= llocated, >>>>>>>>>>> >> >> that is a different session S2. LMA cannot move a flow fr= om session S2 >>>>>>>>>>> >> >> to a MAG that isn't part of that session. So first thing = to do after >>>>>>>>>>> >> >> S2 is created, if there's a desire to move flows across o= ther MAGs, is >>>>>>>>>>> >> > >>>>>>>>>>> >> > Right, our draft uses FMI signalling to add if1 to the ses= sion (we use >>>>>>>>>>> >> > the flowmob cache structure of this purpose). We are discu= ssing about >>>>>>>>>>> >> > two ways of doing exactly the same thing. However, in your= s, you need >>>>>>>>>>> >> > the MAG to take the initiative, while ours also supports t= he LMA >>>>>>>>>>> >> > initiate the flow movement. >>>>>>>>>>> >> >>>>>>>>>>> >> You seem to be conflating session management and flow moveme= nt. >>>>>>>>>>> >> >>>>>>>>>>> >> In my approach, session management is MAG initiated, as it h= as been in >>>>>>>>>>> >> the past with PMIPv6. Once a session exists across an interf= ace set, >>>>>>>>>>> >> flow movement can be LMA-initiated at any time from one inte= rface in >>>>>>>>>>> >> the set to another. >>>>>>>>>>> >> >>>>>>>>>>> >> I do not see a reason to depart from RFC 5213 and allow the = LMA to >>>>>>>>>>> >> initiate session management (except for purposes of revocati= on but >>>>>>>>>>> >> that is supported already.) >>>>>>>>>>> > >>>>>>>>>>> > I see the reason to add it in order to support the scenarios = I mentioned >>>>>>>>>>> > in my example. Those cannot be supported with RFC5213 model, = as they >>>>>>>>>>> > require first the MAG to send a PBU. We need either new signa= ling from >>>>>>>>>>> > the LMA to the MAG to make the MAG aware of the required pref= ixes to >>>>>>>>>>> > support flow mobility, or a trigger from the LMA to the MAG, = so the MAG >>>>>>>>>>> > can send a PBU and then follow your model. >>>>>>>>>>> >>>>>>>>>>> In the systems I know the MAG is the entity that creates attach= es a MN >>>>>>>>>>> interface to a session and therefore I do not understand why yo= u would >>>>>>>>>>> need the LMA to attach an interface to a session. The LMA has n= o >>>>>>>>>>> interface with the interface... That's a MAG duty. >>>>>>>>>>> >>>>>>>>>>> In which system is the scenario you're outlining useful? >>>>>>>>>> >>>>>>>>>> I must be really bad at explaining this... >>>>>>>>>> >>>>>>>>>> Lets consider the following scenario: >>>>>>>>>> >>>>>>>>>> - MN attaches if1 to MAG1. As a result, if1 is attached to the s= ession >>>>>>>>>> with MAG1. Pref1::/64 is delegated to if1. >>>>>>>>>> >>>>>>>>>> - Later on, MN attaches if2 to MAG2. As a result if2 is attached= to the >>>>>>>>>> session with MAG2. Pref2::/64 is delegated to if2. >>>>>>>>>> >>>>>>>>>> (nothing new so far, no flow mobility) >>>>>>>>>> >>>>>>>>>> - Some point in time later, LMA wants to move a flow X, addresse= d to >>>>>>>>>> pref2::/64 to if1. MAG1 cannot send a PBU at that particular mom= ent (how >>>>>>>>>> can it know it has to?) to make MAG1 attach if1 to session with = pref2. >>>>>>>>>> Therefore, we need some signaling, initiated by the LMA, to make= that >>>>>>>>>> flow movement happen. >>>>>>>>>> >>>>>>>>>> How can this scenario be supported with your approach? I fail to= see it. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Carlos >>>>>>>>>> >>>>>>>>> >>>>>>>>> I think you still mis-understand Julien solution. >>>>>>>>> >>>>>>>>> Let's see the following scenario: >>>>>>>>> >>>>>>>>> Step1: if1 is attached to MAG1, session 1 is created: >>>>>>>>> >>>>>>>>> =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] >>>>>>>>> >>>>>>>>> Step2: if2 is attached to MAG2, session 2 is created: >>>>>>>>> >>>>>>>>> =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2] >>>>>>>>> >>>>>>>>> If we amuse that the MAG2 knows that IF2 and IF1 are hidden by a >>>>>>>>> logical interface to support flow mobility -> MAGs send PBU messa= ges >>>>>>>>> to attaches IF1 to S2 and IF2 to S1. Then two sessions are update= d as >>>>>>>>> follow: >>>>>>>>> >>>>>>>>> =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] >>>>>>>>> =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2, IF1] >>>>>>>>> >>>>>>>>> After that flow can be moved freely without extra signaling messa= ges >>>>>>>>> in any-cases (eg. policy changes) >>>>>>>>> >>>>>>>>> My question to Julien is that: How can MAG1 know that Session 2 i= s >>>>>>>>> created to attach IF1 to S2 in advance? >>>>>>>> >>>>>>>> I think the question is backward. The real question should be, if >>>>>>>> there's an intent that flows bound to prefix2 be able to move betw= een >>>>>>>> if1 and if2, why on earth would session 2 be created without if1 >>>>>>>> attached to it? I see no reason. >>>>>>>> >>>>>>> >>>>>>> How can you create session 2 with IF1 without informing MAG1 about = prefix2? >>>>>>> I think the attachment is completed only when MAG1 is received PBA >>>>>>> message including Prefix2. But it needs PBU messages from MAG1 firs= t. >>>>>> >>>>>> Right so this what you do. If you want a session2 that allows to mov= e >>>>>> flows between if1 and if2, you attach both if1 and if2 to session2 >>>>>> when the interfaces are brought up. >>>>>> >>>>>>> I sill do not understand how MAG1 can initiate PBU message to attac= h >>>>>>> IF1 to session2. >>>>>> >>>>>> IF1 is brought up. There is a desire to have session2 encompassing >>>>>> this interface. So, MAG1 sends a PBU to attach IF1 to session2. What >>>>>> is complicated? >>>>>> >>>>> >>>>> In the above scenario, the session 2 is created only after the IF2 is >>>>> attached to MAG2. We can not attach IF1 to session 2 when it dose not >>>>> exist. >>>> >>>> If session2 will at some point requires having flow sent to if1, why >>>> can't session2 be created when if1 brought up? >>>> >>> >>> Because the MAG1 can not know all prefix(es) that will be assigned to >>> the sessions that will be created in the future. >>> >>> In the above example, MAG1 can not know that prefix2 will be assigned >>> to session 2 when the IF2 is up. >> >> All I'm saying is, if at some point flows from session2 have to go on >> interface1, you create session2 when interface1 or interface2 comes >> up, whichever happens first. >> > > Well, I have simpler questions. > > A new session can be created at any time, right? > > Now, assume that session N is created when interface1,2 are already worki= ng. > How to attach both interface 1 and 2 to the new session N? L2 triggers, or policy profile update triggers both MAG1 and MAG2 to send PBU to attach if1 and if2 to a new session N. > IMHO, when a new session is created for an interface, we need > signaling messages to attach another working interfaces in the set to > that new session. --julien From trungtm2909@gmail.com Mon Feb 7 23:25:59 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29B9A3A7039 for ; Mon, 7 Feb 2011 23:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uo6GvrT0pBeX for ; Mon, 7 Feb 2011 23:25:57 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 59CE53A6AE3 for ; Mon, 7 Feb 2011 23:25:57 -0800 (PST) Received: by iwc10 with SMTP id 10so5968695iwc.31 for ; Mon, 07 Feb 2011 23:26:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TtqWu5cyQFVIbPfUXAmCjAun2NnHSwpg05Z8laerLPw=; b=lZpnIDHYcnCXSvNbWCY2MwJezfjXYm88vWwTfs6WqCc/QZH9fHPNFICXt25ggEDeK4 G3JwErQzkUXT5WJuMkHpjEJfSt8xI43cQyGSeDT8AdlxIh7RMPaJU+4O69t/4si0FSfC xxjjTk49ZUv0M6Cd5prDiCTmET3YTuv+ruDg8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pc6ENY7J2rXyoLtDXYLh6D5a0046bJGWxiT97FcJD6vV02Do3DRruG5dHp3NQtiQpl tHe2qjsytT1LPS05Um/vR395ozWdrbqeGoaZuDMMAL7ohmbHYxL6ALhMzfr3rbw9OHhZ JIgFLskcQtQ0KzYxgdoFXY3Rn9O0p0VO+jNIA= MIME-Version: 1.0 Received: by 10.42.220.8 with SMTP id hw8mr5879522icb.111.1297149962928; Mon, 07 Feb 2011 23:26:02 -0800 (PST) Received: by 10.42.171.4 with HTTP; Mon, 7 Feb 2011 23:26:02 -0800 (PST) In-Reply-To: References: <1296920514.3773.26.camel@acorde.it.uc3m.es> <1297017501.4715.2.camel@acorde.it.uc3m.es> <1297019696.4715.5.camel@acorde.it.uc3m.es> <1297115574.3099.3.camel@acorde.it.uc3m.es> <1297126584.3099.96.camel@acorde.it.uc3m.es> Date: Tue, 8 Feb 2011 16:26:02 +0900 Message-ID: From: Tran Minh Trung To: Julien Laganier Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 07:25:59 -0000 On Tue, Feb 8, 2011 at 4:11 PM, Julien Laganier wro= te: > On Mon, Feb 7, 2011 at 10:26 PM, Tran Minh Trung = wrote: >> On Tue, Feb 8, 2011 at 2:10 PM, Julien Laganier = wrote: >>> On Mon, Feb 7, 2011 at 9:03 PM, Tran Minh Trung = wrote: >>>> On Tue, Feb 8, 2011 at 1:12 PM, Julien Laganier wrote: >>>>> On Mon, Feb 7, 2011 at 5:51 PM, Tran Minh Trung wrote: >>>>>> On Tue, Feb 8, 2011 at 10:41 AM, Julien Laganier wrote: >>>>>>> On Mon, Feb 7, 2011 at 5:30 PM, Tran Minh Trung wrote: >>>>>>>> On Tue, Feb 8, 2011 at 10:22 AM, Julien Laganier wrote: >>>>>>>>> Hi Tran, >>>>>>>>> >>>>>>>>> On Mon, Feb 7, 2011 at 5:08 PM, Tran Minh Trung wrote: >>>>>>>>>> Hi Carlos and Julien, >>>>>>>>>> >>>>>>>>>> 2011/2/8 Carlos Jes=FAs Bernardos Cano : >>>>>>>>>>> Hi Julien, >>>>>>>>>>> >>>>>>>>>>> On Mon, 2011-02-07 at 15:56 -0800, Julien Laganier wrote: >>>>>>>>>>>> Hi Carlos, >>>>>>>>>>>> >>>>>>>>>>>> 2011/2/7 Carlos Jes=FAs Bernardos Cano : >>>>>>>>>>>> > Hi Julien, >>>>>>>>>>>> > >>>>>>>>>>>> > On Mon, 2011-02-07 at 12:43 -0800, Julien Laganier wrote: >>>>>>>>>>>> >> Hi Carlos, >>>>>>>>>>>> >> >>>>>>>>>>>> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : >>>>>>>>>>>> >> > Hi Julien, >>>>>>>>>>>> >> > >>>>>>>>>>>> >> > On Sun, 2011-02-06 at 10:56 -0800, Julien Laganier wrote: >>>>>>>>>>>> >> >> Hi Carlos, >>>>>>>>>>>> >> >> >>>>>>>>>>>> >> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano = : >>>>>>>>>>>> >> >> > Hi Julien, >>>>>>>>>>>> >> >> > >>>>>>>>>>>> >> >> > On Sun, 2011-02-06 at 10:11 -0800, Julien Laganier wro= te: >>>>>>>>>>>> >> >> >> 2011/2/5 Carlos Jes=FAs Bernardos Cano : >>>>>>>>>>>> >> >> >> > On Fri, 2011-02-04 at 12:59 -0800, Julien Laganier = wrote: >>>>>>>>>>>> >> >> >> >> On Fri, Feb 4, 2011 at 10:40 AM, Rajeev Koodli wrote: >>>>>>>>>>>> >> >> >> >> > >>>>>>>>>>>> >> >> >> >> > >>>>>>>>>>>> >> >> >> >> > On 2/4/11 10:16 AM, "Julien Laganier" wrote: >>>>>>>>>>>> >> >> >> >> > >>>>>>>>>>>> >> >> >> >> >>> >>>>>>>>>>>> >> >> >> >> >>> The LMA needs to provide the prefix info to th= e MAG. This can be either in >>>>>>>>>>>> >> >> >> >> >>> PBA or in FMI (if not provided in PBA). >>>>>>>>>>>> >> >> >> >> >> >>>>>>>>>>>> >> >> >> >> >> The LMA can provide the prefix to the MAG at se= ssion creation, i.e., >>>>>>>>>>>> >> >> >> >> >> in the PBU. This information does not need to b= e (re)conveyed at flow >>>>>>>>>>>> >> >> >> >> >> movement. >>>>>>>>>>>> >> >> >> >> > >>>>>>>>>>>> >> >> >> >> > If it was conveyed in PBA, surely you don't reco= nvey. >>>>>>>>>>>> >> >> >> >> > If the prefix was not conveyed in PBA (as in the= example we discussed >>>>>>>>>>>> >> >> >> >> > y'day), you provide it in FMI. >>>>>>>>>>>> >> >> >> >> >>>>>>>>>>>> >> >> >> >> IMO the prefix can always be conveyed in the PBA t= hat is received in >>>>>>>>>>>> >> >> >> >> response to the PBU attaching an interface to a PM= IPv6 flow mobility >>>>>>>>>>>> >> >> >> >> session. >>>>>>>>>>>> >> >> >> > >>>>>>>>>>>> >> >> >> > What about the following scenario: >>>>>>>>>>>> >> >> >> > >>>>>>>>>>>> >> >> >> > MN has two interfaces: if1 and if2. if1 attaches to= MAG1, a mobility >>>>>>>>>>>> >> >> >> > session is created, pref1 is delegated. Some point = in time later, if2 >>>>>>>>>>>> >> >> >> > attaches to MAG2, new mobility sesison created, pre= f2 is delegated. >>>>>>>>>>>> >> >> >> > flowX addressed to pref2 wants to be moved to if1. = In this case we need >>>>>>>>>>>> >> >> >> > some signaling from LMA to MAG1 that cannot be conv= eted in PBA. >>>>>>>>>>>> >> >> >> >>>>>>>>>>>> >> >> >> If flow X addresssed to pref2 wants to be moved to if= 1, first thing to >>>>>>>>>>>> >> >> >> do is to attach the if1 to the session corresponding = to pref2, so MAG1 >>>>>>>>>>>> >> >> >> sends a PBU, and LMA sends back a PBA with the prefix= set of the >>>>>>>>>>>> >> >> >> session (pref2.) >>>>>>>>>>>> >> >> > >>>>>>>>>>>> >> >> > if1 was previously attached to MAG1 (and LMA delegated= pref1). How can >>>>>>>>>>>> >> >> > MAG1 know when LMA wants to move flow X to if1 (to sen= d a PBU)? Some >>>>>>>>>>>> >> >> > signaling is needed there. >>>>>>>>>>>> >> >> >>>>>>>>>>>> >> >> if1 was attached to MAG1 and had session S1 with prefix = pref1. When >>>>>>>>>>>> >> >> if2 is attached to MAG2, if a different prefix pref2 is = allocated, >>>>>>>>>>>> >> >> that is a different session S2. LMA cannot move a flow f= rom session S2 >>>>>>>>>>>> >> >> to a MAG that isn't part of that session. So first thing= to do after >>>>>>>>>>>> >> >> S2 is created, if there's a desire to move flows across = other MAGs, is >>>>>>>>>>>> >> > >>>>>>>>>>>> >> > Right, our draft uses FMI signalling to add if1 to the se= ssion (we use >>>>>>>>>>>> >> > the flowmob cache structure of this purpose). We are disc= ussing about >>>>>>>>>>>> >> > two ways of doing exactly the same thing. However, in you= rs, you need >>>>>>>>>>>> >> > the MAG to take the initiative, while ours also supports = the LMA >>>>>>>>>>>> >> > initiate the flow movement. >>>>>>>>>>>> >> >>>>>>>>>>>> >> You seem to be conflating session management and flow movem= ent. >>>>>>>>>>>> >> >>>>>>>>>>>> >> In my approach, session management is MAG initiated, as it = has been in >>>>>>>>>>>> >> the past with PMIPv6. Once a session exists across an inter= face set, >>>>>>>>>>>> >> flow movement can be LMA-initiated at any time from one int= erface in >>>>>>>>>>>> >> the set to another. >>>>>>>>>>>> >> >>>>>>>>>>>> >> I do not see a reason to depart from RFC 5213 and allow the= LMA to >>>>>>>>>>>> >> initiate session management (except for purposes of revocat= ion but >>>>>>>>>>>> >> that is supported already.) >>>>>>>>>>>> > >>>>>>>>>>>> > I see the reason to add it in order to support the scenarios= I mentioned >>>>>>>>>>>> > in my example. Those cannot be supported with RFC5213 model,= as they >>>>>>>>>>>> > require first the MAG to send a PBU. We need either new sign= aling from >>>>>>>>>>>> > the LMA to the MAG to make the MAG aware of the required pre= fixes to >>>>>>>>>>>> > support flow mobility, or a trigger from the LMA to the MAG,= so the MAG >>>>>>>>>>>> > can send a PBU and then follow your model. >>>>>>>>>>>> >>>>>>>>>>>> In the systems I know the MAG is the entity that creates attac= hes a MN >>>>>>>>>>>> interface to a session and therefore I do not understand why y= ou would >>>>>>>>>>>> need the LMA to attach an interface to a session. The LMA has = no >>>>>>>>>>>> interface with the interface... That's a MAG duty. >>>>>>>>>>>> >>>>>>>>>>>> In which system is the scenario you're outlining useful? >>>>>>>>>>> >>>>>>>>>>> I must be really bad at explaining this... >>>>>>>>>>> >>>>>>>>>>> Lets consider the following scenario: >>>>>>>>>>> >>>>>>>>>>> - MN attaches if1 to MAG1. As a result, if1 is attached to the = session >>>>>>>>>>> with MAG1. Pref1::/64 is delegated to if1. >>>>>>>>>>> >>>>>>>>>>> - Later on, MN attaches if2 to MAG2. As a result if2 is attache= d to the >>>>>>>>>>> session with MAG2. Pref2::/64 is delegated to if2. >>>>>>>>>>> >>>>>>>>>>> (nothing new so far, no flow mobility) >>>>>>>>>>> >>>>>>>>>>> - Some point in time later, LMA wants to move a flow X, address= ed to >>>>>>>>>>> pref2::/64 to if1. MAG1 cannot send a PBU at that particular mo= ment (how >>>>>>>>>>> can it know it has to?) to make MAG1 attach if1 to session with= pref2. >>>>>>>>>>> Therefore, we need some signaling, initiated by the LMA, to mak= e that >>>>>>>>>>> flow movement happen. >>>>>>>>>>> >>>>>>>>>>> How can this scenario be supported with your approach? I fail t= o see it. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Carlos >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I think you still mis-understand Julien solution. >>>>>>>>>> >>>>>>>>>> Let's see the following scenario: >>>>>>>>>> >>>>>>>>>> Step1: if1 is attached to MAG1, session 1 is created: >>>>>>>>>> >>>>>>>>>> =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] >>>>>>>>>> >>>>>>>>>> Step2: if2 is attached to MAG2, session 2 is created: >>>>>>>>>> >>>>>>>>>> =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2] >>>>>>>>>> >>>>>>>>>> If we amuse that the MAG2 knows that IF2 and IF1 are hidden by a >>>>>>>>>> logical interface to support flow mobility -> MAGs send PBU mess= ages >>>>>>>>>> to attaches IF1 to S2 and IF2 to S1. Then two sessions are updat= ed as >>>>>>>>>> follow: >>>>>>>>>> >>>>>>>>>> =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] >>>>>>>>>> =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2, IF1] >>>>>>>>>> >>>>>>>>>> After that flow can be moved freely without extra signaling mess= ages >>>>>>>>>> in any-cases (eg. policy changes) >>>>>>>>>> >>>>>>>>>> My question to Julien is that: How can MAG1 know that Session 2 = is >>>>>>>>>> created to attach IF1 to S2 in advance? >>>>>>>>> >>>>>>>>> I think the question is backward. The real question should be, if >>>>>>>>> there's an intent that flows bound to prefix2 be able to move bet= ween >>>>>>>>> if1 and if2, why on earth would session 2 be created without if1 >>>>>>>>> attached to it? I see no reason. >>>>>>>>> >>>>>>>> >>>>>>>> How can you create session 2 with IF1 without informing MAG1 about= prefix2? >>>>>>>> I think the attachment is completed only when MAG1 is received PBA >>>>>>>> message including Prefix2. But it needs PBU messages from MAG1 fir= st. >>>>>>> >>>>>>> Right so this what you do. If you want a session2 that allows to mo= ve >>>>>>> flows between if1 and if2, you attach both if1 and if2 to session2 >>>>>>> when the interfaces are brought up. >>>>>>> >>>>>>>> I sill do not understand how MAG1 can initiate PBU message to atta= ch >>>>>>>> IF1 to session2. >>>>>>> >>>>>>> IF1 is brought up. There is a desire to have session2 encompassing >>>>>>> this interface. So, MAG1 sends a PBU to attach IF1 to session2. Wha= t >>>>>>> is complicated? >>>>>>> >>>>>> >>>>>> In the above scenario, the session 2 is created only after the IF2 i= s >>>>>> attached to MAG2. We can not attach IF1 to session 2 when it dose no= t >>>>>> exist. >>>>> >>>>> If session2 will at some point requires having flow sent to if1, why >>>>> can't session2 be created when if1 brought up? >>>>> >>>> >>>> Because the MAG1 can not know all prefix(es) that will be assigned to >>>> the sessions that will be created in the future. >>>> >>>> In the above example, MAG1 can not know that prefix2 will be assigned >>>> to session 2 when the IF2 is up. >>> >>> All I'm saying is, if at some point flows from session2 have to go on >>> interface1, you create session2 when interface1 or interface2 comes >>> up, whichever happens first. >>> >> >> Well, I have simpler questions. >> >> A new session can be created at any time, right? >> >> Now, assume that session N is created when interface1,2 are already work= ing. >> How to attach both interface 1 and 2 to the new session N? > > L2 triggers, or policy profile update triggers both MAG1 and MAG2 to > send PBU to attach if1 and if2 to a new session N. > Did you mean that the LMA sends L2 triggers to both MAG1 and MAG2? I am not sure it is valid assumption or not since creating a new session is occurred at L3 and it is L3 Job. I prefer to use extra signaling messages between LMA and MAGs as FMI/FMA in the current draft, or using HUR/HUA messages as pro-active signaling messages described in https://datatracker.ietf.org/doc/draft-trung-netext-flow-mobility-support/?= include_text=3D1 Regards, TrungTM >> IMHO, when a new session is created for an interface, we need >> signaling messages to attach another working interfaces in the set to >> that new session. > > --julien > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 From telemaco.melia@alcatel-lucent.com Tue Feb 8 02:55:48 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 198CC3A7109 for ; Tue, 8 Feb 2011 02:55:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSAOZMdXpEdG for ; Tue, 8 Feb 2011 02:55:47 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id DF11F3A6D95 for ; Tue, 8 Feb 2011 02:55:46 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p18Aqd60022716 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 8 Feb 2011 11:55:47 +0100 Received: from FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com ([135.120.45.54]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 8 Feb 2011 11:55:27 +0100 From: "MELIA, TELEMACO (TELEMACO)" To: "cjbc@it.uc3m.es" , Julien Laganier Date: Tue, 8 Feb 2011 11:55:26 +0100 Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvFSxZW2ZZz0+TKTbqWYBc+EPTRuwCM3bmw Message-ID: <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CFFD@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> References: <1296920511.3773.25.camel@acorde.it.uc3m.es> In-Reply-To: <1296920511.3773.25.camel@acorde.it.uc3m.es> Accept-Language: en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 10:55:48 -0000 > > The LMA needs to provide the prefix info to the MAG. This can be either= in > > PBA or in FMI (if not provided in PBA). >=20 > The LMA can provide the prefix to the MAG at session creation, i.e., > in the PBU. This information does not need to be (re)conveyed at flow > movement. If different prefixes are assigned for different sessions, and we want to move flows across interfaces, we need some kind of signaling to make the MAG aware of the prefixes. It cannot be done at session creation, since not all the interfaces necessarily attach simultaneously, Carlos Exactly, in the charter we say sequentially or simultaneously. We need to cover both cases. telemaco From yh21.han@gmail.com Tue Feb 8 03:00:32 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DEE23A710D for ; Tue, 8 Feb 2011 03:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KWY1S8sy6Au for ; Tue, 8 Feb 2011 03:00:31 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id C7BBD3A710B for ; Tue, 8 Feb 2011 03:00:30 -0800 (PST) Received: by wwa36 with SMTP id 36so6116641wwa.13 for ; Tue, 08 Feb 2011 03:00:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=zgm6Q6JtI2YbXJhEwZ/rC9K0yLxSqJtF61A4PetvGB0=; b=xfV+SP+h0JJY2q5jUlOvGb6V2VI77ykvH1M9uhIvbVethi6gLHxYHUTcR9Kd1Ux9lb uENAwkSr0Dl+inGw487g4tkzPDMab98niQX1WmREAe56ZJwelmwBSp/4s2ZYgdbLJMKC 2YUa5NZInt2SM2NRbqwQo91oTjpCNXQmclITE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=MliDLOM424jhP0+IC85P9cYq+hmZYT5+35eAO7bWpCiE77MI3Nzudh0/jaaqC3RUIj 9P6nN92Jak4f9QMKZZys1nItDBiQvO3a9BkhWJ5pqwBENW00wEtemkwVjmZgpjkvQMJF gXvlCSTHzpY/p/JKM1dELUSwzcFZwh9poelfI= Received: by 10.227.152.78 with SMTP id f14mr12015787wbw.86.1297162836654; Tue, 08 Feb 2011 03:00:36 -0800 (PST) Received: from USERPC ([220.68.82.28]) by mx.google.com with ESMTPS id u2sm2755021weh.12.2011.02.08.03.00.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 08 Feb 2011 03:00:35 -0800 (PST) From: "Youn-Hee Han" To: "'Julien Laganier'" , "'Rajeev Koodli'" References: In-Reply-To: Date: Tue, 8 Feb 2011 20:00:29 +0900 Message-ID: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIo/NBbQQqyeWpvtmcXp7I2XAzY+gJkMbtkAO4ljUKTImNb0A== Content-Language: ko Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 11:00:32 -0000 Hi Julien, > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf > Of Julien Laganier > Sent: Tuesday, February 08, 2011 1:38 PM > To: Rajeev Koodli > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos- > netext-pmipv6-flowmob as WG doc > > On Mon, Feb 7, 2011 at 6:15 PM, Rajeev Koodli wrote: > > > > If flow mobility has nothing do with prefix management, I am lost. > > No reason to be lost: Prefix management is how do I get prefix for the > MN. Flow mobility is how to I move flows across interfaces. The two > needs not to be intertwined together, as I've shown in my other notes. > E.g., I can do flow mobility without adding/deleting prefixes from > sessions, and vice versa. Yes, I agree with you. Flow mobility is how to move flows across interface. So, I thought that it would be better to define "a flow" exactly in netext WG prior to discuss flow mobility management. As the definition of "a flow", all I can think is a five-tuple plus something. If we assume that it is correct, I think that flow mobility and prefix addition are inevitably tied. As you know, RFC5213 (and IPv6 protocol spec) already allow to assign multiple prefixes across multiple interfaces of an MN. Yes, I also agree with you that in real-world (3GPP), there may be no need to assign multiple prefixes into an MN. (if somebody knows its necessity, please tell me when it should happen). So, flow mobility can be done without adding prefixes. However, different interfaces are allowed to be assigned different prefixes by RFC 5213 and IPv6 spec. We can't expect what kind of prefixes an MAG advertises. Therefore, sometimes, we need prefix addition to move a flow to a new interface of which MAG does not yet advertise the prefix of the flow being moved. (snip...) > >> I see no reason to depart from that in the context of extending the > >> protocol to support mobility, nor I am aware of any system > >> architecture that would require this capability. > > > > Okay, see your position. I see it differently. I don't need to be > > bound by some "presumed implementation model" of PMIP6 and limit > > myself *only* to a prefix assignment model you are imagining. > > It's not an implementation model, it is a protocol model, and it's not > imaginary. Implementation has nothing to do with this. > > There's no reason to extend prefix assignment model to do flow mobility > unless you can point me out in which real world context your scenario > actually happens. As I insisted in the old mail, I agree with Julien in this regard. Current draft allows too much space regarding the prefix allocation model (unique, shared, and hybrid). When a flow should be moved to a new interface and the prefix which the flow uses is not yet advertised by the new MAG, just inform the prefix to the MAG and thus make it advertise the prefix and setup the tunnel based on the new prefix. That's all!. If the prefix is already advertised by the MAG, there is nothing to do and just move the flow. This behaviors are very natural one when we want to support IP-level mobility. > >> If this is something really important, the WG can be rechartered to > >> work on a different extension that would allow adding/removing > >> prefixes from existing PMIPv6 sessions. > > > > Huh.. What in the current charter forces us not to have the LMA > > add/refresh/delete a prefix on-demand? > > Engineering is about finding a solution to a problem. Adding/deleting > prefix on-demand is not a solution to flow mobility. I've shown you how > to do flow mobility without this capability. >From the viewpoint of protocol, I think that at least, prefix addition to an interface is a necessary function to support flow mobility, as I explained above. But, it does not mean prefix addition should happen always whenever flow mobility occurs. It is sometimes needed. > Now a different engineering problem would be: how to add/delete prefixes > to a PMIPv6 session, and that would be useful for e.g. > renumbering. This is a different problem that we haven't been chartered > to work on. Prefix addition is just prefix addition. IMHO, renumbering is closer to prefix change. We just harness that function to support IP-level mobility. Youn-Hee From telemaco.melia@alcatel-lucent.com Tue Feb 8 03:23:33 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72D933A7116 for ; Tue, 8 Feb 2011 03:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.748 X-Spam-Level: X-Spam-Status: No, score=-5.748 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPdyji-Xc3+v for ; Tue, 8 Feb 2011 03:23:05 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 472553A7110 for ; Tue, 8 Feb 2011 03:23:04 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p18BMFW5024462 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 8 Feb 2011 12:23:03 +0100 Received: from FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com ([135.120.45.54]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 8 Feb 2011 12:22:51 +0100 From: "MELIA, TELEMACO (TELEMACO)" To: Stefano Faccin , Sri Gundavelli , "Giaretta, Gerardo" , stefano faccin Date: Tue, 8 Feb 2011 12:22:50 +0100 Thread-Topic: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLwmpURzmRlysrlUidlexdQorGZJPuBh2AgAAR4ICAAAzJgIAACkaAgADJ5gCAAKKGAP//oT5wgAEesLCAAAq77oAAADZggAC0szCAAI3PsIAF1g8g Message-ID: <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6D001@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> References: <680854867F7FD04BB9B06EB8ACA8D5AC05E1F0A3@XCH02DFW.rim.net> <680854867F7FD04BB9B06EB8ACA8D5AC05E1F0CB@XCH02DFW.rim.net> <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CC7E@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> <680854867F7FD04BB9B06EB8ACA8D5AC05E1F356@XCH02DFW.rim.net> In-Reply-To: <680854867F7FD04BB9B06EB8ACA8D5AC05E1F356@XCH02DFW.rim.net> Accept-Language: en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_006_3D6C64F2D792B540BAAEBCEF6509363B0EE6D6D001FRMRSSXCHMBSE_"; type="multipart/alternative" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 11:23:33 -0000 --_006_3D6C64F2D792B540BAAEBCEF6509363B0EE6D6D001FRMRSSXCHMBSE_ Content-Type: multipart/alternative; boundary="_000_3D6C64F2D792B540BAAEBCEF6509363B0EE6D6D001FRMRSSXCHMBSE_" --_000_3D6C64F2D792B540BAAEBCEF6509363B0EE6D6D001FRMRSSXCHMBSE_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Stefano, We agree that the solution has to have a customer, no need to convince me. = All what I am saying is that there are other methods to solve the ESSID iss= ue, for instance considering WIFI as trusted access. As you are well aware = some vendors are already offering solutions. In my opinion this is orthogonal to the current discussions on the list. My 2 cents telemaco ________________________________ De : Stefano Faccin [mailto:sfaccin@rim.com] Envoy=E9 : vendredi 4 f=E9vrier 2011 19:15 =C0 : MELIA, TELEMACO (TELEMACO); Sri Gundavelli; Giaretta, Gerardo; stefan= o faccin Cc : netext@ietf.org; Basavaraj.Patil@nokia.com Objet : RE: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmi= pv6-flowmob as WG doc Telemaco, I apologize if I fail to make my point. I am just trying to see how this solution can get applied to a realistic ca= se. I guess we want to design a protocol that solves issues and provides a = tool for realistic use cases, I hope? If so, my point is that we have open = issues on how this protocol will be used in those cases. Now, we also want = to develop a protocol that has a customer, correct? Not just have an academ= ic exercise, correct? If so, it has been said previously on this ML that 3G= PP is the biggest potential customer for this work (if there are others I m= ust have missed the emails indicating what other customers are out there). = So, if we want to make this applicable to 3GPP, it means it will go in futu= re releases of 3GPP, obviously. Which means it needs to support what is alr= eady supported in current releases, otherwise you are proposing a solution = that steps backwards in time in terms of what it can support. As for the use cases I have provided (i.e. per access network versus per ac= cess technology), I have not heard any real use case confuting the relevanc= e of the use cases, but just what this protocol cannot do to support them, = which concerns me. Cheers, Stefano Faccin Standards Manager Research In Motion Corporation 5000 Riverside Drive Building 6, Brazos East, Ste. 100 Irving, Texas 75039 USA Office: (972) 910 3451 Internal: 820.63451 [cid:image001.jpg@01CBC78A.E6FA51D0]: (510) 230 8422 www.rim.com; www.blackberry.com [cid:image002.jpg@01CBC78A.E6FA51D0] P Consider the environment before printing. From: MELIA, TELEMACO (TELEMACO) [mailto:telemaco.melia@alcatel-lucent.com] Sent: Friday, February 04, 2011 1:49 AM To: Stefano Faccin; Sri Gundavelli; Giaretta, Gerardo; stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: RE: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pm= ipv6-flowmob as WG doc Stefano, all, I believe the authors of the draft never intended to replicate all the feat= ures of the client based approach. In addition to this I fail to see why we should spend so much time in discu= ssing the WLAN ESSID issue. Of course we can debate about trusted/untrusted= access but I think this is orthogonal to the PMIP flow mobility discussion= . If not can you please explain? telemaco ________________________________ De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part de= Stefano Faccin Envoy=E9 : vendredi 4 f=E9vrier 2011 00:02 =C0 : Sri Gundavelli; Giaretta, Gerardo; stefano faccin Cc : netext@ietf.org; Basavaraj.Patil@nokia.com Objet : Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pm= ipv6-flowmob as WG doc Sri, I am glad to hear that you also think that the network-based flow mobility = solution cannot intrinsically provide all the features of the client-based = approach. I am also glad that you hear that access selection solutions in place today= are sci-fi. Why do you believe that an operator that wants e.g. to move th= e voice traffic and video streaming to the WLAN APs it deploys (because it = can offload them and can control QoS) may not want to move the same flows t= o a WLAN in a hotel where the user will get an awful user experience? Anoth= er example: policies may be configured by an enterprise in the device so th= at the enterprise will allow the MN to direct some traffic on certain WLAN = APs (e.g. the one the enterprise deploys) but not on other WLAN APs. I thin= k the per-access network scenarios are indeed more than realistic. Perhaps = we're trying to oversimplify the scenarios just to fit the solution in them= ? Stefano Faccin Standards Manager Research In Motion Corporation 5000 Riverside Drive Building 6, Brazos East, Ste. 100 Irving, Texas 75039 USA Office: (972) 910 3451 Internal: 820.63451 [cid:image001.jpg@01CBC78A.E6FA51D0]: (510) 230 8422 www.rim.com; www.blackberry.com [cid:image003.jpg@01CBC78A.E6FA51D0] P Consider the environment before printing. From: Sri Gundavelli [mailto:sgundave@cisco.com] Sent: Thursday, February 03, 2011 2:56 PM To: Stefano Faccin; Giaretta, Gerardo; stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-p= mipv6-flowmob as WG doc Hi Stefano, My point on the synchronized policy assumption still remains, as I've noted= in the other thread. Therefore, if we want to provide a protocol for network based flow mobility= to provide an alternative to existing solutions, we need to provide a solu= tion that realistically provides the same functionality. I will probably take a defensive stand on this. As I've stated before, I do= not believe network-based mobility approaches can match client based appro= aches 1:1, in every aspect. Its simply not possible, specially when we don'= t have the needed MN-AR interface argument, for carrying Attachment Prefere= nces. But, most of the features that are practical from deployment perspect= ive (unlike some of the complex flow mobility scenarios, complexity in the = order of science fiction moves :)), every thing else can be achieved over n= etwork-based approaches, with out any MN-AR interface. Hence, my argument t= o keep the specs simple As as for simplified policies versus what current solutions already provide= (e.g. per access network policy and not just per access technology), why s= hould we go ahead with a solution that brings us back in time wrt what we c= an provide to users and operators? Please note that even today (and not jus= t future releases of 3GPP or future IETF protocols) there are deployment sc= enarios where the decisions to choose or not whether to route traffic over = a certain WLAN is based on the specific WLAN (e.g. SSID) and not just on th= e fact that the MN is connected to WLAN. To large part, in the context of trusted non-3GPP access, basic flow mobili= ty functions can be supported. We can break this down and bring some of the= aspects around network ownership, cost parameters and tie the flow policy = rules to it. But, I don't think the goal is to support all such features. Regards Sri On 2/3/11 2:22 PM, "Stefano Faccin" wrote: Hi Sri, I need to agree with the Gerardo. You are making an assumption that is inco= rrect.Synchronizing policies between the MN and the LMA is not an easy and = scalable solution. I understand synchronizing policies between a MN and a p= olicy server that is the only repository for a given MN (i.e. one MN has it= s policy in a single policy server). Assuming that all the LMAs in a networ= k that the MN can be connected to have synchronized policies with the MN is= clearly not realistic. As as for simplified policies versus what current solutions already provide= (e.g. per access network policy and not just per access technology), why s= hould we go ahead with a solution that brings us back in time wrt what we c= an provide to users and operators? Please note that even today (and not jus= t future releases of 3GPP or future IETF protocols) there are deployment sc= enarios where the decisions to choose or not whether to route traffic over = a certain WLAN is based on the specific WLAN (e.g. SSID) and not just on th= e fact that the MN is connected to WLAN. Therefore, if we want to provide a protocol for network based flow mobility= to provide an alternative to existing solutions, we need to provide a solu= tion that realistically provides the same functionality. Cheers, Stefano Faccin Standards ManagerResearch In Motion Corporation 5000 Riverside Drive Building 6, Brazos East, Ste. 100Irving, Texas 75039 USA Office: (972) 910 3451 Internal: 820.63451[cid:image001.jpg@01CBC78A.E6FA5= 1D0]: (510) 230 8422www.rim.com ; www.blackberry.com [cid:image003.jpg@01CBC78A.E6FA51D0] P Consider the environment before printing. From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of= Giaretta, Gerardo Sent: Wednesday, February 02, 2011 9:14 PM To: Sri Gundavelli; stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-p= mipv6-flowmob as WG doc Hi Sri, There is no implicit assumption of synchronized policies. A basic example t= hat shows that there is no assumption is the following: ANDSF policies may = be based also on location of the UE. For example the UE should prefer WLAN = only in a given location. When the UE is attached over WLAN there is no way= for the PDNGW/HA to verify the location of the UE and therefore to verify = UE actions based on policies. The assumption on synchronization of policies is only applicable to this dr= aft and I think it is a wrong one. Cheers Gerardo From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of= Sri Gundavelli Sent: Wednesday, February 02, 2011 6:50 PM To: stefano faccin Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-p= mipv6-flowmob as WG doc Hi Stefano, One comment. Agree with you there is no ANDSF interface to the network node, but the ass= umption of synchronized policies between the ANDSF server and the PDN GW/HA= is there, implicitly IMO. With out this assumption, I do not know, how the= HA can ever validate the flow mobility options received in the BU. If the = operator requires any control on enforcing a flow policy rule, the PDN GW/H= A needs to have synchronized policies, without which its always the client = decision. I'm not sure, operators in 3GPP would like that :) No doubt, the lack of MN-AR interface is surely an issue for supporting com= plex flow policies. I realize the issues and I agree with you. But, the ass= umption of synchronized policies can offer some solution with some configur= ation requirement on the HA (assuming there are no other issues). There are= also the proposals on flow mirroring on the UE ..., requiring no flow poli= cies. I've not evaluated this, however. Folks can comment on this. It is also to be noted, for some of the scenarios such, there is no flow po= licy interface needed. We can identify what scenarios create any configurat= ion limitations on the HA and which one's do not . As I've noted earlier, t= his is surely an open issue, that we need to discuss in the WG. Regards Sri On 2/2/11 9:08 AM, "stefano faccin" wrote: Sri, thanks for the reply. Can you clarify in which system or scenario ANDSF is = available to network entities as well? There is no such availability in 3GP= P, and making such information available would require considerable archite= ctural changes, therefore the applicability of this solution to what seems = to be the only realistic scenario hinges on 3GPP making considerable archit= ectural changes. I would therefore not be so hastily concluding that the AN= DSF information is available to the LMA and underestimate what it would rea= lly take to make the solution applicable. If we cannot guarantee that there is at least one realistic solution to hav= e the MNa nd LMA in synch, how do we expect that this solution is applicabl= e at all? In 3GPP there is no need to have such implicit assumption, be cau= se 1) the MN is provided policies explicitly through the ANDSF, and 2) it i= s the MN and only the MN that makes IP flow mobility decisions and communic= ates them explicitly (with well defined signalling) to the LMA, and therefo= re no magic is needed. There is no need in 3GPP to have the ANDSF and PDN G= W policies synchronized, since the PDN GW does not use such policies. Sri, in the end it is a matter of whether we develop a solution that will r= ely on some unknown magic to be deployed, or a solution that we know can be= deployed in at least one way because there are solutions to what I conside= r major open issues. Cheers, Stefano On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli wrote: Hi Stefano, Thanks for the discussion. As you say, the ANDSF policies are allowing the MN a.) to make the right ne= twork attachment decision and b.) make the access selection on a flow basis= . This same policy that is present in the ANDSF server, is available for th= e network nodes as well. I'm not sure, with out this assumption the solutio= n can work for all currently listed cases. We clearly need the MN and the L= MA to be in synch with respect to the configured policy. How, that is done,= I guess we will not try to know. I thought even in 3GPP, this is the impl= ied assumption ? But, this is for you to clarify. Not specifically for IFOM= where UE and PDN GW/HA are negotiating the flow policies, but generally th= at the PDN GW and the ANDSF policy server will have synchronized policies. = The MAG and the LMA have the ability to carry this flow policy information = in signaling messages and influence the access selection. The policy is a o= paque object, with extensible formats, when carried in the signaling plane,= should allow the LMA/MAG to apply those access policies, while assuming MN= is following the same rules. These policies can surely reflect the specifi= c WLAN access/operator specific rule. I'm surely with you, the lack of MN-A= R interface is surely an issue and I see that. But, we need to understand, = what are the limitations with the approach of out of band policy interface= s and what will be the solution limitations. If we need to tie the flow mov= ement at the prefix granularity and rely on the natural ND interface in the= form of RA PIO option, more like PDN offload in MAPCON, or at the granular= ity of a flow level, is open for discussion. I want to simplify this draft = for sure, we can surely discuss each of these issues on the WG draft. Regards Sri On 2/1/11 8:29 PM, "stefano faccin" > wrote: Sri, thanks for the reply. I'd like to comment on the "the flow policy decisions need not be based on = the specific WLAN network". Does it mean, as I believe it does, that the cu= rrent solution would not allow an operator deploying such solution to decid= e to route flows over a specific WLAN or not depending on which specific WL= AN the MN is connected to? E.g. the operator or the entity in control of th= e decisions for the routing may want to direct certain traffic always over = WLANs that the operator deploys, and instead route only some of the traffic= over WLANs of roaming partners or of the MN user home. How does this solut= ion support that scenario if the LMA is not told specifically which WLAN th= e MN is connected to? From a deployment point of view, I do not believe we = can afford to leave out this scenario. Please note that the establishment o= f a security relationship between the MN and the MAG, and a specific MAG id= entity, cannot guarantee that the LMA knows which specific WLAN access netw= ork the MN is connected to. Assuming that would severely restrict the deplo= yment scenarios. As for the MN and the LMA being magically in synch, I am very concerned abo= ut a "glass ball" solution. You mention ANDSF defined by 3GPP as a solution= for this "out of band" delivery of policy. Fair enough, however there is a= n issue with that. ANDSF is designed specific to be a MN-centric solution w= here policies are provisioned in the MN and the MN decides which network te= chnologies and access networks it needs to connect to, under what condition= s, and which IP traffic needs to be routed on such accesses. No IP point of= attachment in the network (i.e. the PDN GW in 3GPP that is the LMA in PMIP= v6) is aware under any conditions of such policy. Therefore, even if in ord= er to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would unfor= tunately not provide a solution unless the MN can communicate to the MAG an= d the LMA the decisions the MN has taken based on the ANDSF policies. I believe the key point here is that we need to understand how the solution= can be realistically applied to a real scenario, and that we need to ensur= e that important and realistic deployment scenarios are not excluded by the= solution. Cheers, Stefano On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli > wrote: Hi Stefano: These are valid points and some good comments. Let me share my thoughts. Carlo's draft is not assuming any new MN-AR interface. Its going with the a= ssumption there is established policy on the mobile and on the LMA, which a= llows the mobile to select the access network at a flow level granularity, = without requiring any explicit signaling between the MAG and the MN. To lar= ge part this is all about out of band policy interface, such as ANDSF, towa= rds the UE, leading to the assumption that magically the MN and the LMA are= in sync with respect to flow policies, access selection and they will make= the right forwarding decision. Secondly, the flow policy decisions need no= t be based on the specific WLAN network, but it is implicitly driven by the= MAG - LMA security relation, where the MAG attachment to the WLAN network = transitively allows the LMA to make the flow policy decisions based on the = MAG identity. If the WLAN network is not trusted, there is truly no MAG in = that network, where the LMA shares a security relation with that node. There are still some open issues on this draft that needs to be discussed i= n the WG. On the approaches to allow more a flow aggregate movement, that = is a discussion point. There are issues that we need to discuss, supporting= split link model, or eliminating some favorite brand of signaling message = (FMA) and riding on PBU/PBA and just with one FMI trigger, and on the aspec= ts around MN applying the flow policies by flow mirroring. We have no agree= ment on those issues yet. Its just a base draft, for further discussion and resolving those issues. B= ut, hope that is not a stopper for base draft selection. Sri On 2/1/11 6:39 PM, "stefano faccin" > wrote: Raj, thanks for the email. I need to apologize in advance if my questions have already been answered b= efore (though I cannot find a conclusive answer anywhere). I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability. In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicat= e to the network where the flows should be routed or for the LMA to receive= somehow from somewhere some policies, the solution cannot really provide f= low mobility since there is no way to decide which flows are routed where. = If we are thinking about a host-based solution, I have not yet seen a solut= ion as to how the host can indicate to the MAG and ultimately to the MAG wh= ich flows should be routed on each access. If we are relying on modificatio= ns of layer 2 protocols, aren't we defining a solution that works only with= some technologies (since for other access technologies it is rather unreal= istic to modify L2 for IP flow mobility purposes)? If we are thinking of an= LMA-based solution, can we hear of at least one example of a real-life sce= nario where the LMA would receive such policies, and how such delivery woul= d happen? Also, should there be a solution to have policies in the LMA, how= does the LMA actually decide to route flows on one access or the other? E.= g., if some flows need to be routed on certain WLAN networks, but shall not= be routed on other WLAN networks, how does the LMA know which specific WLA= N network the host is connected to? Perhaps I missed the ability for the MA= G to know e.g. the WLAN SSID and provide it to the LMA, in which case I wou= ld appreciate if somebody could highlight to me where that is defined. I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important. Cheers, Stefano On Tue, Feb 1, 2011 at 3:47 PM, > wrote: Hello, We have discussed the flow mobility solutions for Proxy MIP6 previously at IETFs 78 and 79. This is a consensus call for adopting this I-D: draft-bernardos-netext-pmipv6-flowmob-02 as the working group document. I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt The consensus call will expire on Feb 15th, 2011. Please indicate your support or concerns in adopting this I-D as the WG baseline document on the mailing list. Please note that this I-D will serve as the baseline in the WG and will be developed further based on input and feedback from WG members. -Basavaraj _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --_000_3D6C64F2D792B540BAAEBCEF6509363B0EE6D6D001FRMRSSXCHMBSE_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

Hi Stefano,=

 =

We agree th= at the solution has to have a customer, no need to convince me. All what I am sayi= ng is that there are other methods to solve the ESSID issue, for instance considering WIFI as trusted access. As you are well aware some vendors are = already offering solutions.

In my opini= on this is orthogonal to the current discussions on the list.

 =

My 2 cents<= o:p>

telemaco

 =

De : Stefano = Faccin [mailto:sfaccin@rim.com]
Envoy=E9 : vendredi 4 f= =E9vrier 2011 19:15
=C0 : MELIA, TELEMACO (TELEMACO); Sri Gundavelli; Giaretta, Gerardo; stefano faccin
Cc : netext@ietf.org; Basavaraj.Patil@nokia.com
Objet : RE: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc=

 

Telemaco,=

I apologize if= I fail to make my point.

 

I am just tryi= ng to see how this solution can get applied to a realistic case. I guess we want = to design a protocol that solves issues and provides a tool for realistic use cases, I hope? If so, my point is that we have open issues on how this prot= ocol will be used in those cases. Now, we also want to develop a protocol that h= as a customer, correct? Not just have an academic exercise, correct? If so, it h= as been said previously on this ML that 3GPP is the biggest potential customer= for this work (if there are others I must have missed the emails indicating wha= t other customers are out there). So, if we want to make this applicable to 3= GPP, it means it will go in future releases of 3GPP, obviously. Which means it n= eeds to support what is already supported in current releases, otherwise you are proposing a solution that steps backwards in time in terms of what it can support.

 

As for the use= cases I have provided (i.e. per access network versus per access technology), I h= ave not heard any real use case confuting the relevance of the use cases, but j= ust what this protocol cannot do to support them, which concerns me.

Cheers,

 

Stefano Facc= in

 <= /o:p>

Standards Ma= nager

Research In Motion Corporation
5000 Riverside Drive
Building 6, Brazos East, Ste. 100

Irving, Texas = 75039 USA
Office: (972) 910 3451 

Internal: 820.= 63451

3DUntitled-1: (510) 230 8422

www.rim.com; www.blackberry.com

 

3D"cid:image004.png@01CB49EA.87D92140"=

 

P Consider the environment before printing.

 

From:= MELIA, TELEMACO (TELEMACO) [mailto:telemaco.melia@alcatel-lucent.com]
Sent: Friday, February 04, 2= 011 1:49 AM
To: Stefano Faccin; Sri Gundavelli; Giaretta, Gerardo; stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: RE: [netext] Consen= sus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc

 

Stefano, al= l,

 =

I believe t= he authors of the draft never intended to replicate all the features of the cl= ient based approach.

 =

In addition= to this I fail to see why we should spend so much time in discussing the WLAN ESSID issue. Of course we can debate about trusted/untrusted access but I t= hink this is orthogonal to the PMIP flow mobility discussion. If not can you ple= ase explain?

 =

telemaco

De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part de Stefano Faccin
Envoy=E9 : vendredi 4 f= =E9vrier 2011 00:02
=C0 : Sri Gundavelli; G= iaretta, Gerardo; stefano faccin
Cc : netext@ietf.org; Basavaraj.Patil@nokia.com
Objet : Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG do= c

 

Sri,

I am glad to h= ear that you also think that the network-based flow mobility solution cannot intrinsically provide all the features of the client-based approach. <= /o:p>

 

I am also glad= that you hear that access selection solutions in place today are sci-fi. Why do = you believe that an operator that wants e.g. to move the voice traffic and vide= o streaming to the WLAN APs it deploys (because it can offload them and can control QoS) may not want to move the same flows to a WLAN in a hotel where= the user will get an awful user experience? Another example: policies may be configured by an enterprise in the device so that the enterprise will allow= the MN to direct some traffic on certain WLAN APs (e.g. the one the enterprise deploys) but not on other WLAN APs. I think the per-access network scenario= s are indeed more than realistic. Perhaps we’re trying to oversimplify = the scenarios just to fit the solution in them?

 

Stefano Facc= in

 <= /o:p>

Standards Ma= nager

Research In Motion Corporation
5000 Riverside Drive
Building 6, Brazos East, Ste. 100

Irving, Texas = 75039 USA
Office: (972) 910 3451 

Internal: 820.= 63451

3DUntitled-1: (510) 230 8= 422

www.rim.com; www.blackberry.com

 

3D"cid:image004.png@01CB49EA.87D92140"=

 

P Consider the environment before printing.

 

From:= Sri Gundavelli [mailto:sgundave@cisco.com]
Sent: Thursday, February 03,= 2011 2:56 PM
To: Stefano Faccin; Giaretta= , Gerardo; stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consen= sus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

 

Hi Stefano,

My point on the synchronized policy assumption still remains, as I’ve= noted in the other thread.

Therefore, if we want= to provide a protocol for network based flow mobility to provide an alternativ= e to existing solutions, we need to provide a solution that realistically provid= es the same functionality.

I will probably take a defensive stand on this. As I’ve stated before= , I do not believe network-based mobility approaches can match client based approaches 1:1, in every aspect. Its simply not possible, specially when we don’= t have the needed MN-AR interface argument, for carrying Attachment Preferences. But, = most of the features that are practical from deployment perspective (unlike some= of the complex flow mobility scenarios, complexity in the order of science fic= tion moves :)), every thing else can be achieved over network-based approaches, = with out any MN-AR interface. Hence, my argument to keep the specs simple
 
As as for simplified = policies versus what current solutions already provide (e.g. per access network poli= cy and not just per access technology), why should we go ahead with a solution that brings us back in time wrt what we can provide to users and operators? Please note that even today (and not just future releases of 3GPP or future IETF protocols) there are deployment scenarios where the decisions t= o choose or not whether to route traffic over a certain WLAN is based on the specific WLAN (e.g. SSID) and not just on the fact that the MN is connected= to WLAN.

To large part, in the context of trusted non-3GPP access, basic flow mobili= ty functions can be supported. We can break this down and bring some of the aspects around network ownership, cost parameters and tie the flow policy r= ules to it. But, I don’t think the goal is to support all such features.


Regards
Sri



On 2/3/11 2:22 PM, "Stefano Faccin" <sfaccin@rim.com> wrote:

Hi Sri,
I need to agree with the Gerardo. You are making an assumption that is incorrect.Synchronizing policies between the MN and the LMA is not an easy = and scalable solution. I understand synchronizing policies between a MN and a policy server that is the only repository for a given MN (i.e. one MN has i= ts policy in a single policy server). Assuming that all the LMAs in a network = that the MN can be connected to have synchronized policies with the MN is clearl= y not realistic.

As as for simplified policies versus what current solutions already provide (e.g. per access network policy and not just per access technology), why sh= ould we go ahead with a solution that brings us back in time wrt what we can pro= vide to users and operators? Please note that even today (and not just fu= ture releases of 3GPP or future IETF protocols) there are deployment scenarios w= here the decisions to choose or not whether to route traffic over a certain WLAN= is based on the specific WLAN (e.g. SSID) and not just on the fact that the MN= is connected to WLAN.
 
Therefore, if we want to provide a protocol for network based flow mobility= to provide an alternative to existing solutions, we need to provide a solution that realistically provides the same functionality.
 
Cheers,
 
Stefano Faccin Standards ManagerResearch In Motion Corporation
5000 Riverside Drive
Building 6, Brazos East, Ste. 100Irving, Texas 75039 USA
Office: (972) 910 3451  Internal: 820.63451= : (510) 230 8422www.rim.com <outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D41= 49BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1= BEA0000/www.rim.com> ; www.blackberry.com <outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F0= 6753D40D4149BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3= E0000006F1BEA0000/www.blackberry.com>
= <http://www.blackber= ry.com/>

P Consider the environment before printing.


From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org]= On Behalf Of Giaretta, Gerardo
Sent: Wednesday, February 02= , 2011 9:14 PM
To: Sri Gundavelli; stefano = faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consen= sus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

Hi Sri,
 
There is no implicit assumption of synchronized policies. A basic example t= hat shows that there is no assumption is the following: ANDSF policies may be b= ased also on location of the UE. For example the UE should prefer WLAN only in a given location. When the UE is attached over WLAN there is no way for the PDNGW/HA to verify the location of the UE and therefore to verify UE action= s based on policies.
 
The assumption on synchronization of policies is only applicable to this dr= aft and I think it is a wrong one.
 
Cheers
Gerardo
 

From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org]= On Behalf Of Sri Gundavelli
Sent: Wednesday, February 02= , 2011 6:50 PM
To: stefano faccin
Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
Subject: Re: [netext] Consen= sus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

Hi Stefano,

One comment.

Agree with you there is no ANDSF interface to the network node, but the assumption of synchronized policies between the ANDSF server and the PDN GW= /HA is there, implicitly IMO. With out this assumption, I do not know, how the = HA can ever validate the flow mobility options received in the BU. If the oper= ator requires any control on enforcing a flow policy rule, the PDN GW/HA needs t= o have synchronized policies, without which its always the client decision. I= ’m not sure, operators in 3GPP would like that :)

No doubt, the lack of MN-AR interface is surely an issue for supporting com= plex flow policies. I realize the issues and I agree with you. But, the assumpti= on of synchronized policies can offer some solution with some configuration requirement on the HA (assuming there are no other issues). There are also = the proposals on flow mirroring on the UE ..., requiring no flow policies. I= 217;ve not evaluated this, however. Folks can comment on this.

It is also to be noted, for some of the scenarios such, there is no flow po= licy interface needed. We can identify what scenarios create any configuration limitations on the HA and which one’s do not . As I’ve noted ea= rlier, this is surely an open issue, that we need to discuss in the WG.



Regards
Sri




 


On 2/2/11 9:08 AM, "stefano faccin" <sfaccinstd@gmail.com> wrote:
Sri,
thanks for the reply. Can you clarify in which system or scenario ANDSF is available to network entities as well? There is no such availability in 3GP= P, and making such information available would require considerable architectu= ral changes, therefore the applicability of this solution to what seems to be t= he only realistic scenario hinges on 3GPP making considerable architectural changes. I would therefore not be so hastily concluding that the ANDSF information is available to the LMA and underestimate what it would really = take to make the solution applicable.

If we cannot guarantee that there is at least one realistic solution to hav= e the MNa nd LMA in synch, how do we expect that this solution is applicable = at all? In 3GPP there is no need to have such implicit assumption, be cause 1)= the MN is provided policies explicitly through the ANDSF, and 2) it is the MN a= nd only the MN that makes IP flow mobility decisions and communicates them explicitly (with well defined signalling) to the LMA, and therefore no magi= c is needed. There is no need in 3GPP to have the ANDSF and PDN GW policies synchronized, since the PDN GW does not use such policies.

Sri, in the end it is a matter of whether we develop a solution that will r= ely on some unknown magic to be deployed, or a solution that we know can be dep= loyed in at least one way because there are solutions to what I consider major op= en issues.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli <sgundave@cisco.com> wrote:
Hi Stefano,

Thanks for the discussion.

As you say, the ANDSF policies are allowing the MN a.) to make the right network attachment decision and b.) make the access selection on a flow bas= is. This same policy that is present in the ANDSF server, is available for the network nodes as well. I’m not sure, with out this assumption the sol= ution can work for all currently listed cases. We clearly need the MN and the LMA to = be in synch with respect to the configured policy. How, that is done, I guess = we will not try to know.  I thought even in 3GPP, this is the implied assumption ? But, this is for you to clarify. Not specifically for IFOM whe= re UE and PDN GW/HA are negotiating the flow policies, but generally that the = PDN GW and the ANDSF policy server will have synchronized policies. The MAG and= the LMA have the ability to carry this flow policy information in signaling messages and influence the access selection. The policy is a opaque object, with extensible formats, when carried in the signaling plane, should allow = the LMA/MAG to apply those access policies, while assuming MN is following the = same rules. These policies can surely reflect the specific WLAN access/operator specific rule. I’m surely with you, the lack of MN-AR interface is su= rely an issue and I see that. But, we need to understand, what are the limitations = with the approach of  out of band policy interfaces and what will be the solution limitations. If we need to tie the flow movement at the prefix granularity and rely on the natural ND interface in the form of RA PIO opti= on, more like PDN offload in MAPCON, or at the granularity of a flow level, is = open for discussion. I want to simplify this draft for sure, we can surely discu= ss each of these issues on the WG draft.


Regards
Sri






On 2/1/11 8:29 PM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com= > > wrote:
Sri,
thanks for the reply.

I'd like to comment on the "the flow policy decisions need not be based on the specific WLAN network". Does it mea= n, as I believe it does, that the current solution would not allow an operator deploying such solution to decide to route flows over a specific WLAN or no= t depending on which specific WLAN the MN is connected to? E.g. the operator = or the entity in control of the decisions for the routing may want to direct certa= in traffic always over WLANs that the operator deploys, and instead route only some of the traffic over WLANs of roaming partners or of the MN user home. = How does this solution support that scenario if the LMA is not told specificall= y which WLAN the MN is connected to? From a deployment point of view, I do no= t believe we can afford to leave out this scenario. Please note that the establishment of a security relationship between the MN and the MAG, and a specific MAG identity, cannot guarantee that the LMA knows which specific W= LAN access network the MN is connected to. Assuming that would severely restric= t the deployment scenarios.

As for the MN and the LMA being magically in synch, I am very concerned abo= ut a "glass ball" solution. You mention ANDSF defined by 3GPP as a solution for this "out of band" delivery of policy. Fair enough, however there is an issue with that. ANDSF is designed specific to be a MN-centric solution where policies are provisioned in the MN and the MN dec= ides which network technologies and access networks it needs to connect to, unde= r what conditions, and which IP traffic needs to be routed on such accesses. = No IP point of attachment in the network (i.e. the PDN GW in 3GPP that is the = LMA in PMIPv6) is aware under any conditions of such policy. Therefore, even if= in order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would unfortunately not provide a solution unless the MN can communicate to the M= AG and the LMA the decisions the MN has taken based on the ANDSF policies.

I believe the key point here is that we need to understand how the solution= can be realistically applied to a real scenario, and that we need to ensure tha= t important and realistic deployment scenarios are not excluded by the soluti= on.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli <sgundave@cisco.com <http://sgundave@cisco.com>= > wrote:
Hi Stefano:

These are valid points and some good comments. Let me share my thoughts.
Carlo’s draft is not assuming any new MN-AR interface. Its going with= the assumption there is established policy on the mobile and on the LMA, which allows the mobile to select the access network at a flow level granularity, without requiring any explicit signaling between the MAG and the MN. To lar= ge part this is all about out of band policy interface, such as ANDSF, towards= the UE, leading to the assumption that magically the MN and the LMA are in sync with respect to flow policies, access selection and they will make the righ= t forwarding decision. Secondly, the flow policy decisions need not be based = on the specific WLAN network, but it is implicitly driven by the MAG – L= MA security relation, where the MAG attachment to the WLAN network transitivel= y allows the LMA to make the flow policy decisions based on the MAG identity.= If the WLAN network is not trusted, there is truly no MAG in that network, whe= re the LMA shares a security relation with that node.

There are still some open issues on this draft that needs to be discussed i= n the WG.  On the approaches to allow more a flow aggregate movement, th= at is a discussion point. There are issues that we need to discuss, supporting split link model, or eliminating some favorite brand of signaling message (= FMA) and riding on PBU/PBA and just with one FMI trigger, and on the aspects aro= und MN applying the flow policies by flow mirroring. We have no agreement on th= ose issues yet.

Its just a base draft, for further discussion and resolving those issues. B= ut, hope that is not a stopper for base draft selection.


Sri






On 2/1/11 6:39 PM, "stefano faccin" <sfaccinstd@gmail.com <http://sfaccinstd@gmail.com= >  <http://sfaccinstd@gmail.c= om> > wrote:
Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered before (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) shoul= d have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition= per se, unless there are solutions in place for either the host to indicate to = the network where the flows should be routed or for the LMA to receive somehow = from somewhere some policies, the solution cannot really provide flow mobility s= ince there is no way to decide which flows are routed where. If we are thinking about a host-based solution, I have not yet seen a solution as to how the h= ost can indicate to the MAG and ultimately to the MAG which flows should be rou= ted on each access. If we are relying on modifications of layer 2 protocols, ar= en't we defining a solution that works only with some technologies (since for ot= her access technologies it is rather unrealistic to modify L2 for IP flow mobil= ity purposes)? If we are thinking of an LMA-based solution, can we hear of at l= east one example of a real-life scenario where the LMA would receive such polici= es, and how such delivery would happen? Also, should there be a solution to hav= e policies in the LMA, how does the LMA actually decide to route flows on one access or the other? E.g., if some flows need to be routed on certain WLAN networks, but shall not be routed on other WLAN networks, how does the LMA = know which specific WLAN network the host is connected to? Perhaps I missed the ability for the MAG to know e.g. the WLAN SSID and provide it to the LMA, i= n which case I would appreciate if somebody could highlight to me where that = is defined.

I think that, though not integral to the protocol specification, understand= ing what framework the protocol would/needs to fit in is rather important.

Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM,  <Basavaraj.Patil@nokia.com <http://Basavaraj.Patil@nok= ia.com>  <http://Basavaraj.Pat= il@nokia.com> > wrote:

Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at<= br> IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt
The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be<= br> developed further based on input and feedback from WG members.

-Basavaraj

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

 
 
------------------------------------------------------= ---------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from you= r system. Use, dissemination, distribution, or reproduction of this transmiss= ion by unintended recipients is not authorized and may be unlawful.

------------------------------------------------= ---------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from you= r system. Use, dissemination, distribution, or reproduction of this transmiss= ion by unintended recipients is not authorized and may be unlawful. =

------------------------------------------------= ---------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from you= r system. Use, dissemination, distribution, or reproduction of this transmiss= ion by unintended recipients is not authorized and may be unlawful. =

--_000_3D6C64F2D792B540BAAEBCEF6509363B0EE6D6D001FRMRSSXCHMBSE_-- --_006_3D6C64F2D792B540BAAEBCEF6509363B0EE6D6D001FRMRSSXCHMBSE_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=722; creation-date="Tue, 08 Feb 2011 12:22:51 GMT"; modification-date="Tue, 08 Feb 2011 12:22:51 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAKAA4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDSu9Nv V0vVpbjQL2KfU7xR5T6qqmRclsrnhecDFbGl6hqL69Noem63ZRQ6faops5Y2mmiYBQdz8BuSR1qD 4pxpLdeHo5UV0N2cqwyD93tXexW0ELtJFBGjv95lQAt9T3oA/9k= --_006_3D6C64F2D792B540BAAEBCEF6509363B0EE6D6D001FRMRSSXCHMBSE_ Content-Type: image/jpeg; name="image002.jpg" Content-Description: image002.jpg Content-Disposition: inline; filename="image002.jpg"; size=2232; creation-date="Tue, 08 Feb 2011 12:22:51 GMT"; modification-date="Tue, 08 Feb 2011 12:22:51 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAA+AIoDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDxmiii gAooooAKKKkt08ydE9TQNK7sXRpalQTKQSORto/spf8Ansf++a0KOKZ7f1Sj2M/+yl/57H/vmg6U McTH/vmtDiljQyypGvV2Cj8aTsH1Sj2MeXT5oxlcOB6VVr0L/hFVz/x+t/37/wDr1QvfBcZkEgvW G7r+67/nXH9dofzfmcdfCqK5oHGUV1J8FqR8t+c+8X/16zr/AMMX1lG0qFLiNeSY85A9wa0hiqM3 ZSOJwkuhj0UUV0EBRRRQAqqzsFUZZjgD1NbvirwZrHg6a2i1aOIfaULxtE+4cYyPqMj86x7P/j9g /wCui/zr179oP/WaB9Lj/wBp0AeN0V6Z8I9O1b7Pqup6fZ6PPGuyJn1ORlC4yx24U+2c47VdxrNp 8KrzUjpnh9bXU3klySwnHmORhE27eOwB6CgDyu0tZb68gtIAGlnkWNATjLMcD9TW/q3hLU/CeuLY 6osfmGHzUaJtysCccHjvW7faJ4T0XxL4fTQNYur65fUIfOSaIqFXeMHO0d+3P+PZfEjQrrxF8Q9L 0604ea0AZyOI0Dksx+n88UG2Ht7RN7I4aw8JaxqWgXOt28KfY7bO4s+GfHXaO+K2NP8AhZ4j1Kzj u4ms44pRuTzZGBYeuNp4rrfHWq22i6fY+C9JXYpjBnAPKwqMhT7sRk/j6119zY6jfeH9Pi0zUDYy qkbNIFzuXZjH5kH8KylNqVl0R3yxFTkUtk3p6Hjms/DnW9ChjmvJbMxyNsDRyM2DjOD8o9KqaT4e uP7UgZpYiqHeQM9vw+ldd4oh1W01FLPVNRa9KJvQ5OAD7djxU+i6HNJbf2gkqeW8JPOcrhiG4742 j/voV5mIxNb3owR2wklSUpu9+xV/s+X++n61VvLO4EYxHuAOTt5rrbjS4RczCGdxFCzhwY8sAqhu Ofm4PtVe6sore1aTzJGkDxhcptGGTdzzwa8Zxrxu5LRGTnCa5b7nE0o4PHauo1Hw6JENyZDGETzJ GSIsWQRhztGfmPOKzX8PyLMEE2VJb5jGRhRCJQWH8JwcEdjmuiNKclexwycYu1zyvxFapaazMkYC o+HCjtkc/rmsyu8Hhy312C61eWd2M9tK1miJ8g8t0jDO+eOWJ246c5GQKydR8PR+HriK7aN9Ttkl lhnhngeD548KxGCTsyww2RzwQOlfS0rqnHm3scMt9DmaKfO8ck8jxRCGNmJWMEkIM8DJ5OKZWgh8 EgiuI5CCQjhsD2NfRvirwzoPxMtdNvU10RQwK5jaEqd2/aec9CNvSvm+lDMOjEfQ0Adh8QvB1l4M vLS3sNY+3C5RmeM4DRYxgnB6HJx9DTtQ8TeFItK0oaH4eeHVLGSKSS6uG+WQoOcqGOctz2rjCSep zRQB1974+v8AxH4s0bVNb8hI9PnjP7mMgBd4LHuT0r3XXvEXh/QLGfxRJNBPK9uIoCkgZphksqL7 EnJ+mT0r5boycAZ4HSgDtNJ1W61/WNQ1O7+aeQFnbPG5jwB6AAYHsK9wEMHibwxp62urSWZjCMzQ ybWBCFShwR3P6V4d4Sh8vSnlI5lkPPsBj/GtzAzXk1a/LWldXWx7UKUqtKDbs0dL4p8PQ6EkMy6o byWdyGV/v9M7s5Ofx9az9P1OO1tTE8soyT8q5IAOMj8cc1l4oxXBWUamysjrgpKPLJ3N7+3Yg+8X FwG3btw3Zz65z196G1yFg26e4bdjcG3HdjpnnnFYOKSub6vHux8iN268TLHZAIZgLdCyFPkI465z kH6V5hqfi7VL+KaBLiaCC4OZkWZiZv8AfOfm/Gt3xHfrZ6W8YP724GxR7dzXC17WAw8Yxc38rnk4 2SUlGJZi1K/gs5LOK9uI7aU5eFJWCMenK5wadPq2pXRJuNQupiYhCfMmZsxgghOT93IBx04FVKK9 Q88KKKKACiiigAooooAKKKKAPQ9JiW20i1i3KCIwx5HU8/1q3uX++v8A30K8x3H1oyfU158sDzNv mPSjj+VJKJ6duX++v/fQo3r/AH1/76FeY5PqaMn1NT9QX8xX9of3fxPSZb21gGZbqFMerism+8V2 VupW1BuZOxwVUf1NcZmgnNaQwNNfE7mc8fNq0VYnvL2e+uDPcSF3P5Aeg9qgoortSSVkcDbbuwoo opiCiiigD//Z --_006_3D6C64F2D792B540BAAEBCEF6509363B0EE6D6D001FRMRSSXCHMBSE_ Content-Type: image/jpeg; name="image003.jpg" Content-Description: image003.jpg Content-Disposition: inline; filename="image003.jpg"; size=2232; creation-date="Tue, 08 Feb 2011 12:22:51 GMT"; modification-date="Tue, 08 Feb 2011 12:22:51 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAA+AIoDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDxmiii gAooooAKKKkt08ydE9TQNK7sXRpalQTKQSORto/spf8Ansf++a0KOKZ7f1Sj2M/+yl/57H/vmg6U McTH/vmtDiljQyypGvV2Cj8aTsH1Sj2MeXT5oxlcOB6VVr0L/hFVz/x+t/37/wDr1QvfBcZkEgvW G7r+67/nXH9dofzfmcdfCqK5oHGUV1J8FqR8t+c+8X/16zr/AMMX1lG0qFLiNeSY85A9wa0hiqM3 ZSOJwkuhj0UUV0EBRRRQAqqzsFUZZjgD1NbvirwZrHg6a2i1aOIfaULxtE+4cYyPqMj86x7P/j9g /wCui/zr179oP/WaB9Lj/wBp0AeN0V6Z8I9O1b7Pqup6fZ6PPGuyJn1ORlC4yx24U+2c47VdxrNp 8KrzUjpnh9bXU3klySwnHmORhE27eOwB6CgDyu0tZb68gtIAGlnkWNATjLMcD9TW/q3hLU/CeuLY 6osfmGHzUaJtysCccHjvW7faJ4T0XxL4fTQNYur65fUIfOSaIqFXeMHO0d+3P+PZfEjQrrxF8Q9L 0604ea0AZyOI0Dksx+n88UG2Ht7RN7I4aw8JaxqWgXOt28KfY7bO4s+GfHXaO+K2NP8AhZ4j1Kzj u4ms44pRuTzZGBYeuNp4rrfHWq22i6fY+C9JXYpjBnAPKwqMhT7sRk/j6119zY6jfeH9Pi0zUDYy qkbNIFzuXZjH5kH8KylNqVl0R3yxFTkUtk3p6Hjms/DnW9ChjmvJbMxyNsDRyM2DjOD8o9KqaT4e uP7UgZpYiqHeQM9vw+ldd4oh1W01FLPVNRa9KJvQ5OAD7djxU+i6HNJbf2gkqeW8JPOcrhiG4742 j/voV5mIxNb3owR2wklSUpu9+xV/s+X++n61VvLO4EYxHuAOTt5rrbjS4RczCGdxFCzhwY8sAqhu Ofm4PtVe6sore1aTzJGkDxhcptGGTdzzwa8Zxrxu5LRGTnCa5b7nE0o4PHauo1Hw6JENyZDGETzJ GSIsWQRhztGfmPOKzX8PyLMEE2VJb5jGRhRCJQWH8JwcEdjmuiNKclexwycYu1zyvxFapaazMkYC o+HCjtkc/rmsyu8Hhy312C61eWd2M9tK1miJ8g8t0jDO+eOWJ246c5GQKydR8PR+HriK7aN9Ttkl lhnhngeD548KxGCTsyww2RzwQOlfS0rqnHm3scMt9DmaKfO8ck8jxRCGNmJWMEkIM8DJ5OKZWgh8 EgiuI5CCQjhsD2NfRvirwzoPxMtdNvU10RQwK5jaEqd2/aec9CNvSvm+lDMOjEfQ0Adh8QvB1l4M vLS3sNY+3C5RmeM4DRYxgnB6HJx9DTtQ8TeFItK0oaH4eeHVLGSKSS6uG+WQoOcqGOctz2rjCSep zRQB1974+v8AxH4s0bVNb8hI9PnjP7mMgBd4LHuT0r3XXvEXh/QLGfxRJNBPK9uIoCkgZphksqL7 EnJ+mT0r5boycAZ4HSgDtNJ1W61/WNQ1O7+aeQFnbPG5jwB6AAYHsK9wEMHibwxp62urSWZjCMzQ ybWBCFShwR3P6V4d4Sh8vSnlI5lkPPsBj/GtzAzXk1a/LWldXWx7UKUqtKDbs0dL4p8PQ6EkMy6o byWdyGV/v9M7s5Ofx9az9P1OO1tTE8soyT8q5IAOMj8cc1l4oxXBWUamysjrgpKPLJ3N7+3Yg+8X FwG3btw3Zz65z196G1yFg26e4bdjcG3HdjpnnnFYOKSub6vHux8iN268TLHZAIZgLdCyFPkI465z kH6V5hqfi7VL+KaBLiaCC4OZkWZiZv8AfOfm/Gt3xHfrZ6W8YP724GxR7dzXC17WAw8Yxc38rnk4 2SUlGJZi1K/gs5LOK9uI7aU5eFJWCMenK5wadPq2pXRJuNQupiYhCfMmZsxgghOT93IBx04FVKK9 Q88KKKKACiiigAooooAKKKKAPQ9JiW20i1i3KCIwx5HU8/1q3uX++v8A30K8x3H1oyfU158sDzNv mPSjj+VJKJ6duX++v/fQo3r/AH1/76FeY5PqaMn1NT9QX8xX9of3fxPSZb21gGZbqFMerism+8V2 VupW1BuZOxwVUf1NcZmgnNaQwNNfE7mc8fNq0VYnvL2e+uDPcSF3P5Aeg9qgoortSSVkcDbbuwoo opiCiiigD//Z --_006_3D6C64F2D792B540BAAEBCEF6509363B0EE6D6D001FRMRSSXCHMBSE_-- From pierrick.seite@orange-ftgroup.com Tue Feb 8 08:25:17 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 842793A6803 for ; Tue, 8 Feb 2011 08:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxaq3nQdRXip for ; Tue, 8 Feb 2011 08:25:16 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id EB09F3A67E3 for ; Tue, 8 Feb 2011 08:25:15 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 988B76C0007; Tue, 8 Feb 2011 17:25:52 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 8840E6C0004; Tue, 8 Feb 2011 17:25:52 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Feb 2011 17:25:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Feb 2011 17:25:21 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQIo/NBbQQqyeWpvtmcXp7I2XAzY+gJkMbtkAO4ljUKTImNb0IAAaHJQ References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> From: To: , , X-OriginalArrivalTime: 08 Feb 2011 16:25:22.0803 (UTC) FILETIME=[C8D70C30:01CBC7AC] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 16:25:17 -0000 Hi, Going through this long thread :-), it seems we could agree on the = following (just a tentative to summarize): Sessions should be created/updated with all available interfaces. = Rewriting Tran's example: when the MN attaches to MAG1 via If1, the LMA = creates session 1: Session1: [Pref1, MAG1, IF1] Then, if the MN attaches to MAG2 via If2, the LMA creates session 2 with = both If1 and If2. The LMA also updates session 1 with If2:=20 Session1: [Pref1, MAG1, IF1, IF2] Session2: [Pref2, MAG2, IF2, IF1] MAG2 receives prefixes 1 and 2 in PBA but MAG1 is not sending PBU. So, = if the LMA wants to move flow with Pref2 from if2 to If1, the LMA needs = to provide Pref2 to MAG1. Also, the LMA should be able to create new = sessions with already up interfaces, e.g. if1 and if2. To address both = issues, PBU from MAG1 could be triggered (triggering is to be clarified) = or we could define LMA/MAG specific L3 signalling (FMI/FMA). My 2 cents, Pierrick > -----Message d'origine----- > De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la = part > de Youn-Hee Han > Envoy=E9=A0: mardi 8 f=E9vrier 2011 12:00 > =C0=A0: 'Julien Laganier'; 'Rajeev Koodli' > Cc=A0: netext@ietf.org; Basavaraj.Patil@nokia.com > Objet=A0: Re: [netext] Consensus call to adopt = I-D:draft-bernardos-netext- > pmipv6-flowmob as WG doc >=20 > Hi Julien, >=20 > > -----Original Message----- > > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On = Behalf > > Of Julien Laganier > > Sent: Tuesday, February 08, 2011 1:38 PM > > To: Rajeev Koodli > > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > > Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos- > > netext-pmipv6-flowmob as WG doc > > > > On Mon, Feb 7, 2011 at 6:15 PM, Rajeev Koodli = wrote: > > > > > > If flow mobility has nothing do with prefix management, I am lost. > > > > No reason to be lost: Prefix management is how do I get prefix for = the > > MN. Flow mobility is how to I move flows across interfaces. The two > > needs not to be intertwined together, as I've shown in my other = notes. > > E.g., I can do flow mobility without adding/deleting prefixes from > > sessions, and vice versa. >=20 > Yes, I agree with you. Flow mobility is how to move flows across = interface. > So, I thought that it would be better to define "a flow" exactly in = netext > WG prior to discuss flow mobility management. As the definition of "a > flow", > all I can think is a five-tuple plus something. If we assume that it = is > correct, I think that flow mobility and prefix addition are inevitably > tied. > As you know, RFC5213 (and IPv6 protocol spec) already allow to assign > multiple prefixes across multiple interfaces of an MN. Yes, I also = agree > with you that in real-world (3GPP), there may be no need to assign > multiple > prefixes into an MN. (if somebody knows its necessity, please tell me = when > it should happen). So, flow mobility can be done without adding = prefixes. > However, different interfaces are allowed to be assigned different > prefixes > by RFC 5213 and IPv6 spec. We can't expect what kind of prefixes an = MAG > advertises. Therefore, sometimes, we need prefix addition to move a = flow > to > a new interface of which MAG does not yet advertise the prefix of the = flow > being moved. >=20 > (snip...) >=20 > > >> I see no reason to depart from that in the context of extending = the > > >> protocol to support mobility, nor I am aware of any system > > >> architecture that would require this capability. > > > > > > Okay, see your position. I see it differently. I don't need to be > > > bound by some "presumed implementation model" of PMIP6 and limit > > > myself *only* to a prefix assignment model you are imagining. > > > > It's not an implementation model, it is a protocol model, and it's = not > > imaginary. Implementation has nothing to do with this. > > > > There's no reason to extend prefix assignment model to do flow = mobility > > unless you can point me out in which real world context your = scenario > > actually happens. >=20 > As I insisted in the old mail, I agree with Julien in this regard. = Current > draft allows too much space regarding the prefix allocation model = (unique, > shared, and hybrid). When a flow should be moved to a new interface = and > the > prefix which the flow uses is not yet advertised by the new MAG, just > inform > the prefix to the MAG and thus make it advertise the prefix and setup = the > tunnel based on the new prefix. That's all!. If the prefix is already > advertised by the MAG, there is nothing to do and just move the flow. = This > behaviors are very natural one when we want to support IP-level = mobility. >=20 > > >> If this is something really important, the WG can be rechartered = to > > >> work on a different extension that would allow adding/removing > > >> prefixes from existing PMIPv6 sessions. > > > > > > Huh.. What in the current charter forces us not to have the LMA > > > add/refresh/delete a prefix on-demand? > > > > Engineering is about finding a solution to a problem. = Adding/deleting > > prefix on-demand is not a solution to flow mobility. I've shown you = how > > to do flow mobility without this capability. >=20 > From the viewpoint of protocol, I think that at least, prefix addition = to > an > interface is a necessary function to support flow mobility, as I = explained > above. But, it does not mean prefix addition should happen always = whenever > flow mobility occurs. It is sometimes needed. >=20 > > Now a different engineering problem would be: how to add/delete = prefixes > > to a PMIPv6 session, and that would be useful for e.g. > > renumbering. This is a different problem that we haven't been = chartered > > to work on. >=20 > Prefix addition is just prefix addition. IMHO, renumbering is closer = to > prefix change. We just harness that function to support IP-level = mobility. >=20 > Youn-Hee >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From julien.ietf@gmail.com Tue Feb 8 13:41:27 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2798B3A689F for ; Tue, 8 Feb 2011 13:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5sE0yZxdZms for ; Tue, 8 Feb 2011 13:41:25 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id ED6963A6835 for ; Tue, 8 Feb 2011 13:41:24 -0800 (PST) Received: by ewy8 with SMTP id 8so3609385ewy.31 for ; Tue, 08 Feb 2011 13:41:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3e71zl5ver2k6ELVGVmRSAipgQb8b9GEjlV+j8YhkBI=; b=UhawyT0FDB4Ln8892txiuUxncLpVgoWs0ak8ngEbs0te9B96M3yutNGItJbHcc0bo5 CDFaOhi1kALdsXfxTpWnY+15uxJUWeNbGscCrw1dnKaarJqw7QAKtTRg5eSBeJqYT2gs 6rDBrNXNP3HF+chs5UkE8Wj46/qMAwJFRj3c0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CUjdSZfRfZqof0DSSo9i5TFdnXtsVnhu0LPKXG3YwwbqoEQTUfneUPwKoYKivfailK kffRGr29yG3xTjcrn5Q+0I2gfARTHMv0WD7KUcJYlGrJr+qek9wtkwO2Wq8pJ7AY1SP9 KD1fGZpUxPgt5NnPVb0zIJ7O3SvYIdMvm+JJg= MIME-Version: 1.0 Received: by 10.103.192.12 with SMTP id u12mr10380788mup.75.1297201291857; Tue, 08 Feb 2011 13:41:31 -0800 (PST) Received: by 10.103.221.9 with HTTP; Tue, 8 Feb 2011 13:41:31 -0800 (PST) In-Reply-To: References: <1296920514.3773.26.camel@acorde.it.uc3m.es> <1297017501.4715.2.camel@acorde.it.uc3m.es> <1297019696.4715.5.camel@acorde.it.uc3m.es> <1297115574.3099.3.camel@acorde.it.uc3m.es> <1297126584.3099.96.camel@acorde.it.uc3m.es> Date: Tue, 8 Feb 2011 13:41:31 -0800 Message-ID: From: Julien Laganier To: Tran Minh Trung Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 21:41:27 -0000 On Mon, Feb 7, 2011 at 11:26 PM, Tran Minh Trung wr= ote: > On Tue, Feb 8, 2011 at 4:11 PM, Julien Laganier w= rote: >> On Mon, Feb 7, 2011 at 10:26 PM, Tran Minh Trung = wrote: >>> On Tue, Feb 8, 2011 at 2:10 PM, Julien Laganier = wrote: >>>> On Mon, Feb 7, 2011 at 9:03 PM, Tran Minh Trung wrote: >>>>> On Tue, Feb 8, 2011 at 1:12 PM, Julien Laganier wrote: >>>>>> On Mon, Feb 7, 2011 at 5:51 PM, Tran Minh Trung wrote: >>>>>>> On Tue, Feb 8, 2011 at 10:41 AM, Julien Laganier wrote: >>>>>>>> On Mon, Feb 7, 2011 at 5:30 PM, Tran Minh Trung wrote: >>>>>>>>> On Tue, Feb 8, 2011 at 10:22 AM, Julien Laganier wrote: >>>>>>>>>> Hi Tran, >>>>>>>>>> >>>>>>>>>> On Mon, Feb 7, 2011 at 5:08 PM, Tran Minh Trung wrote: >>>>>>>>>>> Hi Carlos and Julien, >>>>>>>>>>> >>>>>>>>>>> 2011/2/8 Carlos Jes=FAs Bernardos Cano : >>>>>>>>>>>> Hi Julien, >>>>>>>>>>>> >>>>>>>>>>>> On Mon, 2011-02-07 at 15:56 -0800, Julien Laganier wrote: >>>>>>>>>>>>> Hi Carlos, >>>>>>>>>>>>> >>>>>>>>>>>>> 2011/2/7 Carlos Jes=FAs Bernardos Cano : >>>>>>>>>>>>> > Hi Julien, >>>>>>>>>>>>> > >>>>>>>>>>>>> > On Mon, 2011-02-07 at 12:43 -0800, Julien Laganier wrote: >>>>>>>>>>>>> >> Hi Carlos, >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : >>>>>>>>>>>>> >> > Hi Julien, >>>>>>>>>>>>> >> > >>>>>>>>>>>>> >> > On Sun, 2011-02-06 at 10:56 -0800, Julien Laganier wrote= : >>>>>>>>>>>>> >> >> Hi Carlos, >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> >> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : >>>>>>>>>>>>> >> >> > Hi Julien, >>>>>>>>>>>>> >> >> > >>>>>>>>>>>>> >> >> > On Sun, 2011-02-06 at 10:11 -0800, Julien Laganier wr= ote: >>>>>>>>>>>>> >> >> >> 2011/2/5 Carlos Jes=FAs Bernardos Cano : >>>>>>>>>>>>> >> >> >> > On Fri, 2011-02-04 at 12:59 -0800, Julien Laganier= wrote: >>>>>>>>>>>>> >> >> >> >> On Fri, Feb 4, 2011 at 10:40 AM, Rajeev Koodli wrote: >>>>>>>>>>>>> >> >> >> >> > >>>>>>>>>>>>> >> >> >> >> > >>>>>>>>>>>>> >> >> >> >> > On 2/4/11 10:16 AM, "Julien Laganier" wrote: >>>>>>>>>>>>> >> >> >> >> > >>>>>>>>>>>>> >> >> >> >> >>> >>>>>>>>>>>>> >> >> >> >> >>> The LMA needs to provide the prefix info to t= he MAG. This can be either in >>>>>>>>>>>>> >> >> >> >> >>> PBA or in FMI (if not provided in PBA). >>>>>>>>>>>>> >> >> >> >> >> >>>>>>>>>>>>> >> >> >> >> >> The LMA can provide the prefix to the MAG at s= ession creation, i.e., >>>>>>>>>>>>> >> >> >> >> >> in the PBU. This information does not need to = be (re)conveyed at flow >>>>>>>>>>>>> >> >> >> >> >> movement. >>>>>>>>>>>>> >> >> >> >> > >>>>>>>>>>>>> >> >> >> >> > If it was conveyed in PBA, surely you don't rec= onvey. >>>>>>>>>>>>> >> >> >> >> > If the prefix was not conveyed in PBA (as in th= e example we discussed >>>>>>>>>>>>> >> >> >> >> > y'day), you provide it in FMI. >>>>>>>>>>>>> >> >> >> >> >>>>>>>>>>>>> >> >> >> >> IMO the prefix can always be conveyed in the PBA = that is received in >>>>>>>>>>>>> >> >> >> >> response to the PBU attaching an interface to a P= MIPv6 flow mobility >>>>>>>>>>>>> >> >> >> >> session. >>>>>>>>>>>>> >> >> >> > >>>>>>>>>>>>> >> >> >> > What about the following scenario: >>>>>>>>>>>>> >> >> >> > >>>>>>>>>>>>> >> >> >> > MN has two interfaces: if1 and if2. if1 attaches t= o MAG1, a mobility >>>>>>>>>>>>> >> >> >> > session is created, pref1 is delegated. Some point= in time later, if2 >>>>>>>>>>>>> >> >> >> > attaches to MAG2, new mobility sesison created, pr= ef2 is delegated. >>>>>>>>>>>>> >> >> >> > flowX addressed to pref2 wants to be moved to if1.= In this case we need >>>>>>>>>>>>> >> >> >> > some signaling from LMA to MAG1 that cannot be con= veted in PBA. >>>>>>>>>>>>> >> >> >> >>>>>>>>>>>>> >> >> >> If flow X addresssed to pref2 wants to be moved to i= f1, first thing to >>>>>>>>>>>>> >> >> >> do is to attach the if1 to the session corresponding= to pref2, so MAG1 >>>>>>>>>>>>> >> >> >> sends a PBU, and LMA sends back a PBA with the prefi= x set of the >>>>>>>>>>>>> >> >> >> session (pref2.) >>>>>>>>>>>>> >> >> > >>>>>>>>>>>>> >> >> > if1 was previously attached to MAG1 (and LMA delegate= d pref1). How can >>>>>>>>>>>>> >> >> > MAG1 know when LMA wants to move flow X to if1 (to se= nd a PBU)? Some >>>>>>>>>>>>> >> >> > signaling is needed there. >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> >> >> if1 was attached to MAG1 and had session S1 with prefix= pref1. When >>>>>>>>>>>>> >> >> if2 is attached to MAG2, if a different prefix pref2 is= allocated, >>>>>>>>>>>>> >> >> that is a different session S2. LMA cannot move a flow = from session S2 >>>>>>>>>>>>> >> >> to a MAG that isn't part of that session. So first thin= g to do after >>>>>>>>>>>>> >> >> S2 is created, if there's a desire to move flows across= other MAGs, is >>>>>>>>>>>>> >> > >>>>>>>>>>>>> >> > Right, our draft uses FMI signalling to add if1 to the s= ession (we use >>>>>>>>>>>>> >> > the flowmob cache structure of this purpose). We are dis= cussing about >>>>>>>>>>>>> >> > two ways of doing exactly the same thing. However, in yo= urs, you need >>>>>>>>>>>>> >> > the MAG to take the initiative, while ours also supports= the LMA >>>>>>>>>>>>> >> > initiate the flow movement. >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> You seem to be conflating session management and flow move= ment. >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> In my approach, session management is MAG initiated, as it= has been in >>>>>>>>>>>>> >> the past with PMIPv6. Once a session exists across an inte= rface set, >>>>>>>>>>>>> >> flow movement can be LMA-initiated at any time from one in= terface in >>>>>>>>>>>>> >> the set to another. >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> I do not see a reason to depart from RFC 5213 and allow th= e LMA to >>>>>>>>>>>>> >> initiate session management (except for purposes of revoca= tion but >>>>>>>>>>>>> >> that is supported already.) >>>>>>>>>>>>> > >>>>>>>>>>>>> > I see the reason to add it in order to support the scenario= s I mentioned >>>>>>>>>>>>> > in my example. Those cannot be supported with RFC5213 model= , as they >>>>>>>>>>>>> > require first the MAG to send a PBU. We need either new sig= naling from >>>>>>>>>>>>> > the LMA to the MAG to make the MAG aware of the required pr= efixes to >>>>>>>>>>>>> > support flow mobility, or a trigger from the LMA to the MAG= , so the MAG >>>>>>>>>>>>> > can send a PBU and then follow your model. >>>>>>>>>>>>> >>>>>>>>>>>>> In the systems I know the MAG is the entity that creates atta= ches a MN >>>>>>>>>>>>> interface to a session and therefore I do not understand why = you would >>>>>>>>>>>>> need the LMA to attach an interface to a session. The LMA has= no >>>>>>>>>>>>> interface with the interface... That's a MAG duty. >>>>>>>>>>>>> >>>>>>>>>>>>> In which system is the scenario you're outlining useful? >>>>>>>>>>>> >>>>>>>>>>>> I must be really bad at explaining this... >>>>>>>>>>>> >>>>>>>>>>>> Lets consider the following scenario: >>>>>>>>>>>> >>>>>>>>>>>> - MN attaches if1 to MAG1. As a result, if1 is attached to the= session >>>>>>>>>>>> with MAG1. Pref1::/64 is delegated to if1. >>>>>>>>>>>> >>>>>>>>>>>> - Later on, MN attaches if2 to MAG2. As a result if2 is attach= ed to the >>>>>>>>>>>> session with MAG2. Pref2::/64 is delegated to if2. >>>>>>>>>>>> >>>>>>>>>>>> (nothing new so far, no flow mobility) >>>>>>>>>>>> >>>>>>>>>>>> - Some point in time later, LMA wants to move a flow X, addres= sed to >>>>>>>>>>>> pref2::/64 to if1. MAG1 cannot send a PBU at that particular m= oment (how >>>>>>>>>>>> can it know it has to?) to make MAG1 attach if1 to session wit= h pref2. >>>>>>>>>>>> Therefore, we need some signaling, initiated by the LMA, to ma= ke that >>>>>>>>>>>> flow movement happen. >>>>>>>>>>>> >>>>>>>>>>>> How can this scenario be supported with your approach? I fail = to see it. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Carlos >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I think you still mis-understand Julien solution. >>>>>>>>>>> >>>>>>>>>>> Let's see the following scenario: >>>>>>>>>>> >>>>>>>>>>> Step1: if1 is attached to MAG1, session 1 is created: >>>>>>>>>>> >>>>>>>>>>> =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] >>>>>>>>>>> >>>>>>>>>>> Step2: if2 is attached to MAG2, session 2 is created: >>>>>>>>>>> >>>>>>>>>>> =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2] >>>>>>>>>>> >>>>>>>>>>> If we amuse that the MAG2 knows that IF2 and IF1 are hidden by = a >>>>>>>>>>> logical interface to support flow mobility -> MAGs send PBU mes= sages >>>>>>>>>>> to attaches IF1 to S2 and IF2 to S1. Then two sessions are upda= ted as >>>>>>>>>>> follow: >>>>>>>>>>> >>>>>>>>>>> =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] >>>>>>>>>>> =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2, IF1] >>>>>>>>>>> >>>>>>>>>>> After that flow can be moved freely without extra signaling mes= sages >>>>>>>>>>> in any-cases (eg. policy changes) >>>>>>>>>>> >>>>>>>>>>> My question to Julien is that: How can MAG1 know that Session 2= is >>>>>>>>>>> created to attach IF1 to S2 in advance? >>>>>>>>>> >>>>>>>>>> I think the question is backward. The real question should be, i= f >>>>>>>>>> there's an intent that flows bound to prefix2 be able to move be= tween >>>>>>>>>> if1 and if2, why on earth would session 2 be created without if1 >>>>>>>>>> attached to it? I see no reason. >>>>>>>>>> >>>>>>>>> >>>>>>>>> How can you create session 2 with IF1 without informing MAG1 abou= t prefix2? >>>>>>>>> I think the attachment is completed only when MAG1 is received PB= A >>>>>>>>> message including Prefix2. But it needs PBU messages from MAG1 fi= rst. >>>>>>>> >>>>>>>> Right so this what you do. If you want a session2 that allows to m= ove >>>>>>>> flows between if1 and if2, you attach both if1 and if2 to session2 >>>>>>>> when the interfaces are brought up. >>>>>>>> >>>>>>>>> I sill do not understand how MAG1 can initiate PBU message to att= ach >>>>>>>>> IF1 to session2. >>>>>>>> >>>>>>>> IF1 is brought up. There is a desire to have session2 encompassing >>>>>>>> this interface. So, MAG1 sends a PBU to attach IF1 to session2. Wh= at >>>>>>>> is complicated? >>>>>>>> >>>>>>> >>>>>>> In the above scenario, the session 2 is created only after the IF2 = is >>>>>>> attached to MAG2. We can not attach IF1 to session 2 when it dose n= ot >>>>>>> exist. >>>>>> >>>>>> If session2 will at some point requires having flow sent to if1, why >>>>>> can't session2 be created when if1 brought up? >>>>>> >>>>> >>>>> Because the MAG1 can not know all prefix(es) that will be assigned to >>>>> the sessions that will be created in the future. >>>>> >>>>> In the above example, MAG1 can not know that prefix2 will be assigned >>>>> to session 2 when the IF2 is up. >>>> >>>> All I'm saying is, if at some point flows from session2 have to go on >>>> interface1, you create session2 when interface1 or interface2 comes >>>> up, whichever happens first. >>>> >>> >>> Well, I have simpler questions. >>> >>> A new session can be created at any time, right? >>> >>> Now, assume that session N is created when interface1,2 are already wor= king. >>> How to attach both interface 1 and 2 to the new session N? >> >> L2 triggers, or policy profile update triggers both MAG1 and MAG2 to >> send PBU to attach if1 and if2 to a new session N. >> > > Did you mean that the LMA sends L2 triggers to both MAG1 and MAG2? No. I meant the L2 or a policy profile update triggers both MAG1 and MAG2 to attach interface1 and interface2 to session2 by sending a PBU. > I am not sure it is valid assumption or not since creating a new > session is occurred at L3 and it is L3 Job. See above. > I prefer to use extra signaling messages between LMA and MAGs as > FMI/FMA in the current draft, or using HUR/HUA messages as pro-active > signaling messages described in > https://datatracker.ietf.org/doc/draft-trung-netext-flow-mobility-support= /?include_text=3D1 Well this is your preference but in the systems that use PMIPv6 I am familiar with (3GPP), the session (PDN connection) is always created by the MAG (SGW / ePDG), upon L2 trigger (attach, additional PDN connectivity.) Nobody has been able to point me out a real world scenario in which the LMA unilateraly decides to create a session... --julien --julien From julien.ietf@gmail.com Tue Feb 8 13:46:10 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 600683A6875 for ; Tue, 8 Feb 2011 13:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+855t5AUUWD for ; Tue, 8 Feb 2011 13:46:09 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 756833A67F3 for ; Tue, 8 Feb 2011 13:46:05 -0800 (PST) Received: by ewy8 with SMTP id 8so3612614ewy.31 for ; Tue, 08 Feb 2011 13:46:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6vz9iPKpWZItyK/wQ9fTwW98FF9uBJzaJNNm3LmdPl4=; b=CiLS+24cp+M6E6MWBia/WHvbSAHUYLsciCtacV7KJbyE0v5b2daBQcpuKh6sYhZ6Na Qw+yqXhY+TgyGwNC6N0gghn7VoqiSZogPrgoNmNiH/71SZXs5gJsNef7Dws0zIYvcfH3 /wVDZpimrZIDOizzNdD9woEUOW3hUoreYqRZI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lFcw66eNKXu3l3ETuS6kyh1t2r3wWXNMFEe3x2MxHigorzmOaxbMDI9Qtb0KbfoTm+ 501V/jxEznB7yecknFFRw7oU5TADvJI20wFV8KMLvlwAxOzDGwSrDmST5JSle2okXtyE Mptz+aB5S+ckWqOpkIsam+nmXJ6+MWRyZnqm4= MIME-Version: 1.0 Received: by 10.103.124.3 with SMTP id b3mr12345006mun.3.1297201572633; Tue, 08 Feb 2011 13:46:12 -0800 (PST) Received: by 10.103.221.9 with HTTP; Tue, 8 Feb 2011 13:46:12 -0800 (PST) In-Reply-To: <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CFFD@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> References: <1296920511.3773.25.camel@acorde.it.uc3m.es> <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CFFD@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> Date: Tue, 8 Feb 2011 13:46:12 -0800 Message-ID: From: Julien Laganier To: "MELIA, TELEMACO (TELEMACO)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 21:46:10 -0000 On Tue, Feb 8, 2011 at 2:55 AM, MELIA, TELEMACO (TELEMACO) wrote: >> > The LMA needs to provide the prefix info to the MAG. This can be either in >> > PBA or in FMI (if not provided in PBA). >> >> The LMA can provide the prefix to the MAG at session creation, i.e., >> in the PBU. This information does not need to be (re)conveyed at flow >> movement. > > If different prefixes are assigned for different sessions, and we want > to move flows across interfaces, we need some kind of signaling to make > the MAG aware of the prefixes. It cannot be done at session creation, > since not all the interfaces necessarily attach simultaneously, I should have written "The LMA can provide the prefix to the MAG at the time when the interface is attached to that session by the MAG, i.e., by including the prefix in the PBA that replies to the PBU attaching the interface." Also as I said to Tran, in the systems that use PMIPv6 I am familiar with (3GPP), the session (PDN connection) is always created by the MAG (SGW / ePDG), upon L2 trigger (attach, additional PDN connectivity.) What is a real world scenario in which the LMA unilateraly decides to create a session? Who needs that? What problem does it solve? etc. etc. --julien From julien.ietf@gmail.com Tue Feb 8 13:55:27 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E091D3A6896 for ; Tue, 8 Feb 2011 13:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVYWaoUdKkMT for ; Tue, 8 Feb 2011 13:55:27 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id E6A993A6895 for ; Tue, 8 Feb 2011 13:55:25 -0800 (PST) Received: by eyd10 with SMTP id 10so3607909eyd.31 for ; Tue, 08 Feb 2011 13:55:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DZTqGupB1hptXmmpL8ZZqlmNzK4LOgIL7mnhrr0PULA=; b=XHTjiYPhEYSRgO9LnHis+zj2uh3X6qAqIk5uz6QVgmVa9/w+/TscO1bq8nPoF6Yc6S +P0yPwpeAMCivw5f3d9ichs/Nrs27Xgf/4HH6Pn4w+sz9/sCYfGbF5uJV/nB5ifWXwwS Z7YHRYJFtwa0HVmja3AyjZ42cRVp//XvwI6JE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jPwJNiAvoOm8gFLYf+kktg8f3O4xKxyYXHB3FdGEMY+FAcl7nMt5E/1r0HJLimS++M Ha2dl+xyu8Bg1Ks/5leOyWu5k12kqwGkgw5C+tJYuUnrFKzTXNWLPKNJZJ1KLMUbbaUk CS2uYskYuXp104BKF6jnHKEOcg+TO+H3ashWA= MIME-Version: 1.0 Received: by 10.103.124.3 with SMTP id b3mr12356438mun.3.1297202132781; Tue, 08 Feb 2011 13:55:32 -0800 (PST) Received: by 10.103.221.9 with HTTP; Tue, 8 Feb 2011 13:55:32 -0800 (PST) In-Reply-To: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> Date: Tue, 8 Feb 2011 13:55:32 -0800 Message-ID: From: Julien Laganier To: Youn-Hee Han Content-Type: text/plain; charset=ISO-8859-1 Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 21:55:28 -0000 Hi Youn-Hee, On Tue, Feb 8, 2011 at 3:00 AM, Youn-Hee Han wrote: > Hi Julien, > >> -----Original Message----- >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf >> Of Julien Laganier >> Sent: Tuesday, February 08, 2011 1:38 PM >> To: Rajeev Koodli >> Cc: netext@ietf.org; Basavaraj.Patil@nokia.com >> Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos- >> netext-pmipv6-flowmob as WG doc >> >> On Mon, Feb 7, 2011 at 6:15 PM, Rajeev Koodli wrote: >> > >> > If flow mobility has nothing do with prefix management, I am lost. >> >> No reason to be lost: Prefix management is how do I get prefix for the >> MN. Flow mobility is how to I move flows across interfaces. The two >> needs not to be intertwined together, as I've shown in my other notes. >> E.g., I can do flow mobility without adding/deleting prefixes from >> sessions, and vice versa. > > Yes, I agree with you. Flow mobility is how to move flows across interface. > So, I thought that it would be better to define "a flow" exactly in netext > WG prior to discuss flow mobility management. As the definition of "a flow", > all I can think is a five-tuple plus something. If we assume that it is > correct, I think that flow mobility and prefix addition are inevitably tied. > As you know, RFC5213 (and IPv6 protocol spec) already allow to assign > multiple prefixes across multiple interfaces of an MN. I know this, but in 5213 the LMA doesn't unilaterally decide to create a new session with a different prefix et. What is documented in 5213 is a way by which the LMA avoids the same session to be used across different interfaces unless the MAG explicitley requested for that to happen via setting the Handoff Indicator to "handoff across different interfaces. So the entity that decides if multiple session are created is the MAG, based on L2 triggers or policy profile. > Yes, I also agree > with you that in real-world (3GPP), there may be no need to assign multiple > prefixes into an MN. (if somebody knows its necessity, please tell me when > it should happen). So, flow mobility can be done without adding prefixes. So we don't need any of the additional complexity (LMA to MAG signaling) unless there is a real world usecase for it. Who needs an LMA to unilaterally create sessions? What problem does it solve? > However, different interfaces are allowed to be assigned different prefixes > by RFC 5213 and IPv6 spec. They are not allowed to be assigned different prefixes. They are required to be assigned different prefixes and session based on the MAG being unable to determine whether the host supports handoffs across interfaces (thanks to virtual interface) or not. This is to avoid a legacy host to break down. This is not the same as saying the LMA can decide to have multiple sessions. Please review the multihoming discussion we had on the netlmm list at the time of RFC5213 work. > We can't expect what kind of prefixes an MAG > advertises. Therefore, sometimes, we need prefix addition to move a flow to > a new interface of which MAG does not yet advertise the prefix of the flow > being moved. No you don't, unless you have a real world use case. --julien From julien.ietf@gmail.com Tue Feb 8 14:18:37 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85FBF3A688C for ; Tue, 8 Feb 2011 14:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmk0NVSeCzW1 for ; Tue, 8 Feb 2011 14:18:36 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id C88503A6884 for ; Tue, 8 Feb 2011 14:18:35 -0800 (PST) Received: by bwz12 with SMTP id 12so342374bwz.31 for ; Tue, 08 Feb 2011 14:18:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=L8+NWloZRsZiDVjS11DCgRhuZLj5h0JrPMIpyWU5bEI=; b=q6ksns41qb98Rf96hrYHlIPDFDROwdL3W9elwaL2MI0Ns6RILdRFF/AzBowNV4up/3 NrPH1hgJTsllctqGFzpRo1E1+jKzxWUoJf5w0Tx3k8P2P6hrw9kypL3LwMy81DOJpg+p BIbLcxoGhbEimqquYeqM1f1lTca+D7eRMZfeM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SRzMz74fvsPUaR/DZRLUsvQBq834Hjgnzxgnrjxhis0DOqAVQbBCYWWxVp4cSHc0Lz 9Uq58V1n1lr42/yCoa2+le8u2QvvPV7N5QWepLCId99VIy/O0ZKxD4RiviWWLIKSGkF2 9oRMPOBJ/8mvrGcwqz8AmTLqWlekgX5JFemDE= MIME-Version: 1.0 Received: by 10.103.226.2 with SMTP id d2mr13235879mur.111.1297203520797; Tue, 08 Feb 2011 14:18:40 -0800 (PST) Received: by 10.103.221.9 with HTTP; Tue, 8 Feb 2011 14:18:40 -0800 (PST) In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> Date: Tue, 8 Feb 2011 14:18:40 -0800 Message-ID: From: Julien Laganier To: pierrick.seite@orange-ftgroup.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 22:18:37 -0000 Hi Pierrick, I am going to intertwine the steps in your scenario below with the missing pieces of the big picture so that we are not doing an academic exercise but focusing on the real world: 1. when the MN first attaches with if1 to a network, MAG1 requests attachment of if1 to a session1 by sending a PBU to LMA 2. because the MN add no session1 previously, the LMA creates session 1 and allocates a prefix for it. The prefix is sent back to MAG1 in the PBA: =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1-IF1] 3. then, if the MN attaches with if2 to another network, but does not request this interface be attached to a distinct session, MAG2 requests attachemnt of If2 to session1 by sending a PBU to LMA 4. Because the MN already has session 1, the LMA updates session1 with if2, and send the pref1 back to MAG2 in the PBA: =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1-IF1, MAG2-IF2] 5. Creation of a new session 2 for if2 is requested by either of MN requests via L2 triggers, or a change in policy profile. As a result, MAG2 requests attachment of if2 to session2 by sending a PBU to LMA. 6. because the MN add no session2 previously, the LMA creates session 2 and allocates a prefix for it. The prefix pref2 is sent back to MAG2 in the PBA: =A0 =A0 =A0 =A0 =A0Session2: [Pref2, MAG2-IF2] 7. Flow2 starts over if2 with prefix2. 8. Attachment of if1 to session2 is requested by either of MN requests via L2 triggers, or a change in policy profile. As a result, MAG1 requests attachment of if1 to session2 by sending a PBU to LMA. 9. Because the MN already has session 2, the LMA updates session2 with if1: =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2-IF2, MAG1-IF1] 10. At any point, the LMA decides to move Flow2 between two interfaces of session 2, and it does so. That's all that needed. It maps perfectly to 3GPP. If you have in mind a different system in whcih that doesn't map, please let me know. --julien On Tue, Feb 8, 2011 at 8:25 AM, wrote: > Hi, > > Going through this long thread :-), it seems we could agree on the follow= ing (just a tentative to summarize): > > Sessions should be created/updated with all available interfaces. Rewriti= ng Tran's example: when the MN attaches to MAG1 via If1, the LMA creates se= ssion 1: > > =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] > > Then, if the MN attaches to MAG2 via If2, the LMA creates session 2 with = both If1 and If2. The LMA also updates session 1 with If2: > > =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] > =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2, IF1] > > MAG2 receives prefixes 1 and 2 in PBA but MAG1 is not sending PBU. So, if= the LMA wants to move flow with Pref2 from if2 to If1, the LMA needs to pr= ovide Pref2 to MAG1. Also, the LMA should be able to create new sessions wi= th already up interfaces, e.g. if1 and if2. To address both issues, PBU fro= m MAG1 could be triggered (triggering is to be clarified) or we could defin= e LMA/MAG specific L3 signalling (FMI/FMA). > > My 2 cents, > Pierrick > >> -----Message d'origine----- >> De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la pa= rt >> de Youn-Hee Han >> Envoy=E9=A0: mardi 8 f=E9vrier 2011 12:00 >> =C0=A0: 'Julien Laganier'; 'Rajeev Koodli' >> Cc=A0: netext@ietf.org; Basavaraj.Patil@nokia.com >> Objet=A0: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netex= t- >> pmipv6-flowmob as WG doc >> >> Hi Julien, >> >> > -----Original Message----- >> > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Beha= lf >> > Of Julien Laganier >> > Sent: Tuesday, February 08, 2011 1:38 PM >> > To: Rajeev Koodli >> > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com >> > Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos- >> > netext-pmipv6-flowmob as WG doc >> > >> > On Mon, Feb 7, 2011 at 6:15 PM, Rajeev Koodli wrot= e: >> > > >> > > If flow mobility has nothing do with prefix management, I am lost. >> > >> > No reason to be lost: Prefix management is how do I get prefix for the >> > MN. Flow mobility is how to I move flows across interfaces. The two >> > needs not to be intertwined together, as I've shown in my other notes. >> > E.g., I can do flow mobility without adding/deleting prefixes from >> > sessions, and vice versa. >> >> Yes, I agree with you. Flow mobility is how to move flows across interfa= ce. >> So, I thought that it would be better to define "a flow" exactly in nete= xt >> WG prior to discuss flow mobility management. As the definition of "a >> flow", >> all I can think is a five-tuple plus something. If we assume that it is >> correct, I think that flow mobility and prefix addition are inevitably >> tied. >> As you know, RFC5213 (and IPv6 protocol spec) already allow to assign >> multiple prefixes across multiple interfaces of an MN. Yes, I also agree >> with you that in real-world (3GPP), there may be no need to assign >> multiple >> prefixes into an MN. (if somebody knows its necessity, please tell me wh= en >> it should happen). So, flow mobility can be done without adding prefixes= . >> However, different interfaces are allowed to be assigned different >> prefixes >> by RFC 5213 and IPv6 spec. We can't expect what kind of prefixes an MAG >> advertises. Therefore, sometimes, we need prefix addition to move a flow >> to >> a new interface of which MAG does not yet advertise the prefix of the fl= ow >> being moved. >> >> (snip...) >> >> > >> I see no reason to depart from that in the context of extending the >> > >> protocol to support mobility, nor I am aware of any system >> > >> architecture that would require this capability. >> > > >> > > Okay, see your position. I see it differently. I don't need to be >> > > bound by some "presumed implementation model" of PMIP6 and limit >> > > myself *only* to a prefix assignment model you are imagining. >> > >> > It's not an implementation model, it is a protocol model, and it's not >> > imaginary. Implementation has nothing to do with this. >> > >> > There's no reason to extend prefix assignment model to do flow mobilit= y >> > unless you can point me out in which real world context your scenario >> > actually happens. >> >> As I insisted in the old mail, I agree with Julien in this regard. Curre= nt >> draft allows too much space regarding the prefix allocation model (uniqu= e, >> shared, and hybrid). When a flow should be moved to a new interface and >> the >> prefix which the flow uses is not yet advertised by the new MAG, just >> inform >> the prefix to the MAG and thus make it advertise the prefix and setup th= e >> tunnel based on the new prefix. That's all!. If the prefix is already >> advertised by the MAG, there is nothing to do and just move the flow. Th= is >> behaviors are very natural one when we want to support IP-level mobility= . >> >> > >> If this is something really important, the WG can be rechartered to >> > >> work on a different extension that would allow adding/removing >> > >> prefixes from existing PMIPv6 sessions. >> > > >> > > Huh.. What in the current charter forces us not to have the LMA >> > > add/refresh/delete a prefix on-demand? >> > >> > Engineering is about finding a solution to a problem. Adding/deleting >> > prefix on-demand is not a solution to flow mobility. I've shown you ho= w >> > to do flow mobility without this capability. >> >> From the viewpoint of protocol, I think that at least, prefix addition t= o >> an >> interface is a necessary function to support flow mobility, as I explain= ed >> above. But, it does not mean prefix addition should happen always whenev= er >> flow mobility occurs. It is sometimes needed. >> >> > Now a different engineering problem would be: how to add/delete prefix= es >> > to a PMIPv6 session, and that would be useful for e.g. >> > renumbering. This is a different problem that we haven't been chartere= d >> > to work on. >> >> Prefix addition is just prefix addition. IMHO, renumbering is closer to >> prefix change. We just harness that function to support IP-level mobilit= y. >> >> Youn-Hee >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > From cjbc@it.uc3m.es Tue Feb 8 15:35:54 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 782A83A68B0 for ; Tue, 8 Feb 2011 15:35:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.056 X-Spam-Level: X-Spam-Status: No, score=-4.056 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdu22A-r04b8 for ; Tue, 8 Feb 2011 15:35:52 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 2D0063A67AD for ; Tue, 8 Feb 2011 15:35:52 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.3] (213.37.82.169.static.user.ono.com [213.37.82.169]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 4CFDDC27AF6; Wed, 9 Feb 2011 00:35:57 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: pierrick.seite@orange-ftgroup.com In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-clZc9XnAHHtiQuHB0eY6" Organization: Universidad Carlos III de Madrid Date: Wed, 09 Feb 2011 00:37:05 +0100 Message-ID: <1297208225.5169.78.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17944.000 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 08 Feb 2011 23:35:54 -0000 --=-clZc9XnAHHtiQuHB0eY6 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Pierrick, Thanks for the summary. I agree with your summarized view. Carlos On Tue, 2011-02-08 at 17:25 +0100, pierrick.seite@orange-ftgroup.com wrote: > Hi, >=20 > Going through this long thread :-), it seems we could agree on the follow= ing (just a tentative to summarize): >=20 > Sessions should be created/updated with all available interfaces. Rewriti= ng Tran's example: when the MN attaches to MAG1 via If1, the LMA creates se= ssion 1: >=20 > Session1: [Pref1, MAG1, IF1] >=20 > Then, if the MN attaches to MAG2 via If2, the LMA creates session 2 with = both If1 and If2. The LMA also updates session 1 with If2:=20 >=20 > Session1: [Pref1, MAG1, IF1, IF2] > Session2: [Pref2, MAG2, IF2, IF1] >=20 > MAG2 receives prefixes 1 and 2 in PBA but MAG1 is not sending PBU. So, if= the LMA wants to move flow with Pref2 from if2 to If1, the LMA needs to pr= ovide Pref2 to MAG1. Also, the LMA should be able to create new sessions wi= th already up interfaces, e.g. if1 and if2. To address both issues, PBU fro= m MAG1 could be triggered (triggering is to be clarified) or we could defin= e LMA/MAG specific L3 signalling (FMI/FMA). >=20 > My 2 cents, > Pierrick >=20 > > -----Message d'origine----- > > De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la par= t > > de Youn-Hee Han > > Envoy=E9 : mardi 8 f=E9vrier 2011 12:00 > > =C0 : 'Julien Laganier'; 'Rajeev Koodli' > > Cc : netext@ietf.org; Basavaraj.Patil@nokia.com > > Objet : Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext= - > > pmipv6-flowmob as WG doc > >=20 > > Hi Julien, > >=20 > > > -----Original Message----- > > > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Beh= alf > > > Of Julien Laganier > > > Sent: Tuesday, February 08, 2011 1:38 PM > > > To: Rajeev Koodli > > > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > > > Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos- > > > netext-pmipv6-flowmob as WG doc > > > > > > On Mon, Feb 7, 2011 at 6:15 PM, Rajeev Koodli wro= te: > > > > > > > > If flow mobility has nothing do with prefix management, I am lost. > > > > > > No reason to be lost: Prefix management is how do I get prefix for th= e > > > MN. Flow mobility is how to I move flows across interfaces. The two > > > needs not to be intertwined together, as I've shown in my other notes= . > > > E.g., I can do flow mobility without adding/deleting prefixes from > > > sessions, and vice versa. > >=20 > > Yes, I agree with you. Flow mobility is how to move flows across interf= ace. > > So, I thought that it would be better to define "a flow" exactly in net= ext > > WG prior to discuss flow mobility management. As the definition of "a > > flow", > > all I can think is a five-tuple plus something. If we assume that it is > > correct, I think that flow mobility and prefix addition are inevitably > > tied. > > As you know, RFC5213 (and IPv6 protocol spec) already allow to assign > > multiple prefixes across multiple interfaces of an MN. Yes, I also agre= e > > with you that in real-world (3GPP), there may be no need to assign > > multiple > > prefixes into an MN. (if somebody knows its necessity, please tell me w= hen > > it should happen). So, flow mobility can be done without adding prefixe= s. > > However, different interfaces are allowed to be assigned different > > prefixes > > by RFC 5213 and IPv6 spec. We can't expect what kind of prefixes an MAG > > advertises. Therefore, sometimes, we need prefix addition to move a flo= w > > to > > a new interface of which MAG does not yet advertise the prefix of the f= low > > being moved. > >=20 > > (snip...) > >=20 > > > >> I see no reason to depart from that in the context of extending th= e > > > >> protocol to support mobility, nor I am aware of any system > > > >> architecture that would require this capability. > > > > > > > > Okay, see your position. I see it differently. I don't need to be > > > > bound by some "presumed implementation model" of PMIP6 and limit > > > > myself *only* to a prefix assignment model you are imagining. > > > > > > It's not an implementation model, it is a protocol model, and it's no= t > > > imaginary. Implementation has nothing to do with this. > > > > > > There's no reason to extend prefix assignment model to do flow mobili= ty > > > unless you can point me out in which real world context your scenario > > > actually happens. > >=20 > > As I insisted in the old mail, I agree with Julien in this regard. Curr= ent > > draft allows too much space regarding the prefix allocation model (uniq= ue, > > shared, and hybrid). When a flow should be moved to a new interface and > > the > > prefix which the flow uses is not yet advertised by the new MAG, just > > inform > > the prefix to the MAG and thus make it advertise the prefix and setup t= he > > tunnel based on the new prefix. That's all!. If the prefix is already > > advertised by the MAG, there is nothing to do and just move the flow. T= his > > behaviors are very natural one when we want to support IP-level mobilit= y. > >=20 > > > >> If this is something really important, the WG can be rechartered t= o > > > >> work on a different extension that would allow adding/removing > > > >> prefixes from existing PMIPv6 sessions. > > > > > > > > Huh.. What in the current charter forces us not to have the LMA > > > > add/refresh/delete a prefix on-demand? > > > > > > Engineering is about finding a solution to a problem. Adding/deleting > > > prefix on-demand is not a solution to flow mobility. I've shown you h= ow > > > to do flow mobility without this capability. > >=20 > > From the viewpoint of protocol, I think that at least, prefix addition = to > > an > > interface is a necessary function to support flow mobility, as I explai= ned > > above. But, it does not mean prefix addition should happen always whene= ver > > flow mobility occurs. It is sometimes needed. > >=20 > > > Now a different engineering problem would be: how to add/delete prefi= xes > > > to a PMIPv6 session, and that would be useful for e.g. > > > renumbering. This is a different problem that we haven't been charter= ed > > > to work on. > >=20 > > Prefix addition is just prefix addition. IMHO, renumbering is closer to > > prefix change. We just harness that function to support IP-level mobili= ty. > >=20 > > Youn-Hee > >=20 > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-clZc9XnAHHtiQuHB0eY6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1R06EACgkQNdy6TdFwT2cK2gCaAyLXQfydGDQbLRpv5VrznTX7 DxEAoNXYvGTAyw9mc2/hGsIPNzLDBBX3 =ttBN -----END PGP SIGNATURE----- --=-clZc9XnAHHtiQuHB0eY6-- From cjbc@it.uc3m.es Tue Feb 8 15:36:00 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC8CD3A68B0 for ; Tue, 8 Feb 2011 15:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.056 X-Spam-Level: X-Spam-Status: No, score=-4.056 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvzdy+HwVJeE for ; Tue, 8 Feb 2011 15:35:59 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 8345D3A68D1 for ; Tue, 8 Feb 2011 15:35:59 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.3] (213.37.82.169.static.user.ono.com [213.37.82.169]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 0720175A109; Wed, 9 Feb 2011 00:36:06 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Julien Laganier In-Reply-To: References: <1297130408.3099.144.camel@acorde.it.uc3m.es> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-TPNHePy0SCEHNB+Mtn6L" Organization: Universidad Carlos III de Madrid Date: Wed, 09 Feb 2011 00:37:13 +0100 Message-ID: <1297208233.5169.79.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17944.000 Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 08 Feb 2011 23:36:00 -0000 --=-TPNHePy0SCEHNB+Mtn6L Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Julien, On Mon, 2011-02-07 at 20:40 -0800, Julien Laganier wrote: > 2011/2/7 Carlos Jes=FAs Bernardos Cano : > > Hi Julien, > > > > On Mon, 2011-02-07 at 17:51 -0800, Julien Laganier wrote: > >> On Mon, Feb 7, 2011 at 5:54 PM, Rajeev Koodli wrot= e: > >> > > >> > > >> > On 2/7/11 5:18 PM, "Julien Laganier" wrote: > >> > > >> >>> > >> >>> Right. > >> >>> > >> >>> The LMA adding a prefix to an existing session should be supported= . It's not > >> >>> very different from a router advertising a new prefix on an interf= ace to its > >> >>> host. > >> >>> > >> >>> I might still be missing something here.. > >> >> > >> >> I don't know why this should be supported... It is not supported in > >> >> RFC 5213 and has nothing to do with flow mobility. I have shown how > >> >> one can do flow mobility without this capability. What substantiate= s > >> >> the claim that this should be supported? > >> >> > >> > > >> > Hmm.. I hope we are not making a requirement here that if something = is not > >> > supported in RFC 5213, it should not be worked on here. > >> > Also, I don't think we are required to accept a single solution beca= use it > >> > fits some pre-existing model; we are working to add new functions wi= thin > >> > some reasonable bounds which we all can agree on. > >> > >> Technically speaking dynamic prefix management is a different feature > >> from flow mobility, thus if specified it should go in a different spec > >> so that one can implement RFC 5213 with dynamic prefix management but > >> without flow mobility. > >> > >> On a more procedural note, I hope we can all agree that there is > >> indeed a charter that details what we are working on and that we are > >> not packing arbitrary features that are not listed as deliverables > >> into the protocol. We are chartered to do PMIPv6 flow mobility, not > >> dynamic prefix management for PMIPv6. > > > > I'm sorry, but solution described in our draft (of course you may like > > it or not, we can agree/disagree on its technical approach, etc.) is > > perfectly within the scope of the charter. It is not fair you consider > > it out of scope. >=20 > You are mixing dynamic prefix management with flow mobility into one > protocol extensions where they are not required to. Whether they are required or not depends on the assumptions of the scenario. >=20 > Can you point me to a real world usecase where you actually need to > add/delete prefixes to do prefix management? I read 3GPP specs but I > don't know where this is needed. Is this needed somewhere else? Can you point me a scenario which cannot be supported with our approach (which requires less L2 triggers to be in place)? Carlos >=20 > --julien --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-TPNHePy0SCEHNB+Mtn6L Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1R06kACgkQNdy6TdFwT2d3aACfVfWay96duPY2ozRoFG/yDle5 tOUAn0FKV+8VwGcBaODPDva5xldWh6bk =B1W7 -----END PGP SIGNATURE----- --=-TPNHePy0SCEHNB+Mtn6L-- From cjbc@it.uc3m.es Tue Feb 8 15:36:04 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5D3F3A67AD for ; Tue, 8 Feb 2011 15:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.056 X-Spam-Level: X-Spam-Status: No, score=-4.056 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9HFeH9k3R70 for ; Tue, 8 Feb 2011 15:36:03 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 922533A68D5 for ; Tue, 8 Feb 2011 15:36:02 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.3] (213.37.82.169.static.user.ono.com [213.37.82.169]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id D99B37F2BB5; Wed, 9 Feb 2011 00:36:08 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Julien Laganier In-Reply-To: References: <1296920514.3773.26.camel@acorde.it.uc3m.es> <1297017501.4715.2.camel@acorde.it.uc3m.es> <1297019696.4715.5.camel@acorde.it.uc3m.es> <1297115574.3099.3.camel@acorde.it.uc3m.es> <1297126584.3099.96.camel@acorde.it.uc3m.es> <1297129998.3099.140.camel@acorde.it.uc3m.es> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-xaCe9ZR/kdBMOV7qUoG3" Organization: Universidad Carlos III de Madrid Date: Wed, 09 Feb 2011 00:37:16 +0100 Message-ID: <1297208236.5169.80.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17944.000 Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 08 Feb 2011 23:36:04 -0000 --=-xaCe9ZR/kdBMOV7qUoG3 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Julien, I agree with all your points below, in the sense that it's true that flow mobility could be enabled by relying on all those L2 triggers. Where I disagree is why we need to do so if we can do it without putting those strong requirements. I understand relying on L2 when it is that or modifying the IP stack of the MN, but not in any other case. Besides, the modifications we propose are fairly simplex. Carlos On Mon, 2011-02-07 at 20:24 -0800, Julien Laganier wrote: > 2011/2/7 Carlos Jes=FAs Bernardos Cano : > > Hi Julien, > > > > On Mon, 2011-02-07 at 17:14 -0800, Julien Laganier wrote: > >> Hi Carlos, > >> > >> 2011/2/7 Carlos Jes=FAs Bernardos Cano : > >> > Hi Julien, > >> > > >> > On Mon, 2011-02-07 at 15:56 -0800, Julien Laganier wrote: > >> >> Hi Carlos, > >> >> > >> >> 2011/2/7 Carlos Jes=FAs Bernardos Cano : > >> >> > Hi Julien, > >> >> > > >> >> > On Mon, 2011-02-07 at 12:43 -0800, Julien Laganier wrote: > >> >> >> Hi Carlos, > >> >> >> > >> >> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : > >> >> >> > Hi Julien, > >> >> >> > > >> >> >> > On Sun, 2011-02-06 at 10:56 -0800, Julien Laganier wrote: > >> >> >> >> Hi Carlos, > >> >> >> >> > >> >> >> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : > >> >> >> >> > Hi Julien, > >> >> >> >> > > >> >> >> >> > On Sun, 2011-02-06 at 10:11 -0800, Julien Laganier wrote: > >> >> >> >> >> 2011/2/5 Carlos Jes=FAs Bernardos Cano : > >> >> >> >> >> > On Fri, 2011-02-04 at 12:59 -0800, Julien Laganier wrote= : > >> >> >> >> >> >> On Fri, Feb 4, 2011 at 10:40 AM, Rajeev Koodli wrote: > >> >> >> >> >> >> > > >> >> >> >> >> >> > > >> >> >> >> >> >> > On 2/4/11 10:16 AM, "Julien Laganier" wrote: > >> >> >> >> >> >> > > >> >> >> >> >> >> >>> > >> >> >> >> >> >> >>> The LMA needs to provide the prefix info to the MAG= . This can be either in > >> >> >> >> >> >> >>> PBA or in FMI (if not provided in PBA). > >> >> >> >> >> >> >> > >> >> >> >> >> >> >> The LMA can provide the prefix to the MAG at session= creation, i.e., > >> >> >> >> >> >> >> in the PBU. This information does not need to be (re= )conveyed at flow > >> >> >> >> >> >> >> movement. > >> >> >> >> >> >> > > >> >> >> >> >> >> > If it was conveyed in PBA, surely you don't reconvey. > >> >> >> >> >> >> > If the prefix was not conveyed in PBA (as in the exam= ple we discussed > >> >> >> >> >> >> > y'day), you provide it in FMI. > >> >> >> >> >> >> > >> >> >> >> >> >> IMO the prefix can always be conveyed in the PBA that i= s received in > >> >> >> >> >> >> response to the PBU attaching an interface to a PMIPv6 = flow mobility > >> >> >> >> >> >> session. > >> >> >> >> >> > > >> >> >> >> >> > What about the following scenario: > >> >> >> >> >> > > >> >> >> >> >> > MN has two interfaces: if1 and if2. if1 attaches to MAG1= , a mobility > >> >> >> >> >> > session is created, pref1 is delegated. Some point in ti= me later, if2 > >> >> >> >> >> > attaches to MAG2, new mobility sesison created, pref2 is= delegated. > >> >> >> >> >> > flowX addressed to pref2 wants to be moved to if1. In th= is case we need > >> >> >> >> >> > some signaling from LMA to MAG1 that cannot be conveted = in PBA. > >> >> >> >> >> > >> >> >> >> >> If flow X addresssed to pref2 wants to be moved to if1, fi= rst thing to > >> >> >> >> >> do is to attach the if1 to the session corresponding to pr= ef2, so MAG1 > >> >> >> >> >> sends a PBU, and LMA sends back a PBA with the prefix set = of the > >> >> >> >> >> session (pref2.) > >> >> >> >> > > >> >> >> >> > if1 was previously attached to MAG1 (and LMA delegated pref= 1). How can > >> >> >> >> > MAG1 know when LMA wants to move flow X to if1 (to send a P= BU)? Some > >> >> >> >> > signaling is needed there. > >> >> >> >> > >> >> >> >> if1 was attached to MAG1 and had session S1 with prefix pref1= . When > >> >> >> >> if2 is attached to MAG2, if a different prefix pref2 is alloc= ated, > >> >> >> >> that is a different session S2. LMA cannot move a flow from s= ession S2 > >> >> >> >> to a MAG that isn't part of that session. So first thing to d= o after > >> >> >> >> S2 is created, if there's a desire to move flows across other= MAGs, is > >> >> >> > > >> >> >> > Right, our draft uses FMI signalling to add if1 to the session= (we use > >> >> >> > the flowmob cache structure of this purpose). We are discussin= g about > >> >> >> > two ways of doing exactly the same thing. However, in yours, y= ou need > >> >> >> > the MAG to take the initiative, while ours also supports the L= MA > >> >> >> > initiate the flow movement. > >> >> >> > >> >> >> You seem to be conflating session management and flow movement. > >> >> >> > >> >> >> In my approach, session management is MAG initiated, as it has b= een in > >> >> >> the past with PMIPv6. Once a session exists across an interface = set, > >> >> >> flow movement can be LMA-initiated at any time from one interfac= e in > >> >> >> the set to another. > >> >> >> > >> >> >> I do not see a reason to depart from RFC 5213 and allow the LMA = to > >> >> >> initiate session management (except for purposes of revocation b= ut > >> >> >> that is supported already.) > >> >> > > >> >> > I see the reason to add it in order to support the scenarios I me= ntioned > >> >> > in my example. Those cannot be supported with RFC5213 model, as t= hey > >> >> > require first the MAG to send a PBU. We need either new signaling= from > >> >> > the LMA to the MAG to make the MAG aware of the required prefixes= to > >> >> > support flow mobility, or a trigger from the LMA to the MAG, so t= he MAG > >> >> > can send a PBU and then follow your model. > >> >> > >> >> In the systems I know the MAG is the entity that creates attaches a= MN > >> >> interface to a session and therefore I do not understand why you wo= uld > >> >> need the LMA to attach an interface to a session. The LMA has no > >> >> interface with the interface... That's a MAG duty. > >> >> > >> >> In which system is the scenario you're outlining useful? > >> > > >> > I must be really bad at explaining this... > >> > > >> > Lets consider the following scenario: > >> > > >> > - MN attaches if1 to MAG1. As a result, if1 is attached to the sessi= on > >> > with MAG1. Pref1::/64 is delegated to if1. > >> > > >> > - Later on, MN attaches if2 to MAG2. As a result if2 is attached to = the > >> > session with MAG2. Pref2::/64 is delegated to if2. > >> > > >> > (nothing new so far, no flow mobility) > >> > > >> > - Some point in time later, LMA wants to move a flow X, addressed to > >> > pref2::/64 to if1. MAG1 cannot send a PBU at that particular moment = (how > >> > can it know it has to?) to make MAG1 attach if1 to session with pref= 2. > >> > Therefore, we need some signaling, initiated by the LMA, to make tha= t > >> > flow movement happen. > >> > > >> > How can this scenario be supported with your approach? I fail to see= it. > >> > >> This scenario can't be supported without if1 being part of session2 > >> where the pref2 belongs. So what's needed is that if1 be attached to > >> session2 such that flows bound to prefix2 can move between if1 and > >> if2. As I've indicated to you in the systems I am familiar with the > >> MAG is the entity that creates session, which results in this > >> scenario: > >> > >> - MN attaches if1 to session1. As a result, MAG1 signals to LMA that > >> if1 is attached to the session1. Pref1::/64 is delegated to session1. > >> > >> - Later on MN wants another session. As a result, MAG1 signals to LMA > >> that if1 is attached to the session2. Pref2::/64 is delegated to > >> session2. > > > > How does the MN express that "desire of another session"? >=20 > L2 triggers. As per RFC 5213. >=20 > > Besides, how does the MN knows that it'd require that session, before e= ven > > considering attaching the second interface if2? >=20 > The trigger to session2 creation is not attachment of a second > interface, it's the will of having a different session from the one > that existed in the first place, session1 aka default session. If > there will be flows in session2 that will need to get on if1 or if2 at > some point, you can simply create session2 whenever the first > interface in the set is brought up. Conversely, you can tear down the > session whenever both interfaces are down. Not sure what is so > complex. >=20 > > With current RFC5213, I don't know how two different mobility sessions > > referring to the same interface of the MN can be created. I see how > > different prefixes can belong to the same mobility sessions, though. Ar= e > > you already referring here to an extension to current PMIPv6? >=20 > Yes. You define a session as a set of prefixes that are valid over a > set of interfaces. This is the only thing that you need to do to > support flow mobility, no need for FMI/FMA and LMA initiated > signaling. >=20 > >> - Later on MN attaches if2 to session2. As a result, MAG2 signals to > >> LMA that if2 is attached to the session2. Pref2::/64 is now valid over > >> both if1 and if2 for session2. > >> > > > > MN cannot really "attach" anything, it is unaware of PMIPv6 operations > > (at least its IP stack). >=20 > Right, layer 3 of the MN is unaware. Layer 2 (virtual interfaces etc.) > is, otherwise none of that can possibly work. >=20 > > How could the MAGs know what interfaces should be added to which > > sessions? >=20 > A MAG attaches interfaces to session based on the policy profile or L2 > triggers. If neither the policy profile nor L2 triggers says anything > about multiple session, then I guess the MAG simply attaches whatever > interfaces comes up to the only session that the MN has. We do not > need to make this more complicated than needed to be. >=20 > > I'm really sorry that I still don't get your point, but in > > your reasoning it seems that events just occur in the right order to > > support flow mobility, but in reality MAGs do not know about all the > > interfaces a MN has, which ones are attached to the same PMIPv6 domain, > > and so on and so forth. >=20 > In reality MAG doesn't need to know about all the interfaces the MN > has. MAG simply need to knows what interface should be attached to > which session. It knows this via L2 triggers or policy profile. >=20 > > Flow mobility should be controlled by the LMA, > > which is the only entity that can understand triggers (PBUs can be used > > as triggers as well) and "add" interfaces to mobility sessions. >=20 > Interface being attached to a session is controlled by the MAG which > is the only entity that knows that an interface is actually attached. > Flow mobility decision can be taken entirely at LMA and the MAG needs > not to know. >=20 > --julien --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-xaCe9ZR/kdBMOV7qUoG3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1R06wACgkQNdy6TdFwT2ee0QCfRZSJgVt/+r1p0YE/vrUnGCwH 4H8AnR2btP9neskEvcZdMy8w7LJ4lydI =1bM/ -----END PGP SIGNATURE----- --=-xaCe9ZR/kdBMOV7qUoG3-- From rkoodli@cisco.com Tue Feb 8 16:53:44 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 590D53A6837 for ; Tue, 8 Feb 2011 16:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.901 X-Spam-Level: X-Spam-Status: No, score=-109.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aflUo+SOrGkh for ; Tue, 8 Feb 2011 16:53:42 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id ED1CA3A6836 for ; Tue, 8 Feb 2011 16:53:41 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmUBAFB0UU2tJXG//2dsb2JhbACWZ412ZnOhZJs4hVoEhHuGb4M1 Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rtp-iport-2.cisco.com with ESMTP; 09 Feb 2011 00:53:48 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p190rmUi012722; Wed, 9 Feb 2011 00:53:48 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Feb 2011 18:53:48 -0600 Received: from 10.21.69.113 ([10.21.69.113]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Wed, 9 Feb 2011 00:53:48 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 08 Feb 2011 17:12:34 -0800 From: Rajeev Koodli To: , , Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQIo/NBbQQqyeWpvtmcXp7I2XAzY+gJkMbtkAO4ljUKTImNb0IAAaHJQgACUtQQ= In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 09 Feb 2011 00:53:48.0554 (UTC) FILETIME=[CFAF3EA0:01CBC7F3] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 00:53:44 -0000 Hello Pierrick, Someone had to do this to make progress :-) I largely agree, please see below: On 2/8/11 8:25 AM, "pierrick.seite@orange-ftgroup.com" > Sessions should be created/updated with all available interfaces. Rewriti= ng > Tran's example: when the MN attaches to MAG1 via If1, the LMA creates ses= sion > 1: >=20 > Session1: [Pref1, MAG1, IF1] >=20 > Then, if the MN attaches to MAG2 via If2, the LMA creates session 2 with = both > If1 and If2. The LMA also updates session 1 with If2: >=20 > Session1: [Pref1, MAG1, IF1, IF2] > Session2: [Pref2, MAG2, IF2, IF1] >=20 > MAG2 receives prefixes 1 and 2 in PBA This is fine with me, i.e., LMA sending Pref2 and Pref1 at this time. As I have stated before, I should also be able to *not* send Pref1 to MAG2 at this time (attach), i.e., send it whenever LMA wants. > but MAG1 is not sending PBU. So, if the > LMA wants to move flow with Pref2 from if2 to If1, the LMA needs to provi= de > Pref2 to MAG1. Also, the LMA should be able to create new sessions with > already up interfaces, e.g. if1 and if2. To address both issues, PBU from= MAG1 > could be triggered (triggering is to be clarified) or we could define LMA= /MAG > specific L3 signalling (FMI/FMA). >=20 I would like LMA-initiated signaling (FMI/FMA) for this (i.e., signaling to MAG1 with Pref2) as well as for the above (i.e., being able to signal MAG2 with Pref1) *whenever* the LMA wants. > My 2 cents, Thanks, -Rajeev > Pierrick >=20 >> -----Message d'origine----- >> De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part >> de Youn-Hee Han >> Envoy=E9=A0: mardi 8 f=E9vrier 2011 12:00 >> =C0=A0: 'Julien Laganier'; 'Rajeev Koodli' >> Cc=A0: netext@ietf.org; Basavaraj.Patil@nokia.com >> Objet=A0: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext- >> pmipv6-flowmob as WG doc >>=20 >> Hi Julien, >>=20 >>> -----Original Message----- >>> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behal= f >>> Of Julien Laganier >>> Sent: Tuesday, February 08, 2011 1:38 PM >>> To: Rajeev Koodli >>> Cc: netext@ietf.org; Basavaraj.Patil@nokia.com >>> Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos- >>> netext-pmipv6-flowmob as WG doc >>>=20 >>> On Mon, Feb 7, 2011 at 6:15 PM, Rajeev Koodli wrote= : >>>>=20 >>>> If flow mobility has nothing do with prefix management, I am lost. >>>=20 >>> No reason to be lost: Prefix management is how do I get prefix for the >>> MN. Flow mobility is how to I move flows across interfaces. The two >>> needs not to be intertwined together, as I've shown in my other notes. >>> E.g., I can do flow mobility without adding/deleting prefixes from >>> sessions, and vice versa. >>=20 >> Yes, I agree with you. Flow mobility is how to move flows across interfa= ce. >> So, I thought that it would be better to define "a flow" exactly in nete= xt >> WG prior to discuss flow mobility management. As the definition of "a >> flow", >> all I can think is a five-tuple plus something. If we assume that it is >> correct, I think that flow mobility and prefix addition are inevitably >> tied. >> As you know, RFC5213 (and IPv6 protocol spec) already allow to assign >> multiple prefixes across multiple interfaces of an MN. Yes, I also agree >> with you that in real-world (3GPP), there may be no need to assign >> multiple >> prefixes into an MN. (if somebody knows its necessity, please tell me wh= en >> it should happen). So, flow mobility can be done without adding prefixes= . >> However, different interfaces are allowed to be assigned different >> prefixes >> by RFC 5213 and IPv6 spec. We can't expect what kind of prefixes an MAG >> advertises. Therefore, sometimes, we need prefix addition to move a flow >> to >> a new interface of which MAG does not yet advertise the prefix of the fl= ow >> being moved. >>=20 >> (snip...) >>=20 >>>>> I see no reason to depart from that in the context of extending the >>>>> protocol to support mobility, nor I am aware of any system >>>>> architecture that would require this capability. >>>>=20 >>>> Okay, see your position. I see it differently. I don't need to be >>>> bound by some "presumed implementation model" of PMIP6 and limit >>>> myself *only* to a prefix assignment model you are imagining. >>>=20 >>> It's not an implementation model, it is a protocol model, and it's not >>> imaginary. Implementation has nothing to do with this. >>>=20 >>> There's no reason to extend prefix assignment model to do flow mobility >>> unless you can point me out in which real world context your scenario >>> actually happens. >>=20 >> As I insisted in the old mail, I agree with Julien in this regard. Curre= nt >> draft allows too much space regarding the prefix allocation model (uniqu= e, >> shared, and hybrid). When a flow should be moved to a new interface and >> the >> prefix which the flow uses is not yet advertised by the new MAG, just >> inform >> the prefix to the MAG and thus make it advertise the prefix and setup th= e >> tunnel based on the new prefix. That's all!. If the prefix is already >> advertised by the MAG, there is nothing to do and just move the flow. Th= is >> behaviors are very natural one when we want to support IP-level mobility= . >>=20 >>>>> If this is something really important, the WG can be rechartered to >>>>> work on a different extension that would allow adding/removing >>>>> prefixes from existing PMIPv6 sessions. >>>>=20 >>>> Huh.. What in the current charter forces us not to have the LMA >>>> add/refresh/delete a prefix on-demand? >>>=20 >>> Engineering is about finding a solution to a problem. Adding/deleting >>> prefix on-demand is not a solution to flow mobility. I've shown you how >>> to do flow mobility without this capability. >>=20 >> From the viewpoint of protocol, I think that at least, prefix addition t= o >> an >> interface is a necessary function to support flow mobility, as I explain= ed >> above. But, it does not mean prefix addition should happen always whenev= er >> flow mobility occurs. It is sometimes needed. >>=20 >>> Now a different engineering problem would be: how to add/delete prefixe= s >>> to a PMIPv6 session, and that would be useful for e.g. >>> renumbering. This is a different problem that we haven't been chartered >>> to work on. >>=20 >> Prefix addition is just prefix addition. IMHO, renumbering is closer to >> prefix change. We just harness that function to support IP-level mobilit= y. >>=20 >> Youn-Hee >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext From julien.ietf@gmail.com Tue Feb 8 17:15:19 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 037623A6837 for ; Tue, 8 Feb 2011 17:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0fE9vx1phIU for ; Tue, 8 Feb 2011 17:15:18 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id E5DB73A6836 for ; Tue, 8 Feb 2011 17:15:17 -0800 (PST) Received: by fxm9 with SMTP id 9so7238418fxm.31 for ; Tue, 08 Feb 2011 17:15:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DEn4bTf6Olero+IK/Hj8LQ4VCqmpXm03lNWddp43UXM=; b=U/TKXTcLZkMTfy+GaHbl65KeqBg5FFm0ZkVJWyQ2zcZtPgkccuOo8kl0ZjC+XBkqD4 g6xjjVSLC/YjFxh180nfXBlEEHCaNFfLBJ2W7j7COTyThKlW6mKkhwnBimtiJ3YQIfGE bCHnDftTbBXE6aH2tDnso0mR0TQVsd9OtWoBQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=iCxtcWGSrDfR0J9bI3AxtiFzsu5P4GyvY39v23HsdjmftvIpDt5l7FhRxqqNFmTnLo bkTCqktllWTBtQvLe5k6EOcj8//fHmcoOnWRt/FuWI88UJo1+FErdLj64EExaOmY/HAR MxQW8s8bllHOhFQygaJbYuQaj/GbjDxHroW0o= MIME-Version: 1.0 Received: by 10.103.243.16 with SMTP id v16mr13270908mur.57.1297214125357; Tue, 08 Feb 2011 17:15:25 -0800 (PST) Received: by 10.103.221.9 with HTTP; Tue, 8 Feb 2011 17:15:25 -0800 (PST) In-Reply-To: <1297208233.5169.79.camel@acorde.it.uc3m.es> References: <1297130408.3099.144.camel@acorde.it.uc3m.es> <1297208233.5169.79.camel@acorde.it.uc3m.es> Date: Tue, 8 Feb 2011 17:15:25 -0800 Message-ID: From: Julien Laganier To: cjbc@it.uc3m.es Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 01:15:19 -0000 Hi Carlos, 2011/2/8 Carlos Jes=FAs Bernardos Cano : > Hi Julien, > [snip.] >> >> >> >> Technically speaking dynamic prefix management is a different feature >> >> from flow mobility, thus if specified it should go in a different spe= c >> >> so that one can implement RFC 5213 with dynamic prefix management but >> >> without flow mobility. >> >> >> >> On a more procedural note, I hope we can all agree that there is >> >> indeed a charter that details what we are working on and that we are >> >> not packing arbitrary features that are not listed as deliverables >> >> into the protocol. We are chartered to do PMIPv6 flow mobility, not >> >> dynamic prefix management for PMIPv6. >> > >> > I'm sorry, but solution described in our draft (of course you may like >> > it or not, we can agree/disagree on its technical approach, etc.) is >> > perfectly within the scope of the charter. It is not fair you consider >> > it out of scope. >> >> You are mixing dynamic prefix management with flow mobility into one >> protocol extensions where they are not required to. > > Whether they are required or not depends on the assumptions of the > scenario. Yes. And I'm saying that the scenario you assume doesn't address a real-world usecase. >> Can you point me to a real world usecase where you actually need to >> add/delete prefixes to do prefix management? I read 3GPP specs but I >> don't know where this is needed. Is this needed somewhere else? > > Can you point me a scenario which cannot be supported with our approach > (which requires less L2 triggers to be in place)? This is backward. It's not the role of a standard organization to pack in a standard specification a feature on the ground that it doesn't prevent to support scenario X. On the contrary we should deliver specification that are solving real world problems. Now I've been asking for a couple of days already what is the real-world usecase from which stems the pressing need to support addition/deletion of prefixes on one hand, and LMA deciding unilaterally to attach an existing session to another of the MN's interface on the other hand. So far I haven't got ANY answer besides statement that "this is needed", or "I want it". Should I take this state of affair as a confession that there's indeed no real usecase? --julien From julien.ietf@gmail.com Tue Feb 8 17:21:30 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1FF13A6892 for ; Tue, 8 Feb 2011 17:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OEXwL+xDq1e for ; Tue, 8 Feb 2011 17:21:28 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 534F63A688C for ; Tue, 8 Feb 2011 17:21:28 -0800 (PST) Received: by fxm9 with SMTP id 9so7243378fxm.31 for ; Tue, 08 Feb 2011 17:21:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ANcW7hWhZQ6s9fLh07k503nzbMC25xaodNWwFYblPbM=; b=XRazRsqK1ErtQXOfg9P8k37c6UT+49V+kSTBLotiC11QzlmFepmg6XYR0/Pq4YrZh5 VVKvUDf/1oqRv+352+bbc6BrGPBRCJRUBSrMhzLpGS/0G/t6A/LQsu8rc/o7cN+rTO9L yqHAfYKGhhzaQbdn8noXG3PYVK/CT6UiQp3yU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VuZACqqPU2S4UPTfJ5C2QHaxoKsOD0L52FiiOo6EJyPL1z5S+mFDdAzMltx5X0LkV4 o+3IvagcKjZT6UUVtOU2URyrBt+1L2JVPfIZWP5oiUYCNXTXP5Ff7wgtJvh9/7mBI6ii GOnibRpyGbsNwfeUjgDabQgoFSNP4hM+8cZls= MIME-Version: 1.0 Received: by 10.103.226.2 with SMTP id d2mr13425044mur.111.1297214495230; Tue, 08 Feb 2011 17:21:35 -0800 (PST) Received: by 10.103.221.9 with HTTP; Tue, 8 Feb 2011 17:21:35 -0800 (PST) In-Reply-To: <1297208236.5169.80.camel@acorde.it.uc3m.es> References: <1296920514.3773.26.camel@acorde.it.uc3m.es> <1297017501.4715.2.camel@acorde.it.uc3m.es> <1297019696.4715.5.camel@acorde.it.uc3m.es> <1297115574.3099.3.camel@acorde.it.uc3m.es> <1297126584.3099.96.camel@acorde.it.uc3m.es> <1297129998.3099.140.camel@acorde.it.uc3m.es> <1297208236.5169.80.camel@acorde.it.uc3m.es> Date: Tue, 8 Feb 2011 17:21:35 -0800 Message-ID: From: Julien Laganier To: cjbc@it.uc3m.es Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 01:21:30 -0000 Hi Carlos, I am glad to see you agree with me :-) You're actually proving my point. To run any of the flow mobility stuff on a host, you will need either layer 2 to hide the dissimilar interfaces (virtual interface thing), in which case you do have L2 triggers, or to modify the layer 3, which this WG is explicitly prevented from doing assuming that's even possible. So you need layer 2. And that is actually exactly how netext could get chartered to work on flow mobility, because we assumed layer 2 would be there to help with all the stuff we're not allowed to do at layer 3. --julien 2011/2/8 Carlos Jes=FAs Bernardos Cano : > Hi Julien, > > I agree with all your points below, in the sense that it's true that > flow mobility could be enabled by relying on all those L2 triggers. > Where I disagree is why we need to do so if we can do it without putting > those strong requirements. I understand relying on L2 when it is that or > modifying the IP stack of the MN, but not in any other case. Besides, > the modifications we propose are fairly simplex. > > Carlos > > On Mon, 2011-02-07 at 20:24 -0800, Julien Laganier wrote: >> 2011/2/7 Carlos Jes=FAs Bernardos Cano : >> > Hi Julien, >> > >> > On Mon, 2011-02-07 at 17:14 -0800, Julien Laganier wrote: >> >> Hi Carlos, >> >> >> >> 2011/2/7 Carlos Jes=FAs Bernardos Cano : >> >> > Hi Julien, >> >> > >> >> > On Mon, 2011-02-07 at 15:56 -0800, Julien Laganier wrote: >> >> >> Hi Carlos, >> >> >> >> >> >> 2011/2/7 Carlos Jes=FAs Bernardos Cano : >> >> >> > Hi Julien, >> >> >> > >> >> >> > On Mon, 2011-02-07 at 12:43 -0800, Julien Laganier wrote: >> >> >> >> Hi Carlos, >> >> >> >> >> >> >> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : >> >> >> >> > Hi Julien, >> >> >> >> > >> >> >> >> > On Sun, 2011-02-06 at 10:56 -0800, Julien Laganier wrote: >> >> >> >> >> Hi Carlos, >> >> >> >> >> >> >> >> >> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : >> >> >> >> >> > Hi Julien, >> >> >> >> >> > >> >> >> >> >> > On Sun, 2011-02-06 at 10:11 -0800, Julien Laganier wrote: >> >> >> >> >> >> 2011/2/5 Carlos Jes=FAs Bernardos Cano : >> >> >> >> >> >> > On Fri, 2011-02-04 at 12:59 -0800, Julien Laganier wrot= e: >> >> >> >> >> >> >> On Fri, Feb 4, 2011 at 10:40 AM, Rajeev Koodli wrote: >> >> >> >> >> >> >> > >> >> >> >> >> >> >> > >> >> >> >> >> >> >> > On 2/4/11 10:16 AM, "Julien Laganier" wrote: >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >>> >> >> >> >> >> >> >> >>> The LMA needs to provide the prefix info to the MA= G. This can be either in >> >> >> >> >> >> >> >>> PBA or in FMI (if not provided in PBA). >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> The LMA can provide the prefix to the MAG at sessio= n creation, i.e., >> >> >> >> >> >> >> >> in the PBU. This information does not need to be (r= e)conveyed at flow >> >> >> >> >> >> >> >> movement. >> >> >> >> >> >> >> > >> >> >> >> >> >> >> > If it was conveyed in PBA, surely you don't reconvey= . >> >> >> >> >> >> >> > If the prefix was not conveyed in PBA (as in the exa= mple we discussed >> >> >> >> >> >> >> > y'day), you provide it in FMI. >> >> >> >> >> >> >> >> >> >> >> >> >> >> IMO the prefix can always be conveyed in the PBA that = is received in >> >> >> >> >> >> >> response to the PBU attaching an interface to a PMIPv6= flow mobility >> >> >> >> >> >> >> session. >> >> >> >> >> >> > >> >> >> >> >> >> > What about the following scenario: >> >> >> >> >> >> > >> >> >> >> >> >> > MN has two interfaces: if1 and if2. if1 attaches to MAG= 1, a mobility >> >> >> >> >> >> > session is created, pref1 is delegated. Some point in t= ime later, if2 >> >> >> >> >> >> > attaches to MAG2, new mobility sesison created, pref2 i= s delegated. >> >> >> >> >> >> > flowX addressed to pref2 wants to be moved to if1. In t= his case we need >> >> >> >> >> >> > some signaling from LMA to MAG1 that cannot be conveted= in PBA. >> >> >> >> >> >> >> >> >> >> >> >> If flow X addresssed to pref2 wants to be moved to if1, f= irst thing to >> >> >> >> >> >> do is to attach the if1 to the session corresponding to p= ref2, so MAG1 >> >> >> >> >> >> sends a PBU, and LMA sends back a PBA with the prefix set= of the >> >> >> >> >> >> session (pref2.) >> >> >> >> >> > >> >> >> >> >> > if1 was previously attached to MAG1 (and LMA delegated pre= f1). How can >> >> >> >> >> > MAG1 know when LMA wants to move flow X to if1 (to send a = PBU)? Some >> >> >> >> >> > signaling is needed there. >> >> >> >> >> >> >> >> >> >> if1 was attached to MAG1 and had session S1 with prefix pref= 1. When >> >> >> >> >> if2 is attached to MAG2, if a different prefix pref2 is allo= cated, >> >> >> >> >> that is a different session S2. LMA cannot move a flow from = session S2 >> >> >> >> >> to a MAG that isn't part of that session. So first thing to = do after >> >> >> >> >> S2 is created, if there's a desire to move flows across othe= r MAGs, is >> >> >> >> > >> >> >> >> > Right, our draft uses FMI signalling to add if1 to the sessio= n (we use >> >> >> >> > the flowmob cache structure of this purpose). We are discussi= ng about >> >> >> >> > two ways of doing exactly the same thing. However, in yours, = you need >> >> >> >> > the MAG to take the initiative, while ours also supports the = LMA >> >> >> >> > initiate the flow movement. >> >> >> >> >> >> >> >> You seem to be conflating session management and flow movement. >> >> >> >> >> >> >> >> In my approach, session management is MAG initiated, as it has = been in >> >> >> >> the past with PMIPv6. Once a session exists across an interface= set, >> >> >> >> flow movement can be LMA-initiated at any time from one interfa= ce in >> >> >> >> the set to another. >> >> >> >> >> >> >> >> I do not see a reason to depart from RFC 5213 and allow the LMA= to >> >> >> >> initiate session management (except for purposes of revocation = but >> >> >> >> that is supported already.) >> >> >> > >> >> >> > I see the reason to add it in order to support the scenarios I m= entioned >> >> >> > in my example. Those cannot be supported with RFC5213 model, as = they >> >> >> > require first the MAG to send a PBU. We need either new signalin= g from >> >> >> > the LMA to the MAG to make the MAG aware of the required prefixe= s to >> >> >> > support flow mobility, or a trigger from the LMA to the MAG, so = the MAG >> >> >> > can send a PBU and then follow your model. >> >> >> >> >> >> In the systems I know the MAG is the entity that creates attaches = a MN >> >> >> interface to a session and therefore I do not understand why you w= ould >> >> >> need the LMA to attach an interface to a session. The LMA has no >> >> >> interface with the interface... That's a MAG duty. >> >> >> >> >> >> In which system is the scenario you're outlining useful? >> >> > >> >> > I must be really bad at explaining this... >> >> > >> >> > Lets consider the following scenario: >> >> > >> >> > - MN attaches if1 to MAG1. As a result, if1 is attached to the sess= ion >> >> > with MAG1. Pref1::/64 is delegated to if1. >> >> > >> >> > - Later on, MN attaches if2 to MAG2. As a result if2 is attached to= the >> >> > session with MAG2. Pref2::/64 is delegated to if2. >> >> > >> >> > (nothing new so far, no flow mobility) >> >> > >> >> > - Some point in time later, LMA wants to move a flow X, addressed t= o >> >> > pref2::/64 to if1. MAG1 cannot send a PBU at that particular moment= (how >> >> > can it know it has to?) to make MAG1 attach if1 to session with pre= f2. >> >> > Therefore, we need some signaling, initiated by the LMA, to make th= at >> >> > flow movement happen. >> >> > >> >> > How can this scenario be supported with your approach? I fail to se= e it. >> >> >> >> This scenario can't be supported without if1 being part of session2 >> >> where the pref2 belongs. So what's needed is that if1 be attached to >> >> session2 such that flows bound to prefix2 can move between if1 and >> >> if2. As I've indicated to you in the systems I am familiar with the >> >> MAG is the entity that creates session, which results in this >> >> scenario: >> >> >> >> - MN attaches if1 to session1. As a result, MAG1 signals to LMA that >> >> if1 is attached to the session1. Pref1::/64 is delegated to session1. >> >> >> >> - Later on MN wants another session. As a result, MAG1 signals to LMA >> >> that if1 is attached to the session2. Pref2::/64 is delegated to >> >> session2. >> > >> > How does the MN express that "desire of another session"? >> >> L2 triggers. As per RFC 5213. >> >> > Besides, how does the MN knows that it'd require that session, before = even >> > considering attaching the second interface if2? >> >> The trigger to session2 creation is not attachment of a second >> interface, it's the will of having a different session from the one >> that existed in the first place, session1 aka default session. If >> there will be flows in session2 that will need to get on if1 or if2 at >> some point, you can simply create session2 whenever the first >> interface in the set is brought up. Conversely, you can tear down the >> session whenever both interfaces are down. Not sure what is so >> complex. >> >> > With current RFC5213, I don't know how two different mobility sessions >> > referring to the same interface of the MN can be created. I see how >> > different prefixes can belong to the same mobility sessions, though. A= re >> > you already referring here to an extension to current PMIPv6? >> >> Yes. You define a session as a set of prefixes that are valid over a >> set of interfaces. This is the only thing that you need to do to >> support flow mobility, no need for FMI/FMA and LMA initiated >> signaling. >> >> >> - Later on MN attaches if2 to session2. As a result, MAG2 signals to >> >> LMA that if2 is attached to the session2. Pref2::/64 is now valid ove= r >> >> both if1 and if2 for session2. >> >> >> > >> > MN cannot really "attach" anything, it is unaware of PMIPv6 operations >> > (at least its IP stack). >> >> Right, layer 3 of the MN is unaware. Layer 2 (virtual interfaces etc.) >> is, otherwise none of that can possibly work. >> >> > How could the MAGs know what interfaces should be added to which >> > sessions? >> >> A MAG attaches interfaces to session based on the policy profile or L2 >> triggers. If neither the policy profile nor L2 triggers says anything >> about multiple session, then I guess the MAG simply attaches whatever >> interfaces comes up to the only session that the MN has. We do not >> need to make this more complicated than needed to be. >> >> > I'm really sorry that I still don't get your point, but in >> > your reasoning it seems that events just occur in the right order to >> > support flow mobility, but in reality MAGs do not know about all the >> > interfaces a MN has, which ones are attached to the same PMIPv6 domain= , >> > and so on and so forth. >> >> In reality MAG doesn't need to know about all the interfaces the MN >> has. MAG simply need to knows what interface should be attached to >> which session. It knows this via L2 triggers or policy profile. >> >> > Flow mobility should be controlled by the LMA, >> > which is the only entity that can understand triggers (PBUs can be use= d >> > as triggers as well) and "add" interfaces to mobility sessions. >> >> Interface being attached to a session is controlled by the MAG which >> is the only entity that knows that an interface is actually attached. >> Flow mobility decision can be taken entirely at LMA and the MAG needs >> not to know. >> >> --julien > > -- > Carlos Jes=FAs Bernardos Cano =A0 =A0 http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA =A04D55 35DC BA4D D170 4F67 > From julien.ietf@gmail.com Tue Feb 8 17:25:35 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6B7C3A688C for ; Tue, 8 Feb 2011 17:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLdNd55YE1SR for ; Tue, 8 Feb 2011 17:25:34 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 417ED3A6836 for ; Tue, 8 Feb 2011 17:25:33 -0800 (PST) Received: by fxm9 with SMTP id 9so7246148fxm.31 for ; Tue, 08 Feb 2011 17:25:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9GYl3CmHHIGzM16DhQznqBREHVkq7ZyGbqfZ4IoVnvA=; b=NzDfgwtYPF55g9BaM123MHCLyhpmhYhPnchqg0YxD+E9qL6EnczSnN6yl9f353ZXZF u72eCvfiGzDNRHMaAeZ3Dg1IhUbRumDseF4O7v2dHjZbCqetJgn56JgMbnC/SRdy55An tDz5Wiaa+li7dI2haHXzUUcnyo6psd2BfKXXU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dDXpD2QMzMxbz+C0f9KdLlHKuXbSEs0uEO19tbqnEIKkly22D0vyj79oDv2ouDXThN DcnVevzUoKObTb78AT6+xp/n45ADE3bys3pv24ITT88pKN8vWrBISqXGZ7uhMl3XwX92 EOK/NMKzzN+KwM3GgJYgzIkk7zYmiYfydMnvY= MIME-Version: 1.0 Received: by 10.103.226.2 with SMTP id d2mr13429035mur.111.1297214741465; Tue, 08 Feb 2011 17:25:41 -0800 (PST) Received: by 10.103.221.9 with HTTP; Tue, 8 Feb 2011 17:25:41 -0800 (PST) In-Reply-To: References: <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> Date: Tue, 8 Feb 2011 17:25:41 -0800 Message-ID: From: Julien Laganier To: Rajeev Koodli Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 01:25:36 -0000 Hello Rajeev, What would actually really helps all of us to make progress is that instead of telling what you'd like, as in > I would like LMA-initiated signaling (FMI/FMA) for this (i.e., signaling = to > MAG1 with Pref2) as well as for the above (i.e., being able to signal MAG= 2 > with Pref1) *whenever* the LMA wants. you'd rather tell us why this is needed, by whom, and where... I've been asking the same question over and over but nobody writes down an answer to this in this thread. Absent that, will I be forced to conclude that this needed by no-one? --julien On Tue, Feb 8, 2011 at 5:12 PM, Rajeev Koodli wrote: > > Hello Pierrick, > > Someone had to do this to make progress :-) > > I largely agree, please see below: > > On 2/8/11 8:25 AM, "pierrick.seite@orange-ftgroup.com" > > >> Sessions should be created/updated with all available interfaces. Rewrit= ing >> Tran's example: when the MN attaches to MAG1 via If1, the LMA creates se= ssion >> 1: >> >> =A0 =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1] >> >> Then, if the MN attaches to MAG2 via If2, the LMA creates session 2 with= both >> If1 and If2. The LMA also updates session 1 with If2: >> >> =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1, IF2] >> =A0 =A0 =A0 =A0 =A0Session2: [Pref2, MAG2, IF2, IF1] >> >> MAG2 receives prefixes 1 and 2 in PBA > > This is fine with me, i.e., LMA sending Pref2 and Pref1 at this time. > As I have stated before, I should also be able to *not* send Pref1 to MAG= 2 > at this time (attach), i.e., send it whenever LMA wants. > > >> but MAG1 is not sending PBU. So, if the >> LMA wants to move flow with Pref2 from if2 to If1, the LMA needs to prov= ide >> Pref2 to MAG1. Also, the LMA should be able to create new sessions with >> already up interfaces, e.g. if1 and if2. To address both issues, PBU fro= m MAG1 >> could be triggered (triggering is to be clarified) or we could define LM= A/MAG >> specific L3 signalling (FMI/FMA). >> > > I would like LMA-initiated signaling (FMI/FMA) for this (i.e., signaling = to > MAG1 with Pref2) as well as for the above (i.e., being able to signal MAG= 2 > with Pref1) *whenever* the LMA wants. > >> My 2 cents, > > Thanks, > > -Rajeev > > > >> Pierrick >> >>> -----Message d'origine----- >>> De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la p= art >>> de Youn-Hee Han >>> Envoy=E9=A0: mardi 8 f=E9vrier 2011 12:00 >>> =C0=A0: 'Julien Laganier'; 'Rajeev Koodli' >>> Cc=A0: netext@ietf.org; Basavaraj.Patil@nokia.com >>> Objet=A0: Re: [netext] Consensus call to adopt I-D:draft-bernardos-nete= xt- >>> pmipv6-flowmob as WG doc >>> >>> Hi Julien, >>> >>>> -----Original Message----- >>>> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Beha= lf >>>> Of Julien Laganier >>>> Sent: Tuesday, February 08, 2011 1:38 PM >>>> To: Rajeev Koodli >>>> Cc: netext@ietf.org; Basavaraj.Patil@nokia.com >>>> Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos- >>>> netext-pmipv6-flowmob as WG doc >>>> >>>> On Mon, Feb 7, 2011 at 6:15 PM, Rajeev Koodli wrot= e: >>>>> >>>>> If flow mobility has nothing do with prefix management, I am lost. >>>> >>>> No reason to be lost: Prefix management is how do I get prefix for the >>>> MN. Flow mobility is how to I move flows across interfaces. The two >>>> needs not to be intertwined together, as I've shown in my other notes. >>>> E.g., I can do flow mobility without adding/deleting prefixes from >>>> sessions, and vice versa. >>> >>> Yes, I agree with you. Flow mobility is how to move flows across interf= ace. >>> So, I thought that it would be better to define "a flow" exactly in net= ext >>> WG prior to discuss flow mobility management. As the definition of "a >>> flow", >>> all I can think is a five-tuple plus something. If we assume that it is >>> correct, I think that flow mobility and prefix addition are inevitably >>> tied. >>> As you know, RFC5213 (and IPv6 protocol spec) already allow to assign >>> multiple prefixes across multiple interfaces of an MN. Yes, I also agre= e >>> with you that in real-world (3GPP), there may be no need to assign >>> multiple >>> prefixes into an MN. (if somebody knows its necessity, please tell me w= hen >>> it should happen). So, flow mobility can be done without adding prefixe= s. >>> However, different interfaces are allowed to be assigned different >>> prefixes >>> by RFC 5213 and IPv6 spec. We can't expect what kind of prefixes an MAG >>> advertises. Therefore, sometimes, we need prefix addition to move a flo= w >>> to >>> a new interface of which MAG does not yet advertise the prefix of the f= low >>> being moved. >>> >>> (snip...) >>> >>>>>> I see no reason to depart from that in the context of extending the >>>>>> protocol to support mobility, nor I am aware of any system >>>>>> architecture that would require this capability. >>>>> >>>>> Okay, see your position. I see it differently. I don't need to be >>>>> bound by some "presumed implementation model" of PMIP6 and limit >>>>> myself *only* to a prefix assignment model you are imagining. >>>> >>>> It's not an implementation model, it is a protocol model, and it's not >>>> imaginary. Implementation has nothing to do with this. >>>> >>>> There's no reason to extend prefix assignment model to do flow mobilit= y >>>> unless you can point me out in which real world context your scenario >>>> actually happens. >>> >>> As I insisted in the old mail, I agree with Julien in this regard. Curr= ent >>> draft allows too much space regarding the prefix allocation model (uniq= ue, >>> shared, and hybrid). When a flow should be moved to a new interface and >>> the >>> prefix which the flow uses is not yet advertised by the new MAG, just >>> inform >>> the prefix to the MAG and thus make it advertise the prefix and setup t= he >>> tunnel based on the new prefix. That's all!. If the prefix is already >>> advertised by the MAG, there is nothing to do and just move the flow. T= his >>> behaviors are very natural one when we want to support IP-level mobilit= y. >>> >>>>>> If this is something really important, the WG can be rechartered to >>>>>> work on a different extension that would allow adding/removing >>>>>> prefixes from existing PMIPv6 sessions. >>>>> >>>>> Huh.. What in the current charter forces us not to have the LMA >>>>> add/refresh/delete a prefix on-demand? >>>> >>>> Engineering is about finding a solution to a problem. Adding/deleting >>>> prefix on-demand is not a solution to flow mobility. I've shown you ho= w >>>> to do flow mobility without this capability. >>> >>> From the viewpoint of protocol, I think that at least, prefix addition = to >>> an >>> interface is a necessary function to support flow mobility, as I explai= ned >>> above. But, it does not mean prefix addition should happen always whene= ver >>> flow mobility occurs. It is sometimes needed. >>> >>>> Now a different engineering problem would be: how to add/delete prefix= es >>>> to a PMIPv6 session, and that would be useful for e.g. >>>> renumbering. This is a different problem that we haven't been chartere= d >>>> to work on. >>> >>> Prefix addition is just prefix addition. IMHO, renumbering is closer to >>> prefix change. We just harness that function to support IP-level mobili= ty. >>> >>> Youn-Hee >>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext > > From rkoodli@cisco.com Tue Feb 8 18:00:39 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 089CB3A6837 for ; Tue, 8 Feb 2011 18:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.483 X-Spam-Level: X-Spam-Status: No, score=-110.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZ849nsp9VWd for ; Tue, 8 Feb 2011 18:00:38 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 6BCD23A67B8 for ; Tue, 8 Feb 2011 18:00:37 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKiEUU2tJXG+/2dsb2JhbAClRHOiGJsyhVoEhHuGb4M1gwE Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rtp-iport-1.cisco.com with ESMTP; 09 Feb 2011 02:00:31 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p1920Von012309; Wed, 9 Feb 2011 02:00:31 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Feb 2011 20:00:31 -0600 Received: from 10.21.94.174 ([10.21.94.174]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Wed, 9 Feb 2011 02:00:31 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 08 Feb 2011 18:19:16 -0800 From: Rajeev Koodli To: Youn-Hee Han , "'Julien Laganier'" Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQIo/NBbQQqyeWpvtmcXp7I2XAzY+gJkMbtkAO4ljUKTImNb0IABD8kz In-Reply-To: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 09 Feb 2011 02:00:31.0666 (UTC) FILETIME=[21B9A920:01CBC7FD] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 02:00:39 -0000 Hi Youn-Hee, On 2/8/11 3:00 AM, "Youn-Hee Han" wrote: >> >> No reason to be lost: Prefix management is how do I get prefix for the >> MN. Flow mobility is how to I move flows across interfaces. The two >> needs not to be intertwined together, as I've shown in my other notes. >> E.g., I can do flow mobility without adding/deleting prefixes from >> sessions, and vice versa. > > Yes, I agree with you. Flow mobility is how to move flows across interface. > So, I thought that it would be better to define "a flow" exactly in netext > WG prior to discuss flow mobility management. As the definition of "a flow", > all I can think is a five-tuple plus something. If we assume that it is > correct, I think that flow mobility and prefix addition are inevitably tied. Exactly! > it should happen). So, flow mobility can be done without adding prefixes. > However, different interfaces are allowed to be assigned different prefixes > by RFC 5213 and IPv6 spec. We can't expect what kind of prefixes an MAG > advertises. Therefore, sometimes, we need prefix addition to move a flow to > a new interface of which MAG does not yet advertise the prefix of the flow > being moved. Check. I need to be able to support this, without being forced to always assign prefix(es) before-hand. > When a flow should be moved to a new interface and the > prefix which the flow uses is not yet advertised by the new MAG, just inform > the prefix to the MAG and thus make it advertise the prefix and setup the > tunnel based on the new prefix. That's all!. If the prefix is already > advertised by the MAG, there is nothing to do and just move the flow. This > behaviors are very natural one when we want to support IP-level mobility. > In violent agreement here, not that it's the first time. I have stated the above multiple times. >> >> Engineering is about finding a solution to a problem. Adding/deleting >> prefix on-demand is not a solution to flow mobility. I've shown you how >> to do flow mobility without this capability. > > From the viewpoint of protocol, I think that at least, prefix addition to an > interface is a necessary function to support flow mobility, as I explained > above. But, it does not mean prefix addition should happen always whenever > flow mobility occurs. It is sometimes needed. > Right. >> Now a different engineering problem would be: how to add/delete prefixes >> to a PMIPv6 session, and that would be useful for e.g. >> renumbering. This is a different problem that we haven't been chartered >> to work on. > > Prefix addition is just prefix addition. IMHO, renumbering is closer to > prefix change. We just harness that function to support IP-level mobility. > Yup. -Rajeev > Youn-Hee > From cjbc@it.uc3m.es Tue Feb 8 18:11:27 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC4B13A684B for ; Tue, 8 Feb 2011 18:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.056 X-Spam-Level: X-Spam-Status: No, score=-4.056 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmKEC7QxI4Ml for ; Tue, 8 Feb 2011 18:11:25 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 801733A67B8 for ; Tue, 8 Feb 2011 18:11:23 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.3] (213.37.82.169.static.user.ono.com [213.37.82.169]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 24347B4D160; Wed, 9 Feb 2011 03:11:26 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Julien Laganier In-Reply-To: References: <1296920514.3773.26.camel@acorde.it.uc3m.es> <1297017501.4715.2.camel@acorde.it.uc3m.es> <1297019696.4715.5.camel@acorde.it.uc3m.es> <1297115574.3099.3.camel@acorde.it.uc3m.es> <1297126584.3099.96.camel@acorde.it.uc3m.es> <1297129998.3099.140.camel@acorde.it.uc3m.es> <1297208236.5169.80.camel@acorde.it.uc3m.es> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-bDexMiQkEfUWG9Va4q4K" Organization: Universidad Carlos III de Madrid Date: Wed, 09 Feb 2011 03:12:33 +0100 Message-ID: <1297217553.5169.88.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17944.003 Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 02:11:28 -0000 --=-bDexMiQkEfUWG9Va4q4K Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Julien, On Tue, 2011-02-08 at 17:21 -0800, Julien Laganier wrote: > Hi Carlos, >=20 > I am glad to see you agree with me :-) >=20 > You're actually proving my point. >=20 > To run any of the flow mobility stuff on a host, you will need either > layer 2 to hide the dissimilar interfaces (virtual interface thing), > in which case you do have L2 triggers, or to modify the layer 3, which > this WG is explicitly prevented from doing assuming that's even > possible. >=20 > So you need layer 2. And that is actually exactly how netext could get > chartered to work on flow mobility, because we assumed layer 2 would > be there to help with all the stuff we're not allowed to do at layer > 3. Exactly, you need layer 2 to help with all the stuff we are not allowed to do at layer 3, _but_ not to do things that we don't need to do at the MN, and can be trivially done with LMA-MAG signaling without putting strong requirements on the layer 2. The signaling we define in our draft (or variations around that) allows to support all the scenarios that have been mentioned so far, and does not break any PMIPv6 concept -- just extends it. It does not require complex layer 2 triggers/policies to be in place and it's therefore more layer-2 agnostic. Still, you prefers to go for the "lets redo MIP at layer-2", and I keep failing to see why Carlos >=20 > --julien >=20 > 2011/2/8 Carlos Jes=FAs Bernardos Cano : > > Hi Julien, > > > > I agree with all your points below, in the sense that it's true that > > flow mobility could be enabled by relying on all those L2 triggers. > > Where I disagree is why we need to do so if we can do it without puttin= g > > those strong requirements. I understand relying on L2 when it is that o= r > > modifying the IP stack of the MN, but not in any other case. Besides, > > the modifications we propose are fairly simplex. > > > > Carlos > > > > On Mon, 2011-02-07 at 20:24 -0800, Julien Laganier wrote: > >> 2011/2/7 Carlos Jes=FAs Bernardos Cano : > >> > Hi Julien, > >> > > >> > On Mon, 2011-02-07 at 17:14 -0800, Julien Laganier wrote: > >> >> Hi Carlos, > >> >> > >> >> 2011/2/7 Carlos Jes=FAs Bernardos Cano : > >> >> > Hi Julien, > >> >> > > >> >> > On Mon, 2011-02-07 at 15:56 -0800, Julien Laganier wrote: > >> >> >> Hi Carlos, > >> >> >> > >> >> >> 2011/2/7 Carlos Jes=FAs Bernardos Cano : > >> >> >> > Hi Julien, > >> >> >> > > >> >> >> > On Mon, 2011-02-07 at 12:43 -0800, Julien Laganier wrote: > >> >> >> >> Hi Carlos, > >> >> >> >> > >> >> >> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : > >> >> >> >> > Hi Julien, > >> >> >> >> > > >> >> >> >> > On Sun, 2011-02-06 at 10:56 -0800, Julien Laganier wrote: > >> >> >> >> >> Hi Carlos, > >> >> >> >> >> > >> >> >> >> >> 2011/2/6 Carlos Jes=FAs Bernardos Cano : > >> >> >> >> >> > Hi Julien, > >> >> >> >> >> > > >> >> >> >> >> > On Sun, 2011-02-06 at 10:11 -0800, Julien Laganier wrote= : > >> >> >> >> >> >> 2011/2/5 Carlos Jes=FAs Bernardos Cano : > >> >> >> >> >> >> > On Fri, 2011-02-04 at 12:59 -0800, Julien Laganier wr= ote: > >> >> >> >> >> >> >> On Fri, Feb 4, 2011 at 10:40 AM, Rajeev Koodli wrote: > >> >> >> >> >> >> >> > > >> >> >> >> >> >> >> > > >> >> >> >> >> >> >> > On 2/4/11 10:16 AM, "Julien Laganier" wrote: > >> >> >> >> >> >> >> > > >> >> >> >> >> >> >> >>> > >> >> >> >> >> >> >> >>> The LMA needs to provide the prefix info to the = MAG. This can be either in > >> >> >> >> >> >> >> >>> PBA or in FMI (if not provided in PBA). > >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> The LMA can provide the prefix to the MAG at sess= ion creation, i.e., > >> >> >> >> >> >> >> >> in the PBU. This information does not need to be = (re)conveyed at flow > >> >> >> >> >> >> >> >> movement. > >> >> >> >> >> >> >> > > >> >> >> >> >> >> >> > If it was conveyed in PBA, surely you don't reconv= ey. > >> >> >> >> >> >> >> > If the prefix was not conveyed in PBA (as in the e= xample we discussed > >> >> >> >> >> >> >> > y'day), you provide it in FMI. > >> >> >> >> >> >> >> > >> >> >> >> >> >> >> IMO the prefix can always be conveyed in the PBA tha= t is received in > >> >> >> >> >> >> >> response to the PBU attaching an interface to a PMIP= v6 flow mobility > >> >> >> >> >> >> >> session. > >> >> >> >> >> >> > > >> >> >> >> >> >> > What about the following scenario: > >> >> >> >> >> >> > > >> >> >> >> >> >> > MN has two interfaces: if1 and if2. if1 attaches to M= AG1, a mobility > >> >> >> >> >> >> > session is created, pref1 is delegated. Some point in= time later, if2 > >> >> >> >> >> >> > attaches to MAG2, new mobility sesison created, pref2= is delegated. > >> >> >> >> >> >> > flowX addressed to pref2 wants to be moved to if1. In= this case we need > >> >> >> >> >> >> > some signaling from LMA to MAG1 that cannot be convet= ed in PBA. > >> >> >> >> >> >> > >> >> >> >> >> >> If flow X addresssed to pref2 wants to be moved to if1,= first thing to > >> >> >> >> >> >> do is to attach the if1 to the session corresponding to= pref2, so MAG1 > >> >> >> >> >> >> sends a PBU, and LMA sends back a PBA with the prefix s= et of the > >> >> >> >> >> >> session (pref2.) > >> >> >> >> >> > > >> >> >> >> >> > if1 was previously attached to MAG1 (and LMA delegated p= ref1). How can > >> >> >> >> >> > MAG1 know when LMA wants to move flow X to if1 (to send = a PBU)? Some > >> >> >> >> >> > signaling is needed there. > >> >> >> >> >> > >> >> >> >> >> if1 was attached to MAG1 and had session S1 with prefix pr= ef1. When > >> >> >> >> >> if2 is attached to MAG2, if a different prefix pref2 is al= located, > >> >> >> >> >> that is a different session S2. LMA cannot move a flow fro= m session S2 > >> >> >> >> >> to a MAG that isn't part of that session. So first thing t= o do after > >> >> >> >> >> S2 is created, if there's a desire to move flows across ot= her MAGs, is > >> >> >> >> > > >> >> >> >> > Right, our draft uses FMI signalling to add if1 to the sess= ion (we use > >> >> >> >> > the flowmob cache structure of this purpose). We are discus= sing about > >> >> >> >> > two ways of doing exactly the same thing. However, in yours= , you need > >> >> >> >> > the MAG to take the initiative, while ours also supports th= e LMA > >> >> >> >> > initiate the flow movement. > >> >> >> >> > >> >> >> >> You seem to be conflating session management and flow movemen= t. > >> >> >> >> > >> >> >> >> In my approach, session management is MAG initiated, as it ha= s been in > >> >> >> >> the past with PMIPv6. Once a session exists across an interfa= ce set, > >> >> >> >> flow movement can be LMA-initiated at any time from one inter= face in > >> >> >> >> the set to another. > >> >> >> >> > >> >> >> >> I do not see a reason to depart from RFC 5213 and allow the L= MA to > >> >> >> >> initiate session management (except for purposes of revocatio= n but > >> >> >> >> that is supported already.) > >> >> >> > > >> >> >> > I see the reason to add it in order to support the scenarios I= mentioned > >> >> >> > in my example. Those cannot be supported with RFC5213 model, a= s they > >> >> >> > require first the MAG to send a PBU. We need either new signal= ing from > >> >> >> > the LMA to the MAG to make the MAG aware of the required prefi= xes to > >> >> >> > support flow mobility, or a trigger from the LMA to the MAG, s= o the MAG > >> >> >> > can send a PBU and then follow your model. > >> >> >> > >> >> >> In the systems I know the MAG is the entity that creates attache= s a MN > >> >> >> interface to a session and therefore I do not understand why you= would > >> >> >> need the LMA to attach an interface to a session. The LMA has no > >> >> >> interface with the interface... That's a MAG duty. > >> >> >> > >> >> >> In which system is the scenario you're outlining useful? > >> >> > > >> >> > I must be really bad at explaining this... > >> >> > > >> >> > Lets consider the following scenario: > >> >> > > >> >> > - MN attaches if1 to MAG1. As a result, if1 is attached to the se= ssion > >> >> > with MAG1. Pref1::/64 is delegated to if1. > >> >> > > >> >> > - Later on, MN attaches if2 to MAG2. As a result if2 is attached = to the > >> >> > session with MAG2. Pref2::/64 is delegated to if2. > >> >> > > >> >> > (nothing new so far, no flow mobility) > >> >> > > >> >> > - Some point in time later, LMA wants to move a flow X, addressed= to > >> >> > pref2::/64 to if1. MAG1 cannot send a PBU at that particular mome= nt (how > >> >> > can it know it has to?) to make MAG1 attach if1 to session with p= ref2. > >> >> > Therefore, we need some signaling, initiated by the LMA, to make = that > >> >> > flow movement happen. > >> >> > > >> >> > How can this scenario be supported with your approach? I fail to = see it. > >> >> > >> >> This scenario can't be supported without if1 being part of session2 > >> >> where the pref2 belongs. So what's needed is that if1 be attached t= o > >> >> session2 such that flows bound to prefix2 can move between if1 and > >> >> if2. As I've indicated to you in the systems I am familiar with the > >> >> MAG is the entity that creates session, which results in this > >> >> scenario: > >> >> > >> >> - MN attaches if1 to session1. As a result, MAG1 signals to LMA tha= t > >> >> if1 is attached to the session1. Pref1::/64 is delegated to session= 1. > >> >> > >> >> - Later on MN wants another session. As a result, MAG1 signals to L= MA > >> >> that if1 is attached to the session2. Pref2::/64 is delegated to > >> >> session2. > >> > > >> > How does the MN express that "desire of another session"? > >> > >> L2 triggers. As per RFC 5213. > >> > >> > Besides, how does the MN knows that it'd require that session, befor= e even > >> > considering attaching the second interface if2? > >> > >> The trigger to session2 creation is not attachment of a second > >> interface, it's the will of having a different session from the one > >> that existed in the first place, session1 aka default session. If > >> there will be flows in session2 that will need to get on if1 or if2 at > >> some point, you can simply create session2 whenever the first > >> interface in the set is brought up. Conversely, you can tear down the > >> session whenever both interfaces are down. Not sure what is so > >> complex. > >> > >> > With current RFC5213, I don't know how two different mobility sessio= ns > >> > referring to the same interface of the MN can be created. I see how > >> > different prefixes can belong to the same mobility sessions, though.= Are > >> > you already referring here to an extension to current PMIPv6? > >> > >> Yes. You define a session as a set of prefixes that are valid over a > >> set of interfaces. This is the only thing that you need to do to > >> support flow mobility, no need for FMI/FMA and LMA initiated > >> signaling. > >> > >> >> - Later on MN attaches if2 to session2. As a result, MAG2 signals t= o > >> >> LMA that if2 is attached to the session2. Pref2::/64 is now valid o= ver > >> >> both if1 and if2 for session2. > >> >> > >> > > >> > MN cannot really "attach" anything, it is unaware of PMIPv6 operatio= ns > >> > (at least its IP stack). > >> > >> Right, layer 3 of the MN is unaware. Layer 2 (virtual interfaces etc.) > >> is, otherwise none of that can possibly work. > >> > >> > How could the MAGs know what interfaces should be added to which > >> > sessions? > >> > >> A MAG attaches interfaces to session based on the policy profile or L2 > >> triggers. If neither the policy profile nor L2 triggers says anything > >> about multiple session, then I guess the MAG simply attaches whatever > >> interfaces comes up to the only session that the MN has. We do not > >> need to make this more complicated than needed to be. > >> > >> > I'm really sorry that I still don't get your point, but in > >> > your reasoning it seems that events just occur in the right order to > >> > support flow mobility, but in reality MAGs do not know about all the > >> > interfaces a MN has, which ones are attached to the same PMIPv6 doma= in, > >> > and so on and so forth. > >> > >> In reality MAG doesn't need to know about all the interfaces the MN > >> has. MAG simply need to knows what interface should be attached to > >> which session. It knows this via L2 triggers or policy profile. > >> > >> > Flow mobility should be controlled by the LMA, > >> > which is the only entity that can understand triggers (PBUs can be u= sed > >> > as triggers as well) and "add" interfaces to mobility sessions. > >> > >> Interface being attached to a session is controlled by the MAG which > >> is the only entity that knows that an interface is actually attached. > >> Flow mobility decision can be taken entirely at LMA and the MAG needs > >> not to know. > >> > >> --julien > > > > -- > > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > > --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-bDexMiQkEfUWG9Va4q4K Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1R+BEACgkQNdy6TdFwT2cwCACfYooyrUagt9AARZNCwyUC+SHs FN0AnA+DWCfz0u6sBLcdvLw1pUNrHOZU =6x9q -----END PGP SIGNATURE----- --=-bDexMiQkEfUWG9Va4q4K-- From julien.ietf@gmail.com Tue Feb 8 18:19:38 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7465B3A6892 for ; Tue, 8 Feb 2011 18:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXi6S5J8iZ7J for ; Tue, 8 Feb 2011 18:19:37 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 603353A684F for ; Tue, 8 Feb 2011 18:19:37 -0800 (PST) Received: by fxm9 with SMTP id 9so7292964fxm.31 for ; Tue, 08 Feb 2011 18:19:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1wWyREBZa8NMxaIGPfzhshZR7EpOuWSOvT0GAI6O29Q=; b=rVKxvuawo4QGVJyxYXhKqO7iZIBo1d093Rntdt5dx7B+P89GVd6UM+BC2OCK/SiCpw VMFRhrPevEAnFUD4SHyCEFtPB8nMjLAk3Cb5Hb9qN2ec3gjJWv4eBuP0FW42jFhsOyqP heF8oTSq7AFFW5+FiUTMy8XPp1cA4Ef1B37mo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=yIZvUQ47y8VLzWyHIEScz0cteOfebqlOn24MkBN4Q0daTGbmA3haERyLpjeHutJIgR HGewlVB56pwv98MTJDwPt/JN2B10LcKlJXMJVoxxMQnUeoeDK34/QmVmvTHFG1TyhbGn L1pgAhvabVt9a6HXAVBV6b08zI5GULvrsfHNE= MIME-Version: 1.0 Received: by 10.103.233.4 with SMTP id k4mr13308905mur.129.1297217984502; Tue, 08 Feb 2011 18:19:44 -0800 (PST) Received: by 10.103.221.9 with HTTP; Tue, 8 Feb 2011 18:19:44 -0800 (PST) In-Reply-To: <1297217553.5169.88.camel@acorde.it.uc3m.es> References: <1296920514.3773.26.camel@acorde.it.uc3m.es> <1297017501.4715.2.camel@acorde.it.uc3m.es> <1297019696.4715.5.camel@acorde.it.uc3m.es> <1297115574.3099.3.camel@acorde.it.uc3m.es> <1297126584.3099.96.camel@acorde.it.uc3m.es> <1297129998.3099.140.camel@acorde.it.uc3m.es> <1297208236.5169.80.camel@acorde.it.uc3m.es> <1297217553.5169.88.camel@acorde.it.uc3m.es> Date: Tue, 8 Feb 2011 18:19:44 -0800 Message-ID: From: Julien Laganier To: cjbc@it.uc3m.es Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 02:19:38 -0000 Hi Carlos, 2011/2/8 Carlos Jes=FAs Bernardos Cano : > Hi Julien, > > On Tue, 2011-02-08 at 17:21 -0800, Julien Laganier wrote: >> Hi Carlos, >> >> I am glad to see you agree with me :-) >> >> You're actually proving my point. >> >> To run any of the flow mobility stuff on a host, you will need either >> layer 2 to hide the dissimilar interfaces (virtual interface thing), >> in which case you do have L2 triggers, or to modify the layer 3, which >> this WG is explicitly prevented from doing assuming that's even >> possible. >> >> So you need layer 2. And that is actually exactly how netext could get >> chartered to work on flow mobility, because we assumed layer 2 would >> be there to help with all the stuff we're not allowed to do at layer >> 3. > > Exactly, you need layer 2 to help with all the stuff we are not allowed > to do at layer 3, _but_ not to do things that we don't need to do at the > MN, and can be trivially done with LMA-MAG signaling without putting > strong requirements on the layer 2. > > The signaling we define in our draft (or variations around that) allows > to support all the scenarios that have been mentioned so far, and does > not break any PMIPv6 concept -- just extends it. It does not require > complex layer 2 triggers/policies to be in place and it's therefore more > layer-2 agnostic. Still, you prefers to go for the "lets redo MIP at > layer-2", and I keep failing to see why PMIPv6 as per RFC5213 doesn't work without L2 triggers, so there's no value in extending PMIPv6 to spare relying on L2 triggers that are required anyway. --julien --julien From rkoodli@cisco.com Tue Feb 8 18:32:15 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89FDE3A6878 for ; Tue, 8 Feb 2011 18:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.801 X-Spam-Level: X-Spam-Status: No, score=-109.801 tagged_above=-999 required=5 tests=[AWL=-0.598, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrnrzGKTusp0 for ; Tue, 8 Feb 2011 18:32:12 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id AB0F83A6806 for ; Tue, 8 Feb 2011 18:32:11 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmUBAKuLUU2tJV2a/2dsb2JhbACWaI12ZnOiCJs0gwGCWQSEe4ZvgzWDAQ Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 09 Feb 2011 02:32:19 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p192WJgL031607; Wed, 9 Feb 2011 02:32:19 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Feb 2011 20:32:18 -0600 Received: from 10.21.94.174 ([10.21.94.174]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Wed, 9 Feb 2011 02:32:18 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 08 Feb 2011 18:51:03 -0800 From: Rajeev Koodli To: Julien Laganier Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvIBDCKhyCE4LeLUkmdIbG8HSNKKw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 09 Feb 2011 02:32:18.0887 (UTC) FILETIME=[92847D70:01CBC801] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 02:32:15 -0000 Hi Julien, On 2/8/11 5:25 PM, "Julien Laganier" wrote: > What would actually really helps all of us to make progress is that > instead of telling what you'd like, as in >=20 It would also help if you didn't generalize your reservation to what I am stating as in "..helps *all* of us..". I see you have a model in mind (which is pretty close to what is in the draft already), which is fine. I fail to see why you are restricted to that alone. But, perhaps that's less fruitful to delve into now. >> I would like LMA-initiated signaling (FMI/FMA) for this (i.e., signaling= to >> MAG1 with Pref2) as well as for the above (i.e., being able to signal MA= G2 >> with Pref1) *whenever* the LMA wants. >=20 > you'd rather tell us why this is needed, by whom, and where... I've > been asking the same question over and over but nobody writes down an > answer to this in this thread. I have mentioned why I need it a few times. 1) I am not required to assign all the applicable prefixes at the time of attach *in anticipation* of *potential* flow mobility. I will assign a relevant prefix *if and when* I need to move a flow over. It makes no sense for me to be *forced* to assign all the prefixes at the time of attach (just because it is aligned with legacy RFC 5213 "model"). 2) I want to assign a prefix based on policy triggers, including the TOD rules. I want to move certain type of traffic over to a different interface based on peak hour bulk stats, the volume of traffic the user is consuming at a particular instance, the amount of quota left and so on. I want to be able to refresh the lifetime of that prefix an= d revoke it back to its "natural interface" when I want. I want to be able to offer this for my customers. >=20 > Absent that, will I be forced to conclude that this needed by no-one? If I don't need something that does not imply the rest don't either! :-) -Rajeev >=20 > --julien >=20 > On Tue, Feb 8, 2011 at 5:12 PM, Rajeev Koodli wrote: >>=20 >> Hello Pierrick, >>=20 >> Someone had to do this to make progress :-) >>=20 >> I largely agree, please see below: >>=20 >> On 2/8/11 8:25 AM, "pierrick.seite@orange-ftgroup.com" >>=20 >>=20 >>> Sessions should be created/updated with all available interfaces. Rewri= ting >>> Tran's example: when the MN attaches to MAG1 via If1, the LMA creates >>> session >>> 1: >>>=20 >>> =A0 =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1] >>>=20 >>> Then, if the MN attaches to MAG2 via If2, the LMA creates session 2 wit= h >>> both >>> If1 and If2. The LMA also updates session 1 with If2: >>>=20 >>> =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1, IF2] >>> =A0 =A0 =A0 =A0 =A0Session2: [Pref2, MAG2, IF2, IF1] >>>=20 >>> MAG2 receives prefixes 1 and 2 in PBA >>=20 >> This is fine with me, i.e., LMA sending Pref2 and Pref1 at this time. >> As I have stated before, I should also be able to *not* send Pref1 to MA= G2 >> at this time (attach), i.e., send it whenever LMA wants. >>=20 >>=20 >>> but MAG1 is not sending PBU. So, if the >>> LMA wants to move flow with Pref2 from if2 to If1, the LMA needs to pro= vide >>> Pref2 to MAG1. Also, the LMA should be able to create new sessions with >>> already up interfaces, e.g. if1 and if2. To address both issues, PBU fr= om >>> MAG1 >>> could be triggered (triggering is to be clarified) or we could define >>> LMA/MAG >>> specific L3 signalling (FMI/FMA). >>>=20 >>=20 >> I would like LMA-initiated signaling (FMI/FMA) for this (i.e., signaling= to >> MAG1 with Pref2) as well as for the above (i.e., being able to signal MA= G2 >> with Pref1) *whenever* the LMA wants. >>=20 >>> My 2 cents, >>=20 >> Thanks, >>=20 >> -Rajeev >>=20 >>=20 >>=20 >>> Pierrick >>>=20 >>>> -----Message d'origine----- >>>> De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la pa= rt >>>> de Youn-Hee Han >>>> Envoy=E9=A0: mardi 8 f=E9vrier 2011 12:00 >>>> =C0=A0: 'Julien Laganier'; 'Rajeev Koodli' >>>> Cc=A0: netext@ietf.org; Basavaraj.Patil@nokia.com >>>> Objet=A0: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netex= t- >>>> pmipv6-flowmob as WG doc >>>>=20 >>>> Hi Julien, >>>>=20 >>>>> -----Original Message----- >>>>> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Beh= alf >>>>> Of Julien Laganier >>>>> Sent: Tuesday, February 08, 2011 1:38 PM >>>>> To: Rajeev Koodli >>>>> Cc: netext@ietf.org; Basavaraj.Patil@nokia.com >>>>> Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos- >>>>> netext-pmipv6-flowmob as WG doc >>>>>=20 >>>>> On Mon, Feb 7, 2011 at 6:15 PM, Rajeev Koodli wro= te: >>>>>>=20 >>>>>> If flow mobility has nothing do with prefix management, I am lost. >>>>>=20 >>>>> No reason to be lost: Prefix management is how do I get prefix for th= e >>>>> MN. Flow mobility is how to I move flows across interfaces. The two >>>>> needs not to be intertwined together, as I've shown in my other notes= . >>>>> E.g., I can do flow mobility without adding/deleting prefixes from >>>>> sessions, and vice versa. >>>>=20 >>>> Yes, I agree with you. Flow mobility is how to move flows across inter= face. >>>> So, I thought that it would be better to define "a flow" exactly in ne= text >>>> WG prior to discuss flow mobility management. As the definition of "a >>>> flow", >>>> all I can think is a five-tuple plus something. If we assume that it i= s >>>> correct, I think that flow mobility and prefix addition are inevitably >>>> tied. >>>> As you know, RFC5213 (and IPv6 protocol spec) already allow to assign >>>> multiple prefixes across multiple interfaces of an MN. Yes, I also agr= ee >>>> with you that in real-world (3GPP), there may be no need to assign >>>> multiple >>>> prefixes into an MN. (if somebody knows its necessity, please tell me = when >>>> it should happen). So, flow mobility can be done without adding prefix= es. >>>> However, different interfaces are allowed to be assigned different >>>> prefixes >>>> by RFC 5213 and IPv6 spec. We can't expect what kind of prefixes an MA= G >>>> advertises. Therefore, sometimes, we need prefix addition to move a fl= ow >>>> to >>>> a new interface of which MAG does not yet advertise the prefix of the = flow >>>> being moved. >>>>=20 >>>> (snip...) >>>>=20 >>>>>>> I see no reason to depart from that in the context of extending the >>>>>>> protocol to support mobility, nor I am aware of any system >>>>>>> architecture that would require this capability. >>>>>>=20 >>>>>> Okay, see your position. I see it differently. I don't need to be >>>>>> bound by some "presumed implementation model" of PMIP6 and limit >>>>>> myself *only* to a prefix assignment model you are imagining. >>>>>=20 >>>>> It's not an implementation model, it is a protocol model, and it's no= t >>>>> imaginary. Implementation has nothing to do with this. >>>>>=20 >>>>> There's no reason to extend prefix assignment model to do flow mobili= ty >>>>> unless you can point me out in which real world context your scenario >>>>> actually happens. >>>>=20 >>>> As I insisted in the old mail, I agree with Julien in this regard. Cur= rent >>>> draft allows too much space regarding the prefix allocation model (uni= que, >>>> shared, and hybrid). When a flow should be moved to a new interface an= d >>>> the >>>> prefix which the flow uses is not yet advertised by the new MAG, just >>>> inform >>>> the prefix to the MAG and thus make it advertise the prefix and setup = the >>>> tunnel based on the new prefix. That's all!. If the prefix is already >>>> advertised by the MAG, there is nothing to do and just move the flow. = This >>>> behaviors are very natural one when we want to support IP-level mobili= ty. >>>>=20 >>>>>>> If this is something really important, the WG can be rechartered to >>>>>>> work on a different extension that would allow adding/removing >>>>>>> prefixes from existing PMIPv6 sessions. >>>>>>=20 >>>>>> Huh.. What in the current charter forces us not to have the LMA >>>>>> add/refresh/delete a prefix on-demand? >>>>>=20 >>>>> Engineering is about finding a solution to a problem. Adding/deleting >>>>> prefix on-demand is not a solution to flow mobility. I've shown you h= ow >>>>> to do flow mobility without this capability. >>>>=20 >>>> From the viewpoint of protocol, I think that at least, prefix addition= to >>>> an >>>> interface is a necessary function to support flow mobility, as I expla= ined >>>> above. But, it does not mean prefix addition should happen always when= ever >>>> flow mobility occurs. It is sometimes needed. >>>>=20 >>>>> Now a different engineering problem would be: how to add/delete prefi= xes >>>>> to a PMIPv6 session, and that would be useful for e.g. >>>>> renumbering. This is a different problem that we haven't been charter= ed >>>>> to work on. >>>>=20 >>>> Prefix addition is just prefix addition. IMHO, renumbering is closer t= o >>>> prefix change. We just harness that function to support IP-level mobil= ity. >>>>=20 >>>> Youn-Hee >>>>=20 >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>=20 >>=20 From cjbc@it.uc3m.es Tue Feb 8 18:36:26 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D30603A68A6 for ; Tue, 8 Feb 2011 18:36:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.056 X-Spam-Level: X-Spam-Status: No, score=-4.056 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVTSCD+5lOZV for ; Tue, 8 Feb 2011 18:36:25 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 5A67D3A6806 for ; Tue, 8 Feb 2011 18:36:23 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.3] (213.37.82.169.static.user.ono.com [213.37.82.169]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 3B8ACC1FC59; Wed, 9 Feb 2011 03:36:31 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Julien Laganier In-Reply-To: References: <1296920514.3773.26.camel@acorde.it.uc3m.es> <1297017501.4715.2.camel@acorde.it.uc3m.es> <1297019696.4715.5.camel@acorde.it.uc3m.es> <1297115574.3099.3.camel@acorde.it.uc3m.es> <1297126584.3099.96.camel@acorde.it.uc3m.es> <1297129998.3099.140.camel@acorde.it.uc3m.es> <1297208236.5169.80.camel@acorde.it.uc3m.es> <1297217553.5169.88.camel@acorde.it.uc3m.es> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-usMHFH5ZF/iL3A7NCVUy" Organization: Universidad Carlos III de Madrid Date: Wed, 09 Feb 2011 03:37:34 +0100 Message-ID: <1297219054.5169.109.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17944.003 Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 02:36:27 -0000 --=-usMHFH5ZF/iL3A7NCVUy Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Julien, On Tue, 2011-02-08 at 18:19 -0800, Julien Laganier wrote: > Hi Carlos, >=20 > 2011/2/8 Carlos Jes=FAs Bernardos Cano : > > Hi Julien, > > > > On Tue, 2011-02-08 at 17:21 -0800, Julien Laganier wrote: > >> Hi Carlos, > >> > >> I am glad to see you agree with me :-) > >> > >> You're actually proving my point. > >> > >> To run any of the flow mobility stuff on a host, you will need either > >> layer 2 to hide the dissimilar interfaces (virtual interface thing), > >> in which case you do have L2 triggers, or to modify the layer 3, which > >> this WG is explicitly prevented from doing assuming that's even > >> possible. > >> > >> So you need layer 2. And that is actually exactly how netext could get > >> chartered to work on flow mobility, because we assumed layer 2 would > >> be there to help with all the stuff we're not allowed to do at layer > >> 3. > > > > Exactly, you need layer 2 to help with all the stuff we are not allowed > > to do at layer 3, _but_ not to do things that we don't need to do at th= e > > MN, and can be trivially done with LMA-MAG signaling without putting > > strong requirements on the layer 2. > > > > The signaling we define in our draft (or variations around that) allows > > to support all the scenarios that have been mentioned so far, and does > > not break any PMIPv6 concept -- just extends it. It does not require > > complex layer 2 triggers/policies to be in place and it's therefore mor= e > > layer-2 agnostic. Still, you prefers to go for the "lets redo MIP at > > layer-2", and I keep failing to see why >=20 > PMIPv6 as per RFC5213 doesn't work without L2 triggers, so there's no > value in extending PMIPv6 to spare relying on L2 triggers that are > required anyway. L2 triggers are supported, but you are proposing more complex L2 triggers than required today for PMIPv6 as per RFC5213. Why should we move all the functionality to external L2 triggers if we can do it at the IETF (making the solution expect less from the Layer-2 technology used by the MN)? Again, we are not talking about signaling/functionality that modifies MN behavior, but just a new message between LMA-MAG minor modifications on the state machines, so we are perfectly fine with the charter. Carlos >=20 > --julien >=20 > --julien --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-usMHFH5ZF/iL3A7NCVUy Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEUEABECAAYFAk1R/e4ACgkQNdy6TdFwT2ePhQCgx992n0Fz9TUVNsBgDy573XMI 5YkAljzF92bCFwF2QYNG2j9pLS0NZsg= =y7Rt -----END PGP SIGNATURE----- --=-usMHFH5ZF/iL3A7NCVUy-- From julien.ietf@gmail.com Tue Feb 8 18:42:14 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED7ED3A68C9 for ; Tue, 8 Feb 2011 18:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQXAjfLfJjcE for ; Tue, 8 Feb 2011 18:42:14 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 7DC193A6806 for ; Tue, 8 Feb 2011 18:42:13 -0800 (PST) Received: by fxm9 with SMTP id 9so7309829fxm.31 for ; Tue, 08 Feb 2011 18:42:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=c0/5elBb0u0OPXk0CsyoTWFEgGGqGX8boD/vaSnREPk=; b=x+QxPv4Wi47t/XY7yOAz86pXElP9hdTFMqp3TOMF6hNgK5GfWI1vBlD2N6ikhj+ecX 5V5TdQJE738ytYy71UH650G1lrQgenVlJUocvFvULTh5aVAl1rww5U9WTVqOHxC9wW8Y xWAiYSagY85PbOkkmiDEA2hnVh2OU3tDf6xMQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qMt5A5WYESUMWmwhQii01lm0aTUYNk4I6xIKYVW5PWbmXcyFLlqZG4IMreXRgUU9Ef p+ZbBXQDygYR+LbutbYPuLy6fd4rdzYPxvEn69EHkpQupZHc3EPUdmGtLamms+GNh+yA OOlNLt8VjJg69f2BAByJSWkMFsodwBNdR6l1A= MIME-Version: 1.0 Received: by 10.103.243.16 with SMTP id v16mr13353567mur.57.1297219341131; Tue, 08 Feb 2011 18:42:21 -0800 (PST) Received: by 10.103.221.9 with HTTP; Tue, 8 Feb 2011 18:42:21 -0800 (PST) In-Reply-To: <1297219054.5169.109.camel@acorde.it.uc3m.es> References: <1296920514.3773.26.camel@acorde.it.uc3m.es> <1297017501.4715.2.camel@acorde.it.uc3m.es> <1297019696.4715.5.camel@acorde.it.uc3m.es> <1297115574.3099.3.camel@acorde.it.uc3m.es> <1297126584.3099.96.camel@acorde.it.uc3m.es> <1297129998.3099.140.camel@acorde.it.uc3m.es> <1297208236.5169.80.camel@acorde.it.uc3m.es> <1297217553.5169.88.camel@acorde.it.uc3m.es> <1297219054.5169.109.camel@acorde.it.uc3m.es> Date: Tue, 8 Feb 2011 18:42:21 -0800 Message-ID: From: Julien Laganier To: cjbc@it.uc3m.es Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 02:42:15 -0000 2011/2/8 Carlos Jes=FAs Bernardos Cano : > Hi Julien, > > On Tue, 2011-02-08 at 18:19 -0800, Julien Laganier wrote: >> Hi Carlos, >> >> 2011/2/8 Carlos Jes=FAs Bernardos Cano : >> > Hi Julien, >> > >> > On Tue, 2011-02-08 at 17:21 -0800, Julien Laganier wrote: >> >> Hi Carlos, >> >> >> >> I am glad to see you agree with me :-) >> >> >> >> You're actually proving my point. >> >> >> >> To run any of the flow mobility stuff on a host, you will need either >> >> layer 2 to hide the dissimilar interfaces (virtual interface thing), >> >> in which case you do have L2 triggers, or to modify the layer 3, whic= h >> >> this WG is explicitly prevented from doing assuming that's even >> >> possible. >> >> >> >> So you need layer 2. And that is actually exactly how netext could ge= t >> >> chartered to work on flow mobility, because we assumed layer 2 would >> >> be there to help with all the stuff we're not allowed to do at layer >> >> 3. >> > >> > Exactly, you need layer 2 to help with all the stuff we are not allowe= d >> > to do at layer 3, _but_ not to do things that we don't need to do at t= he >> > MN, and can be trivially done with LMA-MAG signaling without putting >> > strong requirements on the layer 2. >> > >> > The signaling we define in our draft (or variations around that) allow= s >> > to support all the scenarios that have been mentioned so far, and does >> > not break any PMIPv6 concept -- just extends it. It does not require >> > complex layer 2 triggers/policies to be in place and it's therefore mo= re >> > layer-2 agnostic. Still, you prefers to go for the "lets redo MIP at >> > layer-2", and I keep failing to see why >> >> PMIPv6 as per RFC5213 doesn't work without L2 triggers, so there's no >> value in extending PMIPv6 to spare relying on L2 triggers that are >> required anyway. > > L2 triggers are supported, but you are proposing more complex L2 s/supported/required/ > triggers than required today for PMIPv6 as per RFC5213. the trigger is exactly the same, it's "attach interface X to session Y", where in RFC 5213 a session is defined as a tuple of MNID and prefix set. We do not need more. > = Why should we > move all the functionality to external L2 triggers if we can do it at > the IETF (making the solution expect less from the Layer-2 technology > used by the MN)? I don't see where the scheme I am advocating expects more from L2 compared to a vanilla RFC 5213 model. The L2 trigger is the same. --julien > Again, we are not talking about signaling/= functionality > that modifies MN behavior, but just a new message between LMA-MAG minor > modifications on the state machines, so we are perfectly fine with the > charter. > > Carlos From trungtm2909@gmail.com Tue Feb 8 18:49:37 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AD9D3A681A for ; Tue, 8 Feb 2011 18:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=-1.017, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNZkif5GG6iq for ; Tue, 8 Feb 2011 18:49:36 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id CF2963A6876 for ; Tue, 8 Feb 2011 18:49:31 -0800 (PST) Received: by qyk34 with SMTP id 34so985157qyk.10 for ; Tue, 08 Feb 2011 18:49:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Ezp4tj26BLR3lloMBN2lWG5dpMQxXr+RqdMpe0mjAjU=; b=KPMf2ukbDvO2U4is47GOPnzeeig//GPUQrvG2nHv3OJ7u1KhN+xtuamJqKSIMjXYN0 T6Bbw1OhESiJzVnaXr1UN8aPWQqCc6/XKQ7tZcvQIitpfrm8Sgki2xL71+WI1VeBRhMB OGqQT/h1PPF7EOLdtvVs6aBt7QPtj4poBLA90= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XkUnN1ZNr/fA/jEilxA7Und7lPfLQWGqLEcnzj8pnoNRzymR49eV7D6oT+CZyhV4hy hrh6/VcML7niFHhhJplj8UENMeuB04IVvJjX4weZRh87fhZWkXZnZCZN2kZYT+qr8KBy cM4MV9mutG0CuIArtvcE6FuvTFWckjIIle4Yg= MIME-Version: 1.0 Received: by 10.224.19.207 with SMTP id c15mr15842418qab.50.1297219777850; Tue, 08 Feb 2011 18:49:37 -0800 (PST) Received: by 10.224.89.11 with HTTP; Tue, 8 Feb 2011 18:49:37 -0800 (PST) In-Reply-To: References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> Date: Wed, 9 Feb 2011 11:49:37 +0900 Message-ID: From: Tran Minh Trung To: Julien Laganier Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 02:49:37 -0000 Hi Julien, Let me show a real case for the scenario that we are discussing bellow: The network policy is changed and the LMA decides to move flow 2 from IF2 to IF1 before MAG1 received L2 trigger from the MN (say before step #8) In that case, the LMA should signal MAG1 to send PBU to attach IF1 to session 2. Without signaling from LMA how can you do in this case? Just wait until receiving L2 trigger from the MN? On Wed, Feb 9, 2011 at 7:18 AM, Julien Laganier wro= te: > Hi Pierrick, > > I am going to intertwine the steps in your scenario below with the > missing pieces of the big picture so that we are not doing an academic > exercise but focusing on the real world: > > 1. when the MN first attaches with if1 to a network, MAG1 requests > attachment of if1 to a session1 by sending a PBU to LMA > > 2. because the MN add no session1 previously, the LMA creates session > 1 and allocates a prefix for it. The prefix is sent back to MAG1 in > the PBA: > > =A0=A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1-IF1] > > 3. then, if the MN attaches with if2 to another network, but does not > request this interface be attached to a distinct session, MAG2 > requests attachemnt of If2 to session1 by sending a PBU to LMA > > 4. Because the MN already has session 1, the LMA updates session1 with > if2, and send the pref1 back to MAG2 in the PBA: > > =A0=A0 =A0 =A0 =A0 Session1: [Pref1, MAG1-IF1, MAG2-IF2] > > 5. Creation of a new session 2 for if2 is requested by either of MN > requests via L2 triggers, or a change in policy profile. As a result, > MAG2 requests attachment of if2 to session2 by sending a PBU to LMA. > > 6. because the MN add no session2 previously, the LMA creates session > 2 and allocates a prefix for it. The prefix pref2 is sent back to MAG2 > in the PBA: > > =A0=A0 =A0 =A0 =A0 =A0Session2: [Pref2, MAG2-IF2] > > 7. Flow2 starts over if2 with prefix2. > > 8. Attachment of if1 to session2 is requested by either of MN requests > via L2 triggers, or a change in policy profile. As a result, MAG1 > requests attachment of if1 to session2 by sending a PBU to LMA. > > 9. Because the MN already has session 2, the LMA updates session2 with if= 1: > > =A0=A0 =A0 =A0 =A0 Session2: [Pref2, MAG2-IF2, MAG1-IF1] > > 10. At any point, the LMA decides to move Flow2 between two interfaces > of session 2, and it does so. > > That's all that needed. It maps perfectly to 3GPP. If you have in mind > a different system in whcih that doesn't map, please let me know. > > --julien > > On Tue, Feb 8, 2011 at 8:25 AM, =A0 wr= ote: >> Hi, >> >> Going through this long thread :-), it seems we could agree on the follo= wing (just a tentative to summarize): >> >> Sessions should be created/updated with all available interfaces. Rewrit= ing Tran's example: when the MN attaches to MAG1 via If1, the LMA creates s= ession 1: >> >> =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] >> >> Then, if the MN attaches to MAG2 via If2, the LMA creates session 2 with= both If1 and If2. The LMA also updates session 1 with If2: >> >> =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] >> =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2, IF1] >> >> MAG2 receives prefixes 1 and 2 in PBA but MAG1 is not sending PBU. So, i= f the LMA wants to move flow with Pref2 from if2 to If1, the LMA needs to p= rovide Pref2 to MAG1. Also, the LMA should be able to create new sessions w= ith already up interfaces, e.g. if1 and if2. To address both issues, PBU fr= om MAG1 could be triggered (triggering is to be clarified) or we could defi= ne LMA/MAG specific L3 signalling (FMI/FMA). >> >> My 2 cents, >> Pierrick >> >>> -----Message d'origine----- >>> De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la p= art >>> de Youn-Hee Han >>> Envoy=E9=A0: mardi 8 f=E9vrier 2011 12:00 >>> =C0=A0: 'Julien Laganier'; 'Rajeev Koodli' >>> Cc=A0: netext@ietf.org; Basavaraj.Patil@nokia.com >>> Objet=A0: Re: [netext] Consensus call to adopt I-D:draft-bernardos-nete= xt- >>> pmipv6-flowmob as WG doc >>> >>> Hi Julien, >>> >>> > -----Original Message----- >>> > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Beh= alf >>> > Of Julien Laganier >>> > Sent: Tuesday, February 08, 2011 1:38 PM >>> > To: Rajeev Koodli >>> > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com >>> > Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos- >>> > netext-pmipv6-flowmob as WG doc >>> > >>> > On Mon, Feb 7, 2011 at 6:15 PM, Rajeev Koodli wro= te: >>> > > >>> > > If flow mobility has nothing do with prefix management, I am lost. >>> > >>> > No reason to be lost: Prefix management is how do I get prefix for th= e >>> > MN. Flow mobility is how to I move flows across interfaces. The two >>> > needs not to be intertwined together, as I've shown in my other notes= . >>> > E.g., I can do flow mobility without adding/deleting prefixes from >>> > sessions, and vice versa. >>> >>> Yes, I agree with you. Flow mobility is how to move flows across interf= ace. >>> So, I thought that it would be better to define "a flow" exactly in net= ext >>> WG prior to discuss flow mobility management. As the definition of "a >>> flow", >>> all I can think is a five-tuple plus something. If we assume that it is >>> correct, I think that flow mobility and prefix addition are inevitably >>> tied. >>> As you know, RFC5213 (and IPv6 protocol spec) already allow to assign >>> multiple prefixes across multiple interfaces of an MN. Yes, I also agre= e >>> with you that in real-world (3GPP), there may be no need to assign >>> multiple >>> prefixes into an MN. (if somebody knows its necessity, please tell me w= hen >>> it should happen). So, flow mobility can be done without adding prefixe= s. >>> However, different interfaces are allowed to be assigned different >>> prefixes >>> by RFC 5213 and IPv6 spec. We can't expect what kind of prefixes an MAG >>> advertises. Therefore, sometimes, we need prefix addition to move a flo= w >>> to >>> a new interface of which MAG does not yet advertise the prefix of the f= low >>> being moved. >>> >>> (snip...) >>> >>> > >> I see no reason to depart from that in the context of extending th= e >>> > >> protocol to support mobility, nor I am aware of any system >>> > >> architecture that would require this capability. >>> > > >>> > > Okay, see your position. I see it differently. I don't need to be >>> > > bound by some "presumed implementation model" of PMIP6 and limit >>> > > myself *only* to a prefix assignment model you are imagining. >>> > >>> > It's not an implementation model, it is a protocol model, and it's no= t >>> > imaginary. Implementation has nothing to do with this. >>> > >>> > There's no reason to extend prefix assignment model to do flow mobili= ty >>> > unless you can point me out in which real world context your scenario >>> > actually happens. >>> >>> As I insisted in the old mail, I agree with Julien in this regard. Curr= ent >>> draft allows too much space regarding the prefix allocation model (uniq= ue, >>> shared, and hybrid). When a flow should be moved to a new interface and >>> the >>> prefix which the flow uses is not yet advertised by the new MAG, just >>> inform >>> the prefix to the MAG and thus make it advertise the prefix and setup t= he >>> tunnel based on the new prefix. That's all!. If the prefix is already >>> advertised by the MAG, there is nothing to do and just move the flow. T= his >>> behaviors are very natural one when we want to support IP-level mobilit= y. >>> >>> > >> If this is something really important, the WG can be rechartered t= o >>> > >> work on a different extension that would allow adding/removing >>> > >> prefixes from existing PMIPv6 sessions. >>> > > >>> > > Huh.. What in the current charter forces us not to have the LMA >>> > > add/refresh/delete a prefix on-demand? >>> > >>> > Engineering is about finding a solution to a problem. Adding/deleting >>> > prefix on-demand is not a solution to flow mobility. I've shown you h= ow >>> > to do flow mobility without this capability. >>> >>> From the viewpoint of protocol, I think that at least, prefix addition = to >>> an >>> interface is a necessary function to support flow mobility, as I explai= ned >>> above. But, it does not mean prefix addition should happen always whene= ver >>> flow mobility occurs. It is sometimes needed. >>> >>> > Now a different engineering problem would be: how to add/delete prefi= xes >>> > to a PMIPv6 session, and that would be useful for e.g. >>> > renumbering. This is a different problem that we haven't been charter= ed >>> > to work on. >>> >>> Prefix addition is just prefix addition. IMHO, renumbering is closer to >>> prefix change. We just harness that function to support IP-level mobili= ty. >>> >>> Youn-Hee >>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >> > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 From julien.ietf@gmail.com Tue Feb 8 18:53:43 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 242EA3A68D5 for ; Tue, 8 Feb 2011 18:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=-1.066, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NeG9IZpi850h for ; Tue, 8 Feb 2011 18:53:41 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id B53813A68D1 for ; Tue, 8 Feb 2011 18:53:40 -0800 (PST) Received: by fxm9 with SMTP id 9so7318330fxm.31 for ; Tue, 08 Feb 2011 18:53:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/sFQkD1WXe972ECKm2JJOq8WWBvGSFy43IiGiV/eTBA=; b=i7psvGDB1yFegbS63uqb18tA/QXyLf4DEErHer1ShrWrPJuqsE4ydg4SiBMOPotZdp UBl9C1R/sTeSj313Zxtt7eyYQwKZwDAkT4fiBwlUgJIhbIiR2DY2xmKVpsTsSk3CxmOX 7Tt1Y7zbD5gvMpI8Dh0iQnouVijiS8WBZMKFc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=a+x+mr6ZP1e45dL9J5F5OpoYSRFaBb6J3lMUurrDQJsdzTidBpUSABnFPoFb29Gics 4wjSa6MiIE9lFMVftWzRwJUqel+3k7aghYk54Vd8b1QfIPZP50hshDGX1mYhmzCEW66U eNI+WImYnje8Iw39pqK0Y4GMUBtyG8k4yPY5k= MIME-Version: 1.0 Received: by 10.103.124.3 with SMTP id b3mr12663051mun.3.1297220027262; Tue, 08 Feb 2011 18:53:47 -0800 (PST) Received: by 10.103.221.9 with HTTP; Tue, 8 Feb 2011 18:53:47 -0800 (PST) In-Reply-To: References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> Date: Tue, 8 Feb 2011 18:53:47 -0800 Message-ID: From: Julien Laganier To: Tran Minh Trung Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 02:53:43 -0000 Changing the policy on the network side alone isn't sufficient. You'd have to change the policy on the host, too (e.g., using ADNSF in 3GPP) which will trigger the MN to attach IF1 to session 2. This is the system view picture which seems we're missing in this discussio= n. --julien On Tue, Feb 8, 2011 at 6:49 PM, Tran Minh Trung wro= te: > Hi Julien, > > Let me show a real case for the scenario that we are discussing bellow: > > The network policy is changed and the LMA decides to move flow 2 from > IF2 to IF1 before MAG1 received L2 trigger from the MN (say before > step #8) > In that case, the LMA should signal MAG1 to send PBU to attach IF1 to > session 2. > > Without signaling from LMA how can you do in this case? Just wait > until receiving L2 trigger from the MN? > > On Wed, Feb 9, 2011 at 7:18 AM, Julien Laganier w= rote: >> Hi Pierrick, >> >> I am going to intertwine the steps in your scenario below with the >> missing pieces of the big picture so that we are not doing an academic >> exercise but focusing on the real world: >> >> 1. when the MN first attaches with if1 to a network, MAG1 requests >> attachment of if1 to a session1 by sending a PBU to LMA >> >> 2. because the MN add no session1 previously, the LMA creates session >> 1 and allocates a prefix for it. The prefix is sent back to MAG1 in >> the PBA: >> >> =A0=A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1-IF1] >> >> 3. then, if the MN attaches with if2 to another network, but does not >> request this interface be attached to a distinct session, MAG2 >> requests attachemnt of If2 to session1 by sending a PBU to LMA >> >> 4. Because the MN already has session 1, the LMA updates session1 with >> if2, and send the pref1 back to MAG2 in the PBA: >> >> =A0=A0 =A0 =A0 =A0 Session1: [Pref1, MAG1-IF1, MAG2-IF2] >> >> 5. Creation of a new session 2 for if2 is requested by either of MN >> requests via L2 triggers, or a change in policy profile. As a result, >> MAG2 requests attachment of if2 to session2 by sending a PBU to LMA. >> >> 6. because the MN add no session2 previously, the LMA creates session >> 2 and allocates a prefix for it. The prefix pref2 is sent back to MAG2 >> in the PBA: >> >> =A0=A0 =A0 =A0 =A0 =A0Session2: [Pref2, MAG2-IF2] >> >> 7. Flow2 starts over if2 with prefix2. >> >> 8. Attachment of if1 to session2 is requested by either of MN requests >> via L2 triggers, or a change in policy profile. As a result, MAG1 >> requests attachment of if1 to session2 by sending a PBU to LMA. >> >> 9. Because the MN already has session 2, the LMA updates session2 with i= f1: >> >> =A0=A0 =A0 =A0 =A0 Session2: [Pref2, MAG2-IF2, MAG1-IF1] >> >> 10. At any point, the LMA decides to move Flow2 between two interfaces >> of session 2, and it does so. >> >> That's all that needed. It maps perfectly to 3GPP. If you have in mind >> a different system in whcih that doesn't map, please let me know. >> >> --julien >> >> On Tue, Feb 8, 2011 at 8:25 AM, =A0 w= rote: >>> Hi, >>> >>> Going through this long thread :-), it seems we could agree on the foll= owing (just a tentative to summarize): >>> >>> Sessions should be created/updated with all available interfaces. Rewri= ting Tran's example: when the MN attaches to MAG1 via If1, the LMA creates = session 1: >>> >>> =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] >>> >>> Then, if the MN attaches to MAG2 via If2, the LMA creates session 2 wit= h both If1 and If2. The LMA also updates session 1 with If2: >>> >>> =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] >>> =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2, IF1] >>> >>> MAG2 receives prefixes 1 and 2 in PBA but MAG1 is not sending PBU. So, = if the LMA wants to move flow with Pref2 from if2 to If1, the LMA needs to = provide Pref2 to MAG1. Also, the LMA should be able to create new sessions = with already up interfaces, e.g. if1 and if2. To address both issues, PBU f= rom MAG1 could be triggered (triggering is to be clarified) or we could def= ine LMA/MAG specific L3 signalling (FMI/FMA). >>> >>> My 2 cents, >>> Pierrick >>> >>>> -----Message d'origine----- >>>> De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la = part >>>> de Youn-Hee Han >>>> Envoy=E9=A0: mardi 8 f=E9vrier 2011 12:00 >>>> =C0=A0: 'Julien Laganier'; 'Rajeev Koodli' >>>> Cc=A0: netext@ietf.org; Basavaraj.Patil@nokia.com >>>> Objet=A0: Re: [netext] Consensus call to adopt I-D:draft-bernardos-net= ext- >>>> pmipv6-flowmob as WG doc >>>> >>>> Hi Julien, >>>> >>>> > -----Original Message----- >>>> > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Be= half >>>> > Of Julien Laganier >>>> > Sent: Tuesday, February 08, 2011 1:38 PM >>>> > To: Rajeev Koodli >>>> > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com >>>> > Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos- >>>> > netext-pmipv6-flowmob as WG doc >>>> > >>>> > On Mon, Feb 7, 2011 at 6:15 PM, Rajeev Koodli wr= ote: >>>> > > >>>> > > If flow mobility has nothing do with prefix management, I am lost. >>>> > >>>> > No reason to be lost: Prefix management is how do I get prefix for t= he >>>> > MN. Flow mobility is how to I move flows across interfaces. The two >>>> > needs not to be intertwined together, as I've shown in my other note= s. >>>> > E.g., I can do flow mobility without adding/deleting prefixes from >>>> > sessions, and vice versa. >>>> >>>> Yes, I agree with you. Flow mobility is how to move flows across inter= face. >>>> So, I thought that it would be better to define "a flow" exactly in ne= text >>>> WG prior to discuss flow mobility management. As the definition of "a >>>> flow", >>>> all I can think is a five-tuple plus something. If we assume that it i= s >>>> correct, I think that flow mobility and prefix addition are inevitably >>>> tied. >>>> As you know, RFC5213 (and IPv6 protocol spec) already allow to assign >>>> multiple prefixes across multiple interfaces of an MN. Yes, I also agr= ee >>>> with you that in real-world (3GPP), there may be no need to assign >>>> multiple >>>> prefixes into an MN. (if somebody knows its necessity, please tell me = when >>>> it should happen). So, flow mobility can be done without adding prefix= es. >>>> However, different interfaces are allowed to be assigned different >>>> prefixes >>>> by RFC 5213 and IPv6 spec. We can't expect what kind of prefixes an MA= G >>>> advertises. Therefore, sometimes, we need prefix addition to move a fl= ow >>>> to >>>> a new interface of which MAG does not yet advertise the prefix of the = flow >>>> being moved. >>>> >>>> (snip...) >>>> >>>> > >> I see no reason to depart from that in the context of extending t= he >>>> > >> protocol to support mobility, nor I am aware of any system >>>> > >> architecture that would require this capability. >>>> > > >>>> > > Okay, see your position. I see it differently. I don't need to be >>>> > > bound by some "presumed implementation model" of PMIP6 and limit >>>> > > myself *only* to a prefix assignment model you are imagining. >>>> > >>>> > It's not an implementation model, it is a protocol model, and it's n= ot >>>> > imaginary. Implementation has nothing to do with this. >>>> > >>>> > There's no reason to extend prefix assignment model to do flow mobil= ity >>>> > unless you can point me out in which real world context your scenari= o >>>> > actually happens. >>>> >>>> As I insisted in the old mail, I agree with Julien in this regard. Cur= rent >>>> draft allows too much space regarding the prefix allocation model (uni= que, >>>> shared, and hybrid). When a flow should be moved to a new interface an= d >>>> the >>>> prefix which the flow uses is not yet advertised by the new MAG, just >>>> inform >>>> the prefix to the MAG and thus make it advertise the prefix and setup = the >>>> tunnel based on the new prefix. That's all!. If the prefix is already >>>> advertised by the MAG, there is nothing to do and just move the flow. = This >>>> behaviors are very natural one when we want to support IP-level mobili= ty. >>>> >>>> > >> If this is something really important, the WG can be rechartered = to >>>> > >> work on a different extension that would allow adding/removing >>>> > >> prefixes from existing PMIPv6 sessions. >>>> > > >>>> > > Huh.. What in the current charter forces us not to have the LMA >>>> > > add/refresh/delete a prefix on-demand? >>>> > >>>> > Engineering is about finding a solution to a problem. Adding/deletin= g >>>> > prefix on-demand is not a solution to flow mobility. I've shown you = how >>>> > to do flow mobility without this capability. >>>> >>>> From the viewpoint of protocol, I think that at least, prefix addition= to >>>> an >>>> interface is a necessary function to support flow mobility, as I expla= ined >>>> above. But, it does not mean prefix addition should happen always when= ever >>>> flow mobility occurs. It is sometimes needed. >>>> >>>> > Now a different engineering problem would be: how to add/delete pref= ixes >>>> > to a PMIPv6 session, and that would be useful for e.g. >>>> > renumbering. This is a different problem that we haven't been charte= red >>>> > to work on. >>>> >>>> Prefix addition is just prefix addition. IMHO, renumbering is closer t= o >>>> prefix change. We just harness that function to support IP-level mobil= ity. >>>> >>>> Youn-Hee >>>> >>>> _______________________________________________ >>>> 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 >> > > > > -- > Ph.D., Senior Member > Electronics and Telecommunications Research Institute > Standards Research Center > 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA > Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 > From trungtm2909@gmail.com Tue Feb 8 18:57:46 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 066993A681A for ; Tue, 8 Feb 2011 18:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=-0.848, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJdP-GuLXfHA for ; Tue, 8 Feb 2011 18:57:44 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 8F5433A67A3 for ; Tue, 8 Feb 2011 18:57:44 -0800 (PST) Received: by qyj19 with SMTP id 19so4981722qyj.10 for ; Tue, 08 Feb 2011 18:57:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1AHKfQoyzABp9G09hlAZg9cednKlEia+blCMcF/y83g=; b=JZkNo+JJzNuC3saFTaVQuT5g0Ng1g5mNBezudWth2TNzygjBfxjsQ1/9x+ptYOWFkl Fn3MjoC+Eholtvn/72o/y0dwUbs+1IPFSRO6IDUa0alV3KV/XVOTvB8MGrpuwfcE21Q2 ASk0hMXI0PAvSweu7B8gqeRkmAJpVeFYryqyI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Ja94DFqPIKLOf6w5mTkle30QBkSCuLeteMkhBHWtBRnA/yZxCEbaMFAF5v5/wdM0Bd NSdlRsvgW7NhEToMV1bpZ4fKLB4y4ifK98F2t1P/1Ojnj/q+Sleq4X8n/LEW1aPmJ/eO 7ZLEufReDOK8OH/EwBx4iykGuftSOTHTuMO5M= MIME-Version: 1.0 Received: by 10.224.20.71 with SMTP id e7mr16029192qab.150.1297220272058; Tue, 08 Feb 2011 18:57:52 -0800 (PST) Received: by 10.224.89.11 with HTTP; Tue, 8 Feb 2011 18:57:51 -0800 (PST) In-Reply-To: References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> Date: Wed, 9 Feb 2011 11:57:51 +0900 Message-ID: From: Tran Minh Trung To: Julien Laganier Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 02:57:46 -0000 Since we are proposing network-based flow mobility, I think that it must be transparent to the MN. if not the network-based solution is similar as client-based one. Regards, TrungTM On Wed, Feb 9, 2011 at 11:53 AM, Julien Laganier wr= ote: > Changing the policy on the network side alone isn't sufficient. You'd > have to change the policy on the host, too (e.g., using ADNSF in 3GPP) > which will trigger the MN to attach IF1 to session 2. > > This is the system view picture which seems we're missing in this discuss= ion. > > --julien > > On Tue, Feb 8, 2011 at 6:49 PM, Tran Minh Trung w= rote: >> Hi Julien, >> >> Let me show a real case for the scenario that we are discussing bellow: >> >> The network policy is changed and the LMA decides to move flow 2 from >> IF2 to IF1 before MAG1 received L2 trigger from the MN (say before >> step #8) >> In that case, the LMA should signal MAG1 to send PBU to attach IF1 to >> session 2. >> >> Without signaling from LMA how can you do in this case? Just wait >> until receiving L2 trigger from the MN? >> >> On Wed, Feb 9, 2011 at 7:18 AM, Julien Laganier = wrote: >>> Hi Pierrick, >>> >>> I am going to intertwine the steps in your scenario below with the >>> missing pieces of the big picture so that we are not doing an academic >>> exercise but focusing on the real world: >>> >>> 1. when the MN first attaches with if1 to a network, MAG1 requests >>> attachment of if1 to a session1 by sending a PBU to LMA >>> >>> 2. because the MN add no session1 previously, the LMA creates session >>> 1 and allocates a prefix for it. The prefix is sent back to MAG1 in >>> the PBA: >>> >>> =A0=A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1-IF1] >>> >>> 3. then, if the MN attaches with if2 to another network, but does not >>> request this interface be attached to a distinct session, MAG2 >>> requests attachemnt of If2 to session1 by sending a PBU to LMA >>> >>> 4. Because the MN already has session 1, the LMA updates session1 with >>> if2, and send the pref1 back to MAG2 in the PBA: >>> >>> =A0=A0 =A0 =A0 =A0 Session1: [Pref1, MAG1-IF1, MAG2-IF2] >>> >>> 5. Creation of a new session 2 for if2 is requested by either of MN >>> requests via L2 triggers, or a change in policy profile. As a result, >>> MAG2 requests attachment of if2 to session2 by sending a PBU to LMA. >>> >>> 6. because the MN add no session2 previously, the LMA creates session >>> 2 and allocates a prefix for it. The prefix pref2 is sent back to MAG2 >>> in the PBA: >>> >>> =A0=A0 =A0 =A0 =A0 =A0Session2: [Pref2, MAG2-IF2] >>> >>> 7. Flow2 starts over if2 with prefix2. >>> >>> 8. Attachment of if1 to session2 is requested by either of MN requests >>> via L2 triggers, or a change in policy profile. As a result, MAG1 >>> requests attachment of if1 to session2 by sending a PBU to LMA. >>> >>> 9. Because the MN already has session 2, the LMA updates session2 with = if1: >>> >>> =A0=A0 =A0 =A0 =A0 Session2: [Pref2, MAG2-IF2, MAG1-IF1] >>> >>> 10. At any point, the LMA decides to move Flow2 between two interfaces >>> of session 2, and it does so. >>> >>> That's all that needed. It maps perfectly to 3GPP. If you have in mind >>> a different system in whcih that doesn't map, please let me know. >>> >>> --julien >>> >>> On Tue, Feb 8, 2011 at 8:25 AM, =A0 = wrote: >>>> Hi, >>>> >>>> Going through this long thread :-), it seems we could agree on the fol= lowing (just a tentative to summarize): >>>> >>>> Sessions should be created/updated with all available interfaces. Rewr= iting Tran's example: when the MN attaches to MAG1 via If1, the LMA creates= session 1: >>>> >>>> =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] >>>> >>>> Then, if the MN attaches to MAG2 via If2, the LMA creates session 2 wi= th both If1 and If2. The LMA also updates session 1 with If2: >>>> >>>> =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] >>>> =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2, IF1] >>>> >>>> MAG2 receives prefixes 1 and 2 in PBA but MAG1 is not sending PBU. So,= if the LMA wants to move flow with Pref2 from if2 to If1, the LMA needs to= provide Pref2 to MAG1. Also, the LMA should be able to create new sessions= with already up interfaces, e.g. if1 and if2. To address both issues, PBU = from MAG1 could be triggered (triggering is to be clarified) or we could de= fine LMA/MAG specific L3 signalling (FMI/FMA). >>>> >>>> My 2 cents, >>>> Pierrick >>>> >>>>> -----Message d'origine----- >>>>> De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la= part >>>>> de Youn-Hee Han >>>>> Envoy=E9=A0: mardi 8 f=E9vrier 2011 12:00 >>>>> =C0=A0: 'Julien Laganier'; 'Rajeev Koodli' >>>>> Cc=A0: netext@ietf.org; Basavaraj.Patil@nokia.com >>>>> Objet=A0: Re: [netext] Consensus call to adopt I-D:draft-bernardos-ne= text- >>>>> pmipv6-flowmob as WG doc >>>>> >>>>> Hi Julien, >>>>> >>>>> > -----Original Message----- >>>>> > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On B= ehalf >>>>> > Of Julien Laganier >>>>> > Sent: Tuesday, February 08, 2011 1:38 PM >>>>> > To: Rajeev Koodli >>>>> > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com >>>>> > Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos- >>>>> > netext-pmipv6-flowmob as WG doc >>>>> > >>>>> > On Mon, Feb 7, 2011 at 6:15 PM, Rajeev Koodli w= rote: >>>>> > > >>>>> > > If flow mobility has nothing do with prefix management, I am lost= . >>>>> > >>>>> > No reason to be lost: Prefix management is how do I get prefix for = the >>>>> > MN. Flow mobility is how to I move flows across interfaces. The two >>>>> > needs not to be intertwined together, as I've shown in my other not= es. >>>>> > E.g., I can do flow mobility without adding/deleting prefixes from >>>>> > sessions, and vice versa. >>>>> >>>>> Yes, I agree with you. Flow mobility is how to move flows across inte= rface. >>>>> So, I thought that it would be better to define "a flow" exactly in n= etext >>>>> WG prior to discuss flow mobility management. As the definition of "a >>>>> flow", >>>>> all I can think is a five-tuple plus something. If we assume that it = is >>>>> correct, I think that flow mobility and prefix addition are inevitabl= y >>>>> tied. >>>>> As you know, RFC5213 (and IPv6 protocol spec) already allow to assign >>>>> multiple prefixes across multiple interfaces of an MN. Yes, I also ag= ree >>>>> with you that in real-world (3GPP), there may be no need to assign >>>>> multiple >>>>> prefixes into an MN. (if somebody knows its necessity, please tell me= when >>>>> it should happen). So, flow mobility can be done without adding prefi= xes. >>>>> However, different interfaces are allowed to be assigned different >>>>> prefixes >>>>> by RFC 5213 and IPv6 spec. We can't expect what kind of prefixes an M= AG >>>>> advertises. Therefore, sometimes, we need prefix addition to move a f= low >>>>> to >>>>> a new interface of which MAG does not yet advertise the prefix of the= flow >>>>> being moved. >>>>> >>>>> (snip...) >>>>> >>>>> > >> I see no reason to depart from that in the context of extending = the >>>>> > >> protocol to support mobility, nor I am aware of any system >>>>> > >> architecture that would require this capability. >>>>> > > >>>>> > > Okay, see your position. I see it differently. I don't need to be >>>>> > > bound by some "presumed implementation model" of PMIP6 and limit >>>>> > > myself *only* to a prefix assignment model you are imagining. >>>>> > >>>>> > It's not an implementation model, it is a protocol model, and it's = not >>>>> > imaginary. Implementation has nothing to do with this. >>>>> > >>>>> > There's no reason to extend prefix assignment model to do flow mobi= lity >>>>> > unless you can point me out in which real world context your scenar= io >>>>> > actually happens. >>>>> >>>>> As I insisted in the old mail, I agree with Julien in this regard. Cu= rrent >>>>> draft allows too much space regarding the prefix allocation model (un= ique, >>>>> shared, and hybrid). When a flow should be moved to a new interface a= nd >>>>> the >>>>> prefix which the flow uses is not yet advertised by the new MAG, just >>>>> inform >>>>> the prefix to the MAG and thus make it advertise the prefix and setup= the >>>>> tunnel based on the new prefix. That's all!. If the prefix is already >>>>> advertised by the MAG, there is nothing to do and just move the flow.= This >>>>> behaviors are very natural one when we want to support IP-level mobil= ity. >>>>> >>>>> > >> If this is something really important, the WG can be rechartered= to >>>>> > >> work on a different extension that would allow adding/removing >>>>> > >> prefixes from existing PMIPv6 sessions. >>>>> > > >>>>> > > Huh.. What in the current charter forces us not to have the LMA >>>>> > > add/refresh/delete a prefix on-demand? >>>>> > >>>>> > Engineering is about finding a solution to a problem. Adding/deleti= ng >>>>> > prefix on-demand is not a solution to flow mobility. I've shown you= how >>>>> > to do flow mobility without this capability. >>>>> >>>>> From the viewpoint of protocol, I think that at least, prefix additio= n to >>>>> an >>>>> interface is a necessary function to support flow mobility, as I expl= ained >>>>> above. But, it does not mean prefix addition should happen always whe= never >>>>> flow mobility occurs. It is sometimes needed. >>>>> >>>>> > Now a different engineering problem would be: how to add/delete pre= fixes >>>>> > to a PMIPv6 session, and that would be useful for e.g. >>>>> > renumbering. This is a different problem that we haven't been chart= ered >>>>> > to work on. >>>>> >>>>> Prefix addition is just prefix addition. IMHO, renumbering is closer = to >>>>> prefix change. We just harness that function to support IP-level mobi= lity. >>>>> >>>>> Youn-Hee >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> >> >> -- >> Ph.D., Senior Member >> Electronics and Telecommunications Research Institute >> Standards Research Center >> 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA >> Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 >> > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 From julien.ietf@gmail.com Tue Feb 8 19:00:50 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 940F63A68E0 for ; Tue, 8 Feb 2011 19:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=-1.028, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPuKe8j5BZiv for ; Tue, 8 Feb 2011 19:00:49 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id D63AB3A68DB for ; Tue, 8 Feb 2011 19:00:48 -0800 (PST) Received: by fxm9 with SMTP id 9so7323445fxm.31 for ; Tue, 08 Feb 2011 19:00:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=o+TdPQePaMIVEPeqI3tyNdj/LlObStlUgMmZMQJ+KlI=; b=LEnSqsG5O758kVp00pN5r9vrlwvTMtUJ/Czccm8DbzHMdocWvHJK2DO4R+upGc8PX8 YqQIAa7uHkOj7UrSvWETpA+iZvIGnzV0RM2MHzeZd2ku9uhOOTh9EI7bAEqhFeKDUSrq qwZB+c+z1qKj2sDlTKnVrB1BXnaHge3igLmgc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VkqQ5dV4JiNnNuzd/UD+TobsTY9k+77ZtHx7z0NuOX7Gg3D31v9ib7sXzJfjFM1EpM CIG8GGXxGFM+naq/j+VWih726QWNzrkJecpBimMxBJFgEeO0SmIghe0jGvPMtz0wdj/K 6YTg6OMwy+oaAoBWSJnX+PQ2Jae03d3wijZBk= MIME-Version: 1.0 Received: by 10.103.199.3 with SMTP id b3mr2338173muq.93.1297220456596; Tue, 08 Feb 2011 19:00:56 -0800 (PST) Received: by 10.103.221.9 with HTTP; Tue, 8 Feb 2011 19:00:56 -0800 (PST) In-Reply-To: References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> Date: Tue, 8 Feb 2011 19:00:56 -0800 Message-ID: From: Julien Laganier To: Tran Minh Trung Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 03:00:50 -0000 Network based flow mobility cannot be entirely transparent to the MN. It can be made transparent to the *IP layer* on the MN, but at minimum the layer 2 will have to change to decide where to send uplink packets. This is a fact. I am sorry if that means that the network-based solution is functionally equivalent to the client based and only differ in terms of the placement of the functions in various layer, but I cannot help it. --julien On Tue, Feb 8, 2011 at 6:57 PM, Tran Minh Trung wro= te: > Since we are proposing network-based flow mobility, I think that it > must be transparent to the MN. > if not the network-based solution is similar as client-based one. > > Regards, > TrungTM > > On Wed, Feb 9, 2011 at 11:53 AM, Julien Laganier = wrote: >> Changing the policy on the network side alone isn't sufficient. You'd >> have to change the policy on the host, too (e.g., using ADNSF in 3GPP) >> which will trigger the MN to attach IF1 to session 2. >> >> This is the system view picture which seems we're missing in this discus= sion. >> >> --julien >> >> On Tue, Feb 8, 2011 at 6:49 PM, Tran Minh Trung = wrote: >>> Hi Julien, >>> >>> Let me show a real case for the scenario that we are discussing bellow: >>> >>> The network policy is changed and the LMA decides to move flow 2 from >>> IF2 to IF1 before MAG1 received L2 trigger from the MN (say before >>> step #8) >>> In that case, the LMA should signal MAG1 to send PBU to attach IF1 to >>> session 2. >>> >>> Without signaling from LMA how can you do in this case? Just wait >>> until receiving L2 trigger from the MN? >>> >>> On Wed, Feb 9, 2011 at 7:18 AM, Julien Laganier = wrote: >>>> Hi Pierrick, >>>> >>>> I am going to intertwine the steps in your scenario below with the >>>> missing pieces of the big picture so that we are not doing an academic >>>> exercise but focusing on the real world: >>>> >>>> 1. when the MN first attaches with if1 to a network, MAG1 requests >>>> attachment of if1 to a session1 by sending a PBU to LMA >>>> >>>> 2. because the MN add no session1 previously, the LMA creates session >>>> 1 and allocates a prefix for it. The prefix is sent back to MAG1 in >>>> the PBA: >>>> >>>> =A0=A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1-IF1] >>>> >>>> 3. then, if the MN attaches with if2 to another network, but does not >>>> request this interface be attached to a distinct session, MAG2 >>>> requests attachemnt of If2 to session1 by sending a PBU to LMA >>>> >>>> 4. Because the MN already has session 1, the LMA updates session1 with >>>> if2, and send the pref1 back to MAG2 in the PBA: >>>> >>>> =A0=A0 =A0 =A0 =A0 Session1: [Pref1, MAG1-IF1, MAG2-IF2] >>>> >>>> 5. Creation of a new session 2 for if2 is requested by either of MN >>>> requests via L2 triggers, or a change in policy profile. As a result, >>>> MAG2 requests attachment of if2 to session2 by sending a PBU to LMA. >>>> >>>> 6. because the MN add no session2 previously, the LMA creates session >>>> 2 and allocates a prefix for it. The prefix pref2 is sent back to MAG2 >>>> in the PBA: >>>> >>>> =A0=A0 =A0 =A0 =A0 =A0Session2: [Pref2, MAG2-IF2] >>>> >>>> 7. Flow2 starts over if2 with prefix2. >>>> >>>> 8. Attachment of if1 to session2 is requested by either of MN requests >>>> via L2 triggers, or a change in policy profile. As a result, MAG1 >>>> requests attachment of if1 to session2 by sending a PBU to LMA. >>>> >>>> 9. Because the MN already has session 2, the LMA updates session2 with= if1: >>>> >>>> =A0=A0 =A0 =A0 =A0 Session2: [Pref2, MAG2-IF2, MAG1-IF1] >>>> >>>> 10. At any point, the LMA decides to move Flow2 between two interfaces >>>> of session 2, and it does so. >>>> >>>> That's all that needed. It maps perfectly to 3GPP. If you have in mind >>>> a different system in whcih that doesn't map, please let me know. >>>> >>>> --julien >>>> >>>> On Tue, Feb 8, 2011 at 8:25 AM, =A0= wrote: >>>>> Hi, >>>>> >>>>> Going through this long thread :-), it seems we could agree on the fo= llowing (just a tentative to summarize): >>>>> >>>>> Sessions should be created/updated with all available interfaces. Rew= riting Tran's example: when the MN attaches to MAG1 via If1, the LMA create= s session 1: >>>>> >>>>> =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] >>>>> >>>>> Then, if the MN attaches to MAG2 via If2, the LMA creates session 2 w= ith both If1 and If2. The LMA also updates session 1 with If2: >>>>> >>>>> =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] >>>>> =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2, IF1] >>>>> >>>>> MAG2 receives prefixes 1 and 2 in PBA but MAG1 is not sending PBU. So= , if the LMA wants to move flow with Pref2 from if2 to If1, the LMA needs t= o provide Pref2 to MAG1. Also, the LMA should be able to create new session= s with already up interfaces, e.g. if1 and if2. To address both issues, PBU= from MAG1 could be triggered (triggering is to be clarified) or we could d= efine LMA/MAG specific L3 signalling (FMI/FMA). >>>>> >>>>> My 2 cents, >>>>> Pierrick >>>>> >>>>>> -----Message d'origine----- >>>>>> De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De l= a part >>>>>> de Youn-Hee Han >>>>>> Envoy=E9=A0: mardi 8 f=E9vrier 2011 12:00 >>>>>> =C0=A0: 'Julien Laganier'; 'Rajeev Koodli' >>>>>> Cc=A0: netext@ietf.org; Basavaraj.Patil@nokia.com >>>>>> Objet=A0: Re: [netext] Consensus call to adopt I-D:draft-bernardos-n= etext- >>>>>> pmipv6-flowmob as WG doc >>>>>> >>>>>> Hi Julien, >>>>>> >>>>>> > -----Original Message----- >>>>>> > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On = Behalf >>>>>> > Of Julien Laganier >>>>>> > Sent: Tuesday, February 08, 2011 1:38 PM >>>>>> > To: Rajeev Koodli >>>>>> > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com >>>>>> > Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos= - >>>>>> > netext-pmipv6-flowmob as WG doc >>>>>> > >>>>>> > On Mon, Feb 7, 2011 at 6:15 PM, Rajeev Koodli = wrote: >>>>>> > > >>>>>> > > If flow mobility has nothing do with prefix management, I am los= t. >>>>>> > >>>>>> > No reason to be lost: Prefix management is how do I get prefix for= the >>>>>> > MN. Flow mobility is how to I move flows across interfaces. The tw= o >>>>>> > needs not to be intertwined together, as I've shown in my other no= tes. >>>>>> > E.g., I can do flow mobility without adding/deleting prefixes from >>>>>> > sessions, and vice versa. >>>>>> >>>>>> Yes, I agree with you. Flow mobility is how to move flows across int= erface. >>>>>> So, I thought that it would be better to define "a flow" exactly in = netext >>>>>> WG prior to discuss flow mobility management. As the definition of "= a >>>>>> flow", >>>>>> all I can think is a five-tuple plus something. If we assume that it= is >>>>>> correct, I think that flow mobility and prefix addition are inevitab= ly >>>>>> tied. >>>>>> As you know, RFC5213 (and IPv6 protocol spec) already allow to assig= n >>>>>> multiple prefixes across multiple interfaces of an MN. Yes, I also a= gree >>>>>> with you that in real-world (3GPP), there may be no need to assign >>>>>> multiple >>>>>> prefixes into an MN. (if somebody knows its necessity, please tell m= e when >>>>>> it should happen). So, flow mobility can be done without adding pref= ixes. >>>>>> However, different interfaces are allowed to be assigned different >>>>>> prefixes >>>>>> by RFC 5213 and IPv6 spec. We can't expect what kind of prefixes an = MAG >>>>>> advertises. Therefore, sometimes, we need prefix addition to move a = flow >>>>>> to >>>>>> a new interface of which MAG does not yet advertise the prefix of th= e flow >>>>>> being moved. >>>>>> >>>>>> (snip...) >>>>>> >>>>>> > >> I see no reason to depart from that in the context of extending= the >>>>>> > >> protocol to support mobility, nor I am aware of any system >>>>>> > >> architecture that would require this capability. >>>>>> > > >>>>>> > > Okay, see your position. I see it differently. I don't need to b= e >>>>>> > > bound by some "presumed implementation model" of PMIP6 and limit >>>>>> > > myself *only* to a prefix assignment model you are imagining. >>>>>> > >>>>>> > It's not an implementation model, it is a protocol model, and it's= not >>>>>> > imaginary. Implementation has nothing to do with this. >>>>>> > >>>>>> > There's no reason to extend prefix assignment model to do flow mob= ility >>>>>> > unless you can point me out in which real world context your scena= rio >>>>>> > actually happens. >>>>>> >>>>>> As I insisted in the old mail, I agree with Julien in this regard. C= urrent >>>>>> draft allows too much space regarding the prefix allocation model (u= nique, >>>>>> shared, and hybrid). When a flow should be moved to a new interface = and >>>>>> the >>>>>> prefix which the flow uses is not yet advertised by the new MAG, jus= t >>>>>> inform >>>>>> the prefix to the MAG and thus make it advertise the prefix and setu= p the >>>>>> tunnel based on the new prefix. That's all!. If the prefix is alread= y >>>>>> advertised by the MAG, there is nothing to do and just move the flow= . This >>>>>> behaviors are very natural one when we want to support IP-level mobi= lity. >>>>>> >>>>>> > >> If this is something really important, the WG can be rechartere= d to >>>>>> > >> work on a different extension that would allow adding/removing >>>>>> > >> prefixes from existing PMIPv6 sessions. >>>>>> > > >>>>>> > > Huh.. What in the current charter forces us not to have the LMA >>>>>> > > add/refresh/delete a prefix on-demand? >>>>>> > >>>>>> > Engineering is about finding a solution to a problem. Adding/delet= ing >>>>>> > prefix on-demand is not a solution to flow mobility. I've shown yo= u how >>>>>> > to do flow mobility without this capability. >>>>>> >>>>>> From the viewpoint of protocol, I think that at least, prefix additi= on to >>>>>> an >>>>>> interface is a necessary function to support flow mobility, as I exp= lained >>>>>> above. But, it does not mean prefix addition should happen always wh= enever >>>>>> flow mobility occurs. It is sometimes needed. >>>>>> >>>>>> > Now a different engineering problem would be: how to add/delete pr= efixes >>>>>> > to a PMIPv6 session, and that would be useful for e.g. >>>>>> > renumbering. This is a different problem that we haven't been char= tered >>>>>> > to work on. >>>>>> >>>>>> Prefix addition is just prefix addition. IMHO, renumbering is closer= to >>>>>> prefix change. We just harness that function to support IP-level mob= ility. >>>>>> >>>>>> Youn-Hee >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>> >>> >>> >>> -- >>> Ph.D., Senior Member >>> Electronics and Telecommunications Research Institute >>> Standards Research Center >>> 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA >>> Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 >>> >> > > > > -- > Ph.D., Senior Member > Electronics and Telecommunications Research Institute > Standards Research Center > 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA > Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 > From sgundave@cisco.com Tue Feb 8 19:02:47 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E06913A68DB for ; Tue, 8 Feb 2011 19:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.824 X-Spam-Level: X-Spam-Status: No, score=-8.824 tagged_above=-999 required=5 tests=[AWL=-1.775, BAYES_00=-2.599, FRT_BELOW2=2.154, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8tTQuoYctgT for ; Tue, 8 Feb 2011 19:02:46 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 8F7F23A6879 for ; Tue, 8 Feb 2011 19:02:46 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmYFAO6SUU2rR7Ht/2dsb2JhbACWaIhvBoUBZnOiJps1hVoEhHuGb4M1gwE Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 09 Feb 2011 03:02:53 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1932sxK028470; Wed, 9 Feb 2011 03:02:54 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Feb 2011 19:02:54 -0800 Received: from 10.32.246.213 ([10.32.246.213]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Wed, 9 Feb 2011 03:02:54 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 08 Feb 2011 19:03:36 -0800 From: Sri Gundavelli To: Tran Minh Trung , Julien Laganier Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvIBfFdPjMWYcAOs0WdV1BkkeSY8Q== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 09 Feb 2011 03:02:54.0734 (UTC) FILETIME=[D8C482E0:01CBC805] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 03:02:48 -0000 Hi Tran: Policy change is not a general case, it is a special case. It can indeed take affect after a lapse of time. Either way, the trigger from LMA to MAG is one option, I'm still not convinced why I'd need FMA. The trigger should force the MAG to send a PBU and per RFC-5213, it should get a set of prefixes that its hosting on the access link. This essentially, forces the approach of session state creation at the request of the MAG. If policy change is a valid case, a simple trigger is sufficient. Regards Sri On 2/8/11 6:49 PM, "Tran Minh Trung" wrote: > Hi Julien, >=20 > Let me show a real case for the scenario that we are discussing bellow: >=20 > The network policy is changed and the LMA decides to move flow 2 from > IF2 to IF1 before MAG1 received L2 trigger from the MN (say before > step #8) > In that case, the LMA should signal MAG1 to send PBU to attach IF1 to > session 2. >=20 > Without signaling from LMA how can you do in this case? Just wait > until receiving L2 trigger from the MN? >=20 > On Wed, Feb 9, 2011 at 7:18 AM, Julien Laganier w= rote: >> Hi Pierrick, >>=20 >> I am going to intertwine the steps in your scenario below with the >> missing pieces of the big picture so that we are not doing an academic >> exercise but focusing on the real world: >>=20 >> 1. when the MN first attaches with if1 to a network, MAG1 requests >> attachment of if1 to a session1 by sending a PBU to LMA >>=20 >> 2. because the MN add no session1 previously, the LMA creates session >> 1 and allocates a prefix for it. The prefix is sent back to MAG1 in >> the PBA: >>=20 >> =A0=A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1-IF1] >>=20 >> 3. then, if the MN attaches with if2 to another network, but does not >> request this interface be attached to a distinct session, MAG2 >> requests attachemnt of If2 to session1 by sending a PBU to LMA >>=20 >> 4. Because the MN already has session 1, the LMA updates session1 with >> if2, and send the pref1 back to MAG2 in the PBA: >>=20 >> =A0=A0 =A0 =A0 =A0 Session1: [Pref1, MAG1-IF1, MAG2-IF2] >>=20 >> 5. Creation of a new session 2 for if2 is requested by either of MN >> requests via L2 triggers, or a change in policy profile. As a result, >> MAG2 requests attachment of if2 to session2 by sending a PBU to LMA. >>=20 >> 6. because the MN add no session2 previously, the LMA creates session >> 2 and allocates a prefix for it. The prefix pref2 is sent back to MAG2 >> in the PBA: >>=20 >> =A0=A0 =A0 =A0 =A0 =A0Session2: [Pref2, MAG2-IF2] >>=20 >> 7. Flow2 starts over if2 with prefix2. >>=20 >> 8. Attachment of if1 to session2 is requested by either of MN requests >> via L2 triggers, or a change in policy profile. As a result, MAG1 >> requests attachment of if1 to session2 by sending a PBU to LMA. >>=20 >> 9. Because the MN already has session 2, the LMA updates session2 with i= f1: >>=20 >> =A0=A0 =A0 =A0 =A0 Session2: [Pref2, MAG2-IF2, MAG1-IF1] >>=20 >> 10. At any point, the LMA decides to move Flow2 between two interfaces >> of session 2, and it does so. >>=20 >> That's all that needed. It maps perfectly to 3GPP. If you have in mind >> a different system in whcih that doesn't map, please let me know. >>=20 >> --julien >>=20 >> On Tue, Feb 8, 2011 at 8:25 AM, =A0 wro= te: >>> Hi, >>>=20 >>> Going through this long thread :-), it seems we could agree on the foll= owing >>> (just a tentative to summarize): >>>=20 >>> Sessions should be created/updated with all available interfaces. Rewri= ting >>> Tran's example: when the MN attaches to MAG1 via If1, the LMA creates >>> session 1: >>>=20 >>> =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] >>>=20 >>> Then, if the MN attaches to MAG2 via If2, the LMA creates session 2 wit= h >>> both If1 and If2. The LMA also updates session 1 with If2: >>>=20 >>> =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] >>> =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2, IF1] >>>=20 >>> MAG2 receives prefixes 1 and 2 in PBA but MAG1 is not sending PBU. So, = if >>> the LMA wants to move flow with Pref2 from if2 to If1, the LMA needs to >>> provide Pref2 to MAG1. Also, the LMA should be able to create new sessi= ons >>> with already up interfaces, e.g. if1 and if2. To address both issues, P= BU >>> from MAG1 could be triggered (triggering is to be clarified) or we coul= d >>> define LMA/MAG specific L3 signalling (FMI/FMA). >>>=20 >>> My 2 cents, >>> Pierrick >>>=20 >>>> -----Message d'origine----- >>>> De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la pa= rt >>>> de Youn-Hee Han >>>> Envoy=E9=A0: mardi 8 f=E9vrier 2011 12:00 >>>> =C0=A0: 'Julien Laganier'; 'Rajeev Koodli' >>>> Cc=A0: netext@ietf.org; Basavaraj.Patil@nokia.com >>>> Objet=A0: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netex= t- >>>> pmipv6-flowmob as WG doc >>>>=20 >>>> Hi Julien, >>>>=20 >>>>> -----Original Message----- >>>>> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Beh= alf >>>>> Of Julien Laganier >>>>> Sent: Tuesday, February 08, 2011 1:38 PM >>>>> To: Rajeev Koodli >>>>> Cc: netext@ietf.org; Basavaraj.Patil@nokia.com >>>>> Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos- >>>>> netext-pmipv6-flowmob as WG doc >>>>>=20 >>>>> On Mon, Feb 7, 2011 at 6:15 PM, Rajeev Koodli wro= te: >>>>>>=20 >>>>>> If flow mobility has nothing do with prefix management, I am lost. >>>>>=20 >>>>> No reason to be lost: Prefix management is how do I get prefix for th= e >>>>> MN. Flow mobility is how to I move flows across interfaces. The two >>>>> needs not to be intertwined together, as I've shown in my other notes= . >>>>> E.g., I can do flow mobility without adding/deleting prefixes from >>>>> sessions, and vice versa. >>>>=20 >>>> Yes, I agree with you. Flow mobility is how to move flows across inter= face. >>>> So, I thought that it would be better to define "a flow" exactly in ne= text >>>> WG prior to discuss flow mobility management. As the definition of "a >>>> flow", >>>> all I can think is a five-tuple plus something. If we assume that it i= s >>>> correct, I think that flow mobility and prefix addition are inevitably >>>> tied. >>>> As you know, RFC5213 (and IPv6 protocol spec) already allow to assign >>>> multiple prefixes across multiple interfaces of an MN. Yes, I also agr= ee >>>> with you that in real-world (3GPP), there may be no need to assign >>>> multiple >>>> prefixes into an MN. (if somebody knows its necessity, please tell me = when >>>> it should happen). So, flow mobility can be done without adding prefix= es. >>>> However, different interfaces are allowed to be assigned different >>>> prefixes >>>> by RFC 5213 and IPv6 spec. We can't expect what kind of prefixes an MA= G >>>> advertises. Therefore, sometimes, we need prefix addition to move a fl= ow >>>> to >>>> a new interface of which MAG does not yet advertise the prefix of the = flow >>>> being moved. >>>>=20 >>>> (snip...) >>>>=20 >>>>>>> I see no reason to depart from that in the context of extending the >>>>>>> protocol to support mobility, nor I am aware of any system >>>>>>> architecture that would require this capability. >>>>>>=20 >>>>>> Okay, see your position. I see it differently. I don't need to be >>>>>> bound by some "presumed implementation model" of PMIP6 and limit >>>>>> myself *only* to a prefix assignment model you are imagining. >>>>>=20 >>>>> It's not an implementation model, it is a protocol model, and it's no= t >>>>> imaginary. Implementation has nothing to do with this. >>>>>=20 >>>>> There's no reason to extend prefix assignment model to do flow mobili= ty >>>>> unless you can point me out in which real world context your scenario >>>>> actually happens. >>>>=20 >>>> As I insisted in the old mail, I agree with Julien in this regard. Cur= rent >>>> draft allows too much space regarding the prefix allocation model (uni= que, >>>> shared, and hybrid). When a flow should be moved to a new interface an= d >>>> the >>>> prefix which the flow uses is not yet advertised by the new MAG, just >>>> inform >>>> the prefix to the MAG and thus make it advertise the prefix and setup = the >>>> tunnel based on the new prefix. That's all!. If the prefix is already >>>> advertised by the MAG, there is nothing to do and just move the flow. = This >>>> behaviors are very natural one when we want to support IP-level mobili= ty. >>>>=20 >>>>>>> If this is something really important, the WG can be rechartered to >>>>>>> work on a different extension that would allow adding/removing >>>>>>> prefixes from existing PMIPv6 sessions. >>>>>>=20 >>>>>> Huh.. What in the current charter forces us not to have the LMA >>>>>> add/refresh/delete a prefix on-demand? >>>>>=20 >>>>> Engineering is about finding a solution to a problem. Adding/deleting >>>>> prefix on-demand is not a solution to flow mobility. I've shown you h= ow >>>>> to do flow mobility without this capability. >>>>=20 >>>> From the viewpoint of protocol, I think that at least, prefix addition= to >>>> an >>>> interface is a necessary function to support flow mobility, as I expla= ined >>>> above. But, it does not mean prefix addition should happen always when= ever >>>> flow mobility occurs. It is sometimes needed. >>>>=20 >>>>> Now a different engineering problem would be: how to add/delete prefi= xes >>>>> to a PMIPv6 session, and that would be useful for e.g. >>>>> renumbering. This is a different problem that we haven't been charter= ed >>>>> to work on. >>>>=20 >>>> Prefix addition is just prefix addition. IMHO, renumbering is closer t= o >>>> prefix change. We just harness that function to support IP-level mobil= ity. >>>>=20 >>>> Youn-Hee >>>>=20 >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >>=20 >=20 >=20 From sgundave@cisco.com Tue Feb 8 19:05:21 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 196883A68E2 for ; Tue, 8 Feb 2011 19:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.712 X-Spam-Level: X-Spam-Status: No, score=-9.712 tagged_above=-999 required=5 tests=[AWL=0.888, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKQP9Hl94iFJ for ; Tue, 8 Feb 2011 19:05:20 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 5E7E33A68E1 for ; Tue, 8 Feb 2011 19:05:20 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnwGACqTUU2rRN+K/2dsb2JhbACXJ44dc6IpmzWFWgSEe4ZvgzU Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 09 Feb 2011 03:05:28 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p1935Ss3029071; Wed, 9 Feb 2011 03:05:28 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Feb 2011 19:05:28 -0800 Received: from 10.32.246.213 ([10.32.246.213]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Wed, 9 Feb 2011 03:05:28 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 08 Feb 2011 19:06:08 -0800 From: Sri Gundavelli To: Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvIBkv2AcThjc4/uUGOf5Bsrk7KGw== In-Reply-To: <1297126632.3099.97.camel@acorde.it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 09 Feb 2011 03:05:28.0676 (UTC) FILETIME=[34863240:01CBC806] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 03:05:21 -0000 On 2/7/11 4:57 PM, "Carlos Jes=FAs Bernardos Cano" wrote: >>=20 >> I cannot emphasize more than this. We are not looking at flow management= as >> an extended state of BCE entry, rather as some thing new. BCE state is >> different and flow mobility state is different. We want to define our ow= n >> brand of messages. >>=20 >> MAG is responsible for creating the session state and the request for fl= ow >> mobility is carried right in that PBU message. The trigger from LMA to M= AG >> is needed when policy changes and that is when it can send an FMI trigge= r. >> No need for FMA, session management is always initiated by MAG. >>=20 >> The trigger in 99.99% of the times is coming from MAG. MN brings up an >> interface/pulls down an interface and that triggers the LMA to apply a f= low >> policy rules. But, the MAG sending a PBU is the trigger for flow mobilit= y. >> LMA in most cases is learning the triggers from MAG, which is attached t= o >> MN, except for reasons of policy change, where there is a need to send a >> trigger to MAG to send a PBU and that is FMI message. >=20 > So we need to support both cases, agree? >=20 Both cases ? Do you agree, a simple FMI trigger is sufficient ? Sri > Carlos >=20 >>=20 >> Hope we can get some sense into this draft. >>=20 >>=20 >> Sri >>=20 >>=20 From julien.ietf@gmail.com Tue Feb 8 19:07:11 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 683813A68D5 for ; Tue, 8 Feb 2011 19:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.514 X-Spam-Level: X-Spam-Status: No, score=-3.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OnthUJsLjrz for ; Tue, 8 Feb 2011 19:07:10 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 36B103A6876 for ; Tue, 8 Feb 2011 19:07:10 -0800 (PST) Received: by fxm9 with SMTP id 9so7328642fxm.31 for ; Tue, 08 Feb 2011 19:07:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=h/iuWRE99DWHNM1UDa6qDPHmwdccYhz5UPMpp7Ay1nM=; b=hRw4j30C+WJx6ODUft3/j2kirV9DLIh0LnSbsIfEFIVnSmOG8KivrlfG2CSAVMNA53 lkiV1Hvn4OlZBPXAKtYZk5+trTGxitEexBNcDy1AcmGCPb47LfBAArVw4/nJ/G8t3CGm EuJP0gG3OfobplMOxHNapgRA8eEeclx5NamBo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ChMV4A+/DHyzxEdpNyXWradP3pr/GrfYaRF7eB5q5dsBZPOZ1tcDUXzcL0LWVRaeb8 eXtAFKG9LSCAN/erTQ8aK8nEl4/8QmVhqtS1j5qkVEWwnXOeH8SS7/NaCLXRLMcI7Dto M84vsln6ElKXh3RYr+eG+qdolbztbAz2fp/tM= MIME-Version: 1.0 Received: by 10.103.192.12 with SMTP id u12mr10714500mup.75.1297220837863; Tue, 08 Feb 2011 19:07:17 -0800 (PST) Received: by 10.103.221.9 with HTTP; Tue, 8 Feb 2011 19:07:17 -0800 (PST) In-Reply-To: References: Date: Tue, 8 Feb 2011 19:07:17 -0800 Message-ID: From: Julien Laganier To: Rajeev Koodli Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 03:07:11 -0000 Hi Rajeev, On Tue, Feb 8, 2011 at 6:51 PM, Rajeev Koodli wrote: > > Hi Julien, > > On 2/8/11 5:25 PM, "Julien Laganier" wrote: > >> What would actually really helps all of us to make progress is that >> instead of telling what you'd like, as in > > It would also help if you didn't generalize your reservation to what I am > stating as in "..helps *all* of us..". I simply wanted to say that since I see no usecase to justify the type of features you'd like to have in, having a usecase outlined would help this discussion to converge, which seems to be helpful to people on this mailing list. There was certainly no intent to say that my reservations are shared by the whole working group. That being said, > I see you have a model in mind (which is pretty close to what is in the > draft already), which is fine. I fail to see why you are restricted to that > alone. But, perhaps that's less fruitful to delve into now. > > >>> I would like LMA-initiated signaling (FMI/FMA) for this (i.e., signaling to >>> MAG1 with Pref2) as well as for the above (i.e., being able to signal MAG2 >>> with Pref1) *whenever* the LMA wants. >> >> you'd rather tell us why this is needed, by whom, and where... I've >> been asking the same question over and over but nobody writes down an >> answer to this in this thread. > > I have mentioned why I need it a few times. 1) I am not required to assign > all the applicable prefixes at the time of attach *in anticipation* of > *potential* flow mobility. I will assign a relevant prefix *if and when* I > need to move a flow over. In 3GPP, the prefix is assigned when the PDN connection is created, and is then unchanged for the reminder of the lifetime of this PDN connection. So in your own words: You are not required to assign all the applicable prefixes at the time of attach *in anticipation* of *potential* flow mobility. You will assign the relevant prefix *if and when* I you need a PDN connection. If you have another target system than 3GPP, what is it? > It makes no sense for me to be *forced* to assign > all the prefixes at the time of attach (just because it is aligned with > legacy RFC 5213 "model"). Assigning all the prefixes at time of attaches isn't a requirement for flow mobility. You can very well have a single prefix and do flow mobility across multiple interfaces. 2) I want to assign a prefix based on policy > triggers, including the TOD rules. I don't see how useful it is to assign prefixes based on time of day. I understand you might want to move flows based on time of day, but as I said above, you can already move flows with a single prefix when the time is good for you. I want to move certain type of traffic > over to a different interface based on peak hour bulk stats, the volume of > traffic the user is consuming at a particular instance, the amount of quota > left and so on. All capabilities that are perfectly available without juggling with multiple prefixes, as above. > I want to be able to refresh the lifetime of that prefix and > revoke it back to its "natural interface" when I want. This is renumbering - a different interface. I also don't know what a natural interface is when prefixes are assigned from withing an overlay... > I want to be able to offer this for my customers. Most of which you can, as I stated above, independently of prefix juggling... >> Absent that, will I be forced to conclude that this needed by no-one? > > If I don't need something that does not imply the rest don't either! :-) Can they speak up then? :-) --julien From Mohana.Jeyatharan@sg.panasonic.com Tue Feb 8 19:07:59 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1CB33A68D5 for ; Tue, 8 Feb 2011 19:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.064 X-Spam-Level: ** X-Spam-Status: No, score=2.064 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xs1+Ld85IqHp for ; Tue, 8 Feb 2011 19:07:58 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 39DC03A6876 for ; Tue, 8 Feb 2011 19:07:58 -0800 (PST) Received: from mail-gw.jp.panasonic.com ([157.8.1.157]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id p19383AU025805; Wed, 9 Feb 2011 12:08:03 +0900 (JST) Received: from pslexc01.psl.local ([10.81.112.5]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili16) with ESMTP id p19382310526; Wed, 9 Feb 2011 12:08:03 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Feb 2011 11:09:10 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD04A6D405@pslexc01.psl.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvIBSnYOCqeLvzCTpilyOhDS1R+OgAAOsfw References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com><843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> From: "Mohana Jeyatharan" To: "Tran Minh Trung" , "Julien Laganier" Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 03:07:59 -0000 Hi Trung, The MAG getting some triggers from MN is not the same as Client based = flow mobility mobility. Sessions are moved and created based on MAG to = LMA signaling (as in the current draft). Anyway, the draft-bernados has = text that MAG can get such information from MN. Although an explicit = statement such as L2 is not mentioned. Again as Julien pointed out, RFC 5213 also assumes such L2 signaling.=20 BR, Mohana > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On = Behalf > Of Tran Minh Trung > Sent: Wednesday, February 09, 2011 10:58 AM > To: Julien Laganier > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > Subject: Re: [netext] Consensus call to adopt = I-D:draft-bernardos-netext- > pmipv6-flowmob as WG doc >=20 > Since we are proposing network-based flow mobility, I think that it = must be > transparent to the MN. > if not the network-based solution is similar as client-based one. >=20 > Regards, > TrungTM >=20 > On Wed, Feb 9, 2011 at 11:53 AM, Julien Laganier = > wrote: > > Changing the policy on the network side alone isn't sufficient. = You'd > > have to change the policy on the host, too (e.g., using ADNSF in = 3GPP) > > which will trigger the MN to attach IF1 to session 2. > > > > This is the system view picture which seems we're missing in this > discussion. > > > > --julien > > > > On Tue, Feb 8, 2011 at 6:49 PM, Tran Minh Trung > wrote: > >> Hi Julien, > >> > >> Let me show a real case for the scenario that we are discussing = bellow: > >> > >> The network policy is changed and the LMA decides to move flow 2 = from > >> IF2 to IF1 before MAG1 received L2 trigger from the MN (say before > >> step #8) In that case, the LMA should signal MAG1 to send PBU to > >> attach IF1 to session 2. > >> > >> Without signaling from LMA how can you do in this case? Just wait > >> until receiving L2 trigger from the MN? > >> > >> On Wed, Feb 9, 2011 at 7:18 AM, Julien Laganier = > wrote: > >>> Hi Pierrick, > >>> > >>> I am going to intertwine the steps in your scenario below with the > >>> missing pieces of the big picture so that we are not doing an > >>> academic exercise but focusing on the real world: > >>> > >>> 1. when the MN first attaches with if1 to a network, MAG1 requests > >>> attachment of if1 to a session1 by sending a PBU to LMA > >>> > >>> 2. because the MN add no session1 previously, the LMA creates > >>> session > >>> 1 and allocates a prefix for it. The prefix is sent back to MAG1 = in > >>> the PBA: > >>> > >>> =A0=A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1-IF1] > >>> > >>> 3. then, if the MN attaches with if2 to another network, but does > >>> not request this interface be attached to a distinct session, MAG2 > >>> requests attachemnt of If2 to session1 by sending a PBU to LMA > >>> > >>> 4. Because the MN already has session 1, the LMA updates session1 > >>> with if2, and send the pref1 back to MAG2 in the PBA: > >>> > >>> =A0=A0 =A0 =A0 =A0 Session1: [Pref1, MAG1-IF1, MAG2-IF2] > >>> > >>> 5. Creation of a new session 2 for if2 is requested by either of = MN > >>> requests via L2 triggers, or a change in policy profile. As a > >>> result, > >>> MAG2 requests attachment of if2 to session2 by sending a PBU to = LMA. > >>> > >>> 6. because the MN add no session2 previously, the LMA creates > >>> session > >>> 2 and allocates a prefix for it. The prefix pref2 is sent back to > >>> MAG2 in the PBA: > >>> > >>> =A0=A0 =A0 =A0 =A0 =A0Session2: [Pref2, MAG2-IF2] > >>> > >>> 7. Flow2 starts over if2 with prefix2. > >>> > >>> 8. Attachment of if1 to session2 is requested by either of MN > >>> requests via L2 triggers, or a change in policy profile. As a > >>> result, MAG1 requests attachment of if1 to session2 by sending a = PBU to > LMA. > >>> > >>> 9. Because the MN already has session 2, the LMA updates session2 = with > if1: > >>> > >>> =A0=A0 =A0 =A0 =A0 Session2: [Pref2, MAG2-IF2, MAG1-IF1] > >>> > >>> 10. At any point, the LMA decides to move Flow2 between two > >>> interfaces of session 2, and it does so. > >>> > >>> That's all that needed. It maps perfectly to 3GPP. If you have in > >>> mind a different system in whcih that doesn't map, please let me = know. > >>> > >>> --julien > >>> > >>> On Tue, Feb 8, 2011 at 8:25 AM, = =A0 > wrote: > >>>> Hi, > >>>> > >>>> Going through this long thread :-), it seems we could agree on = the > following (just a tentative to summarize): > >>>> > >>>> Sessions should be created/updated with all available interfaces. > Rewriting Tran's example: when the MN attaches to MAG1 via If1, the = LMA > creates session 1: > >>>> > >>>> =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] > >>>> > >>>> Then, if the MN attaches to MAG2 via If2, the LMA creates session = 2 > with both If1 and If2. The LMA also updates session 1 with If2: > >>>> > >>>> =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] > >>>> =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2, IF1] > >>>> > >>>> MAG2 receives prefixes 1 and 2 in PBA but MAG1 is not sending = PBU. > So, if the LMA wants to move flow with Pref2 from if2 to If1, the LMA = needs > to provide Pref2 to MAG1. Also, the LMA should be able to create new > sessions with already up interfaces, e.g. if1 and if2. To address both = issues, > PBU from MAG1 could be triggered (triggering is to be clarified) or we = could > define LMA/MAG specific L3 signalling (FMI/FMA). > >>>> > >>>> My 2 cents, > >>>> Pierrick > >>>> > >>>>> -----Message d'origine----- > >>>>> De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] = De > >>>>> la part de Youn-Hee Han Envoy=E9=A0: mardi 8 f=E9vrier 2011 = 12:00 =C0=A0: > >>>>> 'Julien Laganier'; 'Rajeev Koodli' > >>>>> Cc=A0: netext@ietf.org; Basavaraj.Patil@nokia.com Objet=A0: Re: > >>>>> [netext] Consensus call to adopt I-D:draft-bernardos-netext- > >>>>> pmipv6-flowmob as WG doc > >>>>> > >>>>> Hi Julien, > >>>>> > >>>>> > -----Original Message----- > >>>>> > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] > >>>>> > On Behalf Of Julien Laganier > >>>>> > Sent: Tuesday, February 08, 2011 1:38 PM > >>>>> > To: Rajeev Koodli > >>>>> > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > >>>>> > Subject: Re: [netext] Consensus call to adopt I-D: > >>>>> > draft-bernardos- netext-pmipv6-flowmob as WG doc > >>>>> > > >>>>> > On Mon, Feb 7, 2011 at 6:15 PM, Rajeev Koodli = > wrote: > >>>>> > > > >>>>> > > If flow mobility has nothing do with prefix management, I am = lost. > >>>>> > > >>>>> > No reason to be lost: Prefix management is how do I get prefix > >>>>> > for the MN. Flow mobility is how to I move flows across > >>>>> > interfaces. The two needs not to be intertwined together, as = I've > shown in my other notes. > >>>>> > E.g., I can do flow mobility without adding/deleting prefixes > >>>>> > from sessions, and vice versa. > >>>>> > >>>>> Yes, I agree with you. Flow mobility is how to move flows across > interface. > >>>>> So, I thought that it would be better to define "a flow" exactly > >>>>> in netext WG prior to discuss flow mobility management. As the > >>>>> definition of "a flow", all I can think is a five-tuple plus > >>>>> something. If we assume that it is correct, I think that flow > >>>>> mobility and prefix addition are inevitably tied. > >>>>> As you know, RFC5213 (and IPv6 protocol spec) already allow to > >>>>> assign multiple prefixes across multiple interfaces of an MN. = Yes, > >>>>> I also agree with you that in real-world (3GPP), there may be no > >>>>> need to assign multiple prefixes into an MN. (if somebody knows > >>>>> its necessity, please tell me when it should happen). So, flow > >>>>> mobility can be done without adding prefixes. > >>>>> However, different interfaces are allowed to be assigned = different > >>>>> prefixes by RFC 5213 and IPv6 spec. We can't expect what kind of > >>>>> prefixes an MAG advertises. Therefore, sometimes, we need prefix > >>>>> addition to move a flow to a new interface of which MAG does not > >>>>> yet advertise the prefix of the flow being moved. > >>>>> > >>>>> (snip...) > >>>>> > >>>>> > >> I see no reason to depart from that in the context of > >>>>> > >> extending the protocol to support mobility, nor I am aware = of > >>>>> > >> any system architecture that would require this capability. > >>>>> > > > >>>>> > > Okay, see your position. I see it differently. I don't need = to > >>>>> > > be bound by some "presumed implementation model" of PMIP6 > and > >>>>> > > limit myself *only* to a prefix assignment model you are > imagining. > >>>>> > > >>>>> > It's not an implementation model, it is a protocol model, and > >>>>> > it's not imaginary. Implementation has nothing to do with = this. > >>>>> > > >>>>> > There's no reason to extend prefix assignment model to do flow > >>>>> > mobility unless you can point me out in which real world = context > >>>>> > your scenario actually happens. > >>>>> > >>>>> As I insisted in the old mail, I agree with Julien in this = regard. > >>>>> Current draft allows too much space regarding the prefix > >>>>> allocation model (unique, shared, and hybrid). When a flow = should > >>>>> be moved to a new interface and the prefix which the flow uses = is > >>>>> not yet advertised by the new MAG, just inform the prefix to the > >>>>> MAG and thus make it advertise the prefix and setup the tunnel > >>>>> based on the new prefix. That's all!. If the prefix is already > >>>>> advertised by the MAG, there is nothing to do and just move the > >>>>> flow. This behaviors are very natural one when we want to = support > IP-level mobility. > >>>>> > >>>>> > >> If this is something really important, the WG can be > >>>>> > >> rechartered to work on a different extension that would = allow > >>>>> > >> adding/removing prefixes from existing PMIPv6 sessions. > >>>>> > > > >>>>> > > Huh.. What in the current charter forces us not to have the > >>>>> > > LMA add/refresh/delete a prefix on-demand? > >>>>> > > >>>>> > Engineering is about finding a solution to a problem. > >>>>> > Adding/deleting prefix on-demand is not a solution to flow > >>>>> > mobility. I've shown you how to do flow mobility without this > capability. > >>>>> > >>>>> From the viewpoint of protocol, I think that at least, prefix > >>>>> addition to an interface is a necessary function to support flow > >>>>> mobility, as I explained above. But, it does not mean prefix > >>>>> addition should happen always whenever flow mobility occurs. It = is > >>>>> sometimes needed. > >>>>> > >>>>> > Now a different engineering problem would be: how to = add/delete > >>>>> > prefixes to a PMIPv6 session, and that would be useful for = e.g. > >>>>> > renumbering. This is a different problem that we haven't been > >>>>> > chartered to work on. > >>>>> > >>>>> Prefix addition is just prefix addition. IMHO, renumbering is > >>>>> closer to prefix change. We just harness that function to = support IP- > level mobility. > >>>>> > >>>>> Youn-Hee > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>> > >> > >> > >> > >> -- > >> Ph.D., Senior Member > >> Electronics and Telecommunications Research Institute Standards > >> Research Center > >> 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : > >> +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 > >> > > >=20 >=20 >=20 > -- > Ph.D., Senior Member > Electronics and Telecommunications Research Institute Standards = Research > Center > 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : = +82-42-860- > 1132,=A0=A0 Fax : +82-42-861-5404 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From trungtm2909@gmail.com Tue Feb 8 19:10:49 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06ABD3A68DB for ; Tue, 8 Feb 2011 19:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=-0.726, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1M6YUC5l6sxz for ; Tue, 8 Feb 2011 19:10:44 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 4634A3A6879 for ; Tue, 8 Feb 2011 19:10:44 -0800 (PST) Received: by qyj19 with SMTP id 19so4986430qyj.10 for ; Tue, 08 Feb 2011 19:10:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vLzCinB1ERy2QeyTdOmxLbKAkFL3Zf9o2IB9oVKTJoI=; b=mq437n3ik4ghm6qvtgmNliOoGkuo8XC8fwbS+BidnsO+bEEFs7nwlYDUl2s2Xls48l YwfJqKXDYatmVsinYQ/AynYbhBe/Qy4L7r0ZbxPIQAtk8LsVXO2wxrW2EB0smyaPHuf/ Rfv0umspaQfWp2IkFIGcomaIwxGfz5Q0tjV1Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ni5MjgwB5QME2dU94pbsBpiLM0u/g8G3+phPJRnOy0poC2JMNPUnwvDDSAtG0Edbe7 Biukk+KFKWlNs+uOIMiJwHHMnmycVkh4ii7sAUcovZuaiXW5Xeja9VagOas7Ic1mLEXG R++4kppD61e9euehB22ZgiZCz6QALtYXqFDIU= MIME-Version: 1.0 Received: by 10.224.19.207 with SMTP id c15mr15854174qab.50.1297221051962; Tue, 08 Feb 2011 19:10:51 -0800 (PST) Received: by 10.224.89.11 with HTTP; Tue, 8 Feb 2011 19:10:51 -0800 (PST) In-Reply-To: References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> Date: Wed, 9 Feb 2011 12:10:51 +0900 Message-ID: From: Tran Minh Trung To: Julien Laganier Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 03:10:49 -0000 On Wed, Feb 9, 2011 at 12:00 PM, Julien Laganier wr= ote: > Network based flow mobility cannot be entirely transparent to the MN. > It can be made transparent to the *IP layer* on the MN, but at minimum > the layer 2 will have to change to decide where to send uplink > packets. > Did we agreed that the logical interface can send uplink packets following the path that down-link packets received?. The key purpose of network-based solution is minimize the involvement of th= e MN. IMHO, both vendors and network operator prefer that way. Regards, TrungTM > This is a fact. > > I am sorry if that means that the network-based solution is > functionally equivalent to the client based and only differ in terms > of the placement of the functions in various layer, but I cannot help > it. > > --julien > > On Tue, Feb 8, 2011 at 6:57 PM, Tran Minh Trung w= rote: >> Since we are proposing network-based flow mobility, I think that it >> must be transparent to the MN. >> if not the network-based solution is similar as client-based one. >> >> Regards, >> TrungTM >> >> On Wed, Feb 9, 2011 at 11:53 AM, Julien Laganier = wrote: >>> Changing the policy on the network side alone isn't sufficient. You'd >>> have to change the policy on the host, too (e.g., using ADNSF in 3GPP) >>> which will trigger the MN to attach IF1 to session 2. >>> >>> This is the system view picture which seems we're missing in this discu= ssion. >>> >>> --julien >>> >>> On Tue, Feb 8, 2011 at 6:49 PM, Tran Minh Trung = wrote: >>>> Hi Julien, >>>> >>>> Let me show a real case for the scenario that we are discussing bellow= : >>>> >>>> The network policy is changed and the LMA decides to move flow 2 from >>>> IF2 to IF1 before MAG1 received L2 trigger from the MN (say before >>>> step #8) >>>> In that case, the LMA should signal MAG1 to send PBU to attach IF1 to >>>> session 2. >>>> >>>> Without signaling from LMA how can you do in this case? Just wait >>>> until receiving L2 trigger from the MN? >>>> >>>> On Wed, Feb 9, 2011 at 7:18 AM, Julien Laganier wrote: >>>>> Hi Pierrick, >>>>> >>>>> I am going to intertwine the steps in your scenario below with the >>>>> missing pieces of the big picture so that we are not doing an academi= c >>>>> exercise but focusing on the real world: >>>>> >>>>> 1. when the MN first attaches with if1 to a network, MAG1 requests >>>>> attachment of if1 to a session1 by sending a PBU to LMA >>>>> >>>>> 2. because the MN add no session1 previously, the LMA creates session >>>>> 1 and allocates a prefix for it. The prefix is sent back to MAG1 in >>>>> the PBA: >>>>> >>>>> =A0=A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1-IF1] >>>>> >>>>> 3. then, if the MN attaches with if2 to another network, but does not >>>>> request this interface be attached to a distinct session, MAG2 >>>>> requests attachemnt of If2 to session1 by sending a PBU to LMA >>>>> >>>>> 4. Because the MN already has session 1, the LMA updates session1 wit= h >>>>> if2, and send the pref1 back to MAG2 in the PBA: >>>>> >>>>> =A0=A0 =A0 =A0 =A0 Session1: [Pref1, MAG1-IF1, MAG2-IF2] >>>>> >>>>> 5. Creation of a new session 2 for if2 is requested by either of MN >>>>> requests via L2 triggers, or a change in policy profile. As a result, >>>>> MAG2 requests attachment of if2 to session2 by sending a PBU to LMA. >>>>> >>>>> 6. because the MN add no session2 previously, the LMA creates session >>>>> 2 and allocates a prefix for it. The prefix pref2 is sent back to MAG= 2 >>>>> in the PBA: >>>>> >>>>> =A0=A0 =A0 =A0 =A0 =A0Session2: [Pref2, MAG2-IF2] >>>>> >>>>> 7. Flow2 starts over if2 with prefix2. >>>>> >>>>> 8. Attachment of if1 to session2 is requested by either of MN request= s >>>>> via L2 triggers, or a change in policy profile. As a result, MAG1 >>>>> requests attachment of if1 to session2 by sending a PBU to LMA. >>>>> >>>>> 9. Because the MN already has session 2, the LMA updates session2 wit= h if1: >>>>> >>>>> =A0=A0 =A0 =A0 =A0 Session2: [Pref2, MAG2-IF2, MAG1-IF1] >>>>> >>>>> 10. At any point, the LMA decides to move Flow2 between two interface= s >>>>> of session 2, and it does so. >>>>> >>>>> That's all that needed. It maps perfectly to 3GPP. If you have in min= d >>>>> a different system in whcih that doesn't map, please let me know. >>>>> >>>>> --julien >>>>> >>>>> On Tue, Feb 8, 2011 at 8:25 AM, =A0 wrote: >>>>>> Hi, >>>>>> >>>>>> Going through this long thread :-), it seems we could agree on the f= ollowing (just a tentative to summarize): >>>>>> >>>>>> Sessions should be created/updated with all available interfaces. Re= writing Tran's example: when the MN attaches to MAG1 via If1, the LMA creat= es session 1: >>>>>> >>>>>> =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] >>>>>> >>>>>> Then, if the MN attaches to MAG2 via If2, the LMA creates session 2 = with both If1 and If2. The LMA also updates session 1 with If2: >>>>>> >>>>>> =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] >>>>>> =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2, IF1] >>>>>> >>>>>> MAG2 receives prefixes 1 and 2 in PBA but MAG1 is not sending PBU. S= o, if the LMA wants to move flow with Pref2 from if2 to If1, the LMA needs = to provide Pref2 to MAG1. Also, the LMA should be able to create new sessio= ns with already up interfaces, e.g. if1 and if2. To address both issues, PB= U from MAG1 could be triggered (triggering is to be clarified) or we could = define LMA/MAG specific L3 signalling (FMI/FMA). >>>>>> >>>>>> My 2 cents, >>>>>> Pierrick >>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De = la part >>>>>>> de Youn-Hee Han >>>>>>> Envoy=E9=A0: mardi 8 f=E9vrier 2011 12:00 >>>>>>> =C0=A0: 'Julien Laganier'; 'Rajeev Koodli' >>>>>>> Cc=A0: netext@ietf.org; Basavaraj.Patil@nokia.com >>>>>>> Objet=A0: Re: [netext] Consensus call to adopt I-D:draft-bernardos-= netext- >>>>>>> pmipv6-flowmob as WG doc >>>>>>> >>>>>>> Hi Julien, >>>>>>> >>>>>>> > -----Original Message----- >>>>>>> > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On= Behalf >>>>>>> > Of Julien Laganier >>>>>>> > Sent: Tuesday, February 08, 2011 1:38 PM >>>>>>> > To: Rajeev Koodli >>>>>>> > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com >>>>>>> > Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardo= s- >>>>>>> > netext-pmipv6-flowmob as WG doc >>>>>>> > >>>>>>> > On Mon, Feb 7, 2011 at 6:15 PM, Rajeev Koodli = wrote: >>>>>>> > > >>>>>>> > > If flow mobility has nothing do with prefix management, I am lo= st. >>>>>>> > >>>>>>> > No reason to be lost: Prefix management is how do I get prefix fo= r the >>>>>>> > MN. Flow mobility is how to I move flows across interfaces. The t= wo >>>>>>> > needs not to be intertwined together, as I've shown in my other n= otes. >>>>>>> > E.g., I can do flow mobility without adding/deleting prefixes fro= m >>>>>>> > sessions, and vice versa. >>>>>>> >>>>>>> Yes, I agree with you. Flow mobility is how to move flows across in= terface. >>>>>>> So, I thought that it would be better to define "a flow" exactly in= netext >>>>>>> WG prior to discuss flow mobility management. As the definition of = "a >>>>>>> flow", >>>>>>> all I can think is a five-tuple plus something. If we assume that i= t is >>>>>>> correct, I think that flow mobility and prefix addition are inevita= bly >>>>>>> tied. >>>>>>> As you know, RFC5213 (and IPv6 protocol spec) already allow to assi= gn >>>>>>> multiple prefixes across multiple interfaces of an MN. Yes, I also = agree >>>>>>> with you that in real-world (3GPP), there may be no need to assign >>>>>>> multiple >>>>>>> prefixes into an MN. (if somebody knows its necessity, please tell = me when >>>>>>> it should happen). So, flow mobility can be done without adding pre= fixes. >>>>>>> However, different interfaces are allowed to be assigned different >>>>>>> prefixes >>>>>>> by RFC 5213 and IPv6 spec. We can't expect what kind of prefixes an= MAG >>>>>>> advertises. Therefore, sometimes, we need prefix addition to move a= flow >>>>>>> to >>>>>>> a new interface of which MAG does not yet advertise the prefix of t= he flow >>>>>>> being moved. >>>>>>> >>>>>>> (snip...) >>>>>>> >>>>>>> > >> I see no reason to depart from that in the context of extendin= g the >>>>>>> > >> protocol to support mobility, nor I am aware of any system >>>>>>> > >> architecture that would require this capability. >>>>>>> > > >>>>>>> > > Okay, see your position. I see it differently. I don't need to = be >>>>>>> > > bound by some "presumed implementation model" of PMIP6 and limi= t >>>>>>> > > myself *only* to a prefix assignment model you are imagining. >>>>>>> > >>>>>>> > It's not an implementation model, it is a protocol model, and it'= s not >>>>>>> > imaginary. Implementation has nothing to do with this. >>>>>>> > >>>>>>> > There's no reason to extend prefix assignment model to do flow mo= bility >>>>>>> > unless you can point me out in which real world context your scen= ario >>>>>>> > actually happens. >>>>>>> >>>>>>> As I insisted in the old mail, I agree with Julien in this regard. = Current >>>>>>> draft allows too much space regarding the prefix allocation model (= unique, >>>>>>> shared, and hybrid). When a flow should be moved to a new interface= and >>>>>>> the >>>>>>> prefix which the flow uses is not yet advertised by the new MAG, ju= st >>>>>>> inform >>>>>>> the prefix to the MAG and thus make it advertise the prefix and set= up the >>>>>>> tunnel based on the new prefix. That's all!. If the prefix is alrea= dy >>>>>>> advertised by the MAG, there is nothing to do and just move the flo= w. This >>>>>>> behaviors are very natural one when we want to support IP-level mob= ility. >>>>>>> >>>>>>> > >> If this is something really important, the WG can be recharter= ed to >>>>>>> > >> work on a different extension that would allow adding/removing >>>>>>> > >> prefixes from existing PMIPv6 sessions. >>>>>>> > > >>>>>>> > > Huh.. What in the current charter forces us not to have the LMA >>>>>>> > > add/refresh/delete a prefix on-demand? >>>>>>> > >>>>>>> > Engineering is about finding a solution to a problem. Adding/dele= ting >>>>>>> > prefix on-demand is not a solution to flow mobility. I've shown y= ou how >>>>>>> > to do flow mobility without this capability. >>>>>>> >>>>>>> From the viewpoint of protocol, I think that at least, prefix addit= ion to >>>>>>> an >>>>>>> interface is a necessary function to support flow mobility, as I ex= plained >>>>>>> above. But, it does not mean prefix addition should happen always w= henever >>>>>>> flow mobility occurs. It is sometimes needed. >>>>>>> >>>>>>> > Now a different engineering problem would be: how to add/delete p= refixes >>>>>>> > to a PMIPv6 session, and that would be useful for e.g. >>>>>>> > renumbering. This is a different problem that we haven't been cha= rtered >>>>>>> > to work on. >>>>>>> >>>>>>> Prefix addition is just prefix addition. IMHO, renumbering is close= r to >>>>>>> prefix change. We just harness that function to support IP-level mo= bility. >>>>>>> >>>>>>> Youn-Hee >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> Ph.D., Senior Member >>>> Electronics and Telecommunications Research Institute >>>> Standards Research Center >>>> 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA >>>> Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 >>>> >>> >> >> >> >> -- >> Ph.D., Senior Member >> Electronics and Telecommunications Research Institute >> Standards Research Center >> 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA >> Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 >> > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 From trungtm2909@gmail.com Tue Feb 8 19:13:25 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BACCF3A68D5 for ; Tue, 8 Feb 2011 19:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.081 X-Spam-Level: X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=-0.636, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsKVOEPOtX-B for ; Tue, 8 Feb 2011 19:13:24 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 1BB6E3A6879 for ; Tue, 8 Feb 2011 19:13:23 -0800 (PST) Received: by qyk34 with SMTP id 34so994231qyk.10 for ; Tue, 08 Feb 2011 19:13:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=05q1EAQnKeZVB6NnmWg3RE/SGvqDEhOLLglIeyxtMMU=; b=NB2JOJnMAJd4NPiKHrIoQcH+wY9Ep/9PjXYKANcAkYo4dvXtuUd7QiJOkmtRT5Dl+1 VNx4UnWXmY1d95Ue2oaqg20Jid9J2dJTYLZe4CzK6kqkw4yqvIxdF5vbBRE/EfTH5R5q nDE1Re/2AiB0MWRsnW8O8/7LRRrIPhR2sN9Rw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LsMaTT7mbL948arzqUc/+642bodLIhROh5Z+c7yznJjHzZH48i88FRWyTDe8zMNowS XizQ61RUFXQxqxPf+Yh4vTS3Q86oy7we4HBxFFQ938N91W+1XK6JkQyK5p5ha3a/3BbB LNR4i7nYGVnvaqWoGMFZ5FDEhSUX5NZovLcDI= MIME-Version: 1.0 Received: by 10.224.45.205 with SMTP id g13mr3259738qaf.350.1297221210173; Tue, 08 Feb 2011 19:13:30 -0800 (PST) Received: by 10.224.89.11 with HTTP; Tue, 8 Feb 2011 19:13:30 -0800 (PST) In-Reply-To: References: Date: Wed, 9 Feb 2011 12:13:30 +0900 Message-ID: From: Tran Minh Trung To: Sri Gundavelli Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 03:13:25 -0000 Hi Sri, If all of us are agree that it is not a general case and we can ignore it then I think the Julien's solution is sufficient. I am going out for lunch now. Talk to you later. Regards, TrungTM On Wed, Feb 9, 2011 at 12:03 PM, Sri Gundavelli wrote: > Hi Tran: > > Policy change is not a general case, it is a special case. It can indeed > take affect after a lapse of time. Either way, the trigger from LMA to MA= G > is one option, I'm still not convinced why I'd need FMA. The trigger shou= ld > force the MAG to send a PBU and per RFC-5213, it should get a set of > prefixes that its hosting on the access link. This essentially, forces th= e > approach of session state creation at the request of the MAG. If policy > change is a valid case, a simple trigger is sufficient. > > > Regards > Sri > > > > > > On 2/8/11 6:49 PM, "Tran Minh Trung" wrote: > >> Hi Julien, >> >> Let me show a real case for the scenario that we are discussing bellow: >> >> The network policy is changed and the LMA decides to move flow 2 from >> IF2 to IF1 before MAG1 received L2 trigger from the MN (say before >> step #8) >> In that case, the LMA should signal MAG1 to send PBU to attach IF1 to >> session 2. >> >> Without signaling from LMA how can you do in this case? Just wait >> until receiving L2 trigger from the MN? >> >> On Wed, Feb 9, 2011 at 7:18 AM, Julien Laganier = wrote: >>> Hi Pierrick, >>> >>> I am going to intertwine the steps in your scenario below with the >>> missing pieces of the big picture so that we are not doing an academic >>> exercise but focusing on the real world: >>> >>> 1. when the MN first attaches with if1 to a network, MAG1 requests >>> attachment of if1 to a session1 by sending a PBU to LMA >>> >>> 2. because the MN add no session1 previously, the LMA creates session >>> 1 and allocates a prefix for it. The prefix is sent back to MAG1 in >>> the PBA: >>> >>> =A0=A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1-IF1] >>> >>> 3. then, if the MN attaches with if2 to another network, but does not >>> request this interface be attached to a distinct session, MAG2 >>> requests attachemnt of If2 to session1 by sending a PBU to LMA >>> >>> 4. Because the MN already has session 1, the LMA updates session1 with >>> if2, and send the pref1 back to MAG2 in the PBA: >>> >>> =A0=A0 =A0 =A0 =A0 Session1: [Pref1, MAG1-IF1, MAG2-IF2] >>> >>> 5. Creation of a new session 2 for if2 is requested by either of MN >>> requests via L2 triggers, or a change in policy profile. As a result, >>> MAG2 requests attachment of if2 to session2 by sending a PBU to LMA. >>> >>> 6. because the MN add no session2 previously, the LMA creates session >>> 2 and allocates a prefix for it. The prefix pref2 is sent back to MAG2 >>> in the PBA: >>> >>> =A0=A0 =A0 =A0 =A0 =A0Session2: [Pref2, MAG2-IF2] >>> >>> 7. Flow2 starts over if2 with prefix2. >>> >>> 8. Attachment of if1 to session2 is requested by either of MN requests >>> via L2 triggers, or a change in policy profile. As a result, MAG1 >>> requests attachment of if1 to session2 by sending a PBU to LMA. >>> >>> 9. Because the MN already has session 2, the LMA updates session2 with = if1: >>> >>> =A0=A0 =A0 =A0 =A0 Session2: [Pref2, MAG2-IF2, MAG1-IF1] >>> >>> 10. At any point, the LMA decides to move Flow2 between two interfaces >>> of session 2, and it does so. >>> >>> That's all that needed. It maps perfectly to 3GPP. If you have in mind >>> a different system in whcih that doesn't map, please let me know. >>> >>> --julien >>> >>> On Tue, Feb 8, 2011 at 8:25 AM, =A0 = wrote: >>>> Hi, >>>> >>>> Going through this long thread :-), it seems we could agree on the fol= lowing >>>> (just a tentative to summarize): >>>> >>>> Sessions should be created/updated with all available interfaces. Rewr= iting >>>> Tran's example: when the MN attaches to MAG1 via If1, the LMA creates >>>> session 1: >>>> >>>> =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] >>>> >>>> Then, if the MN attaches to MAG2 via If2, the LMA creates session 2 wi= th >>>> both If1 and If2. The LMA also updates session 1 with If2: >>>> >>>> =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] >>>> =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2, IF1] >>>> >>>> MAG2 receives prefixes 1 and 2 in PBA but MAG1 is not sending PBU. So,= if >>>> the LMA wants to move flow with Pref2 from if2 to If1, the LMA needs t= o >>>> provide Pref2 to MAG1. Also, the LMA should be able to create new sess= ions >>>> with already up interfaces, e.g. if1 and if2. To address both issues, = PBU >>>> from MAG1 could be triggered (triggering is to be clarified) or we cou= ld >>>> define LMA/MAG specific L3 signalling (FMI/FMA). >>>> >>>> My 2 cents, >>>> Pierrick >>>> >>>>> -----Message d'origine----- >>>>> De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la= part >>>>> de Youn-Hee Han >>>>> Envoy=E9=A0: mardi 8 f=E9vrier 2011 12:00 >>>>> =C0=A0: 'Julien Laganier'; 'Rajeev Koodli' >>>>> Cc=A0: netext@ietf.org; Basavaraj.Patil@nokia.com >>>>> Objet=A0: Re: [netext] Consensus call to adopt I-D:draft-bernardos-ne= text- >>>>> pmipv6-flowmob as WG doc >>>>> >>>>> Hi Julien, >>>>> >>>>>> -----Original Message----- >>>>>> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Be= half >>>>>> Of Julien Laganier >>>>>> Sent: Tuesday, February 08, 2011 1:38 PM >>>>>> To: Rajeev Koodli >>>>>> Cc: netext@ietf.org; Basavaraj.Patil@nokia.com >>>>>> Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos- >>>>>> netext-pmipv6-flowmob as WG doc >>>>>> >>>>>> On Mon, Feb 7, 2011 at 6:15 PM, Rajeev Koodli wr= ote: >>>>>>> >>>>>>> If flow mobility has nothing do with prefix management, I am lost. >>>>>> >>>>>> No reason to be lost: Prefix management is how do I get prefix for t= he >>>>>> MN. Flow mobility is how to I move flows across interfaces. The two >>>>>> needs not to be intertwined together, as I've shown in my other note= s. >>>>>> E.g., I can do flow mobility without adding/deleting prefixes from >>>>>> sessions, and vice versa. >>>>> >>>>> Yes, I agree with you. Flow mobility is how to move flows across inte= rface. >>>>> So, I thought that it would be better to define "a flow" exactly in n= etext >>>>> WG prior to discuss flow mobility management. As the definition of "a >>>>> flow", >>>>> all I can think is a five-tuple plus something. If we assume that it = is >>>>> correct, I think that flow mobility and prefix addition are inevitabl= y >>>>> tied. >>>>> As you know, RFC5213 (and IPv6 protocol spec) already allow to assign >>>>> multiple prefixes across multiple interfaces of an MN. Yes, I also ag= ree >>>>> with you that in real-world (3GPP), there may be no need to assign >>>>> multiple >>>>> prefixes into an MN. (if somebody knows its necessity, please tell me= when >>>>> it should happen). So, flow mobility can be done without adding prefi= xes. >>>>> However, different interfaces are allowed to be assigned different >>>>> prefixes >>>>> by RFC 5213 and IPv6 spec. We can't expect what kind of prefixes an M= AG >>>>> advertises. Therefore, sometimes, we need prefix addition to move a f= low >>>>> to >>>>> a new interface of which MAG does not yet advertise the prefix of the= flow >>>>> being moved. >>>>> >>>>> (snip...) >>>>> >>>>>>>> I see no reason to depart from that in the context of extending th= e >>>>>>>> protocol to support mobility, nor I am aware of any system >>>>>>>> architecture that would require this capability. >>>>>>> >>>>>>> Okay, see your position. I see it differently. I don't need to be >>>>>>> bound by some "presumed implementation model" of PMIP6 and limit >>>>>>> myself *only* to a prefix assignment model you are imagining. >>>>>> >>>>>> It's not an implementation model, it is a protocol model, and it's n= ot >>>>>> imaginary. Implementation has nothing to do with this. >>>>>> >>>>>> There's no reason to extend prefix assignment model to do flow mobil= ity >>>>>> unless you can point me out in which real world context your scenari= o >>>>>> actually happens. >>>>> >>>>> As I insisted in the old mail, I agree with Julien in this regard. Cu= rrent >>>>> draft allows too much space regarding the prefix allocation model (un= ique, >>>>> shared, and hybrid). When a flow should be moved to a new interface a= nd >>>>> the >>>>> prefix which the flow uses is not yet advertised by the new MAG, just >>>>> inform >>>>> the prefix to the MAG and thus make it advertise the prefix and setup= the >>>>> tunnel based on the new prefix. That's all!. If the prefix is already >>>>> advertised by the MAG, there is nothing to do and just move the flow.= This >>>>> behaviors are very natural one when we want to support IP-level mobil= ity. >>>>> >>>>>>>> If this is something really important, the WG can be rechartered t= o >>>>>>>> work on a different extension that would allow adding/removing >>>>>>>> prefixes from existing PMIPv6 sessions. >>>>>>> >>>>>>> Huh.. What in the current charter forces us not to have the LMA >>>>>>> add/refresh/delete a prefix on-demand? >>>>>> >>>>>> Engineering is about finding a solution to a problem. Adding/deletin= g >>>>>> prefix on-demand is not a solution to flow mobility. I've shown you = how >>>>>> to do flow mobility without this capability. >>>>> >>>>> From the viewpoint of protocol, I think that at least, prefix additio= n to >>>>> an >>>>> interface is a necessary function to support flow mobility, as I expl= ained >>>>> above. But, it does not mean prefix addition should happen always whe= never >>>>> flow mobility occurs. It is sometimes needed. >>>>> >>>>>> Now a different engineering problem would be: how to add/delete pref= ixes >>>>>> to a PMIPv6 session, and that would be useful for e.g. >>>>>> renumbering. This is a different problem that we haven't been charte= red >>>>>> to work on. >>>>> >>>>> Prefix addition is just prefix addition. IMHO, renumbering is closer = to >>>>> prefix change. We just harness that function to support IP-level mobi= lity. >>>>> >>>>> Youn-Hee >>>>> >>>>> _______________________________________________ >>>>> netext mailing list >>>>> netext@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netext >>>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>> >> >> > > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 From gerardog@qualcomm.com Tue Feb 8 22:24:34 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A9193A68F7 for ; Tue, 8 Feb 2011 22:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.445 X-Spam-Level: X-Spam-Status: No, score=-104.445 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rd9DsCczEHVZ for ; Tue, 8 Feb 2011 22:24:29 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id B71183A685D for ; Tue, 8 Feb 2011 22:24:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1297232678; x=1328768678; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:content-transfer-encoding: mime-version; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20Tran=20Minh=20Trung=20,=20J ulien=20Laganier=0D=0A=09|CC:=20"n etext@ietf.org"=20,=20"Basavaraj.Patil@n okia.com"=0D=0A=09|Subject:=20 RE:=20[netext]=20Consensus=20call=20to=20adopt=0D=0A=20I- D:draft-bernardos-netext-pmipv6-flowmob=20as=20WG=20doc |Thread-Topic:=20[netext]=20Consensus=20call=20to=20adopt =0D=0A=20I-D:draft-bernardos-netext-pmipv6-flowmob=20as =20WG=20doc|Thread-Index:=20AQHLx94soydSZ0L5ekCHxlX1jM06m pP4/lqA//+1byA=3D|Date:=20Wed,=209=20Feb=202011=2006:24:3 7=20+0000|Message-ID:=20|References:=20 =0D=0A=09=0D=0A=09=0D=0A=09<015b01cbc77f$69f132e0$3dd398a0$@gmail.com> =0D=0A=09<843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdme l0.rd.francetelecom.fr>=0D=0A=09=0D=0A=20 |In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|x-originating-ip:=20[172.30.48.1] |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=owb6g+6DG2NZhjKorC924XoL/WOd3ErGCUqZxRPdkGE=; b=QpPrtynoadTct+2ILfLXcGEGPauGyHBAfBZ7Asu85fhM/7JfAoIfYTXL 7H/IXZmzClGfIDoPDQaeApsUBi8RFiBKOMMgkFzetMqtfVvyNIMAjncBh H7tD+PwZZkrhknDkj/FzdxVuBMlKBg9rHPWNbg6qHeGrWbBUc7mAj5CZN c=; X-IronPort-AV: E=McAfee;i="5400,1158,6251"; a="73729786" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 08 Feb 2011 22:24:37 -0800 X-IronPort-AV: E=Sophos;i="4.60,445,1291622400"; d="scan'208";a="49430953" Received: from nasanexhc09.na.qualcomm.com ([172.30.39.8]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 08 Feb 2011 22:24:37 -0800 Received: from NASANEXD01E.na.qualcomm.com ([fe80::6555:8c37:4ee3:efc4]) by nasanexhc09.na.qualcomm.com ([::1]) with mapi id 14.01.0270.001; Tue, 8 Feb 2011 22:24:37 -0800 From: "Giaretta, Gerardo" To: Tran Minh Trung , Julien Laganier Thread-Topic: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLx94soydSZ0L5ekCHxlX1jM06mpP4/lqA//+1byA= Date: Wed, 9 Feb 2011 06:24:37 +0000 Message-ID: References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.48.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 06:24:34 -0000 For my clarification: L2 trigger from MN is the first thing that is receive= d by the MAG when the MN attaches. This is for example when DHCP is perform= ed in WLAN, when the IPsec tunnel is established with ePDG or when the LTE = or eHRPD attach is completed. If that is the case, what is the reason to se= nd packets to a MAG before the L2 trigger is received, i.e. before the MN i= s actually connected to the MAG? Thanks Gerardo=20 > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > Behalf Of Tran Minh Trung > Sent: Tuesday, February 08, 2011 6:50 PM > To: Julien Laganier > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos- > netext-pmipv6-flowmob as WG doc >=20 > Hi Julien, >=20 > Let me show a real case for the scenario that we are discussing bellow: >=20 > The network policy is changed and the LMA decides to move flow 2 from > IF2 to IF1 before MAG1 received L2 trigger from the MN (say before > step #8) > In that case, the LMA should signal MAG1 to send PBU to attach IF1 to > session 2. >=20 > Without signaling from LMA how can you do in this case? Just wait > until receiving L2 trigger from the MN? >=20 > On Wed, Feb 9, 2011 at 7:18 AM, Julien Laganier > wrote: > > Hi Pierrick, > > > > I am going to intertwine the steps in your scenario below with the > > missing pieces of the big picture so that we are not doing an > academic > > exercise but focusing on the real world: > > > > 1. when the MN first attaches with if1 to a network, MAG1 requests > > attachment of if1 to a session1 by sending a PBU to LMA > > > > 2. because the MN add no session1 previously, the LMA creates session > > 1 and allocates a prefix for it. The prefix is sent back to MAG1 in > > the PBA: > > > > =A0=A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1-IF1] > > > > 3. then, if the MN attaches with if2 to another network, but does not > > request this interface be attached to a distinct session, MAG2 > > requests attachemnt of If2 to session1 by sending a PBU to LMA > > > > 4. Because the MN already has session 1, the LMA updates session1 > with > > if2, and send the pref1 back to MAG2 in the PBA: > > > > =A0=A0 =A0 =A0 =A0 Session1: [Pref1, MAG1-IF1, MAG2-IF2] > > > > 5. Creation of a new session 2 for if2 is requested by either of MN > > requests via L2 triggers, or a change in policy profile. As a result, > > MAG2 requests attachment of if2 to session2 by sending a PBU to LMA. > > > > 6. because the MN add no session2 previously, the LMA creates session > > 2 and allocates a prefix for it. The prefix pref2 is sent back to > MAG2 > > in the PBA: > > > > =A0=A0 =A0 =A0 =A0 =A0Session2: [Pref2, MAG2-IF2] > > > > 7. Flow2 starts over if2 with prefix2. > > > > 8. Attachment of if1 to session2 is requested by either of MN > requests > > via L2 triggers, or a change in policy profile. As a result, MAG1 > > requests attachment of if1 to session2 by sending a PBU to LMA. > > > > 9. Because the MN already has session 2, the LMA updates session2 > with if1: > > > > =A0=A0 =A0 =A0 =A0 Session2: [Pref2, MAG2-IF2, MAG1-IF1] > > > > 10. At any point, the LMA decides to move Flow2 between two > interfaces > > of session 2, and it does so. > > > > That's all that needed. It maps perfectly to 3GPP. If you have in > mind > > a different system in whcih that doesn't map, please let me know. > > > > --julien > > > > On Tue, Feb 8, 2011 at 8:25 AM, =A0 > wrote: > >> Hi, > >> > >> Going through this long thread :-), it seems we could agree on the > following (just a tentative to summarize): > >> > >> Sessions should be created/updated with all available interfaces. > Rewriting Tran's example: when the MN attaches to MAG1 via If1, the LMA > creates session 1: > >> > >> =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] > >> > >> Then, if the MN attaches to MAG2 via If2, the LMA creates session 2 > with both If1 and If2. The LMA also updates session 1 with If2: > >> > >> =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] > >> =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2, IF1] > >> > >> MAG2 receives prefixes 1 and 2 in PBA but MAG1 is not sending PBU. > So, if the LMA wants to move flow with Pref2 from if2 to If1, the LMA > needs to provide Pref2 to MAG1. Also, the LMA should be able to create > new sessions with already up interfaces, e.g. if1 and if2. To address > both issues, PBU from MAG1 could be triggered (triggering is to be > clarified) or we could define LMA/MAG specific L3 signalling (FMI/FMA). > >> > >> My 2 cents, > >> Pierrick > >> > >>> -----Message d'origine----- > >>> De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la > part > >>> de Youn-Hee Han > >>> Envoy=E9=A0: mardi 8 f=E9vrier 2011 12:00 > >>> =C0=A0: 'Julien Laganier'; 'Rajeev Koodli' > >>> Cc=A0: netext@ietf.org; Basavaraj.Patil@nokia.com > >>> Objet=A0: Re: [netext] Consensus call to adopt I-D:draft-bernardos- > netext- > >>> pmipv6-flowmob as WG doc > >>> > >>> Hi Julien, > >>> > >>> > -----Original Message----- > >>> > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > Behalf > >>> > Of Julien Laganier > >>> > Sent: Tuesday, February 08, 2011 1:38 PM > >>> > To: Rajeev Koodli > >>> > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > >>> > Subject: Re: [netext] Consensus call to adopt I-D: draft- > bernardos- > >>> > netext-pmipv6-flowmob as WG doc > >>> > > >>> > On Mon, Feb 7, 2011 at 6:15 PM, Rajeev Koodli > wrote: > >>> > > > >>> > > If flow mobility has nothing do with prefix management, I am > lost. > >>> > > >>> > No reason to be lost: Prefix management is how do I get prefix > for the > >>> > MN. Flow mobility is how to I move flows across interfaces. The > two > >>> > needs not to be intertwined together, as I've shown in my other > notes. > >>> > E.g., I can do flow mobility without adding/deleting prefixes > from > >>> > sessions, and vice versa. > >>> > >>> Yes, I agree with you. Flow mobility is how to move flows across > interface. > >>> So, I thought that it would be better to define "a flow" exactly in > netext > >>> WG prior to discuss flow mobility management. As the definition of > "a > >>> flow", > >>> all I can think is a five-tuple plus something. If we assume that > it is > >>> correct, I think that flow mobility and prefix addition are > inevitably > >>> tied. > >>> As you know, RFC5213 (and IPv6 protocol spec) already allow to > assign > >>> multiple prefixes across multiple interfaces of an MN. Yes, I also > agree > >>> with you that in real-world (3GPP), there may be no need to assign > >>> multiple > >>> prefixes into an MN. (if somebody knows its necessity, please tell > me when > >>> it should happen). So, flow mobility can be done without adding > prefixes. > >>> However, different interfaces are allowed to be assigned different > >>> prefixes > >>> by RFC 5213 and IPv6 spec. We can't expect what kind of prefixes an > MAG > >>> advertises. Therefore, sometimes, we need prefix addition to move a > flow > >>> to > >>> a new interface of which MAG does not yet advertise the prefix of > the flow > >>> being moved. > >>> > >>> (snip...) > >>> > >>> > >> I see no reason to depart from that in the context of > extending the > >>> > >> protocol to support mobility, nor I am aware of any system > >>> > >> architecture that would require this capability. > >>> > > > >>> > > Okay, see your position. I see it differently. I don't need to > be > >>> > > bound by some "presumed implementation model" of PMIP6 and > limit > >>> > > myself *only* to a prefix assignment model you are imagining. > >>> > > >>> > It's not an implementation model, it is a protocol model, and > it's not > >>> > imaginary. Implementation has nothing to do with this. > >>> > > >>> > There's no reason to extend prefix assignment model to do flow > mobility > >>> > unless you can point me out in which real world context your > scenario > >>> > actually happens. > >>> > >>> As I insisted in the old mail, I agree with Julien in this regard. > Current > >>> draft allows too much space regarding the prefix allocation model > (unique, > >>> shared, and hybrid). When a flow should be moved to a new interface > and > >>> the > >>> prefix which the flow uses is not yet advertised by the new MAG, > just > >>> inform > >>> the prefix to the MAG and thus make it advertise the prefix and > setup the > >>> tunnel based on the new prefix. That's all!. If the prefix is > already > >>> advertised by the MAG, there is nothing to do and just move the > flow. This > >>> behaviors are very natural one when we want to support IP-level > mobility. > >>> > >>> > >> If this is something really important, the WG can be > rechartered to > >>> > >> work on a different extension that would allow adding/removing > >>> > >> prefixes from existing PMIPv6 sessions. > >>> > > > >>> > > Huh.. What in the current charter forces us not to have the LMA > >>> > > add/refresh/delete a prefix on-demand? > >>> > > >>> > Engineering is about finding a solution to a problem. > Adding/deleting > >>> > prefix on-demand is not a solution to flow mobility. I've shown > you how > >>> > to do flow mobility without this capability. > >>> > >>> From the viewpoint of protocol, I think that at least, prefix > addition to > >>> an > >>> interface is a necessary function to support flow mobility, as I > explained > >>> above. But, it does not mean prefix addition should happen always > whenever > >>> flow mobility occurs. It is sometimes needed. > >>> > >>> > Now a different engineering problem would be: how to add/delete > prefixes > >>> > to a PMIPv6 session, and that would be useful for e.g. > >>> > renumbering. This is a different problem that we haven't been > chartered > >>> > to work on. > >>> > >>> Prefix addition is just prefix addition. IMHO, renumbering is > closer to > >>> prefix change. We just harness that function to support IP-level > mobility. > >>> > >>> Youn-Hee > >>> > >>> _______________________________________________ > >>> netext mailing list > >>> netext@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netext > >> > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > > >=20 >=20 >=20 > -- > Ph.D., Senior Member > Electronics and Telecommunications Research Institute > Standards Research Center > 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA > Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From gerardog@qualcomm.com Tue Feb 8 22:33:35 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BDD03A6905 for ; Tue, 8 Feb 2011 22:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.522 X-Spam-Level: X-Spam-Status: No, score=-105.522 tagged_above=-999 required=5 tests=[AWL=1.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ke9fFAdeI77A for ; Tue, 8 Feb 2011 22:33:33 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id BE4663A6900 for ; Tue, 8 Feb 2011 22:33:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1297233222; x=1328769222; h=from:to:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:content-transfer-encoding: mime-version; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20"netext@ietf.org"=20|Subject:=20M ultiple=20prefixes=20in=20draft-bernardos-netext-pmipv6-f lowmob=20|Thread-Topic:=20Multiple=20prefixes=20in=20draf t-bernardos-netext-pmipv6-flowmob=20|Thread-Index:=20AQHL yCNKzqr1zDYEa0SORquUrs56dQ=3D=3D|Date:=20Wed,=209=20Feb =202011=2006:33:41=20+0000|Message-ID:=20 |References:=20=0D=0A=09=0D=0A=09=0D=0A=09<015b01cbc77f$69f132e0$3d d398a0$@gmail.com>=0D=0A=09<843DA8228A1BA74CA31FB4E111A5C 462017D4533@ftrdmel0.rd.francetelecom.fr>=0D=0A=09 =0D=0A=20|In-Reply-To:=20|Accept-Language:=20en -US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|x-originating-ip:=20[172.30.48.1] |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=3GyLP5snLk8riLF4CiC/TSMsM5h5J19JJGnPSJbfNcs=; b=KylUPmHxb4brCMOXCaxmoMnHlgr+ykJmvNivjOk1GJEYny/oxt/hlNPp FOUHyekA2LXZY/5kt8VZglo6pO1TsmSDL5Kd6xL+yVjyG0DraS+P+dTTR q2DZr/TvNkg7fVq4F7DRMHh83a5OgXMgN/0sjGX2QH55xbf2uEZxiDXBy 0=; X-IronPort-AV: E=McAfee;i="5400,1158,6251"; a="73518929" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 08 Feb 2011 22:33:42 -0800 X-IronPort-AV: E=Sophos;i="4.60,445,1291622400"; d="scan'208";a="49432027" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 08 Feb 2011 22:33:42 -0800 Received: from NASANEXD01E.na.qualcomm.com ([fe80::6555:8c37:4ee3:efc4]) by nasanexhc04.na.qualcomm.com ([::1]) with mapi id 14.01.0270.001; Tue, 8 Feb 2011 22:33:42 -0800 From: "Giaretta, Gerardo" To: "netext@ietf.org" Thread-Topic: Multiple prefixes in draft-bernardos-netext-pmipv6-flowmob Thread-Index: AQHLyCNKzqr1zDYEa0SORquUrs56dQ== Date: Wed, 9 Feb 2011 06:33:41 +0000 Message-ID: References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.48.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [netext] Multiple prefixes in draft-bernardos-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 06:33:36 -0000 Hi all, I am starting a new thread to understand the use case this draft is trying = to solve when referring to multiple prefixes. I think there has been some d= iscussion already in the list but I did not get a good understanding of the= rationale.=20 My understanding is that the goal of the draft is to define a flow mobility= solution for PMIP. This implies that a given PMIP session is shared across= multiple interfaces and some IP flows belonging to that session are sent o= ver one interface and some others over another interface. This is equivalen= t to the RFC6089: IP flows which are tied to the same HoA/HNP can be sent o= ver one CoA/BID or another CoA/BID. Is this the correct understanding of the goals of the I-D? Is this a common= understanding of the term Flow Mobility? If this is the case, then I don't understand why the draft is introducing t= ext about the LMA creating a different session. Is this needed for Flow Mob= ility? If so, for which scenario? Going back to Pierrick's example: when the MN attaches to MAG1 via If1, the LMA creates session 1: Session1: [Pref1, MAG1, IF1] Then, if the MN attaches to MAG2 via If2, there is no reason for the LMA to= create session 2. The LMA just needs to update session 1 with If2:=20 Session1: [Pref1, MAG1, IF1, IF2] In this way MAG/LMA/MN can send over IF2 a TCP connection which earlier was= sent over IF1. This is Flow Mobility.=20 Thanks Gerardo=20 From gerardog@qualcomm.com Tue Feb 8 22:36:40 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFAA13A68BD for ; Tue, 8 Feb 2011 22:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.061 X-Spam-Level: X-Spam-Status: No, score=-106.061 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+RJRGx-8tuZ for ; Tue, 8 Feb 2011 22:36:37 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 2192C3A685D for ; Tue, 8 Feb 2011 22:36:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1297233406; x=1328769406; h=from:to:subject:thread-topic:thread-index:date: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:x-originating-ip: content-type:content-transfer-encoding:mime-version; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20"netext@ietf.org"=20|Subject:=20P olicy=20assumptions=20in=20draft-bernardos-netext-pmipv6- flowmob=20|Thread-Topic:=20Policy=20assumptions=20in=20dr aft-bernardos-netext-pmipv6-flowmob=20|Thread-Index:=20Ac vII7ftLVeZzcTEQJSGxQCfmqdG0g=3D=3D|Date:=20Wed,=209=20Feb =202011=2006:36:45=20+0000|Message-ID:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|x-originating-ip: =20[172.30.48.1]|Content-Type:=20text/plain=3B=20charset =3D"us-ascii"|Content-Transfer-Encoding:=20quoted-printab le|MIME-Version:=201.0; bh=sDz9QmVU2NV4VzXCLwRTufydUNGS9MW9Lcwt+/7TtJQ=; b=V5smawo2MJbLHwLbq+26qMl5zchrzDn6C/7ueSDiXsHiBDwdp8Y0wL0V HVPSjYeVG1zZK9i6UauYHzJEyMYt+e78YPlSk8XRq+5gQNLzsTD+fr84K 8S0GZUnnAc6M7FamlBYEQkl6PV4ZOFociWu7b3idURnPVMojy72nM5bno c=; X-IronPort-AV: E=McAfee;i="5400,1158,6251"; a="73730677" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 08 Feb 2011 22:36:45 -0800 X-IronPort-AV: E=Sophos;i="4.60,445,1291622400"; d="scan'208";a="28502743" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 08 Feb 2011 22:36:45 -0800 Received: from NASANEXD01E.na.qualcomm.com ([fe80::6555:8c37:4ee3:efc4]) by nasanexhc08.na.qualcomm.com ([::1]) with mapi id 14.01.0270.001; Tue, 8 Feb 2011 22:36:45 -0800 From: "Giaretta, Gerardo" To: "netext@ietf.org" Thread-Topic: Policy assumptions in draft-bernardos-netext-pmipv6-flowmob Thread-Index: AcvII7ftLVeZzcTEQJSGxQCfmqdG0g== Date: Wed, 9 Feb 2011 06:36:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.48.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [netext] Policy assumptions in draft-bernardos-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 06:36:41 -0000 I want to go back to the point raised by Stefano which was somehow lost in = the long thread. I need some clarifications on which is the assumption in terms of policies = in the draft. In particular: - Is it correct that there is an assumption that MN and LMA have the same p= olicies and behave accordingly?=20 - Does the MN need to have knowledge of the policy at all?=20 Thanks Gerardo=20 From trungtm2909@gmail.com Wed Feb 9 00:04:53 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DF523A692F for ; Wed, 9 Feb 2011 00:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffj-rX6en8tP for ; Wed, 9 Feb 2011 00:04:51 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 69BA83A692C for ; Wed, 9 Feb 2011 00:04:51 -0800 (PST) Received: by iym1 with SMTP id 1so6555739iym.31 for ; Wed, 09 Feb 2011 00:05:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1OeAvcYWAkJDlyLE5jEbMB+bZOEHGRKAfkSJ5/EBjS0=; b=Qh3grX2msCDad92D40DgJd//vFUUOW5lDQLqd3SbAJaUNwAldX/nyVjtVilOsYOC4/ tPg1IqAnLQLlStg2wm8pybT0GvLKIPZ1OIo5FgmUs/x7mXcNoGpeEJsI8cOiiug3wdZs lBQk1d5d8P17NGCejKPOG7CknTtIFyShZhuIk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=OGgt3UYRw3X9IC2R2buQDcePlRR8Bq0UYKRTpvc/ZqNgb9IbeevTEIxyTrlapv/B8P iqfDNY2Yxb0mGfmGfRkYosZ961FaU+pvweXXhyJ1ezkKkZK2h0kD3RcyOwD2lM7JkF7F KGzFWMl6/iT6HBb4PVP7Ynt+DiwB9yUxgewSM= MIME-Version: 1.0 Received: by 10.42.218.136 with SMTP id hq8mr21748246icb.379.1297238699803; Wed, 09 Feb 2011 00:04:59 -0800 (PST) Received: by 10.42.171.74 with HTTP; Wed, 9 Feb 2011 00:04:59 -0800 (PST) In-Reply-To: References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> Date: Wed, 9 Feb 2011 17:04:59 +0900 Message-ID: From: Tran Minh Trung To: "Giaretta, Gerardo" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Basavaraj.Patil@nokia.com" , "netext@ietf.org" Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 08:04:53 -0000 Hi Gerardo, On Wed, Feb 9, 2011 at 3:24 PM, Giaretta, Gerardo w= rote: > For my clarification: L2 trigger from MN is the first thing that is recei= ved by the MAG when the MN attaches. This is for example when DHCP is perfo= rmed in WLAN, when the IPsec tunnel is established with ePDG or when the LT= E or eHRPD attach is completed. If that is the case, what is the reason to = send packets to a MAG before the L2 trigger is received, i.e. before the MN= is actually connected to the MAG? In the discussed scenario, the network policy is changed when the MN is connecting to the MAG1 and MAG2 via IF1 and IF2 respectively. It is a real case, we should find a solution to support it. Now I can see two ways: (1) The network send message to request the MN to update with new policy. After that the MN sends trigger to MAG1 to attach IF1 to session 2. For example in 3GPP, ANDSF can send SMS to UE via S14 interface to request UE (MN) to update it policy. (Push model) (2) Network sends signal to MAG1 directly to request MAG1 to attach IF1 to session 2. I prefer the second solution since the first one can delay the flow mobility. Why we need to wait until the MN's profile is updated ?. The logical interface can help the MN to send packet to the same path that it receives packet from. Regards, TrungTM Regards, TrungTM > > Thanks > Gerardo > >> -----Original Message----- >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On >> Behalf Of Tran Minh Trung >> Sent: Tuesday, February 08, 2011 6:50 PM >> To: Julien Laganier >> Cc: netext@ietf.org; Basavaraj.Patil@nokia.com >> Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos- >> netext-pmipv6-flowmob as WG doc >> >> Hi Julien, >> >> Let me show a real case for the scenario that we are discussing bellow: >> >> The network policy is changed and the LMA decides to move flow 2 from >> IF2 to IF1 before MAG1 received L2 trigger from the MN (say before >> step #8) >> In that case, the LMA should signal MAG1 to send PBU to attach IF1 to >> session 2. >> >> Without signaling from LMA how can you do in this case? Just wait >> until receiving L2 trigger from the MN? >> >> On Wed, Feb 9, 2011 at 7:18 AM, Julien Laganier >> wrote: >> > Hi Pierrick, >> > >> > I am going to intertwine the steps in your scenario below with the >> > missing pieces of the big picture so that we are not doing an >> academic >> > exercise but focusing on the real world: >> > >> > 1. when the MN first attaches with if1 to a network, MAG1 requests >> > attachment of if1 to a session1 by sending a PBU to LMA >> > >> > 2. because the MN add no session1 previously, the LMA creates session >> > 1 and allocates a prefix for it. The prefix is sent back to MAG1 in >> > the PBA: >> > >> > =A0=A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1-IF1] >> > >> > 3. then, if the MN attaches with if2 to another network, but does not >> > request this interface be attached to a distinct session, MAG2 >> > requests attachemnt of If2 to session1 by sending a PBU to LMA >> > >> > 4. Because the MN already has session 1, the LMA updates session1 >> with >> > if2, and send the pref1 back to MAG2 in the PBA: >> > >> > =A0=A0 =A0 =A0 =A0 Session1: [Pref1, MAG1-IF1, MAG2-IF2] >> > >> > 5. Creation of a new session 2 for if2 is requested by either of MN >> > requests via L2 triggers, or a change in policy profile. As a result, >> > MAG2 requests attachment of if2 to session2 by sending a PBU to LMA. >> > >> > 6. because the MN add no session2 previously, the LMA creates session >> > 2 and allocates a prefix for it. The prefix pref2 is sent back to >> MAG2 >> > in the PBA: >> > >> > =A0=A0 =A0 =A0 =A0 =A0Session2: [Pref2, MAG2-IF2] >> > >> > 7. Flow2 starts over if2 with prefix2. >> > >> > 8. Attachment of if1 to session2 is requested by either of MN >> requests >> > via L2 triggers, or a change in policy profile. As a result, MAG1 >> > requests attachment of if1 to session2 by sending a PBU to LMA. >> > >> > 9. Because the MN already has session 2, the LMA updates session2 >> with if1: >> > >> > =A0=A0 =A0 =A0 =A0 Session2: [Pref2, MAG2-IF2, MAG1-IF1] >> > >> > 10. At any point, the LMA decides to move Flow2 between two >> interfaces >> > of session 2, and it does so. >> > >> > That's all that needed. It maps perfectly to 3GPP. If you have in >> mind >> > a different system in whcih that doesn't map, please let me know. >> > >> > --julien >> > >> > On Tue, Feb 8, 2011 at 8:25 AM, =A0 >> wrote: >> >> Hi, >> >> >> >> Going through this long thread :-), it seems we could agree on the >> following (just a tentative to summarize): >> >> >> >> Sessions should be created/updated with all available interfaces. >> Rewriting Tran's example: when the MN attaches to MAG1 via If1, the LMA >> creates session 1: >> >> >> >> =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] >> >> >> >> Then, if the MN attaches to MAG2 via If2, the LMA creates session 2 >> with both If1 and If2. The LMA also updates session 1 with If2: >> >> >> >> =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] >> >> =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2, IF1] >> >> >> >> MAG2 receives prefixes 1 and 2 in PBA but MAG1 is not sending PBU. >> So, if the LMA wants to move flow with Pref2 from if2 to If1, the LMA >> needs to provide Pref2 to MAG1. Also, the LMA should be able to create >> new sessions with already up interfaces, e.g. if1 and if2. To address >> both issues, PBU from MAG1 could be triggered (triggering is to be >> clarified) or we could define LMA/MAG specific L3 signalling (FMI/FMA). >> >> >> >> My 2 cents, >> >> Pierrick >> >> >> >>> -----Message d'origine----- >> >>> De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De l= a >> part >> >>> de Youn-Hee Han >> >>> Envoy=E9=A0: mardi 8 f=E9vrier 2011 12:00 >> >>> =C0=A0: 'Julien Laganier'; 'Rajeev Koodli' >> >>> Cc=A0: netext@ietf.org; Basavaraj.Patil@nokia.com >> >>> Objet=A0: Re: [netext] Consensus call to adopt I-D:draft-bernardos- >> netext- >> >>> pmipv6-flowmob as WG doc >> >>> >> >>> Hi Julien, >> >>> >> >>> > -----Original Message----- >> >>> > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On >> Behalf >> >>> > Of Julien Laganier >> >>> > Sent: Tuesday, February 08, 2011 1:38 PM >> >>> > To: Rajeev Koodli >> >>> > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com >> >>> > Subject: Re: [netext] Consensus call to adopt I-D: draft- >> bernardos- >> >>> > netext-pmipv6-flowmob as WG doc >> >>> > >> >>> > On Mon, Feb 7, 2011 at 6:15 PM, Rajeev Koodli >> wrote: >> >>> > > >> >>> > > If flow mobility has nothing do with prefix management, I am >> lost. >> >>> > >> >>> > No reason to be lost: Prefix management is how do I get prefix >> for the >> >>> > MN. Flow mobility is how to I move flows across interfaces. The >> two >> >>> > needs not to be intertwined together, as I've shown in my other >> notes. >> >>> > E.g., I can do flow mobility without adding/deleting prefixes >> from >> >>> > sessions, and vice versa. >> >>> >> >>> Yes, I agree with you. Flow mobility is how to move flows across >> interface. >> >>> So, I thought that it would be better to define "a flow" exactly in >> netext >> >>> WG prior to discuss flow mobility management. As the definition of >> "a >> >>> flow", >> >>> all I can think is a five-tuple plus something. If we assume that >> it is >> >>> correct, I think that flow mobility and prefix addition are >> inevitably >> >>> tied. >> >>> As you know, RFC5213 (and IPv6 protocol spec) already allow to >> assign >> >>> multiple prefixes across multiple interfaces of an MN. Yes, I also >> agree >> >>> with you that in real-world (3GPP), there may be no need to assign >> >>> multiple >> >>> prefixes into an MN. (if somebody knows its necessity, please tell >> me when >> >>> it should happen). So, flow mobility can be done without adding >> prefixes. >> >>> However, different interfaces are allowed to be assigned different >> >>> prefixes >> >>> by RFC 5213 and IPv6 spec. We can't expect what kind of prefixes an >> MAG >> >>> advertises. Therefore, sometimes, we need prefix addition to move a >> flow >> >>> to >> >>> a new interface of which MAG does not yet advertise the prefix of >> the flow >> >>> being moved. >> >>> >> >>> (snip...) >> >>> >> >>> > >> I see no reason to depart from that in the context of >> extending the >> >>> > >> protocol to support mobility, nor I am aware of any system >> >>> > >> architecture that would require this capability. >> >>> > > >> >>> > > Okay, see your position. I see it differently. I don't need to >> be >> >>> > > bound by some "presumed implementation model" of PMIP6 and >> limit >> >>> > > myself *only* to a prefix assignment model you are imagining. >> >>> > >> >>> > It's not an implementation model, it is a protocol model, and >> it's not >> >>> > imaginary. Implementation has nothing to do with this. >> >>> > >> >>> > There's no reason to extend prefix assignment model to do flow >> mobility >> >>> > unless you can point me out in which real world context your >> scenario >> >>> > actually happens. >> >>> >> >>> As I insisted in the old mail, I agree with Julien in this regard. >> Current >> >>> draft allows too much space regarding the prefix allocation model >> (unique, >> >>> shared, and hybrid). When a flow should be moved to a new interface >> and >> >>> the >> >>> prefix which the flow uses is not yet advertised by the new MAG, >> just >> >>> inform >> >>> the prefix to the MAG and thus make it advertise the prefix and >> setup the >> >>> tunnel based on the new prefix. That's all!. If the prefix is >> already >> >>> advertised by the MAG, there is nothing to do and just move the >> flow. This >> >>> behaviors are very natural one when we want to support IP-level >> mobility. >> >>> >> >>> > >> If this is something really important, the WG can be >> rechartered to >> >>> > >> work on a different extension that would allow adding/removing >> >>> > >> prefixes from existing PMIPv6 sessions. >> >>> > > >> >>> > > Huh.. What in the current charter forces us not to have the LMA >> >>> > > add/refresh/delete a prefix on-demand? >> >>> > >> >>> > Engineering is about finding a solution to a problem. >> Adding/deleting >> >>> > prefix on-demand is not a solution to flow mobility. I've shown >> you how >> >>> > to do flow mobility without this capability. >> >>> >> >>> From the viewpoint of protocol, I think that at least, prefix >> addition to >> >>> an >> >>> interface is a necessary function to support flow mobility, as I >> explained >> >>> above. But, it does not mean prefix addition should happen always >> whenever >> >>> flow mobility occurs. It is sometimes needed. >> >>> >> >>> > Now a different engineering problem would be: how to add/delete >> prefixes >> >>> > to a PMIPv6 session, and that would be useful for e.g. >> >>> > renumbering. This is a different problem that we haven't been >> chartered >> >>> > to work on. >> >>> >> >>> Prefix addition is just prefix addition. IMHO, renumbering is >> closer to >> >>> prefix change. We just harness that function to support IP-level >> mobility. >> >>> >> >>> Youn-Hee >> >>> >> >>> _______________________________________________ >> >>> 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 >> > >> >> >> >> -- >> Ph.D., Senior Member >> Electronics and Telecommunications Research Institute >> Standards Research Center >> 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA >> Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 From trungtm2909@gmail.com Wed Feb 9 00:31:11 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECA113A6885 for ; Wed, 9 Feb 2011 00:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.03 X-Spam-Level: X-Spam-Status: No, score=-3.03 tagged_above=-999 required=5 tests=[AWL=0.569, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mSCfXRr3mxm for ; Wed, 9 Feb 2011 00:31:10 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 100C83A6943 for ; Wed, 9 Feb 2011 00:31:10 -0800 (PST) Received: by iym1 with SMTP id 1so6575770iym.31 for ; Wed, 09 Feb 2011 00:31:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=k5MAKCKAY0JIQxd2uu8jifhIZvnunHSWQEPAX25V+t4=; b=Z+fLOnhjHdgRVasGjFPprgr2gqyHqHt4D/8pJsqFe0kZCbl06Kj9qysAHiceWkX2Rn DDAitCLxvI/z+C/b+asAg7JWn91bdrgntQQ55TueXyLoeyl41AltYT7Wd4pxJ7uyFmmM FHZ9Nhdys71L7cfq1T/6LqsKF9uTUZNkIhYJ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=iE2Q9bHZUHgiYMrRDReL31TQTsR7nY2sEj7aTHQJ93grNXSAUWHv3aSRxCDDbfS2J8 1szMpw6yrV+3vZQPodV7pnpc8Bm77Snpn+sk/5/P1Xq1ngITQhspu1r6tMm/gCKinOpz qMM+ulnLJdDjYVsJho1m+TkS1JB0KyJmaPHac= MIME-Version: 1.0 Received: by 10.42.220.8 with SMTP id hw8mr7693960icb.111.1297240275930; Wed, 09 Feb 2011 00:31:15 -0800 (PST) Received: by 10.42.171.74 with HTTP; Wed, 9 Feb 2011 00:31:15 -0800 (PST) In-Reply-To: References: Date: Wed, 9 Feb 2011 17:31:15 +0900 Message-ID: From: Tran Minh Trung To: "Giaretta, Gerardo" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "netext@ietf.org" Subject: Re: [netext] Policy assumptions in draft-bernardos-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 08:31:11 -0000 On Wed, Feb 9, 2011 at 3:36 PM, Giaretta, Gerardo w= rote: > I want to go back to the point raised by Stefano which was somehow lost i= n the long thread. > > I need some clarifications on which is the assumption in terms of policie= s in the draft. In particular: > > - Is it correct that there is an assumption that MN and LMA have the same= policies and behave accordingly? > Yes, they should have the same policies. > - Does the MN need to have knowledge of the policy at all? > Yes, it needs to have knowledge of the policy. It is necessary for the MN to send the packet of a NEW flow (not ongoing flow) to the right interface. Regards, TrungTM > Thanks > Gerardo > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 From trungtm2909@gmail.com Wed Feb 9 00:45:40 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC17F3A694E for ; Wed, 9 Feb 2011 00:45:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.082 X-Spam-Level: X-Spam-Status: No, score=-3.082 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvMGQBj9AKCl for ; Wed, 9 Feb 2011 00:45:40 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 1FC903A694A for ; Wed, 9 Feb 2011 00:45:39 -0800 (PST) Received: by iym1 with SMTP id 1so6586662iym.31 for ; Wed, 09 Feb 2011 00:45:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=T3huhfiPnW4WGJULbLLWhy/Roexxw6oYi/4Dt/6uU7Y=; b=q7TUxQkFV1MJQICx8HO/JGSvozj0jE3L1h6mYGQFoB6ENQzBF/DroAaiI1qp/FoYPP UIsq92F7DmxU+qjVwSKaOchBgk6MGBsZ2reaUcb8pOwk3jwxH1E2e1VPKFiTmiKoKDId LGVZAeXQlZSjkDiieIRRRg/AXfS18OZUtio9Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WtW0aXKTnfm2KAkjDbHZKMQJ5ADeUY4EFqPj3yCNr0hf/Q4RXVA+/k8eIDCljDv5ag RZ2B3jFD/NUcPw3WqHorfImFDKWrwlFglJKQ66OyKNr5zecyIB6u2kE42WVcQadqFjeI mkmfTOwRa/ZthzO+e5fbPe+MD77wGADGfX/so= MIME-Version: 1.0 Received: by 10.42.173.194 with SMTP id s2mr5843524icz.312.1297241147912; Wed, 09 Feb 2011 00:45:47 -0800 (PST) Received: by 10.42.171.74 with HTTP; Wed, 9 Feb 2011 00:45:47 -0800 (PST) In-Reply-To: References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> Date: Wed, 9 Feb 2011 17:45:47 +0900 Message-ID: From: Tran Minh Trung To: "Giaretta, Gerardo" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "netext@ietf.org" Subject: Re: [netext] Multiple prefixes in draft-bernardos-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 08:45:41 -0000 On Wed, Feb 9, 2011 at 3:33 PM, Giaretta, Gerardo w= rote: > Hi all, > > I am starting a new thread to understand the use case this draft is tryin= g to solve when referring to multiple prefixes. I think there has been some= discussion already in the list but I did not get a good understanding of t= he rationale. > > My understanding is that the goal of the draft is to define a flow mobili= ty solution for PMIP. This implies that a given PMIP session is shared acro= ss multiple interfaces and some IP flows belonging to that session are sent= over one interface and some others over another interface. This is equival= ent to the RFC6089: IP flows which are tied to the same HoA/HNP can be sent= over one CoA/BID or another CoA/BID. > > Is this the correct understanding of the goals of the I-D? Is this a comm= on understanding of the term Flow Mobility? > Yes you are right. > If this is the case, then I don't understand why the draft is introducing= text about the LMA creating a different session. Is this needed for Flow M= obility? If so, for which scenario? > > Going back to Pierrick's example: > > when the MN attaches to MAG1 via If1, the LMA creates session 1: > > =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] > > Then, if the MN attaches to MAG2 via If2, there is no reason for the LMA = to create session 2. The LMA just needs to update session 1 with If2: > We just follow the basic operation of the RFC5213 that a new prefix will be assigned to new attachment. Then we extend it to support flow mobility by allowing interfaces to be attached to multiple sessions. > =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] > > In this way MAG/LMA/MN can send over IF2 a TCP connection which earlier w= as sent over IF1. This is Flow Mobility. > It only works for the flows in the session1. However session 2,3..n can be created at anytime in the future. We have to attach all working interfaces in the set to a new session whenever it is created. Regards, TrungTM > Thanks > Gerardo > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 From pierrick.seite@orange-ftgroup.com Wed Feb 9 00:56:03 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B02EB3A6949 for ; Wed, 9 Feb 2011 00:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.601, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkp7au5WbRKQ for ; Wed, 9 Feb 2011 00:56:02 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 9E2503A691E for ; Wed, 9 Feb 2011 00:56:02 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C9AE3760005; Wed, 9 Feb 2011 10:01:18 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id AB95B760004; Wed, 9 Feb 2011 10:01:18 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Feb 2011 09:56:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Feb 2011 09:56:09 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462017D4645@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Policy assumptions in draft-bernardos-netext-pmipv6-flowmob Thread-Index: AcvII7ftLVeZzcTEQJSGxQCfmqdG0gAEJcHw References: From: To: , X-OriginalArrivalTime: 09 Feb 2011 08:56:10.0887 (UTC) FILETIME=[32A8C970:01CBC837] Subject: Re: [netext] Policy assumptions in draft-bernardos-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 08:56:03 -0000 I think a pragmatic and basic behaviour could be defined in a first = round. I'd suggest the following: The LMA enforces its decision to the = MN, which is just expected to mirror LMA routing decision, i.e. the MN = sends a packet on the same interface it receives the packet. However, = The MN needs to have a default policy to select the interface when = initiating a flow. If the MN's policy does not match the LMA policy, the = LMA trigger flow handover and the MN follows that decision. Obviously, more sophisticated policies models could be defined. But, = even if not optimal, this model is quite simple and does not require to = synchronize policies. BR, Pierrick > -----Message d'origine----- > De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la = part > de Giaretta, Gerardo > Envoy=E9=A0: mercredi 9 f=E9vrier 2011 07:37 > =C0=A0: netext@ietf.org > Objet=A0: [netext] Policy assumptions in = draft-bernardos-netext-pmipv6- > flowmob >=20 > I want to go back to the point raised by Stefano which was somehow = lost in > the long thread. >=20 > I need some clarifications on which is the assumption in terms of = policies > in the draft. In particular: >=20 > - Is it correct that there is an assumption that MN and LMA have the = same > policies and behave accordingly? >=20 > - Does the MN need to have knowledge of the policy at all? >=20 > Thanks > Gerardo > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From trungtm2909@gmail.com Wed Feb 9 01:01:57 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4452E3A6964 for ; Wed, 9 Feb 2011 01:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.125 X-Spam-Level: X-Spam-Status: No, score=-3.125 tagged_above=-999 required=5 tests=[AWL=0.474, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuYjLN+hetEq for ; Wed, 9 Feb 2011 01:01:56 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 54FDC3A695E for ; Wed, 9 Feb 2011 01:01:56 -0800 (PST) Received: by iym1 with SMTP id 1so6598970iym.31 for ; Wed, 09 Feb 2011 01:02:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IWow/wUIOGtrn4obobDqIov9lasRJe1DgcHqyuIx53U=; b=tphYtLER89CPDQ9mg8h6Q3BvyD1XQF3I1Kp8rE47oBQg613XvZ0JfNuznnAK+0zd1z sXGNiGlxjLwFETvULIGY8LNb45U/uCvQdtdVkd/HQWK3FsZpRIW1fsQq+e0sEy/n5sBU HP6YnUe9UKGNd4pWPFiPBt4GOTS8z4ioCyyg4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=kfMbiNvo6FlLi74F3ZF86MUVSMkLDAwhvTHt0aoW57IJOatoi5k9qrcrUV/iYEfbf4 onKo0k1oFrDzdvMQzYf4y1nWiBA032px/2+aDLfgQbMIrk1SLv5DzAnIzoH69Xn3EgCq mKslj6+yImycfBTYbkkEcNAhxCSwvDY3WjTQg= MIME-Version: 1.0 Received: by 10.42.177.137 with SMTP id bi9mr21912956icb.245.1297242123944; Wed, 09 Feb 2011 01:02:03 -0800 (PST) Received: by 10.42.171.74 with HTTP; Wed, 9 Feb 2011 01:02:03 -0800 (PST) In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462017D4645@ftrdmel0.rd.francetelecom.fr> References: <843DA8228A1BA74CA31FB4E111A5C462017D4645@ftrdmel0.rd.francetelecom.fr> Date: Wed, 9 Feb 2011 18:02:03 +0900 Message-ID: From: Tran Minh Trung To: pierrick.seite@orange-ftgroup.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Policy assumptions in draft-bernardos-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 09:01:57 -0000 Hi Pierrick, On Wed, Feb 9, 2011 at 5:56 PM, wrote: > > I think a pragmatic and basic behaviour could be defined in a first round= . I'd suggest the following: The LMA enforces its decision to the MN, which= is just expected to mirror LMA routing decision, i.e. the MN sends a packe= t on the same interface it receives the packet. However, The MN needs to ha= ve a default policy to select the interface when initiating a flow. If the = MN's policy does not match the LMA policy, the LMA trigger flow handover an= d the MN follows that decision. > It is exactly what we have in the logical interface I-D as well as Bernardos' I-D. Regards, TrungTM > Obviously, more sophisticated policies models could be defined. But, even= if not optimal, this model is quite simple and does not require to synchro= nize policies. > > BR, > Pierrick > >> -----Message d'origine----- >> De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la pa= rt >> de Giaretta, Gerardo >> Envoy=E9=A0: mercredi 9 f=E9vrier 2011 07:37 >> =C0=A0: netext@ietf.org >> Objet=A0: [netext] Policy assumptions in draft-bernardos-netext-pmipv6- >> flowmob >> >> I want to go back to the point raised by Stefano which was somehow lost = in >> the long thread. >> >> I need some clarifications on which is the assumption in terms of polici= es >> in the draft. In particular: >> >> - Is it correct that there is an assumption that MN and LMA have the sam= e >> policies and behave accordingly? >> >> - Does the MN need to have knowledge of the policy at all? >> >> Thanks >> Gerardo >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 From pierrick.seite@orange-ftgroup.com Wed Feb 9 01:05:10 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89DEC3A6949 for ; Wed, 9 Feb 2011 01:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJA3+OLb1He4 for ; Wed, 9 Feb 2011 01:05:09 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 5BA2D3A6957 for ; Wed, 9 Feb 2011 01:05:09 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BB177760005; Wed, 9 Feb 2011 10:10:25 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id B2ABE760003; Wed, 9 Feb 2011 10:10:25 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Feb 2011 10:05:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Feb 2011 10:05:16 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462017D4653@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Multiple prefixes indraft-bernardos-netext-pmipv6-flowmob Thread-Index: AcvINcNp9i1KEpIyQEeNlwuU8hpyeQAAYafg References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com><843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> From: To: , X-OriginalArrivalTime: 09 Feb 2011 09:05:18.0351 (UTC) FILETIME=[78F929F0:01CBC838] Cc: netext@ietf.org Subject: Re: [netext] Multiple prefixes indraft-bernardos-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 09:05:10 -0000 > -----Message d'origine----- > De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la = part > de Tran Minh Trung > Envoy=E9=A0: mercredi 9 f=E9vrier 2011 09:46 > =C0=A0: Giaretta, Gerardo > Cc=A0: netext@ietf.org > Objet=A0: Re: [netext] Multiple prefixes = indraft-bernardos-netext-pmipv6- > flowmob >=20 > On Wed, Feb 9, 2011 at 3:33 PM, Giaretta, Gerardo = > wrote: > > Hi all, > > > > I am starting a new thread to understand the use case this draft is > trying to solve when referring to multiple prefixes. I think there has > been some discussion already in the list but I did not get a good > understanding of the rationale. > > > > My understanding is that the goal of the draft is to define a flow > mobility solution for PMIP. This implies that a given PMIP session is > shared across multiple interfaces and some IP flows belonging to that > session are sent over one interface and some others over another = interface. > This is equivalent to the RFC6089: IP flows which are tied to the same > HoA/HNP can be sent over one CoA/BID or another CoA/BID. > > > > Is this the correct understanding of the goals of the I-D? Is this a > common understanding of the term Flow Mobility? > > >=20 > Yes you are right. >=20 > > If this is the case, then I don't understand why the draft is > introducing text about the LMA creating a different session. Is this > needed for Flow Mobility? If so, for which scenario? > > > > Going back to Pierrick's example: > > > > when the MN attaches to MAG1 via If1, the LMA creates session 1: > > > > =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] > > > > Then, if the MN attaches to MAG2 via If2, there is no reason for the = LMA > to create session 2. The LMA just needs to update session 1 with If2: > > >=20 > We just follow the basic operation of the RFC5213 that a new prefix > will be assigned to new attachment. >=20 > Then we extend it to support flow mobility by allowing interfaces to > be attached to multiple sessions. >=20 > > =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] > > > > In this way MAG/LMA/MN can send over IF2 a TCP connection which = earlier > was sent over IF1. This is Flow Mobility. > > >=20 > It only works for the flows in the session1. However session 2,3..n > can be created at anytime in the future. We have to attach all working > interfaces in the set to a new session whenever it is created. >=20 IMU, the current draft allows different sessions with same prefix, e.g: Session1: [Pref1, MAG1, IF1, IF2] Session2: [Pref1, MAG2, IF1, IF2] Right? > Regards, > TrungTM >=20 > > Thanks > > Gerardo > > > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > > >=20 >=20 >=20 > -- > Ph.D., Senior Member > Electronics and Telecommunications Research Institute > Standards Research Center > 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA > Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From yh21.han@gmail.com Wed Feb 9 03:19:41 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1441E3A69A0 for ; Wed, 9 Feb 2011 03:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2X0jIqUxD0n for ; Wed, 9 Feb 2011 03:19:40 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 934DF3A699F for ; Wed, 9 Feb 2011 03:19:39 -0800 (PST) Received: by wyf23 with SMTP id 23so50187wyf.31 for ; Wed, 09 Feb 2011 03:19:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=lrCmDqhBAYM8XJ6WtG3qq/EaSERD+7PQgiR0ia7zebM=; b=O4cgg4l8QCzUREamZEaKWU6ZF25oSCbOEZKPoXWgObbUpNnyGEL+kDmPJGMirl35c+ UaDrp3r3NYyqUzFIjnb3iqiRJ1KWcrDVFKnOJLINxDemjpmR9LV5W6dZCQlqiWTseZWI AfrmFF7VrGoyXLIpE7nrYx0eB2jjGhNcdG8+8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=eQAyEccf5ryNbtALuVeXrVfyzbgh73UEY4JnTib/gVm9BEcph5VwXFS2WR79O8OdfM p9jeiP22QPOn2GlFBD4AqoqXMWrBRPzcUr+0MBglI0Xl6SOya4SAjNteWP5GmcPlCUVY lcKo+XyWxLtjHBfkykbPPJcVizNjPEwWa+CCI= Received: by 10.227.143.5 with SMTP id s5mr10671598wbu.82.1297250387998; Wed, 09 Feb 2011 03:19:47 -0800 (PST) Received: from USERPC ([220.68.82.28]) by mx.google.com with ESMTPS id 7sm118281wet.0.2011.02.09.03.19.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 03:19:46 -0800 (PST) From: "Youn-Hee Han" To: , , References: <843DA8228A1BA74CA31FB4E111A5C462017D4645@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462017D4645@ftrdmel0.rd.francetelecom.fr> Date: Wed, 9 Feb 2011 20:19:40 +0900 Message-ID: <028f01cbc84b$42e13930$c8a3ab90$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGdzsrCLKJ5OkovNM5bpZXR/mHIagJx5Kj1lEFoivA= Content-Language: ko Subject: Re: [netext] Policy assumptions in draft-bernardos-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 11:19:41 -0000 Hi all, > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf > Of pierrick.seite@orange-ftgroup.com > Sent: Wednesday, February 09, 2011 5:56 PM > To: gerardog@qualcomm.com; netext@ietf.org > Subject: Re: [netext] Policy assumptions in draft-bernardos-netext- > pmipv6-flowmob > > > I think a pragmatic and basic behaviour could be defined in a first > round. I'd suggest the following: The LMA enforces its decision to the > MN, which is just expected to mirror LMA routing decision, i.e. the MN > sends a packet on the same interface it receives the packet. However, > The MN needs to have a default policy to select the interface when > initiating a flow. If the MN's policy does not match the LMA policy, the > LMA trigger flow handover and the MN follows that decision. I second this statement. > Obviously, more sophisticated policies models could be defined. I also agree it. Additionally, we need to discuss what component can manage the network-side policy. MAG, LMA, or Both? Youn-Hee From pierrick.seite@orange-ftgroup.com Wed Feb 9 04:29:49 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA8EB3A69AB for ; Wed, 9 Feb 2011 04:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZ6NuapFXIdY for ; Wed, 9 Feb 2011 04:29:47 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 227433A6984 for ; Wed, 9 Feb 2011 04:29:47 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 76FA2FC4007; Wed, 9 Feb 2011 13:29:59 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 6801BFC4006; Wed, 9 Feb 2011 13:29:59 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Feb 2011 13:29:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Feb 2011 13:29:53 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462017D475F@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvH3ihC4tZ+OMtoQiSf9CXLGDbFIgAdHYgA References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com><843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> From: To: X-OriginalArrivalTime: 09 Feb 2011 12:29:54.0439 (UTC) FILETIME=[0E178970:01CBC855] Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 12:29:49 -0000 Hi, My only concern is on step 8, Please see inline. Pierrick > -----Message d'origine----- > De=A0: Julien Laganier [mailto:julien.ietf@gmail.com] > Envoy=E9=A0: mardi 8 f=E9vrier 2011 23:19 > =C0=A0: SEITE Pierrick RD-RESA-REN > Cc=A0: yh21.han@gmail.com; rkoodli@cisco.com; netext@ietf.org; > Basavaraj.Patil@nokia.com > Objet=A0: Re: [netext] Consensus call to adopt = I-D:draft-bernardos-netext- > pmipv6-flowmob as WG doc >=20 > Hi Pierrick, >=20 > I am going to intertwine the steps in your scenario below with the > missing pieces of the big picture so that we are not doing an academic > exercise but focusing on the real world: >=20 > 1. when the MN first attaches with if1 to a network, MAG1 requests > attachment of if1 to a session1 by sending a PBU to LMA >=20 > 2. because the MN add no session1 previously, the LMA creates session > 1 and allocates a prefix for it. The prefix is sent back to MAG1 in > the PBA: >=20 > =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1-IF1] >=20 > 3. then, if the MN attaches with if2 to another network, but does not > request this interface be attached to a distinct session, MAG2 > requests attachemnt of If2 to session1 by sending a PBU to LMA >=20 > 4. Because the MN already has session 1, the LMA updates session1 with > if2, and send the pref1 back to MAG2 in the PBA: >=20 > =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1-IF1, MAG2-IF2] >=20 > 5. Creation of a new session 2 for if2 is requested by either of MN > requests via L2 triggers, or a change in policy profile. As a result, > MAG2 requests attachment of if2 to session2 by sending a PBU to LMA. >=20 > 6. because the MN add no session2 previously, the LMA creates session > 2 and allocates a prefix for it. The prefix pref2 is sent back to MAG2 > in the PBA: >=20 > =A0 =A0 =A0 =A0 =A0Session2: [Pref2, MAG2-IF2] >=20 > 7. Flow2 starts over if2 with prefix2. >=20 > 8. Attachment of if1 to session2 is requested by either of MN requests > via L2 triggers, or a change in policy profile. As a result, MAG1 > requests attachment of if1 to session2 by sending a PBU to LMA. >=20 But the MN is already attached to MAG1 via If1. So, without being too = 3GPP specific, what kind of L2 triggers can be used? To be more generic, I think that, for this case (attach a working = interface to a new session), we could have LMA/MAG signalling, maybe as = an option? The use-case I have in mind is a short-term deployment of = PMIP IP flow mobility over WiFi and 3GPP networks. Because, it is a = short term deployment, I have to use legacy 3G network (i.e. without LTE = or inter-systems mobility mechanisms); so the 3G network must be = agnostic of PMIP support and I can't rely on L2 to trigger PMIP. > 9. Because the MN already has session 2, the LMA updates session2 with > if1: >=20 > =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2-IF2, MAG1-IF1] >=20 > 10. At any point, the LMA decides to move Flow2 between two interfaces > of session 2, and it does so. >=20 > That's all that needed. It maps perfectly to 3GPP. If you have in mind > a different system in whcih that doesn't map, please let me know. >=20 > --julien >=20 > On Tue, Feb 8, 2011 at 8:25 AM, > wrote: > > Hi, > > > > Going through this long thread :-), it seems we could agree on the > following (just a tentative to summarize): > > > > Sessions should be created/updated with all available interfaces. > Rewriting Tran's example: when the MN attaches to MAG1 via If1, the = LMA > creates session 1: > > > > =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] > > > > Then, if the MN attaches to MAG2 via If2, the LMA creates session 2 = with > both If1 and If2. The LMA also updates session 1 with If2: > > > > =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] > > =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2, IF1] > > > > MAG2 receives prefixes 1 and 2 in PBA but MAG1 is not sending PBU. = So, > if the LMA wants to move flow with Pref2 from if2 to If1, the LMA = needs to > provide Pref2 to MAG1. Also, the LMA should be able to create new = sessions > with already up interfaces, e.g. if1 and if2. To address both issues, = PBU > from MAG1 could be triggered (triggering is to be clarified) or we = could > define LMA/MAG specific L3 signalling (FMI/FMA). > > > > My 2 cents, > > Pierrick > > > >> -----Message d'origine----- > >> De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De = la > part > >> de Youn-Hee Han > >> Envoy=E9=A0: mardi 8 f=E9vrier 2011 12:00 > >> =C0=A0: 'Julien Laganier'; 'Rajeev Koodli' > >> Cc=A0: netext@ietf.org; Basavaraj.Patil@nokia.com > >> Objet=A0: Re: [netext] Consensus call to adopt I-D:draft-bernardos- > netext- > >> pmipv6-flowmob as WG doc > >> > >> Hi Julien, > >> > >> > -----Original Message----- > >> > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > Behalf > >> > Of Julien Laganier > >> > Sent: Tuesday, February 08, 2011 1:38 PM > >> > To: Rajeev Koodli > >> > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > >> > Subject: Re: [netext] Consensus call to adopt I-D: = draft-bernardos- > >> > netext-pmipv6-flowmob as WG doc > >> > > >> > On Mon, Feb 7, 2011 at 6:15 PM, Rajeev Koodli > wrote: > >> > > > >> > > If flow mobility has nothing do with prefix management, I am = lost. > >> > > >> > No reason to be lost: Prefix management is how do I get prefix = for > the > >> > MN. Flow mobility is how to I move flows across interfaces. The = two > >> > needs not to be intertwined together, as I've shown in my other = notes. > >> > E.g., I can do flow mobility without adding/deleting prefixes = from > >> > sessions, and vice versa. > >> > >> Yes, I agree with you. Flow mobility is how to move flows across > interface. > >> So, I thought that it would be better to define "a flow" exactly in > netext > >> WG prior to discuss flow mobility management. As the definition of = "a > >> flow", > >> all I can think is a five-tuple plus something. If we assume that = it is > >> correct, I think that flow mobility and prefix addition are = inevitably > >> tied. > >> As you know, RFC5213 (and IPv6 protocol spec) already allow to = assign > >> multiple prefixes across multiple interfaces of an MN. Yes, I also > agree > >> with you that in real-world (3GPP), there may be no need to assign > >> multiple > >> prefixes into an MN. (if somebody knows its necessity, please tell = me > when > >> it should happen). So, flow mobility can be done without adding > prefixes. > >> However, different interfaces are allowed to be assigned different > >> prefixes > >> by RFC 5213 and IPv6 spec. We can't expect what kind of prefixes an = MAG > >> advertises. Therefore, sometimes, we need prefix addition to move a > flow > >> to > >> a new interface of which MAG does not yet advertise the prefix of = the > flow > >> being moved. > >> > >> (snip...) > >> > >> > >> I see no reason to depart from that in the context of = extending > the > >> > >> protocol to support mobility, nor I am aware of any system > >> > >> architecture that would require this capability. > >> > > > >> > > Okay, see your position. I see it differently. I don't need to = be > >> > > bound by some "presumed implementation model" of PMIP6 and = limit > >> > > myself *only* to a prefix assignment model you are imagining. > >> > > >> > It's not an implementation model, it is a protocol model, and = it's > not > >> > imaginary. Implementation has nothing to do with this. > >> > > >> > There's no reason to extend prefix assignment model to do flow > mobility > >> > unless you can point me out in which real world context your = scenario > >> > actually happens. > >> > >> As I insisted in the old mail, I agree with Julien in this regard. > Current > >> draft allows too much space regarding the prefix allocation model > (unique, > >> shared, and hybrid). When a flow should be moved to a new interface = and > >> the > >> prefix which the flow uses is not yet advertised by the new MAG, = just > >> inform > >> the prefix to the MAG and thus make it advertise the prefix and = setup > the > >> tunnel based on the new prefix. That's all!. If the prefix is = already > >> advertised by the MAG, there is nothing to do and just move the = flow. > This > >> behaviors are very natural one when we want to support IP-level > mobility. > >> > >> > >> If this is something really important, the WG can be = rechartered > to > >> > >> work on a different extension that would allow adding/removing > >> > >> prefixes from existing PMIPv6 sessions. > >> > > > >> > > Huh.. What in the current charter forces us not to have the LMA > >> > > add/refresh/delete a prefix on-demand? > >> > > >> > Engineering is about finding a solution to a problem. = Adding/deleting > >> > prefix on-demand is not a solution to flow mobility. I've shown = you > how > >> > to do flow mobility without this capability. > >> > >> From the viewpoint of protocol, I think that at least, prefix = addition > to > >> an > >> interface is a necessary function to support flow mobility, as I > explained > >> above. But, it does not mean prefix addition should happen always > whenever > >> flow mobility occurs. It is sometimes needed. > >> > >> > Now a different engineering problem would be: how to add/delete > prefixes > >> > to a PMIPv6 session, and that would be useful for e.g. > >> > renumbering. This is a different problem that we haven't been > chartered > >> > to work on. > >> > >> Prefix addition is just prefix addition. IMHO, renumbering is = closer to > >> prefix change. We just harness that function to support IP-level > mobility. > >> > >> Youn-Hee > >> > >> _______________________________________________ > >> netext mailing list > >> netext@ietf.org > >> https://www.ietf.org/mailman/listinfo/netext > > From telemaco.melia@alcatel-lucent.com Wed Feb 9 07:17:39 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BD703A676A for ; Wed, 9 Feb 2011 07:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4dP3UbQUJLm for ; Wed, 9 Feb 2011 07:17:38 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 338EB3A657C for ; Wed, 9 Feb 2011 07:17:38 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p19FHKqD028691 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 Feb 2011 16:17:43 +0100 Received: from FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com ([135.120.45.54]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 9 Feb 2011 16:17:43 +0100 From: "MELIA, TELEMACO (TELEMACO)" To: Julien Laganier , "cjbc@it.uc3m.es" Date: Wed, 9 Feb 2011 16:17:41 +0100 Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvH/9iYZNnTrkfGQpe1zCcxxH88sQAapUvg Message-ID: <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6D1F7@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> References: <1296920514.3773.26.camel@acorde.it.uc3m.es> <1297017501.4715.2.camel@acorde.it.uc3m.es> <1297019696.4715.5.camel@acorde.it.uc3m.es> <1297115574.3099.3.camel@acorde.it.uc3m.es> <1297126584.3099.96.camel@acorde.it.uc3m.es> <1297129998.3099.140.camel@acorde.it.uc3m.es> <1297208236.5169.80.camel@acorde.it.uc3m.es> <1297217553.5169.88.camel@acorde.it.uc3m.es> In-Reply-To: Accept-Language: en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 15:17:39 -0000 But why we cannot design a model where we can dynamically group sessions? Mobile operators have been fighting hard in the past years the disconnectio= n between ARPU and associated cost per users (in other words costs increase= but revenues continue to fall). Data explosion is one of the reasons for s= uch disconnection. I believe that network operators would be eager to learn about innovating t= echnologies to reduce costs expenditures. The work we are pushing with this= ID falls exactly in this category. Restricting to the legacy PMIPv6 model = is a limitation. I would be glad to hear opinions from other (different) voices. telemaco -----Message d'origine----- De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part = de Julien Laganier Envoy=E9=A0: mercredi 9 f=E9vrier 2011 03:20 =C0=A0: cjbc@it.uc3m.es Cc=A0: Basavaraj.Patil@nokia.com; netext@ietf.org Objet=A0: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-= pmipv6-flowmob as WG doc Hi Carlos, 2011/2/8 Carlos Jes=FAs Bernardos Cano : > Hi Julien, > > On Tue, 2011-02-08 at 17:21 -0800, Julien Laganier wrote: >> Hi Carlos, >> >> I am glad to see you agree with me :-) >> >> You're actually proving my point. >> >> To run any of the flow mobility stuff on a host, you will need either >> layer 2 to hide the dissimilar interfaces (virtual interface thing), >> in which case you do have L2 triggers, or to modify the layer 3, which >> this WG is explicitly prevented from doing assuming that's even >> possible. >> >> So you need layer 2. And that is actually exactly how netext could get >> chartered to work on flow mobility, because we assumed layer 2 would >> be there to help with all the stuff we're not allowed to do at layer >> 3. > > Exactly, you need layer 2 to help with all the stuff we are not allowed > to do at layer 3, _but_ not to do things that we don't need to do at the > MN, and can be trivially done with LMA-MAG signaling without putting > strong requirements on the layer 2. > > The signaling we define in our draft (or variations around that) allows > to support all the scenarios that have been mentioned so far, and does > not break any PMIPv6 concept -- just extends it. It does not require > complex layer 2 triggers/policies to be in place and it's therefore more > layer-2 agnostic. Still, you prefers to go for the "lets redo MIP at > layer-2", and I keep failing to see why PMIPv6 as per RFC5213 doesn't work without L2 triggers, so there's no value in extending PMIPv6 to spare relying on L2 triggers that are required anyway. --julien --julien _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From telemaco.melia@alcatel-lucent.com Wed Feb 9 07:35:15 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E3143A6767 for ; Wed, 9 Feb 2011 07:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.005 X-Spam-Level: X-Spam-Status: No, score=-5.005 tagged_above=-999 required=5 tests=[AWL=-0.910, BAYES_00=-2.599, FRT_BELOW2=2.154, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxJcIj7TEMNt for ; Wed, 9 Feb 2011 07:35:12 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id AD47E3A6405 for ; Wed, 9 Feb 2011 07:35:11 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p19FZGx6008492 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 Feb 2011 16:35:16 +0100 Received: from FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com ([135.120.45.54]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 9 Feb 2011 16:35:16 +0100 From: "MELIA, TELEMACO (TELEMACO)" To: Julien Laganier , Tran Minh Trung Date: Wed, 9 Feb 2011 16:35:14 +0100 Thread-Topic: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvIBJiHT6pTC5AuTLiPxUHd+1cGXgAai07Q Message-ID: <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6D206@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 15:35:15 -0000 Why? If the terminal is connected and radio coverage is ok it also means it= is ready to receive traffic on any of the interfaces right? Up the LMA to = route flows. telemaco -----Message d'origine----- De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part = de Julien Laganier Envoy=E9=A0: mercredi 9 f=E9vrier 2011 03:54 =C0=A0: Tran Minh Trung Cc=A0: netext@ietf.org; Basavaraj.Patil@nokia.com Objet=A0: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-p= mipv6-flowmob as WG doc Changing the policy on the network side alone isn't sufficient. You'd have to change the policy on the host, too (e.g., using ADNSF in 3GPP) which will trigger the MN to attach IF1 to session 2. This is the system view picture which seems we're missing in this discussio= n. --julien On Tue, Feb 8, 2011 at 6:49 PM, Tran Minh Trung wro= te: > Hi Julien, > > Let me show a real case for the scenario that we are discussing bellow: > > The network policy is changed and the LMA decides to move flow 2 from > IF2 to IF1 before MAG1 received L2 trigger from the MN (say before > step #8) > In that case, the LMA should signal MAG1 to send PBU to attach IF1 to > session 2. > > Without signaling from LMA how can you do in this case? Just wait > until receiving L2 trigger from the MN? > > On Wed, Feb 9, 2011 at 7:18 AM, Julien Laganier w= rote: >> Hi Pierrick, >> >> I am going to intertwine the steps in your scenario below with the >> missing pieces of the big picture so that we are not doing an academic >> exercise but focusing on the real world: >> >> 1. when the MN first attaches with if1 to a network, MAG1 requests >> attachment of if1 to a session1 by sending a PBU to LMA >> >> 2. because the MN add no session1 previously, the LMA creates session >> 1 and allocates a prefix for it. The prefix is sent back to MAG1 in >> the PBA: >> >> =A0=A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1-IF1] >> >> 3. then, if the MN attaches with if2 to another network, but does not >> request this interface be attached to a distinct session, MAG2 >> requests attachemnt of If2 to session1 by sending a PBU to LMA >> >> 4. Because the MN already has session 1, the LMA updates session1 with >> if2, and send the pref1 back to MAG2 in the PBA: >> >> =A0=A0 =A0 =A0 =A0 Session1: [Pref1, MAG1-IF1, MAG2-IF2] >> >> 5. Creation of a new session 2 for if2 is requested by either of MN >> requests via L2 triggers, or a change in policy profile. As a result, >> MAG2 requests attachment of if2 to session2 by sending a PBU to LMA. >> >> 6. because the MN add no session2 previously, the LMA creates session >> 2 and allocates a prefix for it. The prefix pref2 is sent back to MAG2 >> in the PBA: >> >> =A0=A0 =A0 =A0 =A0 =A0Session2: [Pref2, MAG2-IF2] >> >> 7. Flow2 starts over if2 with prefix2. >> >> 8. Attachment of if1 to session2 is requested by either of MN requests >> via L2 triggers, or a change in policy profile. As a result, MAG1 >> requests attachment of if1 to session2 by sending a PBU to LMA. >> >> 9. Because the MN already has session 2, the LMA updates session2 with i= f1: >> >> =A0=A0 =A0 =A0 =A0 Session2: [Pref2, MAG2-IF2, MAG1-IF1] >> >> 10. At any point, the LMA decides to move Flow2 between two interfaces >> of session 2, and it does so. >> >> That's all that needed. It maps perfectly to 3GPP. If you have in mind >> a different system in whcih that doesn't map, please let me know. >> >> --julien >> >> On Tue, Feb 8, 2011 at 8:25 AM, =A0 w= rote: >>> Hi, >>> >>> Going through this long thread :-), it seems we could agree on the foll= owing (just a tentative to summarize): >>> >>> Sessions should be created/updated with all available interfaces. Rewri= ting Tran's example: when the MN attaches to MAG1 via If1, the LMA creates = session 1: >>> >>> =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] >>> >>> Then, if the MN attaches to MAG2 via If2, the LMA creates session 2 wit= h both If1 and If2. The LMA also updates session 1 with If2: >>> >>> =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] >>> =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2, IF1] >>> >>> MAG2 receives prefixes 1 and 2 in PBA but MAG1 is not sending PBU. So, = if the LMA wants to move flow with Pref2 from if2 to If1, the LMA needs to = provide Pref2 to MAG1. Also, the LMA should be able to create new sessions = with already up interfaces, e.g. if1 and if2. To address both issues, PBU f= rom MAG1 could be triggered (triggering is to be clarified) or we could def= ine LMA/MAG specific L3 signalling (FMI/FMA). >>> >>> My 2 cents, >>> Pierrick >>> >>>> -----Message d'origine----- >>>> De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la = part >>>> de Youn-Hee Han >>>> Envoy=E9=A0: mardi 8 f=E9vrier 2011 12:00 >>>> =C0=A0: 'Julien Laganier'; 'Rajeev Koodli' >>>> Cc=A0: netext@ietf.org; Basavaraj.Patil@nokia.com >>>> Objet=A0: Re: [netext] Consensus call to adopt I-D:draft-bernardos-net= ext- >>>> pmipv6-flowmob as WG doc >>>> >>>> Hi Julien, >>>> >>>> > -----Original Message----- >>>> > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Be= half >>>> > Of Julien Laganier >>>> > Sent: Tuesday, February 08, 2011 1:38 PM >>>> > To: Rajeev Koodli >>>> > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com >>>> > Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos- >>>> > netext-pmipv6-flowmob as WG doc >>>> > >>>> > On Mon, Feb 7, 2011 at 6:15 PM, Rajeev Koodli wr= ote: >>>> > > >>>> > > If flow mobility has nothing do with prefix management, I am lost. >>>> > >>>> > No reason to be lost: Prefix management is how do I get prefix for t= he >>>> > MN. Flow mobility is how to I move flows across interfaces. The two >>>> > needs not to be intertwined together, as I've shown in my other note= s. >>>> > E.g., I can do flow mobility without adding/deleting prefixes from >>>> > sessions, and vice versa. >>>> >>>> Yes, I agree with you. Flow mobility is how to move flows across inter= face. >>>> So, I thought that it would be better to define "a flow" exactly in ne= text >>>> WG prior to discuss flow mobility management. As the definition of "a >>>> flow", >>>> all I can think is a five-tuple plus something. If we assume that it i= s >>>> correct, I think that flow mobility and prefix addition are inevitably >>>> tied. >>>> As you know, RFC5213 (and IPv6 protocol spec) already allow to assign >>>> multiple prefixes across multiple interfaces of an MN. Yes, I also agr= ee >>>> with you that in real-world (3GPP), there may be no need to assign >>>> multiple >>>> prefixes into an MN. (if somebody knows its necessity, please tell me = when >>>> it should happen). So, flow mobility can be done without adding prefix= es. >>>> However, different interfaces are allowed to be assigned different >>>> prefixes >>>> by RFC 5213 and IPv6 spec. We can't expect what kind of prefixes an MA= G >>>> advertises. Therefore, sometimes, we need prefix addition to move a fl= ow >>>> to >>>> a new interface of which MAG does not yet advertise the prefix of the = flow >>>> being moved. >>>> >>>> (snip...) >>>> >>>> > >> I see no reason to depart from that in the context of extending t= he >>>> > >> protocol to support mobility, nor I am aware of any system >>>> > >> architecture that would require this capability. >>>> > > >>>> > > Okay, see your position. I see it differently. I don't need to be >>>> > > bound by some "presumed implementation model" of PMIP6 and limit >>>> > > myself *only* to a prefix assignment model you are imagining. >>>> > >>>> > It's not an implementation model, it is a protocol model, and it's n= ot >>>> > imaginary. Implementation has nothing to do with this. >>>> > >>>> > There's no reason to extend prefix assignment model to do flow mobil= ity >>>> > unless you can point me out in which real world context your scenari= o >>>> > actually happens. >>>> >>>> As I insisted in the old mail, I agree with Julien in this regard. Cur= rent >>>> draft allows too much space regarding the prefix allocation model (uni= que, >>>> shared, and hybrid). When a flow should be moved to a new interface an= d >>>> the >>>> prefix which the flow uses is not yet advertised by the new MAG, just >>>> inform >>>> the prefix to the MAG and thus make it advertise the prefix and setup = the >>>> tunnel based on the new prefix. That's all!. If the prefix is already >>>> advertised by the MAG, there is nothing to do and just move the flow. = This >>>> behaviors are very natural one when we want to support IP-level mobili= ty. >>>> >>>> > >> If this is something really important, the WG can be rechartered = to >>>> > >> work on a different extension that would allow adding/removing >>>> > >> prefixes from existing PMIPv6 sessions. >>>> > > >>>> > > Huh.. What in the current charter forces us not to have the LMA >>>> > > add/refresh/delete a prefix on-demand? >>>> > >>>> > Engineering is about finding a solution to a problem. Adding/deletin= g >>>> > prefix on-demand is not a solution to flow mobility. I've shown you = how >>>> > to do flow mobility without this capability. >>>> >>>> From the viewpoint of protocol, I think that at least, prefix addition= to >>>> an >>>> interface is a necessary function to support flow mobility, as I expla= ined >>>> above. But, it does not mean prefix addition should happen always when= ever >>>> flow mobility occurs. It is sometimes needed. >>>> >>>> > Now a different engineering problem would be: how to add/delete pref= ixes >>>> > to a PMIPv6 session, and that would be useful for e.g. >>>> > renumbering. This is a different problem that we haven't been charte= red >>>> > to work on. >>>> >>>> Prefix addition is just prefix addition. IMHO, renumbering is closer t= o >>>> prefix change. We just harness that function to support IP-level mobil= ity. >>>> >>>> Youn-Hee >>>> >>>> _______________________________________________ >>>> 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 >> > > > > -- > Ph.D., Senior Member > Electronics and Telecommunications Research Institute > Standards Research Center > 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA > Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 > _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From sgundave@cisco.com Wed Feb 9 08:19:06 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E43173A69D5 for ; Wed, 9 Feb 2011 08:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.309 X-Spam-Level: X-Spam-Status: No, score=-9.309 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ci5zdBqiJqMK for ; Wed, 9 Feb 2011 08:19:05 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id DE4583A69D3 for ; Wed, 9 Feb 2011 08:19:05 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFFNUk2rR7H+/2dsb2JhbACkX2VzoTGbF4VcBIR/hnGDOA Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 09 Feb 2011 16:19:15 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p19GJFXD021711; Wed, 9 Feb 2011 16:19:15 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Feb 2011 08:19:15 -0800 Received: from 10.32.246.213 ([10.32.246.213]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Wed, 9 Feb 2011 16:19:15 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Wed, 09 Feb 2011 08:19:54 -0800 From: Sri Gundavelli To: "MELIA, TELEMACO (TELEMACO)" , Julien Laganier , "cjbc@it.uc3m.es" Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvH/9iYZNnTrkfGQpe1zCcxxH88sQAapUvgAAKwYFY= In-Reply-To: <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6D1F7@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 09 Feb 2011 16:19:15.0593 (UTC) FILETIME=[1860FF90:01CBC875] Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 16:19:07 -0000 I do not believe we are chartered to make fundamental model changes. We are not departing from RFC-5213, in how sessions are established, the functiona= l role of the MAG, the proxy model, or any basic changes. If the functional requirement is about enabling LMA to detect a policy change and to force that change in the sessions, we need to discuss about that trigger. If that trigger is from LMA, or an L2 event is one discussion point. But, eventuall= y that trigger should allow a MAG to send a PBU and that should allow the LMA to update the BCE states and return the hosted prefixes in the PBA. Lets no= t discuss about "legacy PMIPv6", and that we are defining a new protocol. I'v= e not heard such comments during chartering of this work and I believe we do need such fundamental changes to solve this flow mobility problem. Sri =20 On 2/9/11 7:17 AM, "MELIA, TELEMACO (TELEMACO)" wrote: > But why we cannot design a model where we can dynamically group sessions? > Mobile operators have been fighting hard in the past years the disconnect= ion > between ARPU and associated cost per users (in other words costs increase= but > revenues continue to fall). Data explosion is one of the reasons for such > disconnection. > I believe that network operators would be eager to learn about innovating > technologies to reduce costs expenditures. The work we are pushing with t= his > ID falls exactly in this category. Restricting to the legacy PMIPv6 model= is a > limitation. >=20 > I would be glad to hear opinions from other (different) voices. >=20 > telemaco >=20 > -----Message d'origine----- > De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part = de > Julien Laganier > Envoy=E9=A0: mercredi 9 f=E9vrier 2011 03:20 > =C0=A0: cjbc@it.uc3m.es > Cc=A0: Basavaraj.Patil@nokia.com; netext@ietf.org > Objet=A0: Re: [netext] Consensus call to adopt I-D: > draft-bernardos-netext-pmipv6-flowmob as WG doc >=20 > Hi Carlos, >=20 > 2011/2/8 Carlos Jes=FAs Bernardos Cano : >> Hi Julien, >>=20 >> On Tue, 2011-02-08 at 17:21 -0800, Julien Laganier wrote: >>> Hi Carlos, >>>=20 >>> I am glad to see you agree with me :-) >>>=20 >>> You're actually proving my point. >>>=20 >>> To run any of the flow mobility stuff on a host, you will need either >>> layer 2 to hide the dissimilar interfaces (virtual interface thing), >>> in which case you do have L2 triggers, or to modify the layer 3, which >>> this WG is explicitly prevented from doing assuming that's even >>> possible. >>>=20 >>> So you need layer 2. And that is actually exactly how netext could get >>> chartered to work on flow mobility, because we assumed layer 2 would >>> be there to help with all the stuff we're not allowed to do at layer >>> 3. >>=20 >> Exactly, you need layer 2 to help with all the stuff we are not allowed >> to do at layer 3, _but_ not to do things that we don't need to do at the >> MN, and can be trivially done with LMA-MAG signaling without putting >> strong requirements on the layer 2. >>=20 >> The signaling we define in our draft (or variations around that) allows >> to support all the scenarios that have been mentioned so far, and does >> not break any PMIPv6 concept -- just extends it. It does not require >> complex layer 2 triggers/policies to be in place and it's therefore more >> layer-2 agnostic. Still, you prefers to go for the "lets redo MIP at >> layer-2", and I keep failing to see why >=20 > PMIPv6 as per RFC5213 doesn't work without L2 triggers, so there's no > value in extending PMIPv6 to spare relying on L2 triggers that are > required anyway. >=20 > --julien >=20 > --julien > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From rkoodli@cisco.com Wed Feb 9 08:56:19 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBC953A67C2 for ; Wed, 9 Feb 2011 08:56:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.65 X-Spam-Level: X-Spam-Status: No, score=-108.65 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_00=-2.599, FRT_BELOW2=2.154, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAXJgo-h2Emj for ; Wed, 9 Feb 2011 08:56:18 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 15DCF3A65A5 for ; Wed, 9 Feb 2011 08:56:18 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAHVWUk2tJXG8/2dsb2JhbACWa4hvBoUBZXOhGJsdhVwEhH+GcYM4gwQ Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rtp-iport-2.cisco.com with ESMTP; 09 Feb 2011 16:56:27 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p19GuRgN010464; Wed, 9 Feb 2011 16:56:27 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Feb 2011 10:56:26 -0600 Received: from 10.21.76.82 ([10.21.76.82]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Wed, 9 Feb 2011 16:56:26 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Wed, 09 Feb 2011 09:15:15 -0800 From: Rajeev Koodli To: Tran Minh Trung , Julien Laganier Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvIfOq99HPNxvY8MUGs5WAfDKxrzQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 09 Feb 2011 16:56:26.0909 (UTC) FILETIME=[4A58CCD0:01CBC87A] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 16:56:20 -0000 On 2/8/11 7:10 PM, "Tran Minh Trung" wrote: > On Wed, Feb 9, 2011 at 12:00 PM, Julien Laganier > wrote: >> Network based flow mobility cannot be entirely transparent to the MN. >> It can be made transparent to the *IP layer* on the MN, but at minimum >> the layer 2 will have to change to decide where to send uplink >> packets. >>=20 >=20 > Did we agreed that the logical interface can send uplink packets > following the path that down-link packets received?. I thought we did, a while back. > The key purpose of network-based solution is minimize the involvement of = the > MN. > IMHO, both vendors and network operator prefer that way. I tend to agree. -Rajeev >=20 > Regards, > TrungTM >=20 >> This is a fact. >>=20 >> I am sorry if that means that the network-based solution is >> functionally equivalent to the client based and only differ in terms >> of the placement of the functions in various layer, but I cannot help >> it. >>=20 >> --julien >>=20 >> On Tue, Feb 8, 2011 at 6:57 PM, Tran Minh Trung >> wrote: >>> Since we are proposing network-based flow mobility, I think that it >>> must be transparent to the MN. >>> if not the network-based solution is similar as client-based one. >>>=20 >>> Regards, >>> TrungTM >>>=20 >>> On Wed, Feb 9, 2011 at 11:53 AM, Julien Laganier >>> wrote: >>>> Changing the policy on the network side alone isn't sufficient. You'd >>>> have to change the policy on the host, too (e.g., using ADNSF in 3GPP) >>>> which will trigger the MN to attach IF1 to session 2. >>>>=20 >>>> This is the system view picture which seems we're missing in this >>>> discussion. >>>>=20 >>>> --julien >>>>=20 >>>> On Tue, Feb 8, 2011 at 6:49 PM, Tran Minh Trung >>>> wrote: >>>>> Hi Julien, >>>>>=20 >>>>> Let me show a real case for the scenario that we are discussing bello= w: >>>>>=20 >>>>> The network policy is changed and the LMA decides to move flow 2 from >>>>> IF2 to IF1 before MAG1 received L2 trigger from the MN (say before >>>>> step #8) >>>>> In that case, the LMA should signal MAG1 to send PBU to attach IF1 to >>>>> session 2. >>>>>=20 >>>>> Without signaling from LMA how can you do in this case? Just wait >>>>> until receiving L2 trigger from the MN? >>>>>=20 >>>>> On Wed, Feb 9, 2011 at 7:18 AM, Julien Laganier >>>>> wrote: >>>>>> Hi Pierrick, >>>>>>=20 >>>>>> I am going to intertwine the steps in your scenario below with the >>>>>> missing pieces of the big picture so that we are not doing an academ= ic >>>>>> exercise but focusing on the real world: >>>>>>=20 >>>>>> 1. when the MN first attaches with if1 to a network, MAG1 requests >>>>>> attachment of if1 to a session1 by sending a PBU to LMA >>>>>>=20 >>>>>> 2. because the MN add no session1 previously, the LMA creates sessio= n >>>>>> 1 and allocates a prefix for it. The prefix is sent back to MAG1 in >>>>>> the PBA: >>>>>>=20 >>>>>> =A0=A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1-IF1] >>>>>>=20 >>>>>> 3. then, if the MN attaches with if2 to another network, but does no= t >>>>>> request this interface be attached to a distinct session, MAG2 >>>>>> requests attachemnt of If2 to session1 by sending a PBU to LMA >>>>>>=20 >>>>>> 4. Because the MN already has session 1, the LMA updates session1 wi= th >>>>>> if2, and send the pref1 back to MAG2 in the PBA: >>>>>>=20 >>>>>> =A0=A0 =A0 =A0 =A0 Session1: [Pref1, MAG1-IF1, MAG2-IF2] >>>>>>=20 >>>>>> 5. Creation of a new session 2 for if2 is requested by either of MN >>>>>> requests via L2 triggers, or a change in policy profile. As a result= , >>>>>> MAG2 requests attachment of if2 to session2 by sending a PBU to LMA. >>>>>>=20 >>>>>> 6. because the MN add no session2 previously, the LMA creates sessio= n >>>>>> 2 and allocates a prefix for it. The prefix pref2 is sent back to MA= G2 >>>>>> in the PBA: >>>>>>=20 >>>>>> =A0=A0 =A0 =A0 =A0 =A0Session2: [Pref2, MAG2-IF2] >>>>>>=20 >>>>>> 7. Flow2 starts over if2 with prefix2. >>>>>>=20 >>>>>> 8. Attachment of if1 to session2 is requested by either of MN reques= ts >>>>>> via L2 triggers, or a change in policy profile. As a result, MAG1 >>>>>> requests attachment of if1 to session2 by sending a PBU to LMA. >>>>>>=20 >>>>>> 9. Because the MN already has session 2, the LMA updates session2 wi= th >>>>>> if1: >>>>>>=20 >>>>>> =A0=A0 =A0 =A0 =A0 Session2: [Pref2, MAG2-IF2, MAG1-IF1] >>>>>>=20 >>>>>> 10. At any point, the LMA decides to move Flow2 between two interfac= es >>>>>> of session 2, and it does so. >>>>>>=20 >>>>>> That's all that needed. It maps perfectly to 3GPP. If you have in mi= nd >>>>>> a different system in whcih that doesn't map, please let me know. >>>>>>=20 >>>>>> --julien >>>>>>=20 >>>>>> On Tue, Feb 8, 2011 at 8:25 AM, =A0 >>>>>> wrote: >>>>>>> Hi, >>>>>>>=20 >>>>>>> Going through this long thread :-), it seems we could agree on the >>>>>>> following (just a tentative to summarize): >>>>>>>=20 >>>>>>> Sessions should be created/updated with all available interfaces. >>>>>>> Rewriting Tran's example: when the MN attaches to MAG1 via If1, the= LMA >>>>>>> creates session 1: >>>>>>>=20 >>>>>>> =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] >>>>>>>=20 >>>>>>> Then, if the MN attaches to MAG2 via If2, the LMA creates session 2= with >>>>>>> both If1 and If2. The LMA also updates session 1 with If2: >>>>>>>=20 >>>>>>> =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] >>>>>>> =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2, IF1] >>>>>>>=20 >>>>>>> MAG2 receives prefixes 1 and 2 in PBA but MAG1 is not sending PBU. = So, >>>>>>> if the LMA wants to move flow with Pref2 from if2 to If1, the LMA n= eeds >>>>>>> to provide Pref2 to MAG1. Also, the LMA should be able to create ne= w >>>>>>> sessions with already up interfaces, e.g. if1 and if2. To address b= oth >>>>>>> issues, PBU from MAG1 could be triggered (triggering is to be clari= fied) >>>>>>> or we could define LMA/MAG specific L3 signalling (FMI/FMA). >>>>>>>=20 >>>>>>> My 2 cents, >>>>>>> Pierrick >>>>>>>=20 >>>>>>>> -----Message d'origine----- >>>>>>>> De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De l= a >>>>>>>> part >>>>>>>> de Youn-Hee Han >>>>>>>> Envoy=E9=A0: mardi 8 f=E9vrier 2011 12:00 >>>>>>>> =C0=A0: 'Julien Laganier'; 'Rajeev Koodli' >>>>>>>> Cc=A0: netext@ietf.org; Basavaraj.Patil@nokia.com >>>>>>>> Objet=A0: Re: [netext] Consensus call to adopt >>>>>>>> I-D:draft-bernardos-netext- >>>>>>>> pmipv6-flowmob as WG doc >>>>>>>>=20 >>>>>>>> Hi Julien, >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On >>>>>>>>> Behalf >>>>>>>>> Of Julien Laganier >>>>>>>>> Sent: Tuesday, February 08, 2011 1:38 PM >>>>>>>>> To: Rajeev Koodli >>>>>>>>> Cc: netext@ietf.org; Basavaraj.Patil@nokia.com >>>>>>>>> Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardo= s- >>>>>>>>> netext-pmipv6-flowmob as WG doc >>>>>>>>>=20 >>>>>>>>> On Mon, Feb 7, 2011 at 6:15 PM, Rajeev Koodli >>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>> If flow mobility has nothing do with prefix management, I am los= t. >>>>>>>>>=20 >>>>>>>>> No reason to be lost: Prefix management is how do I get prefix fo= r the >>>>>>>>> MN. Flow mobility is how to I move flows across interfaces. The t= wo >>>>>>>>> needs not to be intertwined together, as I've shown in my other n= otes. >>>>>>>>> E.g., I can do flow mobility without adding/deleting prefixes fro= m >>>>>>>>> sessions, and vice versa. >>>>>>>>=20 >>>>>>>> Yes, I agree with you. Flow mobility is how to move flows across >>>>>>>> interface. >>>>>>>> So, I thought that it would be better to define "a flow" exactly i= n >>>>>>>> netext >>>>>>>> WG prior to discuss flow mobility management. As the definition of= "a >>>>>>>> flow", >>>>>>>> all I can think is a five-tuple plus something. If we assume that = it is >>>>>>>> correct, I think that flow mobility and prefix addition are inevit= ably >>>>>>>> tied. >>>>>>>> As you know, RFC5213 (and IPv6 protocol spec) already allow to ass= ign >>>>>>>> multiple prefixes across multiple interfaces of an MN. Yes, I also >>>>>>>> agree >>>>>>>> with you that in real-world (3GPP), there may be no need to assign >>>>>>>> multiple >>>>>>>> prefixes into an MN. (if somebody knows its necessity, please tell= me >>>>>>>> when >>>>>>>> it should happen). So, flow mobility can be done without adding >>>>>>>> prefixes. >>>>>>>> However, different interfaces are allowed to be assigned different >>>>>>>> prefixes >>>>>>>> by RFC 5213 and IPv6 spec. We can't expect what kind of prefixes a= n MAG >>>>>>>> advertises. Therefore, sometimes, we need prefix addition to move = a >>>>>>>> flow >>>>>>>> to >>>>>>>> a new interface of which MAG does not yet advertise the prefix of = the >>>>>>>> flow >>>>>>>> being moved. >>>>>>>>=20 >>>>>>>> (snip...) >>>>>>>>=20 >>>>>>>>>>> I see no reason to depart from that in the context of extending= the >>>>>>>>>>> protocol to support mobility, nor I am aware of any system >>>>>>>>>>> architecture that would require this capability. >>>>>>>>>>=20 >>>>>>>>>> Okay, see your position. I see it differently. I don't need to b= e >>>>>>>>>> bound by some "presumed implementation model" of PMIP6 and limit >>>>>>>>>> myself *only* to a prefix assignment model you are imagining. >>>>>>>>>=20 >>>>>>>>> It's not an implementation model, it is a protocol model, and it'= s not >>>>>>>>> imaginary. Implementation has nothing to do with this. >>>>>>>>>=20 >>>>>>>>> There's no reason to extend prefix assignment model to do flow >>>>>>>>> mobility >>>>>>>>> unless you can point me out in which real world context your scen= ario >>>>>>>>> actually happens. >>>>>>>>=20 >>>>>>>> As I insisted in the old mail, I agree with Julien in this regard. >>>>>>>> Current >>>>>>>> draft allows too much space regarding the prefix allocation model >>>>>>>> (unique, >>>>>>>> shared, and hybrid). When a flow should be moved to a new interfac= e and >>>>>>>> the >>>>>>>> prefix which the flow uses is not yet advertised by the new MAG, j= ust >>>>>>>> inform >>>>>>>> the prefix to the MAG and thus make it advertise the prefix and se= tup >>>>>>>> the >>>>>>>> tunnel based on the new prefix. That's all!. If the prefix is alre= ady >>>>>>>> advertised by the MAG, there is nothing to do and just move the fl= ow. >>>>>>>> This >>>>>>>> behaviors are very natural one when we want to support IP-level >>>>>>>> mobility. >>>>>>>>=20 >>>>>>>>>>> If this is something really important, the WG can be rechartere= d to >>>>>>>>>>> work on a different extension that would allow adding/removing >>>>>>>>>>> prefixes from existing PMIPv6 sessions. >>>>>>>>>>=20 >>>>>>>>>> Huh.. What in the current charter forces us not to have the LMA >>>>>>>>>> add/refresh/delete a prefix on-demand? >>>>>>>>>=20 >>>>>>>>> Engineering is about finding a solution to a problem. Adding/dele= ting >>>>>>>>> prefix on-demand is not a solution to flow mobility. I've shown y= ou >>>>>>>>> how >>>>>>>>> to do flow mobility without this capability. >>>>>>>>=20 >>>>>>>> From the viewpoint of protocol, I think that at least, prefix addi= tion >>>>>>>> to >>>>>>>> an >>>>>>>> interface is a necessary function to support flow mobility, as I >>>>>>>> explained >>>>>>>> above. But, it does not mean prefix addition should happen always >>>>>>>> whenever >>>>>>>> flow mobility occurs. It is sometimes needed. >>>>>>>>=20 >>>>>>>>> Now a different engineering problem would be: how to add/delete >>>>>>>>> prefixes >>>>>>>>> to a PMIPv6 session, and that would be useful for e.g. >>>>>>>>> renumbering. This is a different problem that we haven't been >>>>>>>>> chartered >>>>>>>>> to work on. >>>>>>>>=20 >>>>>>>> Prefix addition is just prefix addition. IMHO, renumbering is clos= er to >>>>>>>> prefix change. We just harness that function to support IP-level >>>>>>>> mobility. >>>>>>>>=20 >>>>>>>> Youn-Hee >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> netext mailing list >>>>>>>> netext@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/netext >>>>>>>=20 >>>>>> _______________________________________________ >>>>>> netext mailing list >>>>>> netext@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netext >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>> Ph.D., Senior Member >>>>> Electronics and Telecommunications Research Institute >>>>> Standards Research Center >>>>> 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA >>>>> Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 >>>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> Ph.D., Senior Member >>> Electronics and Telecommunications Research Institute >>> Standards Research Center >>> 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA >>> Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 >>>=20 >>=20 >=20 >=20 From sfaccin@rim.com Wed Feb 9 09:08:13 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87ACC3A67E4 for ; Wed, 9 Feb 2011 09:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.625 X-Spam-Level: X-Spam-Status: No, score=-5.625 tagged_above=-999 required=5 tests=[AWL=0.974, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75ZwA8rU3zlg for ; Wed, 9 Feb 2011 09:08:12 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 124D13A67BD for ; Wed, 9 Feb 2011 09:08:06 -0800 (PST) X-AuditID: 0a666446-b7b81ae000000a21-6e-4d52c9ff705a Received: from XCH138CNC.rim.net ( [10.65.20.127]) by mhs04ykf.rim.net (RIM Mail) with SMTP id BE.FC.02593.FF9C25D4; Wed, 9 Feb 2011 12:08:15 -0500 (EST) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH138CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Feb 2011 12:08:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" content-transfer-encoding: base64 Date: Wed, 9 Feb 2011 11:08:12 -0600 Message-ID: <680854867F7FD04BB9B06EB8ACA8D5AC05EFEC1B@XCH02DFW.rim.net> In-Reply-To: <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6D1F7@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvH/9iYZNnTrkfGQpe1zCcxxH88sQAapUvgAAROw4A= References: <1296920514.3773.26.camel@acorde.it.uc3m.es><1297017501.4715.2.camel@acorde.it.uc3m.es><1297019696.4715.5.camel@acorde.it.uc3m.es><1297115574.3099.3.camel@acorde.it.uc3m.es><1297126584.3099.96.camel@acorde.it.uc3m.es><1297129998.3099.140.camel@acorde.it.uc3m.es><1297208236.5169.80.camel@acorde.it.uc3m.es><1297217553.5169.88.camel@acorde.it.uc3m.es> <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6D1F7@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> From: "Stefano Faccin" To: "MELIA, TELEMACO (TELEMACO)" , "Julien Laganier" , X-OriginalArrivalTime: 09 Feb 2011 17:08:15.0370 (UTC) FILETIME=[F09F5EA0:01CBC87B] X-Brightmail-Tracker: AAAAAgAAAZEXVNa5 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 17:08:13 -0000 VGVsZW1hY28sDQpBbGwgdGhhdCB5b3Ugc2F5IGlzIGdvb2QsIGFwYXJ0IGZyb20gb25lIGRl dGFpbC4gSSBkbyBub3QgYmVsaWV2ZSB0aGF0IGhlcmUgaW4gSUVURiB3ZSBzaG91bGQgYmUg dGFsa2luZyBhYm91dCBBUlBVIGFuZCBjb3N0cyBhbmQgc28gb24uIFdlIGFyZSBqdXN0IG5v dCBjYXBhYmxlIG9mIGV2YWx1YXRpbmcgdGhlbS4gSWYgaW5kZWVkIGFzIHlvdSBzYXkgdGhp cyBzb2x1dGlvbiB3ZXJlIHRoZSBtYWdpYyBhbnN3ZXIgdG8gb3BlcmF0b3IgaXNzdWVzLCBJ IGFtIHN1cmUgb3BlcmF0b3JzIGluIDNHUFAgd291bGQgaGF2ZSBzaG93biBhIGJpZ2dlciBp bnRlcmVzdCBpbiBpdC4gTXkgcHJldmlvdXMgcXVlc3Rpb24gb24gd2hldGhlciB3ZSBoYXZl IGFuIG9wZW4gYW5kIGRlY2xhcmVkIGN1c3RvbWVyIGZvciB0aGlzIHNvbHV0aW9uIChpLmUu IHRoYXQgY2xlYXJseSBzdGF0ZWQgdGhpcyBpcyBuZWVkZWQpIGlzIHN0aWxsIHVuYW5zd2Vy ZWQsIHNvIHBlcmhhcHMgdGhlcmUgaXNuJ3QgaW5kZWVkIHN1Y2ggYW4gaW50ZXJlc3QgaW4g dGhpcyBtYWdpYyBzb2x1dGlvbj8NCkNoZWVycywNClN0ZWZhbm8gRmFjY2luDQoNClN0YW5k YXJkcyBNYW5hZ2VyDQpSZXNlYXJjaCBJbiBNb3Rpb24gQ29ycG9yYXRpb24gDQo1MDAwIFJp dmVyc2lkZSBEcml2ZSANCkJ1aWxkaW5nIDYsIEJyYXpvcyBFYXN0LCBTdGUuIDEwMA0KSXJ2 aW5nLCBUZXhhcyA3NTAzOSBVU0EgDQpPZmZpY2U6ICg5NzIpIDkxMCAzNDUxwqAgDQpJbnRl cm5hbDogODIwLjYzNDUxDQo6ICg1MTApIDIzMCA4NDIyDQp3d3cucmltLmNvbTsgd3d3LmJs YWNrYmVycnkuY29tIA0KDQoNCg0K74GQIENvbnNpZGVyIHRoZSBlbnZpcm9ubWVudCBiZWZv cmUgcHJpbnRpbmcuDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG5l dGV4dC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBNRUxJQSwgVEVMRU1BQ08gKFRFTEVNQUNPKQ0KU2VudDogV2VkbmVz ZGF5LCBGZWJydWFyeSAwOSwgMjAxMSA3OjE4IEFNDQpUbzogSnVsaWVuIExhZ2FuaWVyOyBj amJjQGl0LnVjM20uZXMNCkNjOiBuZXRleHRAaWV0Zi5vcmc7IEJhc2F2YXJhai5QYXRpbEBu b2tpYS5jb20NClN1YmplY3Q6IFJlOiBbbmV0ZXh0XSBDb25zZW5zdXMgY2FsbCB0byBhZG9w dCBJLUQ6IGRyYWZ0LWJlcm5hcmRvcy1uZXRleHQtcG1pcHY2LWZsb3dtb2IgYXMgV0cgZG9j DQoNCkJ1dCB3aHkgd2UgY2Fubm90IGRlc2lnbiBhIG1vZGVsIHdoZXJlIHdlIGNhbiBkeW5h bWljYWxseSBncm91cCBzZXNzaW9ucz8NCk1vYmlsZSBvcGVyYXRvcnMgaGF2ZSBiZWVuIGZp Z2h0aW5nIGhhcmQgaW4gdGhlIHBhc3QgeWVhcnMgdGhlIGRpc2Nvbm5lY3Rpb24gYmV0d2Vl biBBUlBVIGFuZCBhc3NvY2lhdGVkIGNvc3QgcGVyIHVzZXJzIChpbiBvdGhlciB3b3JkcyBj b3N0cyBpbmNyZWFzZSBidXQgcmV2ZW51ZXMgY29udGludWUgdG8gZmFsbCkuIERhdGEgZXhw bG9zaW9uIGlzIG9uZSBvZiB0aGUgcmVhc29ucyBmb3Igc3VjaCBkaXNjb25uZWN0aW9uLg0K SSBiZWxpZXZlIHRoYXQgbmV0d29yayBvcGVyYXRvcnMgd291bGQgYmUgZWFnZXIgdG8gbGVh cm4gYWJvdXQgaW5ub3ZhdGluZyB0ZWNobm9sb2dpZXMgdG8gcmVkdWNlIGNvc3RzIGV4cGVu ZGl0dXJlcy4gVGhlIHdvcmsgd2UgYXJlIHB1c2hpbmcgd2l0aCB0aGlzIElEIGZhbGxzIGV4 YWN0bHkgaW4gdGhpcyBjYXRlZ29yeS4gUmVzdHJpY3RpbmcgdG8gdGhlIGxlZ2FjeSBQTUlQ djYgbW9kZWwgaXMgYSBsaW1pdGF0aW9uLg0KDQpJIHdvdWxkIGJlIGdsYWQgdG8gaGVhciBv cGluaW9ucyBmcm9tIG90aGVyIChkaWZmZXJlbnQpIHZvaWNlcy4NCg0KdGVsZW1hY28NCg0K LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBuZXRleHQtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOm5ldGV4dC1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEp1 bGllbiBMYWdhbmllcg0KRW52b3nDqcKgOiBtZXJjcmVkaSA5IGbDqXZyaWVyIDIwMTEgMDM6 MjANCsOAwqA6IGNqYmNAaXQudWMzbS5lcw0KQ2PCoDogQmFzYXZhcmFqLlBhdGlsQG5va2lh LmNvbTsgbmV0ZXh0QGlldGYub3JnDQpPYmpldMKgOiBSZTogW25ldGV4dF0gQ29uc2Vuc3Vz IGNhbGwgdG8gYWRvcHQgSS1EOiBkcmFmdC1iZXJuYXJkb3MtbmV0ZXh0LXBtaXB2Ni1mbG93 bW9iIGFzIFdHIGRvYw0KDQpIaSBDYXJsb3MsDQoNCjIwMTEvMi84IENhcmxvcyBKZXPDunMg QmVybmFyZG9zIENhbm8gPGNqYmNAaXQudWMzbS5lcz46DQo+IEhpIEp1bGllbiwNCj4NCj4g T24gVHVlLCAyMDExLTAyLTA4IGF0IDE3OjIxIC0wODAwLCBKdWxpZW4gTGFnYW5pZXIgd3Jv dGU6DQo+PiBIaSBDYXJsb3MsDQo+Pg0KPj4gSSBhbSBnbGFkIHRvIHNlZSB5b3UgYWdyZWUg d2l0aCBtZSA6LSkNCj4+DQo+PiBZb3UncmUgYWN0dWFsbHkgcHJvdmluZyBteSBwb2ludC4N Cj4+DQo+PiBUbyBydW4gYW55IG9mIHRoZSBmbG93IG1vYmlsaXR5IHN0dWZmIG9uIGEgaG9z dCwgeW91IHdpbGwgbmVlZCBlaXRoZXINCj4+IGxheWVyIDIgdG8gaGlkZSB0aGUgZGlzc2lt aWxhciBpbnRlcmZhY2VzICh2aXJ0dWFsIGludGVyZmFjZSB0aGluZyksDQo+PiBpbiB3aGlj aCBjYXNlIHlvdSBkbyBoYXZlIEwyIHRyaWdnZXJzLCBvciB0byBtb2RpZnkgdGhlIGxheWVy IDMsIHdoaWNoDQo+PiB0aGlzIFdHIGlzIGV4cGxpY2l0bHkgcHJldmVudGVkIGZyb20gZG9p bmcgYXNzdW1pbmcgdGhhdCdzIGV2ZW4NCj4+IHBvc3NpYmxlLg0KPj4NCj4+IFNvIHlvdSBu ZWVkIGxheWVyIDIuIEFuZCB0aGF0IGlzIGFjdHVhbGx5IGV4YWN0bHkgaG93IG5ldGV4dCBj b3VsZCBnZXQNCj4+IGNoYXJ0ZXJlZCB0byB3b3JrIG9uIGZsb3cgbW9iaWxpdHksIGJlY2F1 c2Ugd2UgYXNzdW1lZCBsYXllciAyIHdvdWxkDQo+PiBiZSB0aGVyZSB0byBoZWxwIHdpdGgg YWxsIHRoZSBzdHVmZiB3ZSdyZSBub3QgYWxsb3dlZCB0byBkbyBhdCBsYXllcg0KPj4gMy4N Cj4NCj4gRXhhY3RseSwgeW91IG5lZWQgbGF5ZXIgMiB0byBoZWxwIHdpdGggYWxsIHRoZSBz dHVmZiB3ZSBhcmUgbm90IGFsbG93ZWQNCj4gdG8gZG8gYXQgbGF5ZXIgMywgX2J1dF8gbm90 IHRvIGRvIHRoaW5ncyB0aGF0IHdlIGRvbid0IG5lZWQgdG8gZG8gYXQgdGhlDQo+IE1OLCBh bmQgY2FuIGJlIHRyaXZpYWxseSBkb25lIHdpdGggTE1BLU1BRyBzaWduYWxpbmcgd2l0aG91 dCBwdXR0aW5nDQo+IHN0cm9uZyByZXF1aXJlbWVudHMgb24gdGhlIGxheWVyIDIuDQo+DQo+ IFRoZSBzaWduYWxpbmcgd2UgZGVmaW5lIGluIG91ciBkcmFmdCAob3IgdmFyaWF0aW9ucyBh cm91bmQgdGhhdCkgYWxsb3dzDQo+IHRvIHN1cHBvcnQgYWxsIHRoZSBzY2VuYXJpb3MgdGhh dCBoYXZlIGJlZW4gbWVudGlvbmVkIHNvIGZhciwgYW5kIGRvZXMNCj4gbm90IGJyZWFrIGFu eSBQTUlQdjYgY29uY2VwdCAtLSBqdXN0IGV4dGVuZHMgaXQuIEl0IGRvZXMgbm90IHJlcXVp cmUNCj4gY29tcGxleCBsYXllciAyIHRyaWdnZXJzL3BvbGljaWVzIHRvIGJlIGluIHBsYWNl IGFuZCBpdCdzIHRoZXJlZm9yZSBtb3JlDQo+IGxheWVyLTIgYWdub3N0aWMuIFN0aWxsLCB5 b3UgcHJlZmVycyB0byBnbyBmb3IgdGhlICJsZXRzIHJlZG8gTUlQIGF0DQo+IGxheWVyLTIi LCBhbmQgSSBrZWVwIGZhaWxpbmcgdG8gc2VlIHdoeQ0KDQpQTUlQdjYgYXMgcGVyIFJGQzUy MTMgZG9lc24ndCB3b3JrIHdpdGhvdXQgTDIgdHJpZ2dlcnMsIHNvIHRoZXJlJ3Mgbm8NCnZh bHVlIGluIGV4dGVuZGluZyBQTUlQdjYgdG8gc3BhcmUgcmVseWluZyBvbiBMMiB0cmlnZ2Vy cyB0aGF0IGFyZQ0KcmVxdWlyZWQgYW55d2F5Lg0KDQotLWp1bGllbg0KDQotLWp1bGllbg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldGV4 dCBtYWlsaW5nIGxpc3QNCm5ldGV4dEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXRleHQNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpuZXRleHQgbWFpbGluZyBsaXN0DQpuZXRleHRAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0DQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQpUaGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2ht ZW50cykgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLCBwcml2aWxlZ2Vk IG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0ZXJpYWwgcHJvdGVjdGVkIGJ5IHRoZSBzb2xpY2l0 b3ItY2xpZW50IG9yIG90aGVyIGFwcGxpY2FibGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1 dGUgbm9uLXB1YmxpYyBpbmZvcm1hdGlvbi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9u IGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGli aXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3Is IHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhp cyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRp c3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9uIGJ5IHVu aW50ZW5kZWQgcmVjaXBpZW50cyBpcyBub3QgYXV0aG9yaXplZCBhbmQgbWF5IGJlIHVubGF3 ZnVsLg0K From rkoodli@cisco.com Wed Feb 9 09:12:34 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA7E23A69A8 for ; Wed, 9 Feb 2011 09:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.472 X-Spam-Level: X-Spam-Status: No, score=-108.472 tagged_above=-999 required=5 tests=[AWL=-1.423, BAYES_00=-2.599, FRT_BELOW2=2.154, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GA-LEDXpV94s for ; Wed, 9 Feb 2011 09:12:33 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E707A3A67D8 for ; Wed, 9 Feb 2011 09:12:32 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAPpZUk2tJV2d/2dsb2JhbACWbYhvBoUBZXOhB5shhVwEhH+GcYM4gwQ Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-1.cisco.com with ESMTP; 09 Feb 2011 17:12:42 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p19HCgJq019111; Wed, 9 Feb 2011 17:12:42 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Feb 2011 11:12:41 -0600 Received: from 10.21.76.82 ([10.21.76.82]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Wed, 9 Feb 2011 17:12:41 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Wed, 09 Feb 2011 09:31:29 -0800 From: Rajeev Koodli To: Tran Minh Trung , Sri Gundavelli Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvIfy9K9Z6dwrarG0uBOL4kXHRPqw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 09 Feb 2011 17:12:41.0811 (UTC) FILETIME=[8F6F0A30:01CBC87C] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 17:12:34 -0000 We can argue about what is "general case" and what is not. IMO, it's not fo= r us to decide, let the marketplace make that call. As protocol designers, I would like to ensure that we provide the necessary tools to address the problems, rather than debate "who wants to play oracle". 1. I just don't see why anyone should be forced assign all prefixes proactively. Parsimonious protocol design has its place - LMA should be abl= e to assign prefixes on-demand, when necessary. And, not clump stuff (all prefixes) under the guise of legacy RFC 5213 design, which BTW, feel free t= o do if you so choose; but just don't make it the only way. 2. FMI is the message to inform the MAG to add a new prefix to BUL, and to advertise the new prefix in RA, just as it should. FMA is a response to FMI= , saying I got the message with the disposition of the Status code. Simple, like other stuff we have in Netext, e.g., Localized Routing. This will do the job for the case. Why do I need PBU/PBA again? Other than to (wastefully) satisfy some vague "PMIP6 model", I don't see anything else. This is not protocol design, it's continued adherence to bad design decisions. -Rajeev On 2/8/11 7:13 PM, "Tran Minh Trung" wrote: > Hi Sri, >=20 > If all of us are agree that it is not a general case and we can ignore > it then I think the Julien's solution is sufficient. >=20 > I am going out for lunch now. >=20 > Talk to you later. > Regards, > TrungTM >=20 > On Wed, Feb 9, 2011 at 12:03 PM, Sri Gundavelli wrot= e: >> Hi Tran: >>=20 >> Policy change is not a general case, it is a special case. It can indeed >> take affect after a lapse of time. Either way, the trigger from LMA to M= AG >> is one option, I'm still not convinced why I'd need FMA. The trigger sho= uld >> force the MAG to send a PBU and per RFC-5213, it should get a set of >> prefixes that its hosting on the access link. This essentially, forces t= he >> approach of session state creation at the request of the MAG. If policy >> change is a valid case, a simple trigger is sufficient. >>=20 >>=20 >> Regards >> Sri >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2/8/11 6:49 PM, "Tran Minh Trung" wrote: >>=20 >>> Hi Julien, >>>=20 >>> Let me show a real case for the scenario that we are discussing bellow: >>>=20 >>> The network policy is changed and the LMA decides to move flow 2 from >>> IF2 to IF1 before MAG1 received L2 trigger from the MN (say before >>> step #8) >>> In that case, the LMA should signal MAG1 to send PBU to attach IF1 to >>> session 2. >>>=20 >>> Without signaling from LMA how can you do in this case? Just wait >>> until receiving L2 trigger from the MN? >>>=20 >>> On Wed, Feb 9, 2011 at 7:18 AM, Julien Laganier >>> wrote: >>>> Hi Pierrick, >>>>=20 >>>> I am going to intertwine the steps in your scenario below with the >>>> missing pieces of the big picture so that we are not doing an academic >>>> exercise but focusing on the real world: >>>>=20 >>>> 1. when the MN first attaches with if1 to a network, MAG1 requests >>>> attachment of if1 to a session1 by sending a PBU to LMA >>>>=20 >>>> 2. because the MN add no session1 previously, the LMA creates session >>>> 1 and allocates a prefix for it. The prefix is sent back to MAG1 in >>>> the PBA: >>>>=20 >>>> =A0=A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1-IF1] >>>>=20 >>>> 3. then, if the MN attaches with if2 to another network, but does not >>>> request this interface be attached to a distinct session, MAG2 >>>> requests attachemnt of If2 to session1 by sending a PBU to LMA >>>>=20 >>>> 4. Because the MN already has session 1, the LMA updates session1 with >>>> if2, and send the pref1 back to MAG2 in the PBA: >>>>=20 >>>> =A0=A0 =A0 =A0 =A0 Session1: [Pref1, MAG1-IF1, MAG2-IF2] >>>>=20 >>>> 5. Creation of a new session 2 for if2 is requested by either of MN >>>> requests via L2 triggers, or a change in policy profile. As a result, >>>> MAG2 requests attachment of if2 to session2 by sending a PBU to LMA. >>>>=20 >>>> 6. because the MN add no session2 previously, the LMA creates session >>>> 2 and allocates a prefix for it. The prefix pref2 is sent back to MAG2 >>>> in the PBA: >>>>=20 >>>> =A0=A0 =A0 =A0 =A0 =A0Session2: [Pref2, MAG2-IF2] >>>>=20 >>>> 7. Flow2 starts over if2 with prefix2. >>>>=20 >>>> 8. Attachment of if1 to session2 is requested by either of MN requests >>>> via L2 triggers, or a change in policy profile. As a result, MAG1 >>>> requests attachment of if1 to session2 by sending a PBU to LMA. >>>>=20 >>>> 9. Because the MN already has session 2, the LMA updates session2 with= if1: >>>>=20 >>>> =A0=A0 =A0 =A0 =A0 Session2: [Pref2, MAG2-IF2, MAG1-IF1] >>>>=20 >>>> 10. At any point, the LMA decides to move Flow2 between two interfaces >>>> of session 2, and it does so. >>>>=20 >>>> That's all that needed. It maps perfectly to 3GPP. If you have in mind >>>> a different system in whcih that doesn't map, please let me know. >>>>=20 >>>> --julien >>>>=20 >>>> On Tue, Feb 8, 2011 at 8:25 AM, =A0 w= rote: >>>>> Hi, >>>>>=20 >>>>> Going through this long thread :-), it seems we could agree on the >>>>> following >>>>> (just a tentative to summarize): >>>>>=20 >>>>> Sessions should be created/updated with all available interfaces. >>>>> Rewriting >>>>> Tran's example: when the MN attaches to MAG1 via If1, the LMA creates >>>>> session 1: >>>>>=20 >>>>> =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] >>>>>=20 >>>>> Then, if the MN attaches to MAG2 via If2, the LMA creates session 2 w= ith >>>>> both If1 and If2. The LMA also updates session 1 with If2: >>>>>=20 >>>>> =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] >>>>> =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2, IF1] >>>>>=20 >>>>> MAG2 receives prefixes 1 and 2 in PBA but MAG1 is not sending PBU. So= , if >>>>> the LMA wants to move flow with Pref2 from if2 to If1, the LMA needs = to >>>>> provide Pref2 to MAG1. Also, the LMA should be able to create new ses= sions >>>>> with already up interfaces, e.g. if1 and if2. To address both issues,= PBU >>>>> from MAG1 could be triggered (triggering is to be clarified) or we co= uld >>>>> define LMA/MAG specific L3 signalling (FMI/FMA). >>>>>=20 >>>>> My 2 cents, >>>>> Pierrick >>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la = part >>>>>> de Youn-Hee Han >>>>>> Envoy=E9=A0: mardi 8 f=E9vrier 2011 12:00 >>>>>> =C0=A0: 'Julien Laganier'; 'Rajeev Koodli' >>>>>> Cc=A0: netext@ietf.org; Basavaraj.Patil@nokia.com >>>>>> Objet=A0: Re: [netext] Consensus call to adopt I-D:draft-bernardos-net= ext- >>>>>> pmipv6-flowmob as WG doc >>>>>>=20 >>>>>> Hi Julien, >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On B= ehalf >>>>>>> Of Julien Laganier >>>>>>> Sent: Tuesday, February 08, 2011 1:38 PM >>>>>>> To: Rajeev Koodli >>>>>>> Cc: netext@ietf.org; Basavaraj.Patil@nokia.com >>>>>>> Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos- >>>>>>> netext-pmipv6-flowmob as WG doc >>>>>>>=20 >>>>>>> On Mon, Feb 7, 2011 at 6:15 PM, Rajeev Koodli w= rote: >>>>>>>>=20 >>>>>>>> If flow mobility has nothing do with prefix management, I am lost. >>>>>>>=20 >>>>>>> No reason to be lost: Prefix management is how do I get prefix for = the >>>>>>> MN. Flow mobility is how to I move flows across interfaces. The two >>>>>>> needs not to be intertwined together, as I've shown in my other not= es. >>>>>>> E.g., I can do flow mobility without adding/deleting prefixes from >>>>>>> sessions, and vice versa. >>>>>>=20 >>>>>> Yes, I agree with you. Flow mobility is how to move flows across >>>>>> interface. >>>>>> So, I thought that it would be better to define "a flow" exactly in >>>>>> netext >>>>>> WG prior to discuss flow mobility management. As the definition of "= a >>>>>> flow", >>>>>> all I can think is a five-tuple plus something. If we assume that it= is >>>>>> correct, I think that flow mobility and prefix addition are inevitab= ly >>>>>> tied. >>>>>> As you know, RFC5213 (and IPv6 protocol spec) already allow to assig= n >>>>>> multiple prefixes across multiple interfaces of an MN. Yes, I also a= gree >>>>>> with you that in real-world (3GPP), there may be no need to assign >>>>>> multiple >>>>>> prefixes into an MN. (if somebody knows its necessity, please tell m= e >>>>>> when >>>>>> it should happen). So, flow mobility can be done without adding pref= ixes. >>>>>> However, different interfaces are allowed to be assigned different >>>>>> prefixes >>>>>> by RFC 5213 and IPv6 spec. We can't expect what kind of prefixes an = MAG >>>>>> advertises. Therefore, sometimes, we need prefix addition to move a = flow >>>>>> to >>>>>> a new interface of which MAG does not yet advertise the prefix of th= e >>>>>> flow >>>>>> being moved. >>>>>>=20 >>>>>> (snip...) >>>>>>=20 >>>>>>>>> I see no reason to depart from that in the context of extending t= he >>>>>>>>> protocol to support mobility, nor I am aware of any system >>>>>>>>> architecture that would require this capability. >>>>>>>>=20 >>>>>>>> Okay, see your position. I see it differently. I don't need to be >>>>>>>> bound by some "presumed implementation model" of PMIP6 and limit >>>>>>>> myself *only* to a prefix assignment model you are imagining. >>>>>>>=20 >>>>>>> It's not an implementation model, it is a protocol model, and it's = not >>>>>>> imaginary. Implementation has nothing to do with this. >>>>>>>=20 >>>>>>> There's no reason to extend prefix assignment model to do flow mobi= lity >>>>>>> unless you can point me out in which real world context your scenar= io >>>>>>> actually happens. >>>>>>=20 >>>>>> As I insisted in the old mail, I agree with Julien in this regard. >>>>>> Current >>>>>> draft allows too much space regarding the prefix allocation model >>>>>> (unique, >>>>>> shared, and hybrid). When a flow should be moved to a new interface = and >>>>>> the >>>>>> prefix which the flow uses is not yet advertised by the new MAG, jus= t >>>>>> inform >>>>>> the prefix to the MAG and thus make it advertise the prefix and setu= p the >>>>>> tunnel based on the new prefix. That's all!. If the prefix is alread= y >>>>>> advertised by the MAG, there is nothing to do and just move the flow= . >>>>>> This >>>>>> behaviors are very natural one when we want to support IP-level mobi= lity. >>>>>>=20 >>>>>>>>> If this is something really important, the WG can be rechartered = to >>>>>>>>> work on a different extension that would allow adding/removing >>>>>>>>> prefixes from existing PMIPv6 sessions. >>>>>>>>=20 >>>>>>>> Huh.. What in the current charter forces us not to have the LMA >>>>>>>> add/refresh/delete a prefix on-demand? >>>>>>>=20 >>>>>>> Engineering is about finding a solution to a problem. Adding/deleti= ng >>>>>>> prefix on-demand is not a solution to flow mobility. I've shown you= how >>>>>>> to do flow mobility without this capability. >>>>>>=20 >>>>>> From the viewpoint of protocol, I think that at least, prefix additi= on to >>>>>> an >>>>>> interface is a necessary function to support flow mobility, as I >>>>>> explained >>>>>> above. But, it does not mean prefix addition should happen always >>>>>> whenever >>>>>> flow mobility occurs. It is sometimes needed. >>>>>>=20 >>>>>>> Now a different engineering problem would be: how to add/delete pre= fixes >>>>>>> to a PMIPv6 session, and that would be useful for e.g. >>>>>>> renumbering. This is a different problem that we haven't been chart= ered >>>>>>> to work on. >>>>>>=20 >>>>>> Prefix addition is just prefix addition. IMHO, renumbering is closer= to >>>>>> prefix change. We just harness that function to support IP-level >>>>>> mobility. >>>>>>=20 >>>>>> Youn-Hee >>>>>>=20 >>>>>> _______________________________________________ >>>>>> netext mailing list >>>>>> netext@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netext >>>>>=20 >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From sfaccin@rim.com Wed Feb 9 09:14:03 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD18F3A67D8 for ; Wed, 9 Feb 2011 09:14:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.872 X-Spam-Level: X-Spam-Status: No, score=-4.872 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTwcNOVgMh-V for ; Wed, 9 Feb 2011 09:14:02 -0800 (PST) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 65B5D3A67C2 for ; Wed, 9 Feb 2011 09:14:01 -0800 (PST) X-AuditID: 0a401fcb-b7b81ae0000009d7-83-4d52cb622e6e Received: from XCH139CNC.rim.net ( [10.65.10.235]) by mhs03ykf.rim.net (RIM Mail) with SMTP id 9D.99.02519.26BC25D4; Wed, 9 Feb 2011 12:14:10 -0500 (EST) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH139CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Feb 2011 12:14:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" content-transfer-encoding: base64 Date: Wed, 9 Feb 2011 11:14:06 -0600 Message-ID: <680854867F7FD04BB9B06EB8ACA8D5AC05EFEC2B@XCH02DFW.rim.net> In-Reply-To: <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6D206@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvIBJiHT6pTC5AuTLiPxUHd+1cGXgAai07QAANlc4A= References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com><843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6D206@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> From: "Stefano Faccin" To: "MELIA, TELEMACO (TELEMACO)" , "Julien Laganier" , "Tran Minh Trung" X-OriginalArrivalTime: 09 Feb 2011 17:14:10.0800 (UTC) FILETIME=[C479AF00:01CBC87C] X-Brightmail-Tracker: AAAAAgAAAZEXVNa5 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 17:14:03 -0000 VGVsZW1hY28sDQpBdCB0aGUgcmlzayBvZiBzb3VuZGluZyBhd2Z1bGx5IHJlcGV0aXRpdmUs IEkgbXVzdCBkaXNhZ3JlZSBvbiB0aGUgIiBpdCBpcyByZWFkeSB0byByZWNlaXZlIHRyYWZm aWMgb24gYW55IG9mIHRoZSBpbnRlcmZhY2VzIHJpZ2h0Ii4gRXNwZWNpYWxseSBiZWNhdXNl IHlvdSBhcmUgaW1wbHlpbmcgImFueSB0cmFmZmljIi4gT25jZSBhZ2FpbiwgdGhlIGN1cnJl bnQgc29sdXRpb24gZG9lcyBub3Qgc3VwcG9ydCB0aGUgc2NlbmFyaW9zIGN1cnJlbnRseSBz dXBwb3J0ZWQgaW4gM0dQUCB3ZXJlIHRoZSBkZWNpc2lvbiBvbiBJUCBmbG93IHJvdXRpbmcg Y2FuIGJlIGJhc2VkIG9uIHRoZSBzcGVjaWZpYyBhY2Nlc3MgbmV0d29yayAoZS5nLiBTU0lE KSB3cnQgYWNjZXNzIHRlY2hub2xvZ3kuIEkgc3RpbGwgaGF2ZSBub3QgaGVhcmQgYW4gYW5z d2VyIG9uIHdoeSB3ZSB0aGluayBpdCB3b3VsZCBiZSB3b3J0aCBwcm9wb3NpbmcgYSBzb2x1 dGlvbiB0aGF0IGdpdmVzIGxlc3MgZnVuY3Rpb25hbGl0eSB0aGFuIHdoYXQgaXMgb3V0IHRo ZXJlIGFuZCBkb2VzIG5vdCBtZWV0IHJlYWwgdXNlIGNhc2Ugc2NlbmFyaW9zIGxpa2UgdGhl IG9uZXMgSSBkZXNjcmliZWQgYmVmb3JlLiBJIGFsc28gaGF2ZSBub3QgaGVhcmQgYW55Ym9k eSBkZW1vbnN0cmF0aW5nIG1lIHRoYXQgdGhlIHVzZSBjYXNlcyBJIHJhaXNlZCBhcmUgcmVh bCBhbmQgdmVyeSBjdXJyZW50LiANCg0KQ2hlZXJzLA0KDQpTdGVmYW5vIEZhY2Npbg0KDQpT dGFuZGFyZHMgTWFuYWdlcg0KUmVzZWFyY2ggSW4gTW90aW9uIENvcnBvcmF0aW9uIA0KNTAw MCBSaXZlcnNpZGUgRHJpdmUgDQpCdWlsZGluZyA2LCBCcmF6b3MgRWFzdCwgU3RlLiAxMDAN CklydmluZywgVGV4YXMgNzUwMzkgVVNBIA0KT2ZmaWNlOiAoOTcyKSA5MTAgMzQ1McKgIA0K SW50ZXJuYWw6IDgyMC42MzQ1MQ0KOiAoNTEwKSAyMzAgODQyMg0Kd3d3LnJpbS5jb207IHd3 dy5ibGFja2JlcnJ5LmNvbSANCg0KDQoNCu+BkCBDb25zaWRlciB0aGUgZW52aXJvbm1lbnQg YmVmb3JlIHByaW50aW5nLg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBuZXRleHQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5ldGV4dC1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgTUVMSUEsIFRFTEVNQUNPIChURUxFTUFDTykNClNlbnQ6IFdl ZG5lc2RheSwgRmVicnVhcnkgMDksIDIwMTEgNzozNSBBTQ0KVG86IEp1bGllbiBMYWdhbmll cjsgVHJhbiBNaW5oIFRydW5nDQpDYzogbmV0ZXh0QGlldGYub3JnOyBCYXNhdmFyYWouUGF0 aWxAbm9raWEuY29tDQpTdWJqZWN0OiBSZTogW25ldGV4dF0gQ29uc2Vuc3VzIGNhbGwgdG8g YWRvcHQgSS1EOmRyYWZ0LWJlcm5hcmRvcy1uZXRleHQtcG1pcHY2LWZsb3dtb2IgYXMgV0cg ZG9jDQoNCldoeT8gSWYgdGhlIHRlcm1pbmFsIGlzIGNvbm5lY3RlZCBhbmQgcmFkaW8gY292 ZXJhZ2UgaXMgb2sgaXQgYWxzbyBtZWFucyBpdCBpcyByZWFkeSB0byByZWNlaXZlIHRyYWZm aWMgb24gYW55IG9mIHRoZSBpbnRlcmZhY2VzIHJpZ2h0PyBVcCB0aGUgTE1BIHRvIHJvdXRl IGZsb3dzLg0KDQp0ZWxlbWFjbw0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRl wqA6IG5ldGV4dC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bmV0ZXh0LWJvdW5jZXNAaWV0 Zi5vcmddIERlIGxhIHBhcnQgZGUgSnVsaWVuIExhZ2FuaWVyDQpFbnZvecOpwqA6IG1lcmNy ZWRpIDkgZsOpdnJpZXIgMjAxMSAwMzo1NA0Kw4DCoDogVHJhbiBNaW5oIFRydW5nDQpDY8Kg OiBuZXRleHRAaWV0Zi5vcmc7IEJhc2F2YXJhai5QYXRpbEBub2tpYS5jb20NCk9iamV0wqA6 IFJlOiBbbmV0ZXh0XSBDb25zZW5zdXMgY2FsbCB0byBhZG9wdCBJLUQ6ZHJhZnQtYmVybmFy ZG9zLW5ldGV4dC1wbWlwdjYtZmxvd21vYiBhcyBXRyBkb2MNCg0KQ2hhbmdpbmcgdGhlIHBv bGljeSBvbiB0aGUgbmV0d29yayBzaWRlIGFsb25lIGlzbid0IHN1ZmZpY2llbnQuIFlvdSdk DQpoYXZlIHRvIGNoYW5nZSB0aGUgcG9saWN5IG9uIHRoZSBob3N0LCB0b28gKGUuZy4sIHVz aW5nIEFETlNGIGluIDNHUFApDQp3aGljaCB3aWxsIHRyaWdnZXIgdGhlIE1OIHRvIGF0dGFj aCBJRjEgdG8gc2Vzc2lvbiAyLg0KDQpUaGlzIGlzIHRoZSBzeXN0ZW0gdmlldyBwaWN0dXJl IHdoaWNoIHNlZW1zIHdlJ3JlIG1pc3NpbmcgaW4gdGhpcyBkaXNjdXNzaW9uLg0KDQotLWp1 bGllbg0KDQpPbiBUdWUsIEZlYiA4LCAyMDExIGF0IDY6NDkgUE0sIFRyYW4gTWluaCBUcnVu ZyA8dHJ1bmd0bTI5MDlAZ21haWwuY29tPiB3cm90ZToNCj4gSGkgSnVsaWVuLA0KPg0KPiBM ZXQgbWUgc2hvdyBhIHJlYWwgY2FzZSBmb3IgdGhlIHNjZW5hcmlvIHRoYXQgd2UgYXJlIGRp c2N1c3NpbmcgYmVsbG93Og0KPg0KPiBUaGUgbmV0d29yayBwb2xpY3kgaXMgY2hhbmdlZCBh bmQgdGhlIExNQSBkZWNpZGVzIHRvIG1vdmUgZmxvdyAyIGZyb20NCj4gSUYyIHRvIElGMSBi ZWZvcmUgTUFHMSByZWNlaXZlZCBMMiB0cmlnZ2VyIGZyb20gdGhlIE1OIChzYXkgYmVmb3Jl DQo+IHN0ZXAgIzgpDQo+IEluIHRoYXQgY2FzZSwgdGhlIExNQSBzaG91bGQgc2lnbmFsIE1B RzEgdG8gc2VuZCBQQlUgdG8gYXR0YWNoIElGMSB0bw0KPiBzZXNzaW9uIDIuDQo+DQo+IFdp dGhvdXQgc2lnbmFsaW5nIGZyb20gTE1BIGhvdyBjYW4geW91IGRvIGluIHRoaXMgY2FzZT8g SnVzdCB3YWl0DQo+IHVudGlsIHJlY2VpdmluZyBMMiB0cmlnZ2VyIGZyb20gdGhlIE1OPw0K Pg0KPiBPbiBXZWQsIEZlYiA5LCAyMDExIGF0IDc6MTggQU0sIEp1bGllbiBMYWdhbmllciA8 anVsaWVuLmlldGZAZ21haWwuY29tPiB3cm90ZToNCj4+IEhpIFBpZXJyaWNrLA0KPj4NCj4+ IEkgYW0gZ29pbmcgdG8gaW50ZXJ0d2luZSB0aGUgc3RlcHMgaW4geW91ciBzY2VuYXJpbyBi ZWxvdyB3aXRoIHRoZQ0KPj4gbWlzc2luZyBwaWVjZXMgb2YgdGhlIGJpZyBwaWN0dXJlIHNv IHRoYXQgd2UgYXJlIG5vdCBkb2luZyBhbiBhY2FkZW1pYw0KPj4gZXhlcmNpc2UgYnV0IGZv Y3VzaW5nIG9uIHRoZSByZWFsIHdvcmxkOg0KPj4NCj4+IDEuIHdoZW4gdGhlIE1OIGZpcnN0 IGF0dGFjaGVzIHdpdGggaWYxIHRvIGEgbmV0d29yaywgTUFHMSByZXF1ZXN0cw0KPj4gYXR0 YWNobWVudCBvZiBpZjEgdG8gYSBzZXNzaW9uMSBieSBzZW5kaW5nIGEgUEJVIHRvIExNQQ0K Pj4NCj4+IDIuIGJlY2F1c2UgdGhlIE1OIGFkZCBubyBzZXNzaW9uMSBwcmV2aW91c2x5LCB0 aGUgTE1BIGNyZWF0ZXMgc2Vzc2lvbg0KPj4gMSBhbmQgYWxsb2NhdGVzIGEgcHJlZml4IGZv ciBpdC4gVGhlIHByZWZpeCBpcyBzZW50IGJhY2sgdG8gTUFHMSBpbg0KPj4gdGhlIFBCQToN Cj4+DQo+PiDCoMKgIMKgIMKgIMKgIMKgU2Vzc2lvbjE6IFtQcmVmMSwgTUFHMS1JRjFdDQo+ Pg0KPj4gMy4gdGhlbiwgaWYgdGhlIE1OIGF0dGFjaGVzIHdpdGggaWYyIHRvIGFub3RoZXIg bmV0d29yaywgYnV0IGRvZXMgbm90DQo+PiByZXF1ZXN0IHRoaXMgaW50ZXJmYWNlIGJlIGF0 dGFjaGVkIHRvIGEgZGlzdGluY3Qgc2Vzc2lvbiwgTUFHMg0KPj4gcmVxdWVzdHMgYXR0YWNo ZW1udCBvZiBJZjIgdG8gc2Vzc2lvbjEgYnkgc2VuZGluZyBhIFBCVSB0byBMTUENCj4+DQo+ PiA0LiBCZWNhdXNlIHRoZSBNTiBhbHJlYWR5IGhhcyBzZXNzaW9uIDEsIHRoZSBMTUEgdXBk YXRlcyBzZXNzaW9uMSB3aXRoDQo+PiBpZjIsIGFuZCBzZW5kIHRoZSBwcmVmMSBiYWNrIHRv IE1BRzIgaW4gdGhlIFBCQToNCj4+DQo+PiDCoMKgIMKgIMKgIMKgIFNlc3Npb24xOiBbUHJl ZjEsIE1BRzEtSUYxLCBNQUcyLUlGMl0NCj4+DQo+PiA1LiBDcmVhdGlvbiBvZiBhIG5ldyBz ZXNzaW9uIDIgZm9yIGlmMiBpcyByZXF1ZXN0ZWQgYnkgZWl0aGVyIG9mIE1ODQo+PiByZXF1 ZXN0cyB2aWEgTDIgdHJpZ2dlcnMsIG9yIGEgY2hhbmdlIGluIHBvbGljeSBwcm9maWxlLiBB cyBhIHJlc3VsdCwNCj4+IE1BRzIgcmVxdWVzdHMgYXR0YWNobWVudCBvZiBpZjIgdG8gc2Vz c2lvbjIgYnkgc2VuZGluZyBhIFBCVSB0byBMTUEuDQo+Pg0KPj4gNi4gYmVjYXVzZSB0aGUg TU4gYWRkIG5vIHNlc3Npb24yIHByZXZpb3VzbHksIHRoZSBMTUEgY3JlYXRlcyBzZXNzaW9u DQo+PiAyIGFuZCBhbGxvY2F0ZXMgYSBwcmVmaXggZm9yIGl0LiBUaGUgcHJlZml4IHByZWYy IGlzIHNlbnQgYmFjayB0byBNQUcyDQo+PiBpbiB0aGUgUEJBOg0KPj4NCj4+IMKgwqAgwqAg wqAgwqAgwqBTZXNzaW9uMjogW1ByZWYyLCBNQUcyLUlGMl0NCj4+DQo+PiA3LiBGbG93MiBz dGFydHMgb3ZlciBpZjIgd2l0aCBwcmVmaXgyLg0KPj4NCj4+IDguIEF0dGFjaG1lbnQgb2Yg aWYxIHRvIHNlc3Npb24yIGlzIHJlcXVlc3RlZCBieSBlaXRoZXIgb2YgTU4gcmVxdWVzdHMN Cj4+IHZpYSBMMiB0cmlnZ2Vycywgb3IgYSBjaGFuZ2UgaW4gcG9saWN5IHByb2ZpbGUuIEFz IGEgcmVzdWx0LCBNQUcxDQo+PiByZXF1ZXN0cyBhdHRhY2htZW50IG9mIGlmMSB0byBzZXNz aW9uMiBieSBzZW5kaW5nIGEgUEJVIHRvIExNQS4NCj4+DQo+PiA5LiBCZWNhdXNlIHRoZSBN TiBhbHJlYWR5IGhhcyBzZXNzaW9uIDIsIHRoZSBMTUEgdXBkYXRlcyBzZXNzaW9uMiB3aXRo IGlmMToNCj4+DQo+PiDCoMKgIMKgIMKgIMKgIFNlc3Npb24yOiBbUHJlZjIsIE1BRzItSUYy LCBNQUcxLUlGMV0NCj4+DQo+PiAxMC4gQXQgYW55IHBvaW50LCB0aGUgTE1BIGRlY2lkZXMg dG8gbW92ZSBGbG93MiBiZXR3ZWVuIHR3byBpbnRlcmZhY2VzDQo+PiBvZiBzZXNzaW9uIDIs IGFuZCBpdCBkb2VzIHNvLg0KPj4NCj4+IFRoYXQncyBhbGwgdGhhdCBuZWVkZWQuIEl0IG1h cHMgcGVyZmVjdGx5IHRvIDNHUFAuIElmIHlvdSBoYXZlIGluIG1pbmQNCj4+IGEgZGlmZmVy ZW50IHN5c3RlbSBpbiB3aGNpaCB0aGF0IGRvZXNuJ3QgbWFwLCBwbGVhc2UgbGV0IG1lIGtu b3cuDQo+Pg0KPj4gLS1qdWxpZW4NCj4+DQo+PiBPbiBUdWUsIEZlYiA4LCAyMDExIGF0IDg6 MjUgQU0sIMKgPHBpZXJyaWNrLnNlaXRlQG9yYW5nZS1mdGdyb3VwLmNvbT4gd3JvdGU6DQo+ Pj4gSGksDQo+Pj4NCj4+PiBHb2luZyB0aHJvdWdoIHRoaXMgbG9uZyB0aHJlYWQgOi0pLCBp dCBzZWVtcyB3ZSBjb3VsZCBhZ3JlZSBvbiB0aGUgZm9sbG93aW5nIChqdXN0IGEgdGVudGF0 aXZlIHRvIHN1bW1hcml6ZSk6DQo+Pj4NCj4+PiBTZXNzaW9ucyBzaG91bGQgYmUgY3JlYXRl ZC91cGRhdGVkIHdpdGggYWxsIGF2YWlsYWJsZSBpbnRlcmZhY2VzLiBSZXdyaXRpbmcgVHJh bidzIGV4YW1wbGU6IHdoZW4gdGhlIE1OIGF0dGFjaGVzIHRvIE1BRzEgdmlhIElmMSwgdGhl IExNQSBjcmVhdGVzIHNlc3Npb24gMToNCj4+Pg0KPj4+IMKgIMKgIMKgIMKgIMKgU2Vzc2lv bjE6IFtQcmVmMSwgTUFHMSwgSUYxXQ0KPj4+DQo+Pj4gVGhlbiwgaWYgdGhlIE1OIGF0dGFj aGVzIHRvIE1BRzIgdmlhIElmMiwgdGhlIExNQSBjcmVhdGVzIHNlc3Npb24gMiB3aXRoIGJv dGggSWYxIGFuZCBJZjIuIFRoZSBMTUEgYWxzbyB1cGRhdGVzIHNlc3Npb24gMSB3aXRoIElm MjoNCj4+Pg0KPj4+IMKgIMKgIMKgIMKgIFNlc3Npb24xOiBbUHJlZjEsIE1BRzEsIElGMSwg SUYyXQ0KPj4+IMKgIMKgIMKgIMKgIFNlc3Npb24yOiBbUHJlZjIsIE1BRzIsIElGMiwgSUYx XQ0KPj4+DQo+Pj4gTUFHMiByZWNlaXZlcyBwcmVmaXhlcyAxIGFuZCAyIGluIFBCQSBidXQg TUFHMSBpcyBub3Qgc2VuZGluZyBQQlUuIFNvLCBpZiB0aGUgTE1BIHdhbnRzIHRvIG1vdmUg ZmxvdyB3aXRoIFByZWYyIGZyb20gaWYyIHRvIElmMSwgdGhlIExNQSBuZWVkcyB0byBwcm92 aWRlIFByZWYyIHRvIE1BRzEuIEFsc28sIHRoZSBMTUEgc2hvdWxkIGJlIGFibGUgdG8gY3Jl YXRlIG5ldyBzZXNzaW9ucyB3aXRoIGFscmVhZHkgdXAgaW50ZXJmYWNlcywgZS5nLiBpZjEg YW5kIGlmMi4gVG8gYWRkcmVzcyBib3RoIGlzc3VlcywgUEJVIGZyb20gTUFHMSBjb3VsZCBi ZSB0cmlnZ2VyZWQgKHRyaWdnZXJpbmcgaXMgdG8gYmUgY2xhcmlmaWVkKSBvciB3ZSBjb3Vs ZCBkZWZpbmUgTE1BL01BRyBzcGVjaWZpYyBMMyBzaWduYWxsaW5nIChGTUkvRk1BKS4NCj4+ Pg0KPj4+IE15IDIgY2VudHMsDQo+Pj4gUGllcnJpY2sNCj4+Pg0KPj4+PiAtLS0tLU1lc3Nh Z2UgZCdvcmlnaW5lLS0tLS0NCj4+Pj4gRGXCoDogbmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpuZXRleHQtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydA0KPj4+PiBkZSBZ b3VuLUhlZSBIYW4NCj4+Pj4gRW52b3nDqcKgOiBtYXJkaSA4IGbDqXZyaWVyIDIwMTEgMTI6 MDANCj4+Pj4gw4DCoDogJ0p1bGllbiBMYWdhbmllcic7ICdSYWplZXYgS29vZGxpJw0KPj4+ PiBDY8KgOiBuZXRleHRAaWV0Zi5vcmc7IEJhc2F2YXJhai5QYXRpbEBub2tpYS5jb20NCj4+ Pj4gT2JqZXTCoDogUmU6IFtuZXRleHRdIENvbnNlbnN1cyBjYWxsIHRvIGFkb3B0IEktRDpk cmFmdC1iZXJuYXJkb3MtbmV0ZXh0LQ0KPj4+PiBwbWlwdjYtZmxvd21vYiBhcyBXRyBkb2MN Cj4+Pj4NCj4+Pj4gSGkgSnVsaWVuLA0KPj4+Pg0KPj4+PiA+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+Pj4+ID4gRnJvbTogbmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpuZXRleHQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+Pj4+ID4gT2YgSnVsaWVu IExhZ2FuaWVyDQo+Pj4+ID4gU2VudDogVHVlc2RheSwgRmVicnVhcnkgMDgsIDIwMTEgMToz OCBQTQ0KPj4+PiA+IFRvOiBSYWplZXYgS29vZGxpDQo+Pj4+ID4gQ2M6IG5ldGV4dEBpZXRm Lm9yZzsgQmFzYXZhcmFqLlBhdGlsQG5va2lhLmNvbQ0KPj4+PiA+IFN1YmplY3Q6IFJlOiBb bmV0ZXh0XSBDb25zZW5zdXMgY2FsbCB0byBhZG9wdCBJLUQ6IGRyYWZ0LWJlcm5hcmRvcy0N Cj4+Pj4gPiBuZXRleHQtcG1pcHY2LWZsb3dtb2IgYXMgV0cgZG9jDQo+Pj4+ID4NCj4+Pj4g PiBPbiBNb24sIEZlYiA3LCAyMDExIGF0IDY6MTUgUE0sIFJhamVldiBLb29kbGkgPHJrb29k bGlAY2lzY28uY29tPiB3cm90ZToNCj4+Pj4gPiA+DQo+Pj4+ID4gPiBJZiBmbG93IG1vYmls aXR5IGhhcyBub3RoaW5nIGRvIHdpdGggcHJlZml4IG1hbmFnZW1lbnQsIEkgYW0gbG9zdC4N Cj4+Pj4gPg0KPj4+PiA+IE5vIHJlYXNvbiB0byBiZSBsb3N0OiBQcmVmaXggbWFuYWdlbWVu dCBpcyBob3cgZG8gSSBnZXQgcHJlZml4IGZvciB0aGUNCj4+Pj4gPiBNTi4gRmxvdyBtb2Jp bGl0eSBpcyBob3cgdG8gSSBtb3ZlIGZsb3dzIGFjcm9zcyBpbnRlcmZhY2VzLiBUaGUgdHdv DQo+Pj4+ID4gbmVlZHMgbm90IHRvIGJlIGludGVydHdpbmVkIHRvZ2V0aGVyLCBhcyBJJ3Zl IHNob3duIGluIG15IG90aGVyIG5vdGVzLg0KPj4+PiA+IEUuZy4sIEkgY2FuIGRvIGZsb3cg bW9iaWxpdHkgd2l0aG91dCBhZGRpbmcvZGVsZXRpbmcgcHJlZml4ZXMgZnJvbQ0KPj4+PiA+ IHNlc3Npb25zLCBhbmQgdmljZSB2ZXJzYS4NCj4+Pj4NCj4+Pj4gWWVzLCBJIGFncmVlIHdp dGggeW91LiBGbG93IG1vYmlsaXR5IGlzIGhvdyB0byBtb3ZlIGZsb3dzIGFjcm9zcyBpbnRl cmZhY2UuDQo+Pj4+IFNvLCBJIHRob3VnaHQgdGhhdCBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8g ZGVmaW5lICJhIGZsb3ciIGV4YWN0bHkgaW4gbmV0ZXh0DQo+Pj4+IFdHIHByaW9yIHRvIGRp c2N1c3MgZmxvdyBtb2JpbGl0eSBtYW5hZ2VtZW50LiBBcyB0aGUgZGVmaW5pdGlvbiBvZiAi YQ0KPj4+PiBmbG93IiwNCj4+Pj4gYWxsIEkgY2FuIHRoaW5rIGlzIGEgZml2ZS10dXBsZSBw bHVzIHNvbWV0aGluZy4gSWYgd2UgYXNzdW1lIHRoYXQgaXQgaXMNCj4+Pj4gY29ycmVjdCwg SSB0aGluayB0aGF0IGZsb3cgbW9iaWxpdHkgYW5kIHByZWZpeCBhZGRpdGlvbiBhcmUgaW5l dml0YWJseQ0KPj4+PiB0aWVkLg0KPj4+PiBBcyB5b3Uga25vdywgUkZDNTIxMyAoYW5kIElQ djYgcHJvdG9jb2wgc3BlYykgYWxyZWFkeSBhbGxvdyB0byBhc3NpZ24NCj4+Pj4gbXVsdGlw bGUgcHJlZml4ZXMgYWNyb3NzIG11bHRpcGxlIGludGVyZmFjZXMgb2YgYW4gTU4uIFllcywg SSBhbHNvIGFncmVlDQo+Pj4+IHdpdGggeW91IHRoYXQgaW4gcmVhbC13b3JsZCAoM0dQUCks IHRoZXJlIG1heSBiZSBubyBuZWVkIHRvIGFzc2lnbg0KPj4+PiBtdWx0aXBsZQ0KPj4+PiBw cmVmaXhlcyBpbnRvIGFuIE1OLiAoaWYgc29tZWJvZHkga25vd3MgaXRzIG5lY2Vzc2l0eSwg cGxlYXNlIHRlbGwgbWUgd2hlbg0KPj4+PiBpdCBzaG91bGQgaGFwcGVuKS4gU28sIGZsb3cg bW9iaWxpdHkgY2FuIGJlIGRvbmUgd2l0aG91dCBhZGRpbmcgcHJlZml4ZXMuDQo+Pj4+IEhv d2V2ZXIsIGRpZmZlcmVudCBpbnRlcmZhY2VzIGFyZSBhbGxvd2VkIHRvIGJlIGFzc2lnbmVk IGRpZmZlcmVudA0KPj4+PiBwcmVmaXhlcw0KPj4+PiBieSBSRkMgNTIxMyBhbmQgSVB2NiBz cGVjLiBXZSBjYW4ndCBleHBlY3Qgd2hhdCBraW5kIG9mIHByZWZpeGVzIGFuIE1BRw0KPj4+ PiBhZHZlcnRpc2VzLiBUaGVyZWZvcmUsIHNvbWV0aW1lcywgd2UgbmVlZCBwcmVmaXggYWRk aXRpb24gdG8gbW92ZSBhIGZsb3cNCj4+Pj4gdG8NCj4+Pj4gYSBuZXcgaW50ZXJmYWNlIG9m IHdoaWNoIE1BRyBkb2VzIG5vdCB5ZXQgYWR2ZXJ0aXNlIHRoZSBwcmVmaXggb2YgdGhlIGZs b3cNCj4+Pj4gYmVpbmcgbW92ZWQuDQo+Pj4+DQo+Pj4+IChzbmlwLi4uKQ0KPj4+Pg0KPj4+ PiA+ID4+IEkgc2VlIG5vIHJlYXNvbiB0byBkZXBhcnQgZnJvbSB0aGF0IGluIHRoZSBjb250 ZXh0IG9mIGV4dGVuZGluZyB0aGUNCj4+Pj4gPiA+PiBwcm90b2NvbCB0byBzdXBwb3J0IG1v YmlsaXR5LCBub3IgSSBhbSBhd2FyZSBvZiBhbnkgc3lzdGVtDQo+Pj4+ID4gPj4gYXJjaGl0 ZWN0dXJlIHRoYXQgd291bGQgcmVxdWlyZSB0aGlzIGNhcGFiaWxpdHkuDQo+Pj4+ID4gPg0K Pj4+PiA+ID4gT2theSwgc2VlIHlvdXIgcG9zaXRpb24uIEkgc2VlIGl0IGRpZmZlcmVudGx5 LiBJIGRvbid0IG5lZWQgdG8gYmUNCj4+Pj4gPiA+IGJvdW5kIGJ5IHNvbWUgInByZXN1bWVk IGltcGxlbWVudGF0aW9uIG1vZGVsIiBvZiBQTUlQNiBhbmQgbGltaXQNCj4+Pj4gPiA+IG15 c2VsZiAqb25seSogdG8gYSBwcmVmaXggYXNzaWdubWVudCBtb2RlbCB5b3UgYXJlIGltYWdp bmluZy4NCj4+Pj4gPg0KPj4+PiA+IEl0J3Mgbm90IGFuIGltcGxlbWVudGF0aW9uIG1vZGVs LCBpdCBpcyBhIHByb3RvY29sIG1vZGVsLCBhbmQgaXQncyBub3QNCj4+Pj4gPiBpbWFnaW5h cnkuIEltcGxlbWVudGF0aW9uIGhhcyBub3RoaW5nIHRvIGRvIHdpdGggdGhpcy4NCj4+Pj4g Pg0KPj4+PiA+IFRoZXJlJ3Mgbm8gcmVhc29uIHRvIGV4dGVuZCBwcmVmaXggYXNzaWdubWVu dCBtb2RlbCB0byBkbyBmbG93IG1vYmlsaXR5DQo+Pj4+ID4gdW5sZXNzIHlvdSBjYW4gcG9p bnQgbWUgb3V0IGluIHdoaWNoIHJlYWwgd29ybGQgY29udGV4dCB5b3VyIHNjZW5hcmlvDQo+ Pj4+ID4gYWN0dWFsbHkgaGFwcGVucy4NCj4+Pj4NCj4+Pj4gQXMgSSBpbnNpc3RlZCBpbiB0 aGUgb2xkIG1haWwsIEkgYWdyZWUgd2l0aCBKdWxpZW4gaW4gdGhpcyByZWdhcmQuIEN1cnJl bnQNCj4+Pj4gZHJhZnQgYWxsb3dzIHRvbyBtdWNoIHNwYWNlIHJlZ2FyZGluZyB0aGUgcHJl Zml4IGFsbG9jYXRpb24gbW9kZWwgKHVuaXF1ZSwNCj4+Pj4gc2hhcmVkLCBhbmQgaHlicmlk KS4gV2hlbiBhIGZsb3cgc2hvdWxkIGJlIG1vdmVkIHRvIGEgbmV3IGludGVyZmFjZSBhbmQN Cj4+Pj4gdGhlDQo+Pj4+IHByZWZpeCB3aGljaCB0aGUgZmxvdyB1c2VzIGlzIG5vdCB5ZXQg YWR2ZXJ0aXNlZCBieSB0aGUgbmV3IE1BRywganVzdA0KPj4+PiBpbmZvcm0NCj4+Pj4gdGhl IHByZWZpeCB0byB0aGUgTUFHIGFuZCB0aHVzIG1ha2UgaXQgYWR2ZXJ0aXNlIHRoZSBwcmVm aXggYW5kIHNldHVwIHRoZQ0KPj4+PiB0dW5uZWwgYmFzZWQgb24gdGhlIG5ldyBwcmVmaXgu IFRoYXQncyBhbGwhLiBJZiB0aGUgcHJlZml4IGlzIGFscmVhZHkNCj4+Pj4gYWR2ZXJ0aXNl ZCBieSB0aGUgTUFHLCB0aGVyZSBpcyBub3RoaW5nIHRvIGRvIGFuZCBqdXN0IG1vdmUgdGhl IGZsb3cuIFRoaXMNCj4+Pj4gYmVoYXZpb3JzIGFyZSB2ZXJ5IG5hdHVyYWwgb25lIHdoZW4g d2Ugd2FudCB0byBzdXBwb3J0IElQLWxldmVsIG1vYmlsaXR5Lg0KPj4+Pg0KPj4+PiA+ID4+ IElmIHRoaXMgaXMgc29tZXRoaW5nIHJlYWxseSBpbXBvcnRhbnQsIHRoZSBXRyBjYW4gYmUg cmVjaGFydGVyZWQgdG8NCj4+Pj4gPiA+PiB3b3JrIG9uIGEgZGlmZmVyZW50IGV4dGVuc2lv biB0aGF0IHdvdWxkIGFsbG93IGFkZGluZy9yZW1vdmluZw0KPj4+PiA+ID4+IHByZWZpeGVz IGZyb20gZXhpc3RpbmcgUE1JUHY2IHNlc3Npb25zLg0KPj4+PiA+ID4NCj4+Pj4gPiA+IEh1 aC4uIFdoYXQgaW4gdGhlIGN1cnJlbnQgY2hhcnRlciBmb3JjZXMgdXMgbm90IHRvIGhhdmUg dGhlIExNQQ0KPj4+PiA+ID4gYWRkL3JlZnJlc2gvZGVsZXRlIGEgcHJlZml4IG9uLWRlbWFu ZD8NCj4+Pj4gPg0KPj4+PiA+IEVuZ2luZWVyaW5nIGlzIGFib3V0IGZpbmRpbmcgYSBzb2x1 dGlvbiB0byBhIHByb2JsZW0uIEFkZGluZy9kZWxldGluZw0KPj4+PiA+IHByZWZpeCBvbi1k ZW1hbmQgaXMgbm90IGEgc29sdXRpb24gdG8gZmxvdyBtb2JpbGl0eS4gSSd2ZSBzaG93biB5 b3UgaG93DQo+Pj4+ID4gdG8gZG8gZmxvdyBtb2JpbGl0eSB3aXRob3V0IHRoaXMgY2FwYWJp bGl0eS4NCj4+Pj4NCj4+Pj4gRnJvbSB0aGUgdmlld3BvaW50IG9mIHByb3RvY29sLCBJIHRo aW5rIHRoYXQgYXQgbGVhc3QsIHByZWZpeCBhZGRpdGlvbiB0bw0KPj4+PiBhbg0KPj4+PiBp bnRlcmZhY2UgaXMgYSBuZWNlc3NhcnkgZnVuY3Rpb24gdG8gc3VwcG9ydCBmbG93IG1vYmls aXR5LCBhcyBJIGV4cGxhaW5lZA0KPj4+PiBhYm92ZS4gQnV0LCBpdCBkb2VzIG5vdCBtZWFu IHByZWZpeCBhZGRpdGlvbiBzaG91bGQgaGFwcGVuIGFsd2F5cyB3aGVuZXZlcg0KPj4+PiBm bG93IG1vYmlsaXR5IG9jY3Vycy4gSXQgaXMgc29tZXRpbWVzIG5lZWRlZC4NCj4+Pj4NCj4+ Pj4gPiBOb3cgYSBkaWZmZXJlbnQgZW5naW5lZXJpbmcgcHJvYmxlbSB3b3VsZCBiZTogaG93 IHRvIGFkZC9kZWxldGUgcHJlZml4ZXMNCj4+Pj4gPiB0byBhIFBNSVB2NiBzZXNzaW9uLCBh bmQgdGhhdCB3b3VsZCBiZSB1c2VmdWwgZm9yIGUuZy4NCj4+Pj4gPiByZW51bWJlcmluZy4g VGhpcyBpcyBhIGRpZmZlcmVudCBwcm9ibGVtIHRoYXQgd2UgaGF2ZW4ndCBiZWVuIGNoYXJ0 ZXJlZA0KPj4+PiA+IHRvIHdvcmsgb24uDQo+Pj4+DQo+Pj4+IFByZWZpeCBhZGRpdGlvbiBp cyBqdXN0IHByZWZpeCBhZGRpdGlvbi4gSU1ITywgcmVudW1iZXJpbmcgaXMgY2xvc2VyIHRv DQo+Pj4+IHByZWZpeCBjaGFuZ2UuIFdlIGp1c3QgaGFybmVzcyB0aGF0IGZ1bmN0aW9uIHRv IHN1cHBvcnQgSVAtbGV2ZWwgbW9iaWxpdHkuDQo+Pj4+DQo+Pj4+IFlvdW4tSGVlDQo+Pj4+ DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4+IG5ldGV4dCBtYWlsaW5nIGxpc3QNCj4+Pj4gbmV0ZXh0QGlldGYub3JnDQo+Pj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0DQo+Pj4NCj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBu ZXRleHQgbWFpbGluZyBsaXN0DQo+PiBuZXRleHRAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0DQo+Pg0KPg0KPg0KPg0KPiAtLQ0K PiBQaC5ELiwgU2VuaW9yIE1lbWJlcg0KPiBFbGVjdHJvbmljcyBhbmQgVGVsZWNvbW11bmlj YXRpb25zIFJlc2VhcmNoIEluc3RpdHV0ZQ0KPiBTdGFuZGFyZHMgUmVzZWFyY2ggQ2VudGVy DQo+IDE2MSBHYWplb25nLURvbmcsIFl1c2VvbmctR3UsIERhZWplb24sIDMwNS0zNTAsIEtP UkVBDQo+IFRlbCA6ICs4Mi00Mi04NjAtMTEzMizCoMKgIEZheCA6ICs4Mi00Mi04NjEtNTQw NA0KPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cm5ldGV4dCBtYWlsaW5nIGxpc3QNCm5ldGV4dEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRleHQNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRleHQgbWFpbGluZyBsaXN0DQpuZXRleHRA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0 DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQpUaGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBh dHRhY2htZW50cykgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLCBwcml2 aWxlZ2VkIG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0ZXJpYWwgcHJvdGVjdGVkIGJ5IHRoZSBz b2xpY2l0b3ItY2xpZW50IG9yIG90aGVyIGFwcGxpY2FibGUgcHJpdmlsZWdlcyksIG9yIGNv bnN0aXR1dGUgbm9uLXB1YmxpYyBpbmZvcm1hdGlvbi4gQW55IHVzZSBvZiB0aGlzIGluZm9y bWF0aW9uIGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMg cHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4g ZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIGFuZCBkZWxl dGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lzdGVtLiBVc2UsIGRpc3NlbWluYXRp b24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9u IGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50cyBpcyBub3QgYXV0aG9yaXplZCBhbmQgbWF5IGJl IHVubGF3ZnVsLg0K From Basavaraj.Patil@nokia.com Wed Feb 9 09:19:27 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F2373A69E2 for ; Wed, 9 Feb 2011 09:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.313 X-Spam-Level: X-Spam-Status: No, score=-103.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4FsdIb91aU5 for ; Wed, 9 Feb 2011 09:19:26 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 024263A69DE for ; Wed, 9 Feb 2011 09:19:25 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p19HJJwN002645; Wed, 9 Feb 2011 19:19:30 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Feb 2011 19:19:21 +0200 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 9 Feb 2011 18:19:21 +0100 Received: from 008-AM1MPN1-005.mgdnok.nokia.com ([169.254.4.149]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi; Wed, 9 Feb 2011 18:19:21 +0100 From: To: , , , Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLw9OSrYVyQtqZEUGfFOgnrCkRuZPwNUIAgAAmFoCAAAk+AP///QSAgAAJMwD///0SgIAAMdcAgAAUO4CAAOjnAIAABrwAgAAm0oCAATmcAIABvD4AgAAHZICAAAUSAIAABSYAgAGrNICAABNEAIAAIoyAgAAQuQCAAATrAIAACvoAgAAqUYCAAUICAIAAHSaAgAAOPYCAAAICAIAA2VuAgAAe4QD//56AAA== Date: Wed, 9 Feb 2011 17:19:14 +0000 Message-ID: In-Reply-To: <680854867F7FD04BB9B06EB8ACA8D5AC05EFEC1B@XCH02DFW.rim.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 Content-Type: text/plain; charset="utf-8" Content-ID: <457fce37-9ef8-43fe-8131-ea92d5ebb9a4> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 09 Feb 2011 17:19:21.0468 (UTC) FILETIME=[7DA5DBC0:01CBC87D] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 17:19:27 -0000 DQpTdGVmYW5vLA0KDQpMZXRzIG5vdCB0YWxrIGFib3V0IEFSUFUgb3Igb3RoZXIgYXNwZWN0cyBv ZiBvcGVyYXRvciBpc3N1ZXMgd2hpY2ggYXJlIElNTw0Kbm90IHJlYWxseSBoZWxwaW5nIHRoaXMg ZGlzY3Vzc2lvbi4NCg0KQnV0IHJlZ2FyZGluZyB0aGUgcXVlc3Rpb24gb2Ygd2hldGhlciB0aGVy ZSBpcyBhbiBvcGVuIGFuZCBkZWNsYXJlZA0KY3VzdG9tZXIsIEkgZG9u4oCZdCBrbm93IGlmIHRo ZSBXRyByZWFsbHkgbmVlZHMgdG8gYW5zd2VyIHRoYXQuDQpUaGUgcG9pbnQgaXMgdGhhdCB3ZSBo YXZlIGRlZmluZWQgYSBuZXR3b3JrIGJhc2VkIG1vYmlsaXR5IHByb3RvY29sDQooUkZDNTIxMykg aW4gdGhlIElFVEYuIFRoZXJlIGlzIGEgY29tbXVuaXR5IG9mIHBlb3BsZSBpbiB0aGUgV0cgd2hp Y2gNCmJlbGlldmVzIHRoYXQgZXh0ZW5kaW5nIHRoZSBwcm90b2NvbCB0byBzdXBwb3J0IGZsb3cg bW9iaWxpdHkgd2lsbCBhZGRyZXNzDQpzb21lIHNjZW5hcmlvcyBhbmQgdXNlIGNhc2VzLiBUaGUg YXBwbGljYWJpbGl0eSAgb2Ygc3VjaCBhIGZlYXR1cmUgaW4gM0dQUA0KYXJjaGl0ZWN0dXJlcyBp cyB0byBzb21lIGV4dGVudCBvcGVuLg0KSSB0aGluayB3ZSBzaG91bGQgYmUgZG9pbmcgdGhlIHdv cmsgYW5kIHNwZWNpZnlpbmcgdGhlIHNvbHV0aW9uLg0KVW5kZXJzdGFuZGluZyB0aGUgdXNlIGNh c2VzIGZvciB0aGUgZmVhdHVyZSBpcyBnb29kLiBCdXQgSSB0aGluayB3ZSBkbyBub3QNCmhhdmUg dG8gZ28gb3ZlcmJvYXJkIGluIHRlcm1zIG9mIHZlcmlmeWluZyB0aGUgY3VzdG9tZXIgZXhpc3Rl bmNlIG9yDQppbnRlcmVzdC4NCg0KLVJhag0KDQpPbiAyLzkvMTEgMTE6MDggQU0sICJleHQgU3Rl ZmFubyBGYWNjaW4iIDxzZmFjY2luQHJpbS5jb20+IHdyb3RlOg0KDQo+VGVsZW1hY28sDQo+QWxs IHRoYXQgeW91IHNheSBpcyBnb29kLCBhcGFydCBmcm9tIG9uZSBkZXRhaWwuIEkgZG8gbm90IGJl bGlldmUgdGhhdA0KPmhlcmUgaW4gSUVURiB3ZSBzaG91bGQgYmUgdGFsa2luZyBhYm91dCBBUlBV IGFuZCBjb3N0cyBhbmQgc28gb24uIFdlIGFyZQ0KPmp1c3Qgbm90IGNhcGFibGUgb2YgZXZhbHVh dGluZyB0aGVtLiBJZiBpbmRlZWQgYXMgeW91IHNheSB0aGlzIHNvbHV0aW9uDQo+d2VyZSB0aGUg bWFnaWMgYW5zd2VyIHRvIG9wZXJhdG9yIGlzc3VlcywgSSBhbSBzdXJlIG9wZXJhdG9ycyBpbiAz R1BQDQo+d291bGQgaGF2ZSBzaG93biBhIGJpZ2dlciBpbnRlcmVzdCBpbiBpdC4gTXkgcHJldmlv dXMgcXVlc3Rpb24gb24gd2hldGhlcg0KPndlIGhhdmUgYW4gb3BlbiBhbmQgZGVjbGFyZWQgY3Vz dG9tZXIgZm9yIHRoaXMgc29sdXRpb24gKGkuZS4gdGhhdA0KPmNsZWFybHkgc3RhdGVkIHRoaXMg aXMgbmVlZGVkKSBpcyBzdGlsbCB1bmFuc3dlcmVkLCBzbyBwZXJoYXBzIHRoZXJlDQo+aXNuJ3Qg aW5kZWVkIHN1Y2ggYW4gaW50ZXJlc3QgaW4gdGhpcyBtYWdpYyBzb2x1dGlvbj8NCj5DaGVlcnMs DQo+U3RlZmFubyBGYWNjaW4NCj4NCj5TdGFuZGFyZHMgTWFuYWdlcg0KPlJlc2VhcmNoIEluIE1v dGlvbiBDb3Jwb3JhdGlvbg0KPjUwMDAgUml2ZXJzaWRlIERyaXZlDQo+QnVpbGRpbmcgNiwgQnJh em9zIEVhc3QsIFN0ZS4gMTAwDQo+SXJ2aW5nLCBUZXhhcyA3NTAzOSBVU0ENCj5PZmZpY2U6ICg5 NzIpIDkxMCAzNDUxDQo+SW50ZXJuYWw6IDgyMC42MzQ1MQ0KPjogKDUxMCkgMjMwIDg0MjINCj53 d3cucmltLmNvbTsgd3d3LmJsYWNrYmVycnkuY29tDQo+DQo+DQo+DQo+74GQIENvbnNpZGVyIHRo ZSBlbnZpcm9ubWVudCBiZWZvcmUgcHJpbnRpbmcuDQo+DQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj5Gcm9tOiBuZXRleHQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5ldGV4dC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj5PZiBNRUxJQSwgVEVMRU1BQ08gKFRFTEVNQUNP KQ0KPlNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDksIDIwMTEgNzoxOCBBTQ0KPlRvOiBKdWxp ZW4gTGFnYW5pZXI7IGNqYmNAaXQudWMzbS5lcw0KPkNjOiBuZXRleHRAaWV0Zi5vcmc7IEJhc2F2 YXJhai5QYXRpbEBub2tpYS5jb20NCj5TdWJqZWN0OiBSZTogW25ldGV4dF0gQ29uc2Vuc3VzIGNh bGwgdG8gYWRvcHQgSS1EOg0KPmRyYWZ0LWJlcm5hcmRvcy1uZXRleHQtcG1pcHY2LWZsb3dtb2Ig YXMgV0cgZG9jDQo+DQo+QnV0IHdoeSB3ZSBjYW5ub3QgZGVzaWduIGEgbW9kZWwgd2hlcmUgd2Ug Y2FuIGR5bmFtaWNhbGx5IGdyb3VwIHNlc3Npb25zPw0KPk1vYmlsZSBvcGVyYXRvcnMgaGF2ZSBi ZWVuIGZpZ2h0aW5nIGhhcmQgaW4gdGhlIHBhc3QgeWVhcnMgdGhlDQo+ZGlzY29ubmVjdGlvbiBi ZXR3ZWVuIEFSUFUgYW5kIGFzc29jaWF0ZWQgY29zdCBwZXIgdXNlcnMgKGluIG90aGVyIHdvcmRz DQo+Y29zdHMgaW5jcmVhc2UgYnV0IHJldmVudWVzIGNvbnRpbnVlIHRvIGZhbGwpLiBEYXRhIGV4 cGxvc2lvbiBpcyBvbmUgb2YNCj50aGUgcmVhc29ucyBmb3Igc3VjaCBkaXNjb25uZWN0aW9uLg0K PkkgYmVsaWV2ZSB0aGF0IG5ldHdvcmsgb3BlcmF0b3JzIHdvdWxkIGJlIGVhZ2VyIHRvIGxlYXJu IGFib3V0IGlubm92YXRpbmcNCj50ZWNobm9sb2dpZXMgdG8gcmVkdWNlIGNvc3RzIGV4cGVuZGl0 dXJlcy4gVGhlIHdvcmsgd2UgYXJlIHB1c2hpbmcgd2l0aA0KPnRoaXMgSUQgZmFsbHMgZXhhY3Rs eSBpbiB0aGlzIGNhdGVnb3J5LiBSZXN0cmljdGluZyB0byB0aGUgbGVnYWN5IFBNSVB2Ng0KPm1v ZGVsIGlzIGEgbGltaXRhdGlvbi4NCj4NCj5JIHdvdWxkIGJlIGdsYWQgdG8gaGVhciBvcGluaW9u cyBmcm9tIG90aGVyIChkaWZmZXJlbnQpIHZvaWNlcy4NCj4NCj50ZWxlbWFjbw0KPg0KPi0tLS0t TWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPkRlIDogbmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzpuZXRleHQtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydA0KPmRlIEp1bGllbiBMYWdh bmllcg0KPkVudm95w6kgOiBtZXJjcmVkaSA5IGbDqXZyaWVyIDIwMTEgMDM6MjANCj7DgCA6IGNq YmNAaXQudWMzbS5lcw0KPkNjIDogQmFzYXZhcmFqLlBhdGlsQG5va2lhLmNvbTsgbmV0ZXh0QGll dGYub3JnDQo+T2JqZXQgOiBSZTogW25ldGV4dF0gQ29uc2Vuc3VzIGNhbGwgdG8gYWRvcHQgSS1E Og0KPmRyYWZ0LWJlcm5hcmRvcy1uZXRleHQtcG1pcHY2LWZsb3dtb2IgYXMgV0cgZG9jDQo+DQo+ SGkgQ2FybG9zLA0KPg0KPjIwMTEvMi84IENhcmxvcyBKZXPDunMgQmVybmFyZG9zIENhbm8gPGNq YmNAaXQudWMzbS5lcz46DQo+PiBIaSBKdWxpZW4sDQo+Pg0KPj4gT24gVHVlLCAyMDExLTAyLTA4 IGF0IDE3OjIxIC0wODAwLCBKdWxpZW4gTGFnYW5pZXIgd3JvdGU6DQo+Pj4gSGkgQ2FybG9zLA0K Pj4+DQo+Pj4gSSBhbSBnbGFkIHRvIHNlZSB5b3UgYWdyZWUgd2l0aCBtZSA6LSkNCj4+Pg0KPj4+ IFlvdSdyZSBhY3R1YWxseSBwcm92aW5nIG15IHBvaW50Lg0KPj4+DQo+Pj4gVG8gcnVuIGFueSBv ZiB0aGUgZmxvdyBtb2JpbGl0eSBzdHVmZiBvbiBhIGhvc3QsIHlvdSB3aWxsIG5lZWQgZWl0aGVy DQo+Pj4gbGF5ZXIgMiB0byBoaWRlIHRoZSBkaXNzaW1pbGFyIGludGVyZmFjZXMgKHZpcnR1YWwg aW50ZXJmYWNlIHRoaW5nKSwNCj4+PiBpbiB3aGljaCBjYXNlIHlvdSBkbyBoYXZlIEwyIHRyaWdn ZXJzLCBvciB0byBtb2RpZnkgdGhlIGxheWVyIDMsIHdoaWNoDQo+Pj4gdGhpcyBXRyBpcyBleHBs aWNpdGx5IHByZXZlbnRlZCBmcm9tIGRvaW5nIGFzc3VtaW5nIHRoYXQncyBldmVuDQo+Pj4gcG9z c2libGUuDQo+Pj4NCj4+PiBTbyB5b3UgbmVlZCBsYXllciAyLiBBbmQgdGhhdCBpcyBhY3R1YWxs eSBleGFjdGx5IGhvdyBuZXRleHQgY291bGQgZ2V0DQo+Pj4gY2hhcnRlcmVkIHRvIHdvcmsgb24g ZmxvdyBtb2JpbGl0eSwgYmVjYXVzZSB3ZSBhc3N1bWVkIGxheWVyIDIgd291bGQNCj4+PiBiZSB0 aGVyZSB0byBoZWxwIHdpdGggYWxsIHRoZSBzdHVmZiB3ZSdyZSBub3QgYWxsb3dlZCB0byBkbyBh dCBsYXllcg0KPj4+IDMuDQo+Pg0KPj4gRXhhY3RseSwgeW91IG5lZWQgbGF5ZXIgMiB0byBoZWxw IHdpdGggYWxsIHRoZSBzdHVmZiB3ZSBhcmUgbm90IGFsbG93ZWQNCj4+IHRvIGRvIGF0IGxheWVy IDMsIF9idXRfIG5vdCB0byBkbyB0aGluZ3MgdGhhdCB3ZSBkb24ndCBuZWVkIHRvIGRvIGF0IHRo ZQ0KPj4gTU4sIGFuZCBjYW4gYmUgdHJpdmlhbGx5IGRvbmUgd2l0aCBMTUEtTUFHIHNpZ25hbGlu ZyB3aXRob3V0IHB1dHRpbmcNCj4+IHN0cm9uZyByZXF1aXJlbWVudHMgb24gdGhlIGxheWVyIDIu DQo+Pg0KPj4gVGhlIHNpZ25hbGluZyB3ZSBkZWZpbmUgaW4gb3VyIGRyYWZ0IChvciB2YXJpYXRp b25zIGFyb3VuZCB0aGF0KSBhbGxvd3MNCj4+IHRvIHN1cHBvcnQgYWxsIHRoZSBzY2VuYXJpb3Mg dGhhdCBoYXZlIGJlZW4gbWVudGlvbmVkIHNvIGZhciwgYW5kIGRvZXMNCj4+IG5vdCBicmVhayBh bnkgUE1JUHY2IGNvbmNlcHQgLS0ganVzdCBleHRlbmRzIGl0LiBJdCBkb2VzIG5vdCByZXF1aXJl DQo+PiBjb21wbGV4IGxheWVyIDIgdHJpZ2dlcnMvcG9saWNpZXMgdG8gYmUgaW4gcGxhY2UgYW5k IGl0J3MgdGhlcmVmb3JlIG1vcmUNCj4+IGxheWVyLTIgYWdub3N0aWMuIFN0aWxsLCB5b3UgcHJl ZmVycyB0byBnbyBmb3IgdGhlICJsZXRzIHJlZG8gTUlQIGF0DQo+PiBsYXllci0yIiwgYW5kIEkg a2VlcCBmYWlsaW5nIHRvIHNlZSB3aHkNCj4NCj5QTUlQdjYgYXMgcGVyIFJGQzUyMTMgZG9lc24n dCB3b3JrIHdpdGhvdXQgTDIgdHJpZ2dlcnMsIHNvIHRoZXJlJ3Mgbm8NCj52YWx1ZSBpbiBleHRl bmRpbmcgUE1JUHY2IHRvIHNwYXJlIHJlbHlpbmcgb24gTDIgdHJpZ2dlcnMgdGhhdCBhcmUNCj5y ZXF1aXJlZCBhbnl3YXkuDQo+DQo+LS1qdWxpZW4NCj4NCj4tLWp1bGllbg0KPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bmV0ZXh0IG1haWxpbmcgbGlz dA0KPm5ldGV4dEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0ZXh0DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj5uZXRleHQgbWFpbGluZyBsaXN0DQo+bmV0ZXh0QGlldGYub3JnDQo+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRleHQNCj4NCj4tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj5UaGlz IHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5IGNvbnRhaW4gY29u ZmlkZW50aWFsDQo+aW5mb3JtYXRpb24sIHByaXZpbGVnZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBt YXRlcmlhbCBwcm90ZWN0ZWQgYnkgdGhlDQo+c29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBs aWNhYmxlIHByaXZpbGVnZXMpLCBvciBjb25zdGl0dXRlDQo+bm9uLXB1YmxpYyBpbmZvcm1hdGlv bi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5IGFueW9uZSBvdGhlciB0aGFuDQo+dGhl IGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzDQo+dHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8g dGhlIHNlbmRlciBhbmQgZGVsZXRlDQo+dGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lzdGVt LiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3INCj5yZXByb2R1Y3Rpb24gb2Yg dGhpcyB0cmFuc21pc3Npb24gYnkgdW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdA0KPmF1dGhv cml6ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4NCg0K From sfaccin@rim.com Wed Feb 9 09:22:10 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFC2C3A67B5 for ; Wed, 9 Feb 2011 09:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.843 X-Spam-Level: X-Spam-Status: No, score=-5.843 tagged_above=-999 required=5 tests=[AWL=0.756, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjGi39QYqDxn for ; Wed, 9 Feb 2011 09:22:07 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 2A39D3A67D1 for ; Wed, 9 Feb 2011 09:22:07 -0800 (PST) X-AuditID: 0a666446-b7b81ae000000a21-c3-4d52cd48a17d Received: from XCH139CNC.rim.net ( [10.65.10.235]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 33.0E.02593.84DC25D4; Wed, 9 Feb 2011 12:22:16 -0500 (EST) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH139CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Feb 2011 12:22:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" content-transfer-encoding: base64 Date: Wed, 9 Feb 2011 11:22:12 -0600 Message-ID: <680854867F7FD04BB9B06EB8ACA8D5AC05EFEC38@XCH02DFW.rim.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLw9OSrYVyQtqZEUGfFOgnrCkRuZPwNUIAgAAmFoCAAAk+AP///QSAgAAJMwD///0SgIAAMdcAgAAUO4CAAOjnAIAABrwAgAAm0oCAATmcAIABvD4AgAAHZICAAAUSAIAABSYAgAGrNICAABNEAIAAIoyAgAAQuQCAAATrAIAACvoAgAAqUYCAAUICAIAAHSaAgAAOPYCAAAICAIAA2VuAgAAe4QD//56AAAAOty4Q References: <680854867F7FD04BB9B06EB8ACA8D5AC05EFEC1B@XCH02DFW.rim.net> From: "Stefano Faccin" To: , , , X-OriginalArrivalTime: 09 Feb 2011 17:22:16.0606 (UTC) FILETIME=[E609CBE0:01CBC87D] X-Brightmail-Tracker: AAAAAgAAAZEXVNa5 Cc: netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 17:22:11 -0000 UmFqLA0KRmluZSB3aXRoIG5vdCB0YWxraW5nIGFib3V0IEFSUFUgKHRoYXQncyBleGFjdGx5 IHdoYXQgSSBzYWlkIGJlbG93KS4NCg0KQXMgZm9yIHRoZSBjdXN0b21lciwgSSBjb3VsZCBs aXZlIHdpdGggd2hhdCB5b3Ugc2F5LiBIb3dldmVyLCBJIGJlbGlldmUgd2UgbmVlZCB0byBh ZGRyZXNzIHVzZSBjYXNlcyB0aGF0IHdvdWxkIGFsbG93IHRoZSBzb2x1dGlvbiB0byBiZSB1 c2FibGUgYnkgYSBjdXN0b21lciB0aGF0IGlzIGFscmVhZHkgYWRvcHRpbmcgYW4gYWx0ZXJu YXRpdmUgc29sdXRpb24uIElmIHdoYXQgTmV0ZXh0IHByb2R1Y2VzIGNhbm5vdCBwcm92aWRl IHRoZSBzYW1lIHNlcnZpY2UsIHdoeSB3b3VsZCBhIGN1c3RvbWVyIGhhdmUgYW55IGludGVy ZXN0IGluIGFkb3B0aW5nIHQ/IFRvIHByb3ZpZGUgbGVzcyBzZXJ2aWNlIHRvIHRoZSBNTnM/ DQoNCkNoZWVycywgDQoNClN0ZWZhbm8gRmFjY2luDQoNClN0YW5kYXJkcyBNYW5hZ2VyDQpS ZXNlYXJjaCBJbiBNb3Rpb24gQ29ycG9yYXRpb24gDQo1MDAwIFJpdmVyc2lkZSBEcml2ZSAN CkJ1aWxkaW5nIDYsIEJyYXpvcyBFYXN0LCBTdGUuIDEwMA0KSXJ2aW5nLCBUZXhhcyA3NTAz OSBVU0EgDQpPZmZpY2U6ICg5NzIpIDkxMCAzNDUxwqAgDQpJbnRlcm5hbDogODIwLjYzNDUx DQo6ICg1MTApIDIzMCA4NDIyDQp3d3cucmltLmNvbTsgd3d3LmJsYWNrYmVycnkuY29tIA0K DQoNCg0K74GQIENvbnNpZGVyIHRoZSBlbnZpcm9ubWVudCBiZWZvcmUgcHJpbnRpbmcuDQoN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJhc2F2YXJhai5QYXRpbEBu b2tpYS5jb20gW21haWx0bzpCYXNhdmFyYWouUGF0aWxAbm9raWEuY29tXSANClNlbnQ6IFdl ZG5lc2RheSwgRmVicnVhcnkgMDksIDIwMTEgOToxOSBBTQ0KVG86IFN0ZWZhbm8gRmFjY2lu OyB0ZWxlbWFjby5tZWxpYUBhbGNhdGVsLWx1Y2VudC5jb207IGp1bGllbi5pZXRmQGdtYWls LmNvbTsgY2piY0BpdC51YzNtLmVzDQpDYzogbmV0ZXh0QGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW25ldGV4dF0gQ29uc2Vuc3VzIGNhbGwgdG8gYWRvcHQgSS1EOiBkcmFmdC1iZXJuYXJk b3MtbmV0ZXh0LXBtaXB2Ni1mbG93bW9iIGFzIFdHIGRvYw0KDQoNClN0ZWZhbm8sDQoNCkxl dHMgbm90IHRhbGsgYWJvdXQgQVJQVSBvciBvdGhlciBhc3BlY3RzIG9mIG9wZXJhdG9yIGlz c3VlcyB3aGljaCBhcmUgSU1PDQpub3QgcmVhbGx5IGhlbHBpbmcgdGhpcyBkaXNjdXNzaW9u Lg0KDQpCdXQgcmVnYXJkaW5nIHRoZSBxdWVzdGlvbiBvZiB3aGV0aGVyIHRoZXJlIGlzIGFu IG9wZW4gYW5kIGRlY2xhcmVkDQpjdXN0b21lciwgSSBkb27igJl0IGtub3cgaWYgdGhlIFdH IHJlYWxseSBuZWVkcyB0byBhbnN3ZXIgdGhhdC4NClRoZSBwb2ludCBpcyB0aGF0IHdlIGhh dmUgZGVmaW5lZCBhIG5ldHdvcmsgYmFzZWQgbW9iaWxpdHkgcHJvdG9jb2wNCihSRkM1MjEz KSBpbiB0aGUgSUVURi4gVGhlcmUgaXMgYSBjb21tdW5pdHkgb2YgcGVvcGxlIGluIHRoZSBX RyB3aGljaA0KYmVsaWV2ZXMgdGhhdCBleHRlbmRpbmcgdGhlIHByb3RvY29sIHRvIHN1cHBv cnQgZmxvdyBtb2JpbGl0eSB3aWxsIGFkZHJlc3MNCnNvbWUgc2NlbmFyaW9zIGFuZCB1c2Ug Y2FzZXMuIFRoZSBhcHBsaWNhYmlsaXR5ICBvZiBzdWNoIGEgZmVhdHVyZSBpbiAzR1BQDQph cmNoaXRlY3R1cmVzIGlzIHRvIHNvbWUgZXh0ZW50IG9wZW4uDQpJIHRoaW5rIHdlIHNob3Vs ZCBiZSBkb2luZyB0aGUgd29yayBhbmQgc3BlY2lmeWluZyB0aGUgc29sdXRpb24uDQpVbmRl cnN0YW5kaW5nIHRoZSB1c2UgY2FzZXMgZm9yIHRoZSBmZWF0dXJlIGlzIGdvb2QuIEJ1dCBJ IHRoaW5rIHdlIGRvIG5vdA0KaGF2ZSB0byBnbyBvdmVyYm9hcmQgaW4gdGVybXMgb2YgdmVy aWZ5aW5nIHRoZSBjdXN0b21lciBleGlzdGVuY2Ugb3INCmludGVyZXN0Lg0KDQotUmFqDQoN Ck9uIDIvOS8xMSAxMTowOCBBTSwgImV4dCBTdGVmYW5vIEZhY2NpbiIgPHNmYWNjaW5Acmlt LmNvbT4gd3JvdGU6DQoNCj5UZWxlbWFjbywNCj5BbGwgdGhhdCB5b3Ugc2F5IGlzIGdvb2Qs IGFwYXJ0IGZyb20gb25lIGRldGFpbC4gSSBkbyBub3QgYmVsaWV2ZSB0aGF0DQo+aGVyZSBp biBJRVRGIHdlIHNob3VsZCBiZSB0YWxraW5nIGFib3V0IEFSUFUgYW5kIGNvc3RzIGFuZCBz byBvbi4gV2UgYXJlDQo+anVzdCBub3QgY2FwYWJsZSBvZiBldmFsdWF0aW5nIHRoZW0uIElm IGluZGVlZCBhcyB5b3Ugc2F5IHRoaXMgc29sdXRpb24NCj53ZXJlIHRoZSBtYWdpYyBhbnN3 ZXIgdG8gb3BlcmF0b3IgaXNzdWVzLCBJIGFtIHN1cmUgb3BlcmF0b3JzIGluIDNHUFANCj53 b3VsZCBoYXZlIHNob3duIGEgYmlnZ2VyIGludGVyZXN0IGluIGl0LiBNeSBwcmV2aW91cyBx dWVzdGlvbiBvbiB3aGV0aGVyDQo+d2UgaGF2ZSBhbiBvcGVuIGFuZCBkZWNsYXJlZCBjdXN0 b21lciBmb3IgdGhpcyBzb2x1dGlvbiAoaS5lLiB0aGF0DQo+Y2xlYXJseSBzdGF0ZWQgdGhp cyBpcyBuZWVkZWQpIGlzIHN0aWxsIHVuYW5zd2VyZWQsIHNvIHBlcmhhcHMgdGhlcmUNCj5p c24ndCBpbmRlZWQgc3VjaCBhbiBpbnRlcmVzdCBpbiB0aGlzIG1hZ2ljIHNvbHV0aW9uPw0K PkNoZWVycywNCj5TdGVmYW5vIEZhY2Npbg0KPg0KPlN0YW5kYXJkcyBNYW5hZ2VyDQo+UmVz ZWFyY2ggSW4gTW90aW9uIENvcnBvcmF0aW9uDQo+NTAwMCBSaXZlcnNpZGUgRHJpdmUNCj5C dWlsZGluZyA2LCBCcmF6b3MgRWFzdCwgU3RlLiAxMDANCj5JcnZpbmcsIFRleGFzIDc1MDM5 IFVTQQ0KPk9mZmljZTogKDk3MikgOTEwIDM0NTENCj5JbnRlcm5hbDogODIwLjYzNDUxDQo+ OiAoNTEwKSAyMzAgODQyMg0KPnd3dy5yaW0uY29tOyB3d3cuYmxhY2tiZXJyeS5jb20NCj4N Cj4NCj4NCj7vgZAgQ29uc2lkZXIgdGhlIGVudmlyb25tZW50IGJlZm9yZSBwcmludGluZy4N Cj4NCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IG5ldGV4dC1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86bmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs Zg0KPk9mIE1FTElBLCBURUxFTUFDTyAoVEVMRU1BQ08pDQo+U2VudDogV2VkbmVzZGF5LCBG ZWJydWFyeSAwOSwgMjAxMSA3OjE4IEFNDQo+VG86IEp1bGllbiBMYWdhbmllcjsgY2piY0Bp dC51YzNtLmVzDQo+Q2M6IG5ldGV4dEBpZXRmLm9yZzsgQmFzYXZhcmFqLlBhdGlsQG5va2lh LmNvbQ0KPlN1YmplY3Q6IFJlOiBbbmV0ZXh0XSBDb25zZW5zdXMgY2FsbCB0byBhZG9wdCBJ LUQ6DQo+ZHJhZnQtYmVybmFyZG9zLW5ldGV4dC1wbWlwdjYtZmxvd21vYiBhcyBXRyBkb2MN Cj4NCj5CdXQgd2h5IHdlIGNhbm5vdCBkZXNpZ24gYSBtb2RlbCB3aGVyZSB3ZSBjYW4gZHlu YW1pY2FsbHkgZ3JvdXAgc2Vzc2lvbnM/DQo+TW9iaWxlIG9wZXJhdG9ycyBoYXZlIGJlZW4g ZmlnaHRpbmcgaGFyZCBpbiB0aGUgcGFzdCB5ZWFycyB0aGUNCj5kaXNjb25uZWN0aW9uIGJl dHdlZW4gQVJQVSBhbmQgYXNzb2NpYXRlZCBjb3N0IHBlciB1c2VycyAoaW4gb3RoZXIgd29y ZHMNCj5jb3N0cyBpbmNyZWFzZSBidXQgcmV2ZW51ZXMgY29udGludWUgdG8gZmFsbCkuIERh dGEgZXhwbG9zaW9uIGlzIG9uZSBvZg0KPnRoZSByZWFzb25zIGZvciBzdWNoIGRpc2Nvbm5l Y3Rpb24uDQo+SSBiZWxpZXZlIHRoYXQgbmV0d29yayBvcGVyYXRvcnMgd291bGQgYmUgZWFn ZXIgdG8gbGVhcm4gYWJvdXQgaW5ub3ZhdGluZw0KPnRlY2hub2xvZ2llcyB0byByZWR1Y2Ug Y29zdHMgZXhwZW5kaXR1cmVzLiBUaGUgd29yayB3ZSBhcmUgcHVzaGluZyB3aXRoDQo+dGhp cyBJRCBmYWxscyBleGFjdGx5IGluIHRoaXMgY2F0ZWdvcnkuIFJlc3RyaWN0aW5nIHRvIHRo ZSBsZWdhY3kgUE1JUHY2DQo+bW9kZWwgaXMgYSBsaW1pdGF0aW9uLg0KPg0KPkkgd291bGQg YmUgZ2xhZCB0byBoZWFyIG9waW5pb25zIGZyb20gb3RoZXIgKGRpZmZlcmVudCkgdm9pY2Vz Lg0KPg0KPnRlbGVtYWNvDQo+DQo+LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+RGUg OiBuZXRleHQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5ldGV4dC1ib3VuY2VzQGlldGYu b3JnXSBEZSBsYSBwYXJ0DQo+ZGUgSnVsaWVuIExhZ2FuaWVyDQo+RW52b3nDqSA6IG1lcmNy ZWRpIDkgZsOpdnJpZXIgMjAxMSAwMzoyMA0KPsOAIDogY2piY0BpdC51YzNtLmVzDQo+Q2Mg OiBCYXNhdmFyYWouUGF0aWxAbm9raWEuY29tOyBuZXRleHRAaWV0Zi5vcmcNCj5PYmpldCA6 IFJlOiBbbmV0ZXh0XSBDb25zZW5zdXMgY2FsbCB0byBhZG9wdCBJLUQ6DQo+ZHJhZnQtYmVy bmFyZG9zLW5ldGV4dC1wbWlwdjYtZmxvd21vYiBhcyBXRyBkb2MNCj4NCj5IaSBDYXJsb3Ms DQo+DQo+MjAxMS8yLzggQ2FybG9zIEplc8O6cyBCZXJuYXJkb3MgQ2FubyA8Y2piY0BpdC51 YzNtLmVzPjoNCj4+IEhpIEp1bGllbiwNCj4+DQo+PiBPbiBUdWUsIDIwMTEtMDItMDggYXQg MTc6MjEgLTA4MDAsIEp1bGllbiBMYWdhbmllciB3cm90ZToNCj4+PiBIaSBDYXJsb3MsDQo+ Pj4NCj4+PiBJIGFtIGdsYWQgdG8gc2VlIHlvdSBhZ3JlZSB3aXRoIG1lIDotKQ0KPj4+DQo+ Pj4gWW91J3JlIGFjdHVhbGx5IHByb3ZpbmcgbXkgcG9pbnQuDQo+Pj4NCj4+PiBUbyBydW4g YW55IG9mIHRoZSBmbG93IG1vYmlsaXR5IHN0dWZmIG9uIGEgaG9zdCwgeW91IHdpbGwgbmVl ZCBlaXRoZXINCj4+PiBsYXllciAyIHRvIGhpZGUgdGhlIGRpc3NpbWlsYXIgaW50ZXJmYWNl cyAodmlydHVhbCBpbnRlcmZhY2UgdGhpbmcpLA0KPj4+IGluIHdoaWNoIGNhc2UgeW91IGRv IGhhdmUgTDIgdHJpZ2dlcnMsIG9yIHRvIG1vZGlmeSB0aGUgbGF5ZXIgMywgd2hpY2gNCj4+ PiB0aGlzIFdHIGlzIGV4cGxpY2l0bHkgcHJldmVudGVkIGZyb20gZG9pbmcgYXNzdW1pbmcg dGhhdCdzIGV2ZW4NCj4+PiBwb3NzaWJsZS4NCj4+Pg0KPj4+IFNvIHlvdSBuZWVkIGxheWVy IDIuIEFuZCB0aGF0IGlzIGFjdHVhbGx5IGV4YWN0bHkgaG93IG5ldGV4dCBjb3VsZCBnZXQN Cj4+PiBjaGFydGVyZWQgdG8gd29yayBvbiBmbG93IG1vYmlsaXR5LCBiZWNhdXNlIHdlIGFz c3VtZWQgbGF5ZXIgMiB3b3VsZA0KPj4+IGJlIHRoZXJlIHRvIGhlbHAgd2l0aCBhbGwgdGhl IHN0dWZmIHdlJ3JlIG5vdCBhbGxvd2VkIHRvIGRvIGF0IGxheWVyDQo+Pj4gMy4NCj4+DQo+ PiBFeGFjdGx5LCB5b3UgbmVlZCBsYXllciAyIHRvIGhlbHAgd2l0aCBhbGwgdGhlIHN0dWZm IHdlIGFyZSBub3QgYWxsb3dlZA0KPj4gdG8gZG8gYXQgbGF5ZXIgMywgX2J1dF8gbm90IHRv IGRvIHRoaW5ncyB0aGF0IHdlIGRvbid0IG5lZWQgdG8gZG8gYXQgdGhlDQo+PiBNTiwgYW5k IGNhbiBiZSB0cml2aWFsbHkgZG9uZSB3aXRoIExNQS1NQUcgc2lnbmFsaW5nIHdpdGhvdXQg cHV0dGluZw0KPj4gc3Ryb25nIHJlcXVpcmVtZW50cyBvbiB0aGUgbGF5ZXIgMi4NCj4+DQo+ PiBUaGUgc2lnbmFsaW5nIHdlIGRlZmluZSBpbiBvdXIgZHJhZnQgKG9yIHZhcmlhdGlvbnMg YXJvdW5kIHRoYXQpIGFsbG93cw0KPj4gdG8gc3VwcG9ydCBhbGwgdGhlIHNjZW5hcmlvcyB0 aGF0IGhhdmUgYmVlbiBtZW50aW9uZWQgc28gZmFyLCBhbmQgZG9lcw0KPj4gbm90IGJyZWFr IGFueSBQTUlQdjYgY29uY2VwdCAtLSBqdXN0IGV4dGVuZHMgaXQuIEl0IGRvZXMgbm90IHJl cXVpcmUNCj4+IGNvbXBsZXggbGF5ZXIgMiB0cmlnZ2Vycy9wb2xpY2llcyB0byBiZSBpbiBw bGFjZSBhbmQgaXQncyB0aGVyZWZvcmUgbW9yZQ0KPj4gbGF5ZXItMiBhZ25vc3RpYy4gU3Rp bGwsIHlvdSBwcmVmZXJzIHRvIGdvIGZvciB0aGUgImxldHMgcmVkbyBNSVAgYXQNCj4+IGxh eWVyLTIiLCBhbmQgSSBrZWVwIGZhaWxpbmcgdG8gc2VlIHdoeQ0KPg0KPlBNSVB2NiBhcyBw ZXIgUkZDNTIxMyBkb2Vzbid0IHdvcmsgd2l0aG91dCBMMiB0cmlnZ2Vycywgc28gdGhlcmUn cyBubw0KPnZhbHVlIGluIGV4dGVuZGluZyBQTUlQdjYgdG8gc3BhcmUgcmVseWluZyBvbiBM MiB0cmlnZ2VycyB0aGF0IGFyZQ0KPnJlcXVpcmVkIGFueXdheS4NCj4NCj4tLWp1bGllbg0K Pg0KPi0tanVsaWVuDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj5uZXRleHQgbWFpbGluZyBsaXN0DQo+bmV0ZXh0QGlldGYub3JnDQo+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRleHQNCj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPm5ldGV4dCBtYWlsaW5n IGxpc3QNCj5uZXRleHRAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldGV4dA0KPg0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPlRoaXMgdHJhbnNtaXNz aW9uIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRp YWwNCj5pbmZvcm1hdGlvbiwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVy aWFsIHByb3RlY3RlZCBieSB0aGUNCj5zb2xpY2l0b3ItY2xpZW50IG9yIG90aGVyIGFwcGxp Y2FibGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1dGUNCj5ub24tcHVibGljIGluZm9ybWF0 aW9uLiBBbnkgdXNlIG9mIHRoaXMgaW5mb3JtYXRpb24gYnkgYW55b25lIG90aGVyIHRoYW4N Cj50aGUgaW50ZW5kZWQgcmVjaXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMNCj50cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVs eSByZXBseSB0byB0aGUgc2VuZGVyIGFuZCBkZWxldGUNCj50aGlzIGluZm9ybWF0aW9uIGZy b20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvcg0K PnJlcHJvZHVjdGlvbiBvZiB0aGlzIHRyYW5zbWlzc2lvbiBieSB1bmludGVuZGVkIHJlY2lw aWVudHMgaXMgbm90DQo+YXV0aG9yaXplZCBhbmQgbWF5IGJlIHVubGF3ZnVsLg0KDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQpUaGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2ht ZW50cykgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLCBwcml2aWxlZ2Vk IG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0ZXJpYWwgcHJvdGVjdGVkIGJ5IHRoZSBzb2xpY2l0 b3ItY2xpZW50IG9yIG90aGVyIGFwcGxpY2FibGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1 dGUgbm9uLXB1YmxpYyBpbmZvcm1hdGlvbi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9u IGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGli aXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3Is IHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhp cyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRp c3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9uIGJ5IHVu aW50ZW5kZWQgcmVjaXBpZW50cyBpcyBub3QgYXV0aG9yaXplZCBhbmQgbWF5IGJlIHVubGF3 ZnVsLg0K From sfaccin@rim.com Wed Feb 9 09:24:56 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2FDC3A6981 for ; Wed, 9 Feb 2011 09:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.994 X-Spam-Level: X-Spam-Status: No, score=-5.994 tagged_above=-999 required=5 tests=[AWL=0.605, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lbXZSnaPFdv for ; Wed, 9 Feb 2011 09:24:55 -0800 (PST) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 1E79E3A67D1 for ; Wed, 9 Feb 2011 09:24:55 -0800 (PST) X-AuditID: 0a401fcb-b7b81ae0000009d7-72-4d52cdf09570 Received: from XCH138CNC.rim.net ( [10.65.20.127]) by mhs03ykf.rim.net (RIM Mail) with SMTP id 5A.6A.02519.0FDC25D4; Wed, 9 Feb 2011 12:25:04 -0500 (EST) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH138CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Feb 2011 12:25:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" content-transfer-encoding: base64 Date: Wed, 9 Feb 2011 11:24:35 -0600 Message-ID: <680854867F7FD04BB9B06EB8ACA8D5AC05EFEC3C@XCH02DFW.rim.net> In-Reply-To: <028f01cbc84b$42e13930$c8a3ab90$@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Policy assumptionsin draft-bernardos-netext-pmipv6-flowmob Thread-Index: AQGdzsrCLKJ5OkovNM5bpZXR/mHIagJx5Kj1lEFoivCAAGTh4A== References: <843DA8228A1BA74CA31FB4E111A5C462017D4645@ftrdmel0.rd.francetelecom.fr> <028f01cbc84b$42e13930$c8a3ab90$@gmail.com> From: "Stefano Faccin" To: "Youn-Hee Han" , , , X-OriginalArrivalTime: 09 Feb 2011 17:25:04.0475 (UTC) FILETIME=[4A1892B0:01CBC87E] X-Brightmail-Tracker: AAAAAwAAAZEXVB72F1TWuQ== Subject: Re: [netext] Policy assumptionsin draft-bernardos-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 17:24:56 -0000 R2VudGxlbWVuLA0KQSBxdWVzdGlvbiBmb3IgY2xhcmlmaWNhdGlvbi4gSG93IGRvZXMgYSBN TiB0aGF0IHN1cHBvcnRzIGJvdGggdGhpcyBzb2x1dGlvbiBhbmQgdGhlIGN1cnJlbnQgc3Rh dGUgb2YgdGhlIGFydCBiZWhhdmUgd2hlbiByb2FtaW5nIGJldHdlZW4gbmV0d29ya3MgdGhh dCBzdXBwb3J0IGRpZmZlcmVudCBzb2x1dGlvbnM/IEhvdyBkb2Ugc3RoZSBNTiBrbm93IHdo YXQgaXQgc2hvdWxkIGRvPw0KDQpBbHNvLCBsZXQncyBjb25zaWRlciB0aGUgcm9hbWluZyBj YXNlLiBJIGd1ZXNzIGEgc3Vic2NyaWJlciBvZiBvcGVyYXRvciBBIGlzIHBheWluZyBmb3Ig YSBjZXJ0YWluIHNlcnZpY2UgZnJvbSBvcGVyYXRvciBBIGFuZCBleHBlY3RzIGEgY2VydGFp biBjb25zaXN0ZW5jeSBpbiB0aGUgc2VydmljZSBpdCBpcyByZWNlaXZpbmcuIElmIG5vdyBw b2xpY2llcyBmb3IgdGhlIGNvbnRyb2wgb2YgdGhlIElQIGZsb3cgbW9iaWxpdHkgcmVzaWRl cyBpbiB0aGUgTE1BLCBhbmQgaWYgdGhlIE1OIGlzIHJvYW1pbmcsIGFuZCBpZiB0aGUgTU4g d2FudHMgbG9jYWwgY29ubmVjdGl2aXR5IChpLmUuIHdpdGhvdXQgdGhlIG5lZWQgdG8gZ28g YmFjayB0byB0aGUgaG9tZSBvcGVyYXRvciBjb3JlIG5ldHdvcmspLCB0aGVuIGEgbG9jYWwg TE1BIGlzIG5lZWRlZC4gVGhpcyBpbXBsaWVzIHRoYXQgdGhlIExNQSBvZiB0aGUgdmlzaXRl ZCBvcGVyYXRvciBuZWVkcyB0byBiZSBwcm92aWRlZCB3aXRoIHRoZSBjb3JyZWN0IHBvbGlj aWVzIGJ5IHRoZSBob21lIG9wZXJhdG9yLiBOb3csIEkgYWxyZWFkeSBmaW5kIGl0IGhhcmQg dG8gYmVsaWV2ZSB0aGF0IHRoZSBMTUFzIGluIHRoZSBob21lIG5ldHdvcmsgY2FuIGJlIHBy b3ZpZGVkIHdpdGggdGhlIGNvcnJlY3QgYW5kIHVwIHRvIHNwZWVkIHBlci1zdWJzY3JpYmVy IHBvbGljaWVzIHRvIHByb3ZpZGUgdGhlIGV4cGVjdGVkIHNlcnZpY2UgdG8gdGhlIE1OLiBC dXQsIGlmIExNQXMgaW4gdGhlIHZpc2l0ZWQgb3BlcmF0b3IgbmVlZHMgdG8gYmUgcHJvdmlk ZWQgdGhlIHNhbWUsIHRoZW4gSSBzZWUgYSBzY2FsYWJpbGl0eSBpc3N1ZSBhbmQgZm9yIHRo ZSBzb2x1dGlvbiB0byB3b3JrIHdlIG5lZWQgdG8gbWFrZSByYXRoZXIgbGFyZ2Ugc3lzdGVt LWxldmVsIGFzc3VtcHRpb25zLiBJIGJlbGlldmUgaXQgaXMgZXNzZW50aWFsIHRoYXQgdGhl IHNvbHV0aW9uIGNhbiB3b3JrIGJvdGggZm9yIE1OcyBjb25uZWN0ZWQgdG8gdGhlaXIgaG9t ZSBuZXR3b3JrcyBhbmQgcm9hbWluZyBNTnMuIEluIHRoZSBob3N0LWJhc2VkIG1vZGVsLCBz aW5jZSB0aGUgZGVjaXNpb24gYXJlIG1hZGUgaW4gdGhlIE1OIGJhc2VkIG9uIHBvbGljaWVz IHRoYXQgY2FuIGJlIHByb3Zpc2lvbmVkL2NvbnRyb2xsZWQgYnkgdGhlIGhvbWUgb3BlcmF0 b3IsIHRoZSBNTiBjYW4gbWFrZSB0aGUgYXBwcm9wcmlhdGUgZGVjaXNpb25zIG9uIGhvdyB0 byByb3V0ZSB0cmFmZmljIGJvdGggaWYgdGhlIE1OIGlzIGluIHRoZSBob21lIG5ldHdvcmsg YW5kIGlmIGl0IGlzIGluIHRoZSB2aXNpdGVkIG5ldHdvcmsuIEkgYmVsaWV2ZSB3ZSBuZWVk IHRvIG1hdGNoIHRoZSBzYW1lIGFiaWxpdHkgaW4gYSBzY2FsYWJsZSB3YXkuDQoNCkNoZWVy cywNCg0KU3RlZmFubyBGYWNjaW4NCg0KU3RhbmRhcmRzIE1hbmFnZXINClJlc2VhcmNoIElu IE1vdGlvbiBDb3Jwb3JhdGlvbiANCjUwMDAgUml2ZXJzaWRlIERyaXZlIA0KQnVpbGRpbmcg NiwgQnJhem9zIEVhc3QsIFN0ZS4gMTAwDQpJcnZpbmcsIFRleGFzIDc1MDM5IFVTQSANCk9m ZmljZTogKDk3MikgOTEwIDM0NTHCoCANCkludGVybmFsOiA4MjAuNjM0NTENCjogKDUxMCkg MjMwIDg0MjINCnd3dy5yaW0uY29tOyB3d3cuYmxhY2tiZXJyeS5jb20gDQoNCg0KDQrvgZAg Q29uc2lkZXIgdGhlIGVudmlyb25tZW50IGJlZm9yZSBwcmludGluZy4NCg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzpuZXRleHQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFlvdW4tSGVlIEhh bg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwOSwgMjAxMSAzOjIwIEFNDQpUbzogcGll cnJpY2suc2VpdGVAb3JhbmdlLWZ0Z3JvdXAuY29tOyBnZXJhcmRvZ0BxdWFsY29tbS5jb207 IG5ldGV4dEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRleHRdIFBvbGljeSBhc3N1bXB0 aW9uc2luIGRyYWZ0LWJlcm5hcmRvcy1uZXRleHQtcG1pcHY2LWZsb3dtb2INCg0KSGkgYWxs LA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG5ldGV4dC1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86bmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs Zg0KPiBPZiBwaWVycmljay5zZWl0ZUBvcmFuZ2UtZnRncm91cC5jb20NCj4gU2VudDogV2Vk bmVzZGF5LCBGZWJydWFyeSAwOSwgMjAxMSA1OjU2IFBNDQo+IFRvOiBnZXJhcmRvZ0BxdWFs Y29tbS5jb207IG5ldGV4dEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW25ldGV4dF0gUG9s aWN5IGFzc3VtcHRpb25zIGluIGRyYWZ0LWJlcm5hcmRvcy1uZXRleHQtDQo+IHBtaXB2Ni1m bG93bW9iDQo+IA0KPiANCj4gSSB0aGluayBhIHByYWdtYXRpYyBhbmQgYmFzaWMgYmVoYXZp b3VyIGNvdWxkIGJlIGRlZmluZWQgaW4gYSBmaXJzdA0KPiByb3VuZC4gSSdkIHN1Z2dlc3Qg dGhlIGZvbGxvd2luZzogVGhlIExNQSBlbmZvcmNlcyBpdHMgZGVjaXNpb24gdG8gdGhlDQo+ IE1OLCB3aGljaCBpcyBqdXN0IGV4cGVjdGVkIHRvIG1pcnJvciBMTUEgcm91dGluZyBkZWNp c2lvbiwgaS5lLiB0aGUgTU4NCj4gc2VuZHMgYSBwYWNrZXQgb24gdGhlIHNhbWUgaW50ZXJm YWNlIGl0IHJlY2VpdmVzIHRoZSBwYWNrZXQuIEhvd2V2ZXIsDQo+IFRoZSBNTiBuZWVkcyB0 byBoYXZlIGEgZGVmYXVsdCBwb2xpY3kgdG8gc2VsZWN0IHRoZSBpbnRlcmZhY2Ugd2hlbg0K PiBpbml0aWF0aW5nIGEgZmxvdy4gSWYgdGhlIE1OJ3MgcG9saWN5IGRvZXMgbm90IG1hdGNo IHRoZSBMTUEgcG9saWN5LCB0aGUNCj4gTE1BIHRyaWdnZXIgZmxvdyBoYW5kb3ZlciBhbmQg dGhlIE1OIGZvbGxvd3MgdGhhdCBkZWNpc2lvbi4NCg0KSSBzZWNvbmQgdGhpcyBzdGF0ZW1l bnQuDQogDQo+IE9idmlvdXNseSwgbW9yZSBzb3BoaXN0aWNhdGVkIHBvbGljaWVzIG1vZGVs cyBjb3VsZCBiZSBkZWZpbmVkLiANCg0KSSBhbHNvIGFncmVlIGl0LiBBZGRpdGlvbmFsbHks IHdlIG5lZWQgdG8gZGlzY3VzcyB3aGF0IGNvbXBvbmVudCBjYW4gbWFuYWdlDQp0aGUgbmV0 d29yay1zaWRlIHBvbGljeS4gTUFHLCBMTUEsIG9yIEJvdGg/DQoNCllvdW4tSGVlDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRleHQg bWFpbGluZyBsaXN0DQpuZXRleHRAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0ZXh0DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpUaGlzIHRyYW5zbWlz c2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5IGNvbnRhaW4gY29uZmlkZW50 aWFsIGluZm9ybWF0aW9uLCBwcml2aWxlZ2VkIG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0ZXJp YWwgcHJvdGVjdGVkIGJ5IHRoZSBzb2xpY2l0b3ItY2xpZW50IG9yIG90aGVyIGFwcGxpY2Fi bGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1YmxpYyBpbmZvcm1hdGlvbi4g QW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBp bnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0 byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lz dGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0aW9u IG9mIHRoaXMgdHJhbnNtaXNzaW9uIGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50cyBpcyBub3Qg YXV0aG9yaXplZCBhbmQgbWF5IGJlIHVubGF3ZnVsLg0K From JuanCarlos.Zuniga@InterDigital.com Wed Feb 9 09:44:16 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD0AB3A69F5 for ; Wed, 9 Feb 2011 09:44:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ummP7d3SemSa for ; Wed, 9 Feb 2011 09:44:15 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 40F553A69F6 for ; Wed, 9 Feb 2011 09:44:15 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Feb 2011 12:44:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 9 Feb 2011 12:44:23 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLw9OSrYVyQtqZEUGfFOgnrCkRuZPwNUIAgAAmFoCAAAk+AP///QSAgAAJMwD///0SgIAAMdcAgAAUO4CAAOjnAIAABrwAgAAm0oCAATmcAIABvD4AgAAHZICAAAUSAIAABSYAgAGrNICAABNEAIAAIoyAgAAQuQCAAATrAIAACvoAgAAqUYCAAUICAIAAHSaAgAAOPYCAAAICAIAA2VuAgAAe4QD//56AAAAPS6rQ References: <680854867F7FD04BB9B06EB8ACA8D5AC05EFEC1B@XCH02DFW.rim.net> From: "Zuniga, Juan Carlos" To: , , , , X-OriginalArrivalTime: 09 Feb 2011 17:44:24.0637 (UTC) FILETIME=[FD9B3ED0:01CBC880] Cc: netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 17:44:16 -0000 KzENCg0KSSBzdXBwb3J0IHRoZSBpZGVhIGZyb20gUGllcnJpY2sgYW5kIFJhaiB0byBzdG9wIGdv aW5nIGluIGNpcmNsZXMgd2l0aCByZWxpZ2lvdXMgYXJndW1lbnRzIGFuZCBjb25jZW50cmF0ZSBv biB0aGUgc29sdXRpb24gYXQgaGFuZCwgd2hpY2ggcmVzcG9uZHMgdG8gd2hhdCB0aGUgV0cgaXMg Y2hhcnRlcmVkIHRvIGRvLg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogbmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuZXRleHQtYm91bmNlc0BpZXRmLm9y Z10gT24NCj4gQmVoYWxmIE9mIEJhc2F2YXJhai5QYXRpbEBub2tpYS5jb20NCj4gU2VudDogRmVi cnVhcnkgOSwgMjAxMSAxMjoxOSBQTQ0KPiBUbzogc2ZhY2NpbkByaW0uY29tOyB0ZWxlbWFjby5t ZWxpYUBhbGNhdGVsLWx1Y2VudC5jb207DQo+IGp1bGllbi5pZXRmQGdtYWlsLmNvbTsgY2piY0Bp dC51YzNtLmVzDQo+IENjOiBuZXRleHRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtuZXRleHRd IENvbnNlbnN1cyBjYWxsIHRvIGFkb3B0IEktRDogZHJhZnQtYmVybmFyZG9zLQ0KPiBuZXRleHQt cG1pcHY2LWZsb3dtb2IgYXMgV0cgZG9jDQo+IA0KPiANCj4gU3RlZmFubywNCj4gDQo+IExldHMg bm90IHRhbGsgYWJvdXQgQVJQVSBvciBvdGhlciBhc3BlY3RzIG9mIG9wZXJhdG9yIGlzc3VlcyB3 aGljaCBhcmUNCj4gSU1PDQo+IG5vdCByZWFsbHkgaGVscGluZyB0aGlzIGRpc2N1c3Npb24uDQo+ IA0KPiBCdXQgcmVnYXJkaW5nIHRoZSBxdWVzdGlvbiBvZiB3aGV0aGVyIHRoZXJlIGlzIGFuIG9w ZW4gYW5kIGRlY2xhcmVkDQo+IGN1c3RvbWVyLCBJIGRvbuKAmXQga25vdyBpZiB0aGUgV0cgcmVh bGx5IG5lZWRzIHRvIGFuc3dlciB0aGF0Lg0KPiBUaGUgcG9pbnQgaXMgdGhhdCB3ZSBoYXZlIGRl ZmluZWQgYSBuZXR3b3JrIGJhc2VkIG1vYmlsaXR5IHByb3RvY29sDQo+IChSRkM1MjEzKSBpbiB0 aGUgSUVURi4gVGhlcmUgaXMgYSBjb21tdW5pdHkgb2YgcGVvcGxlIGluIHRoZSBXRyB3aGljaA0K PiBiZWxpZXZlcyB0aGF0IGV4dGVuZGluZyB0aGUgcHJvdG9jb2wgdG8gc3VwcG9ydCBmbG93IG1v YmlsaXR5IHdpbGwNCj4gYWRkcmVzcw0KPiBzb21lIHNjZW5hcmlvcyBhbmQgdXNlIGNhc2VzLiBU aGUgYXBwbGljYWJpbGl0eSAgb2Ygc3VjaCBhIGZlYXR1cmUgaW4NCj4gM0dQUA0KPiBhcmNoaXRl Y3R1cmVzIGlzIHRvIHNvbWUgZXh0ZW50IG9wZW4uDQo+IEkgdGhpbmsgd2Ugc2hvdWxkIGJlIGRv aW5nIHRoZSB3b3JrIGFuZCBzcGVjaWZ5aW5nIHRoZSBzb2x1dGlvbi4NCj4gVW5kZXJzdGFuZGlu ZyB0aGUgdXNlIGNhc2VzIGZvciB0aGUgZmVhdHVyZSBpcyBnb29kLiBCdXQgSSB0aGluayB3ZSBk bw0KPiBub3QNCj4gaGF2ZSB0byBnbyBvdmVyYm9hcmQgaW4gdGVybXMgb2YgdmVyaWZ5aW5nIHRo ZSBjdXN0b21lciBleGlzdGVuY2Ugb3INCj4gaW50ZXJlc3QuDQo+IA0KPiAtUmFqDQo+IA0KPiBP biAyLzkvMTEgMTE6MDggQU0sICJleHQgU3RlZmFubyBGYWNjaW4iIDxzZmFjY2luQHJpbS5jb20+ IHdyb3RlOg0KPiANCj4gPlRlbGVtYWNvLA0KPiA+QWxsIHRoYXQgeW91IHNheSBpcyBnb29kLCBh cGFydCBmcm9tIG9uZSBkZXRhaWwuIEkgZG8gbm90IGJlbGlldmUgdGhhdA0KPiA+aGVyZSBpbiBJ RVRGIHdlIHNob3VsZCBiZSB0YWxraW5nIGFib3V0IEFSUFUgYW5kIGNvc3RzIGFuZCBzbyBvbi4g V2UNCj4gYXJlDQo+ID5qdXN0IG5vdCBjYXBhYmxlIG9mIGV2YWx1YXRpbmcgdGhlbS4gSWYgaW5k ZWVkIGFzIHlvdSBzYXkgdGhpcw0KPiBzb2x1dGlvbg0KPiA+d2VyZSB0aGUgbWFnaWMgYW5zd2Vy IHRvIG9wZXJhdG9yIGlzc3VlcywgSSBhbSBzdXJlIG9wZXJhdG9ycyBpbiAzR1BQDQo+ID53b3Vs ZCBoYXZlIHNob3duIGEgYmlnZ2VyIGludGVyZXN0IGluIGl0LiBNeSBwcmV2aW91cyBxdWVzdGlv biBvbg0KPiB3aGV0aGVyDQo+ID53ZSBoYXZlIGFuIG9wZW4gYW5kIGRlY2xhcmVkIGN1c3RvbWVy IGZvciB0aGlzIHNvbHV0aW9uIChpLmUuIHRoYXQNCj4gPmNsZWFybHkgc3RhdGVkIHRoaXMgaXMg bmVlZGVkKSBpcyBzdGlsbCB1bmFuc3dlcmVkLCBzbyBwZXJoYXBzIHRoZXJlDQo+ID5pc24ndCBp bmRlZWQgc3VjaCBhbiBpbnRlcmVzdCBpbiB0aGlzIG1hZ2ljIHNvbHV0aW9uPw0KPiA+Q2hlZXJz LA0KPiA+U3RlZmFubyBGYWNjaW4NCj4gPg0KPiA+U3RhbmRhcmRzIE1hbmFnZXINCj4gPlJlc2Vh cmNoIEluIE1vdGlvbiBDb3Jwb3JhdGlvbg0KPiA+NTAwMCBSaXZlcnNpZGUgRHJpdmUNCj4gPkJ1 aWxkaW5nIDYsIEJyYXpvcyBFYXN0LCBTdGUuIDEwMA0KPiA+SXJ2aW5nLCBUZXhhcyA3NTAzOSBV U0ENCj4gPk9mZmljZTogKDk3MikgOTEwIDM0NTENCj4gPkludGVybmFsOiA4MjAuNjM0NTENCj4g PjogKDUxMCkgMjMwIDg0MjINCj4gPnd3dy5yaW0uY29tOyB3d3cuYmxhY2tiZXJyeS5jb20NCj4g Pg0KPiA+DQo+ID4NCj4gPu+BkCBDb25zaWRlciB0aGUgZW52aXJvbm1lbnQgYmVmb3JlIHByaW50 aW5nLg0KPiA+DQo+ID4NCj4gPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID5Gcm9tOiBu ZXRleHQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5ldGV4dC1ib3VuY2VzQGlldGYub3JnXSBP bg0KPiBCZWhhbGYNCj4gPk9mIE1FTElBLCBURUxFTUFDTyAoVEVMRU1BQ08pDQo+ID5TZW50OiBX ZWRuZXNkYXksIEZlYnJ1YXJ5IDA5LCAyMDExIDc6MTggQU0NCj4gPlRvOiBKdWxpZW4gTGFnYW5p ZXI7IGNqYmNAaXQudWMzbS5lcw0KPiA+Q2M6IG5ldGV4dEBpZXRmLm9yZzsgQmFzYXZhcmFqLlBh dGlsQG5va2lhLmNvbQ0KPiA+U3ViamVjdDogUmU6IFtuZXRleHRdIENvbnNlbnN1cyBjYWxsIHRv IGFkb3B0IEktRDoNCj4gPmRyYWZ0LWJlcm5hcmRvcy1uZXRleHQtcG1pcHY2LWZsb3dtb2IgYXMg V0cgZG9jDQo+ID4NCj4gPkJ1dCB3aHkgd2UgY2Fubm90IGRlc2lnbiBhIG1vZGVsIHdoZXJlIHdl IGNhbiBkeW5hbWljYWxseSBncm91cA0KPiBzZXNzaW9ucz8NCj4gPk1vYmlsZSBvcGVyYXRvcnMg aGF2ZSBiZWVuIGZpZ2h0aW5nIGhhcmQgaW4gdGhlIHBhc3QgeWVhcnMgdGhlDQo+ID5kaXNjb25u ZWN0aW9uIGJldHdlZW4gQVJQVSBhbmQgYXNzb2NpYXRlZCBjb3N0IHBlciB1c2VycyAoaW4gb3Ro ZXINCj4gd29yZHMNCj4gPmNvc3RzIGluY3JlYXNlIGJ1dCByZXZlbnVlcyBjb250aW51ZSB0byBm YWxsKS4gRGF0YSBleHBsb3Npb24gaXMgb25lDQo+IG9mDQo+ID50aGUgcmVhc29ucyBmb3Igc3Vj aCBkaXNjb25uZWN0aW9uLg0KPiA+SSBiZWxpZXZlIHRoYXQgbmV0d29yayBvcGVyYXRvcnMgd291 bGQgYmUgZWFnZXIgdG8gbGVhcm4gYWJvdXQNCj4gaW5ub3ZhdGluZw0KPiA+dGVjaG5vbG9naWVz IHRvIHJlZHVjZSBjb3N0cyBleHBlbmRpdHVyZXMuIFRoZSB3b3JrIHdlIGFyZSBwdXNoaW5nDQo+ IHdpdGgNCj4gPnRoaXMgSUQgZmFsbHMgZXhhY3RseSBpbiB0aGlzIGNhdGVnb3J5LiBSZXN0cmlj dGluZyB0byB0aGUgbGVnYWN5DQo+IFBNSVB2Ng0KPiA+bW9kZWwgaXMgYSBsaW1pdGF0aW9uLg0K PiA+DQo+ID5JIHdvdWxkIGJlIGdsYWQgdG8gaGVhciBvcGluaW9ucyBmcm9tIG90aGVyIChkaWZm ZXJlbnQpIHZvaWNlcy4NCj4gPg0KPiA+dGVsZW1hY28NCj4gPg0KPiA+LS0tLS1NZXNzYWdlIGQn b3JpZ2luZS0tLS0tDQo+ID5EZSA6IG5ldGV4dC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bmV0 ZXh0LWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhDQo+IHBhcnQNCj4gPmRlIEp1bGllbiBMYWdhbmll cg0KPiA+RW52b3nDqSA6IG1lcmNyZWRpIDkgZsOpdnJpZXIgMjAxMSAwMzoyMA0KPiA+w4AgOiBj amJjQGl0LnVjM20uZXMNCj4gPkNjIDogQmFzYXZhcmFqLlBhdGlsQG5va2lhLmNvbTsgbmV0ZXh0 QGlldGYub3JnDQo+ID5PYmpldCA6IFJlOiBbbmV0ZXh0XSBDb25zZW5zdXMgY2FsbCB0byBhZG9w dCBJLUQ6DQo+ID5kcmFmdC1iZXJuYXJkb3MtbmV0ZXh0LXBtaXB2Ni1mbG93bW9iIGFzIFdHIGRv Yw0KPiA+DQo+ID5IaSBDYXJsb3MsDQo+ID4NCj4gPjIwMTEvMi84IENhcmxvcyBKZXPDunMgQmVy bmFyZG9zIENhbm8gPGNqYmNAaXQudWMzbS5lcz46DQo+ID4+IEhpIEp1bGllbiwNCj4gPj4NCj4g Pj4gT24gVHVlLCAyMDExLTAyLTA4IGF0IDE3OjIxIC0wODAwLCBKdWxpZW4gTGFnYW5pZXIgd3Jv dGU6DQo+ID4+PiBIaSBDYXJsb3MsDQo+ID4+Pg0KPiA+Pj4gSSBhbSBnbGFkIHRvIHNlZSB5b3Ug YWdyZWUgd2l0aCBtZSA6LSkNCj4gPj4+DQo+ID4+PiBZb3UncmUgYWN0dWFsbHkgcHJvdmluZyBt eSBwb2ludC4NCj4gPj4+DQo+ID4+PiBUbyBydW4gYW55IG9mIHRoZSBmbG93IG1vYmlsaXR5IHN0 dWZmIG9uIGEgaG9zdCwgeW91IHdpbGwgbmVlZA0KPiBlaXRoZXINCj4gPj4+IGxheWVyIDIgdG8g aGlkZSB0aGUgZGlzc2ltaWxhciBpbnRlcmZhY2VzICh2aXJ0dWFsIGludGVyZmFjZQ0KPiB0aGlu ZyksDQo+ID4+PiBpbiB3aGljaCBjYXNlIHlvdSBkbyBoYXZlIEwyIHRyaWdnZXJzLCBvciB0byBt b2RpZnkgdGhlIGxheWVyIDMsDQo+IHdoaWNoDQo+ID4+PiB0aGlzIFdHIGlzIGV4cGxpY2l0bHkg cHJldmVudGVkIGZyb20gZG9pbmcgYXNzdW1pbmcgdGhhdCdzIGV2ZW4NCj4gPj4+IHBvc3NpYmxl Lg0KPiA+Pj4NCj4gPj4+IFNvIHlvdSBuZWVkIGxheWVyIDIuIEFuZCB0aGF0IGlzIGFjdHVhbGx5 IGV4YWN0bHkgaG93IG5ldGV4dCBjb3VsZA0KPiBnZXQNCj4gPj4+IGNoYXJ0ZXJlZCB0byB3b3Jr IG9uIGZsb3cgbW9iaWxpdHksIGJlY2F1c2Ugd2UgYXNzdW1lZCBsYXllciAyDQo+IHdvdWxkDQo+ ID4+PiBiZSB0aGVyZSB0byBoZWxwIHdpdGggYWxsIHRoZSBzdHVmZiB3ZSdyZSBub3QgYWxsb3dl ZCB0byBkbyBhdA0KPiBsYXllcg0KPiA+Pj4gMy4NCj4gPj4NCj4gPj4gRXhhY3RseSwgeW91IG5l ZWQgbGF5ZXIgMiB0byBoZWxwIHdpdGggYWxsIHRoZSBzdHVmZiB3ZSBhcmUgbm90DQo+IGFsbG93 ZWQNCj4gPj4gdG8gZG8gYXQgbGF5ZXIgMywgX2J1dF8gbm90IHRvIGRvIHRoaW5ncyB0aGF0IHdl IGRvbid0IG5lZWQgdG8gZG8gYXQNCj4gdGhlDQo+ID4+IE1OLCBhbmQgY2FuIGJlIHRyaXZpYWxs eSBkb25lIHdpdGggTE1BLU1BRyBzaWduYWxpbmcgd2l0aG91dCBwdXR0aW5nDQo+ID4+IHN0cm9u ZyByZXF1aXJlbWVudHMgb24gdGhlIGxheWVyIDIuDQo+ID4+DQo+ID4+IFRoZSBzaWduYWxpbmcg d2UgZGVmaW5lIGluIG91ciBkcmFmdCAob3IgdmFyaWF0aW9ucyBhcm91bmQgdGhhdCkNCj4gYWxs b3dzDQo+ID4+IHRvIHN1cHBvcnQgYWxsIHRoZSBzY2VuYXJpb3MgdGhhdCBoYXZlIGJlZW4gbWVu dGlvbmVkIHNvIGZhciwgYW5kDQo+IGRvZXMNCj4gPj4gbm90IGJyZWFrIGFueSBQTUlQdjYgY29u Y2VwdCAtLSBqdXN0IGV4dGVuZHMgaXQuIEl0IGRvZXMgbm90IHJlcXVpcmUNCj4gPj4gY29tcGxl eCBsYXllciAyIHRyaWdnZXJzL3BvbGljaWVzIHRvIGJlIGluIHBsYWNlIGFuZCBpdCdzIHRoZXJl Zm9yZQ0KPiBtb3JlDQo+ID4+IGxheWVyLTIgYWdub3N0aWMuIFN0aWxsLCB5b3UgcHJlZmVycyB0 byBnbyBmb3IgdGhlICJsZXRzIHJlZG8gTUlQIGF0DQo+ID4+IGxheWVyLTIiLCBhbmQgSSBrZWVw IGZhaWxpbmcgdG8gc2VlIHdoeQ0KPiA+DQo+ID5QTUlQdjYgYXMgcGVyIFJGQzUyMTMgZG9lc24n dCB3b3JrIHdpdGhvdXQgTDIgdHJpZ2dlcnMsIHNvIHRoZXJlJ3Mgbm8NCj4gPnZhbHVlIGluIGV4 dGVuZGluZyBQTUlQdjYgdG8gc3BhcmUgcmVseWluZyBvbiBMMiB0cmlnZ2VycyB0aGF0IGFyZQ0K PiA+cmVxdWlyZWQgYW55d2F5Lg0KPiA+DQo+ID4tLWp1bGllbg0KPiA+DQo+ID4tLWp1bGllbg0K PiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPm5l dGV4dCBtYWlsaW5nIGxpc3QNCj4gPm5ldGV4dEBpZXRmLm9yZw0KPiA+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRleHQNCj4gPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID5uZXRleHQgbWFpbGluZyBsaXN0DQo+ID5uZXRl eHRAaWV0Zi5vcmcNCj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0 ZXh0DQo+ID4NCj4gPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+VGhpcyB0cmFuc21pc3Npb24gKGluY2x1ZGlu ZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbA0KPiA+aW5mb3JtYXRp b24sIHByaXZpbGVnZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRlcmlhbCBwcm90ZWN0ZWQgYnkg dGhlDQo+ID5zb2xpY2l0b3ItY2xpZW50IG9yIG90aGVyIGFwcGxpY2FibGUgcHJpdmlsZWdlcyks IG9yIGNvbnN0aXR1dGUNCj4gPm5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ugb2YgdGhp cyBpbmZvcm1hdGlvbiBieSBhbnlvbmUgb3RoZXINCj4gdGhhbg0KPiA+dGhlIGludGVuZGVkIHJl Y2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzDQo+ID50cmFu c21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVy IGFuZA0KPiBkZWxldGUNCj4gPnRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4gVXNl LCBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sDQo+IG9yDQo+ID5yZXByb2R1Y3Rpb24gb2Yg dGhpcyB0cmFuc21pc3Npb24gYnkgdW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdA0KPiA+YXV0 aG9yaXplZCBhbmQgbWF5IGJlIHVubGF3ZnVsLg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0ZXh0IG1haWxpbmcgbGlzdA0KPiBuZXRl eHRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRl eHQNCg== From telemaco.melia@alcatel-lucent.com Wed Feb 9 09:53:03 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B18A63A69C5 for ; Wed, 9 Feb 2011 09:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.778 X-Spam-Level: X-Spam-Status: No, score=-4.778 tagged_above=-999 required=5 tests=[AWL=-0.683, BAYES_00=-2.599, FRT_BELOW2=2.154, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9j6DhlWji+M for ; Wed, 9 Feb 2011 09:53:02 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id AC1973A67BD for ; Wed, 9 Feb 2011 09:53:01 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p19Hr8ME013748 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 Feb 2011 18:53:08 +0100 Received: from FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com ([135.120.45.54]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 9 Feb 2011 18:53:08 +0100 From: "MELIA, TELEMACO (TELEMACO)" To: Stefano Faccin , Julien Laganier , Tran Minh Trung Date: Wed, 9 Feb 2011 18:53:08 +0100 Thread-Topic: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvIBJiHT6pTC5AuTLiPxUHd+1cGXgAai07QAANlc4AAAQ1g8A== Message-ID: <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6D23C@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com><843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6D206@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> <680854867F7FD04BB9B06EB8ACA8D5AC05EFEC2B@XCH02DFW.rim.net> In-Reply-To: <680854867F7FD04BB9B06EB8ACA8D5AC05EFEC2B@XCH02DFW.rim.net> Accept-Language: en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 17:53:03 -0000 U3RlZmFubywNCg0KQXQgdGhlIHJpc2sgb2Ygc291bmRpbmcgZXh0cmVtZWx5IHJlcGV0aXRpdmUg SSBiZWxpZXZlIHRoZSBhdXRob3JzIGF0IGRpZmZlcmVudCBzdGFnZXMgZGlkIGFuc3dlciB0aGUg cXVlc3Rpb25zIHBvc2VkIGZyb20gdGhlIGF1ZGllbmNlLiBUbyB2b2lkIGVuZGxlc3MgZGlzY3Vz c2lvbnMgSSdkIGxlYXZlIHRoZSBjaGFpcnMgdG8gY3V0IHRoZSBsaW5lLi4uDQoNCnRlbGVtYWNv DQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogU3RlZmFubyBGYWNjaW4gW21h aWx0bzpzZmFjY2luQHJpbS5jb21dIA0KRW52b3nDqcKgOiBtZXJjcmVkaSA5IGbDqXZyaWVyIDIw MTEgMTg6MTQNCsOAwqA6IE1FTElBLCBURUxFTUFDTyAoVEVMRU1BQ08pOyBKdWxpZW4gTGFnYW5p ZXI7IFRyYW4gTWluaCBUcnVuZw0KQ2PCoDogbmV0ZXh0QGlldGYub3JnOyBCYXNhdmFyYWouUGF0 aWxAbm9raWEuY29tDQpPYmpldMKgOiBSRTogW25ldGV4dF0gQ29uc2Vuc3VzIGNhbGwgdG8gYWRv cHQgSS1EOmRyYWZ0LWJlcm5hcmRvcy1uZXRleHQtcG1pcHY2LWZsb3dtb2IgYXMgV0cgZG9jDQoN ClRlbGVtYWNvLA0KQXQgdGhlIHJpc2sgb2Ygc291bmRpbmcgYXdmdWxseSByZXBldGl0aXZlLCBJ IG11c3QgZGlzYWdyZWUgb24gdGhlICIgaXQgaXMgcmVhZHkgdG8gcmVjZWl2ZSB0cmFmZmljIG9u IGFueSBvZiB0aGUgaW50ZXJmYWNlcyByaWdodCIuIEVzcGVjaWFsbHkgYmVjYXVzZSB5b3UgYXJl IGltcGx5aW5nICJhbnkgdHJhZmZpYyIuIE9uY2UgYWdhaW4sIHRoZSBjdXJyZW50IHNvbHV0aW9u IGRvZXMgbm90IHN1cHBvcnQgdGhlIHNjZW5hcmlvcyBjdXJyZW50bHkgc3VwcG9ydGVkIGluIDNH UFAgd2VyZSB0aGUgZGVjaXNpb24gb24gSVAgZmxvdyByb3V0aW5nIGNhbiBiZSBiYXNlZCBvbiB0 aGUgc3BlY2lmaWMgYWNjZXNzIG5ldHdvcmsgKGUuZy4gU1NJRCkgd3J0IGFjY2VzcyB0ZWNobm9s b2d5LiBJIHN0aWxsIGhhdmUgbm90IGhlYXJkIGFuIGFuc3dlciBvbiB3aHkgd2UgdGhpbmsgaXQg d291bGQgYmUgd29ydGggcHJvcG9zaW5nIGEgc29sdXRpb24gdGhhdCBnaXZlcyBsZXNzIGZ1bmN0 aW9uYWxpdHkgdGhhbiB3aGF0IGlzIG91dCB0aGVyZSBhbmQgZG9lcyBub3QgbWVldCByZWFsIHVz ZSBjYXNlIHNjZW5hcmlvcyBsaWtlIHRoZSBvbmVzIEkgZGVzY3JpYmVkIGJlZm9yZS4gSSBhbHNv IGhhdmUgbm90IGhlYXJkIGFueWJvZHkgZGVtb25zdHJhdGluZyBtZSB0aGF0IHRoZSB1c2UgY2Fz ZXMgSSByYWlzZWQgYXJlIHJlYWwgYW5kIHZlcnkgY3VycmVudC4gDQoNCkNoZWVycywNCg0KU3Rl ZmFubyBGYWNjaW4NCg0KU3RhbmRhcmRzIE1hbmFnZXINClJlc2VhcmNoIEluIE1vdGlvbiBDb3Jw b3JhdGlvbiANCjUwMDAgUml2ZXJzaWRlIERyaXZlIA0KQnVpbGRpbmcgNiwgQnJhem9zIEVhc3Qs IFN0ZS4gMTAwDQpJcnZpbmcsIFRleGFzIDc1MDM5IFVTQSANCk9mZmljZTogKDk3MikgOTEwIDM0 NTHCoCANCkludGVybmFsOiA4MjAuNjM0NTENCjogKDUxMCkgMjMwIDg0MjINCnd3dy5yaW0uY29t OyB3d3cuYmxhY2tiZXJyeS5jb20gDQoNCg0KDQrvgZAgQ29uc2lkZXIgdGhlIGVudmlyb25tZW50 IGJlZm9yZSBwcmludGluZy4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog bmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuZXRleHQtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIE1FTElBLCBURUxFTUFDTyAoVEVMRU1BQ08pDQpTZW50OiBXZWRuZXNkYXks IEZlYnJ1YXJ5IDA5LCAyMDExIDc6MzUgQU0NClRvOiBKdWxpZW4gTGFnYW5pZXI7IFRyYW4gTWlu aCBUcnVuZw0KQ2M6IG5ldGV4dEBpZXRmLm9yZzsgQmFzYXZhcmFqLlBhdGlsQG5va2lhLmNvbQ0K U3ViamVjdDogUmU6IFtuZXRleHRdIENvbnNlbnN1cyBjYWxsIHRvIGFkb3B0IEktRDpkcmFmdC1i ZXJuYXJkb3MtbmV0ZXh0LXBtaXB2Ni1mbG93bW9iIGFzIFdHIGRvYw0KDQpXaHk/IElmIHRoZSB0 ZXJtaW5hbCBpcyBjb25uZWN0ZWQgYW5kIHJhZGlvIGNvdmVyYWdlIGlzIG9rIGl0IGFsc28gbWVh bnMgaXQgaXMgcmVhZHkgdG8gcmVjZWl2ZSB0cmFmZmljIG9uIGFueSBvZiB0aGUgaW50ZXJmYWNl cyByaWdodD8gVXAgdGhlIExNQSB0byByb3V0ZSBmbG93cy4NCg0KdGVsZW1hY28NCg0KLS0tLS1N ZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBuZXRleHQtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOm5ldGV4dC1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEp1bGllbiBMYWdhbmll cg0KRW52b3nDqcKgOiBtZXJjcmVkaSA5IGbDqXZyaWVyIDIwMTEgMDM6NTQNCsOAwqA6IFRyYW4g TWluaCBUcnVuZw0KQ2PCoDogbmV0ZXh0QGlldGYub3JnOyBCYXNhdmFyYWouUGF0aWxAbm9raWEu Y29tDQpPYmpldMKgOiBSZTogW25ldGV4dF0gQ29uc2Vuc3VzIGNhbGwgdG8gYWRvcHQgSS1EOmRy YWZ0LWJlcm5hcmRvcy1uZXRleHQtcG1pcHY2LWZsb3dtb2IgYXMgV0cgZG9jDQoNCkNoYW5naW5n IHRoZSBwb2xpY3kgb24gdGhlIG5ldHdvcmsgc2lkZSBhbG9uZSBpc24ndCBzdWZmaWNpZW50LiBZ b3UnZA0KaGF2ZSB0byBjaGFuZ2UgdGhlIHBvbGljeSBvbiB0aGUgaG9zdCwgdG9vIChlLmcuLCB1 c2luZyBBRE5TRiBpbiAzR1BQKQ0Kd2hpY2ggd2lsbCB0cmlnZ2VyIHRoZSBNTiB0byBhdHRhY2gg SUYxIHRvIHNlc3Npb24gMi4NCg0KVGhpcyBpcyB0aGUgc3lzdGVtIHZpZXcgcGljdHVyZSB3aGlj aCBzZWVtcyB3ZSdyZSBtaXNzaW5nIGluIHRoaXMgZGlzY3Vzc2lvbi4NCg0KLS1qdWxpZW4NCg0K T24gVHVlLCBGZWIgOCwgMjAxMSBhdCA2OjQ5IFBNLCBUcmFuIE1pbmggVHJ1bmcgPHRydW5ndG0y OTA5QGdtYWlsLmNvbT4gd3JvdGU6DQo+IEhpIEp1bGllbiwNCj4NCj4gTGV0IG1lIHNob3cgYSBy ZWFsIGNhc2UgZm9yIHRoZSBzY2VuYXJpbyB0aGF0IHdlIGFyZSBkaXNjdXNzaW5nIGJlbGxvdzoN Cj4NCj4gVGhlIG5ldHdvcmsgcG9saWN5IGlzIGNoYW5nZWQgYW5kIHRoZSBMTUEgZGVjaWRlcyB0 byBtb3ZlIGZsb3cgMiBmcm9tDQo+IElGMiB0byBJRjEgYmVmb3JlIE1BRzEgcmVjZWl2ZWQgTDIg dHJpZ2dlciBmcm9tIHRoZSBNTiAoc2F5IGJlZm9yZQ0KPiBzdGVwICM4KQ0KPiBJbiB0aGF0IGNh c2UsIHRoZSBMTUEgc2hvdWxkIHNpZ25hbCBNQUcxIHRvIHNlbmQgUEJVIHRvIGF0dGFjaCBJRjEg dG8NCj4gc2Vzc2lvbiAyLg0KPg0KPiBXaXRob3V0IHNpZ25hbGluZyBmcm9tIExNQSBob3cgY2Fu IHlvdSBkbyBpbiB0aGlzIGNhc2U/IEp1c3Qgd2FpdA0KPiB1bnRpbCByZWNlaXZpbmcgTDIgdHJp Z2dlciBmcm9tIHRoZSBNTj8NCj4NCj4gT24gV2VkLCBGZWIgOSwgMjAxMSBhdCA3OjE4IEFNLCBK dWxpZW4gTGFnYW5pZXIgPGp1bGllbi5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6DQo+PiBIaSBQaWVy cmljaywNCj4+DQo+PiBJIGFtIGdvaW5nIHRvIGludGVydHdpbmUgdGhlIHN0ZXBzIGluIHlvdXIg c2NlbmFyaW8gYmVsb3cgd2l0aCB0aGUNCj4+IG1pc3NpbmcgcGllY2VzIG9mIHRoZSBiaWcgcGlj dHVyZSBzbyB0aGF0IHdlIGFyZSBub3QgZG9pbmcgYW4gYWNhZGVtaWMNCj4+IGV4ZXJjaXNlIGJ1 dCBmb2N1c2luZyBvbiB0aGUgcmVhbCB3b3JsZDoNCj4+DQo+PiAxLiB3aGVuIHRoZSBNTiBmaXJz dCBhdHRhY2hlcyB3aXRoIGlmMSB0byBhIG5ldHdvcmssIE1BRzEgcmVxdWVzdHMNCj4+IGF0dGFj aG1lbnQgb2YgaWYxIHRvIGEgc2Vzc2lvbjEgYnkgc2VuZGluZyBhIFBCVSB0byBMTUENCj4+DQo+ PiAyLiBiZWNhdXNlIHRoZSBNTiBhZGQgbm8gc2Vzc2lvbjEgcHJldmlvdXNseSwgdGhlIExNQSBj cmVhdGVzIHNlc3Npb24NCj4+IDEgYW5kIGFsbG9jYXRlcyBhIHByZWZpeCBmb3IgaXQuIFRoZSBw cmVmaXggaXMgc2VudCBiYWNrIHRvIE1BRzEgaW4NCj4+IHRoZSBQQkE6DQo+Pg0KPj4gwqDCoCDC oCDCoCDCoCDCoFNlc3Npb24xOiBbUHJlZjEsIE1BRzEtSUYxXQ0KPj4NCj4+IDMuIHRoZW4sIGlm IHRoZSBNTiBhdHRhY2hlcyB3aXRoIGlmMiB0byBhbm90aGVyIG5ldHdvcmssIGJ1dCBkb2VzIG5v dA0KPj4gcmVxdWVzdCB0aGlzIGludGVyZmFjZSBiZSBhdHRhY2hlZCB0byBhIGRpc3RpbmN0IHNl c3Npb24sIE1BRzINCj4+IHJlcXVlc3RzIGF0dGFjaGVtbnQgb2YgSWYyIHRvIHNlc3Npb24xIGJ5 IHNlbmRpbmcgYSBQQlUgdG8gTE1BDQo+Pg0KPj4gNC4gQmVjYXVzZSB0aGUgTU4gYWxyZWFkeSBo YXMgc2Vzc2lvbiAxLCB0aGUgTE1BIHVwZGF0ZXMgc2Vzc2lvbjEgd2l0aA0KPj4gaWYyLCBhbmQg c2VuZCB0aGUgcHJlZjEgYmFjayB0byBNQUcyIGluIHRoZSBQQkE6DQo+Pg0KPj4gwqDCoCDCoCDC oCDCoCBTZXNzaW9uMTogW1ByZWYxLCBNQUcxLUlGMSwgTUFHMi1JRjJdDQo+Pg0KPj4gNS4gQ3Jl YXRpb24gb2YgYSBuZXcgc2Vzc2lvbiAyIGZvciBpZjIgaXMgcmVxdWVzdGVkIGJ5IGVpdGhlciBv ZiBNTg0KPj4gcmVxdWVzdHMgdmlhIEwyIHRyaWdnZXJzLCBvciBhIGNoYW5nZSBpbiBwb2xpY3kg cHJvZmlsZS4gQXMgYSByZXN1bHQsDQo+PiBNQUcyIHJlcXVlc3RzIGF0dGFjaG1lbnQgb2YgaWYy IHRvIHNlc3Npb24yIGJ5IHNlbmRpbmcgYSBQQlUgdG8gTE1BLg0KPj4NCj4+IDYuIGJlY2F1c2Ug dGhlIE1OIGFkZCBubyBzZXNzaW9uMiBwcmV2aW91c2x5LCB0aGUgTE1BIGNyZWF0ZXMgc2Vzc2lv bg0KPj4gMiBhbmQgYWxsb2NhdGVzIGEgcHJlZml4IGZvciBpdC4gVGhlIHByZWZpeCBwcmVmMiBp cyBzZW50IGJhY2sgdG8gTUFHMg0KPj4gaW4gdGhlIFBCQToNCj4+DQo+PiDCoMKgIMKgIMKgIMKg IMKgU2Vzc2lvbjI6IFtQcmVmMiwgTUFHMi1JRjJdDQo+Pg0KPj4gNy4gRmxvdzIgc3RhcnRzIG92 ZXIgaWYyIHdpdGggcHJlZml4Mi4NCj4+DQo+PiA4LiBBdHRhY2htZW50IG9mIGlmMSB0byBzZXNz aW9uMiBpcyByZXF1ZXN0ZWQgYnkgZWl0aGVyIG9mIE1OIHJlcXVlc3RzDQo+PiB2aWEgTDIgdHJp Z2dlcnMsIG9yIGEgY2hhbmdlIGluIHBvbGljeSBwcm9maWxlLiBBcyBhIHJlc3VsdCwgTUFHMQ0K Pj4gcmVxdWVzdHMgYXR0YWNobWVudCBvZiBpZjEgdG8gc2Vzc2lvbjIgYnkgc2VuZGluZyBhIFBC VSB0byBMTUEuDQo+Pg0KPj4gOS4gQmVjYXVzZSB0aGUgTU4gYWxyZWFkeSBoYXMgc2Vzc2lvbiAy LCB0aGUgTE1BIHVwZGF0ZXMgc2Vzc2lvbjIgd2l0aCBpZjE6DQo+Pg0KPj4gwqDCoCDCoCDCoCDC oCBTZXNzaW9uMjogW1ByZWYyLCBNQUcyLUlGMiwgTUFHMS1JRjFdDQo+Pg0KPj4gMTAuIEF0IGFu eSBwb2ludCwgdGhlIExNQSBkZWNpZGVzIHRvIG1vdmUgRmxvdzIgYmV0d2VlbiB0d28gaW50ZXJm YWNlcw0KPj4gb2Ygc2Vzc2lvbiAyLCBhbmQgaXQgZG9lcyBzby4NCj4+DQo+PiBUaGF0J3MgYWxs IHRoYXQgbmVlZGVkLiBJdCBtYXBzIHBlcmZlY3RseSB0byAzR1BQLiBJZiB5b3UgaGF2ZSBpbiBt aW5kDQo+PiBhIGRpZmZlcmVudCBzeXN0ZW0gaW4gd2hjaWggdGhhdCBkb2Vzbid0IG1hcCwgcGxl YXNlIGxldCBtZSBrbm93Lg0KPj4NCj4+IC0tanVsaWVuDQo+Pg0KPj4gT24gVHVlLCBGZWIgOCwg MjAxMSBhdCA4OjI1IEFNLCDCoDxwaWVycmljay5zZWl0ZUBvcmFuZ2UtZnRncm91cC5jb20+IHdy b3RlOg0KPj4+IEhpLA0KPj4+DQo+Pj4gR29pbmcgdGhyb3VnaCB0aGlzIGxvbmcgdGhyZWFkIDot KSwgaXQgc2VlbXMgd2UgY291bGQgYWdyZWUgb24gdGhlIGZvbGxvd2luZyAoanVzdCBhIHRlbnRh dGl2ZSB0byBzdW1tYXJpemUpOg0KPj4+DQo+Pj4gU2Vzc2lvbnMgc2hvdWxkIGJlIGNyZWF0ZWQv dXBkYXRlZCB3aXRoIGFsbCBhdmFpbGFibGUgaW50ZXJmYWNlcy4gUmV3cml0aW5nIFRyYW4ncyBl eGFtcGxlOiB3aGVuIHRoZSBNTiBhdHRhY2hlcyB0byBNQUcxIHZpYSBJZjEsIHRoZSBMTUEgY3Jl YXRlcyBzZXNzaW9uIDE6DQo+Pj4NCj4+PiDCoCDCoCDCoCDCoCDCoFNlc3Npb24xOiBbUHJlZjEs IE1BRzEsIElGMV0NCj4+Pg0KPj4+IFRoZW4sIGlmIHRoZSBNTiBhdHRhY2hlcyB0byBNQUcyIHZp YSBJZjIsIHRoZSBMTUEgY3JlYXRlcyBzZXNzaW9uIDIgd2l0aCBib3RoIElmMSBhbmQgSWYyLiBU aGUgTE1BIGFsc28gdXBkYXRlcyBzZXNzaW9uIDEgd2l0aCBJZjI6DQo+Pj4NCj4+PiDCoCDCoCDC oCDCoCBTZXNzaW9uMTogW1ByZWYxLCBNQUcxLCBJRjEsIElGMl0NCj4+PiDCoCDCoCDCoCDCoCBT ZXNzaW9uMjogW1ByZWYyLCBNQUcyLCBJRjIsIElGMV0NCj4+Pg0KPj4+IE1BRzIgcmVjZWl2ZXMg cHJlZml4ZXMgMSBhbmQgMiBpbiBQQkEgYnV0IE1BRzEgaXMgbm90IHNlbmRpbmcgUEJVLiBTbywg aWYgdGhlIExNQSB3YW50cyB0byBtb3ZlIGZsb3cgd2l0aCBQcmVmMiBmcm9tIGlmMiB0byBJZjEs IHRoZSBMTUEgbmVlZHMgdG8gcHJvdmlkZSBQcmVmMiB0byBNQUcxLiBBbHNvLCB0aGUgTE1BIHNo b3VsZCBiZSBhYmxlIHRvIGNyZWF0ZSBuZXcgc2Vzc2lvbnMgd2l0aCBhbHJlYWR5IHVwIGludGVy ZmFjZXMsIGUuZy4gaWYxIGFuZCBpZjIuIFRvIGFkZHJlc3MgYm90aCBpc3N1ZXMsIFBCVSBmcm9t IE1BRzEgY291bGQgYmUgdHJpZ2dlcmVkICh0cmlnZ2VyaW5nIGlzIHRvIGJlIGNsYXJpZmllZCkg b3Igd2UgY291bGQgZGVmaW5lIExNQS9NQUcgc3BlY2lmaWMgTDMgc2lnbmFsbGluZyAoRk1JL0ZN QSkuDQo+Pj4NCj4+PiBNeSAyIGNlbnRzLA0KPj4+IFBpZXJyaWNrDQo+Pj4NCj4+Pj4gLS0tLS1N ZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+Pj4+IERlwqA6IG5ldGV4dC1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86bmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQNCj4+Pj4gZGUgWW91 bi1IZWUgSGFuDQo+Pj4+IEVudm95w6nCoDogbWFyZGkgOCBmw6l2cmllciAyMDExIDEyOjAwDQo+ Pj4+IMOAwqA6ICdKdWxpZW4gTGFnYW5pZXInOyAnUmFqZWV2IEtvb2RsaScNCj4+Pj4gQ2PCoDog bmV0ZXh0QGlldGYub3JnOyBCYXNhdmFyYWouUGF0aWxAbm9raWEuY29tDQo+Pj4+IE9iamV0wqA6 IFJlOiBbbmV0ZXh0XSBDb25zZW5zdXMgY2FsbCB0byBhZG9wdCBJLUQ6ZHJhZnQtYmVybmFyZG9z LW5ldGV4dC0NCj4+Pj4gcG1pcHY2LWZsb3dtb2IgYXMgV0cgZG9jDQo+Pj4+DQo+Pj4+IEhpIEp1 bGllbiwNCj4+Pj4NCj4+Pj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiA+IEZy b206IG5ldGV4dC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bmV0ZXh0LWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZg0KPj4+PiA+IE9mIEp1bGllbiBMYWdhbmllcg0KPj4+PiA+IFNlbnQ6IFR1 ZXNkYXksIEZlYnJ1YXJ5IDA4LCAyMDExIDE6MzggUE0NCj4+Pj4gPiBUbzogUmFqZWV2IEtvb2Rs aQ0KPj4+PiA+IENjOiBuZXRleHRAaWV0Zi5vcmc7IEJhc2F2YXJhai5QYXRpbEBub2tpYS5jb20N Cj4+Pj4gPiBTdWJqZWN0OiBSZTogW25ldGV4dF0gQ29uc2Vuc3VzIGNhbGwgdG8gYWRvcHQgSS1E OiBkcmFmdC1iZXJuYXJkb3MtDQo+Pj4+ID4gbmV0ZXh0LXBtaXB2Ni1mbG93bW9iIGFzIFdHIGRv Yw0KPj4+PiA+DQo+Pj4+ID4gT24gTW9uLCBGZWIgNywgMjAxMSBhdCA2OjE1IFBNLCBSYWplZXYg S29vZGxpIDxya29vZGxpQGNpc2NvLmNvbT4gd3JvdGU6DQo+Pj4+ID4gPg0KPj4+PiA+ID4gSWYg ZmxvdyBtb2JpbGl0eSBoYXMgbm90aGluZyBkbyB3aXRoIHByZWZpeCBtYW5hZ2VtZW50LCBJIGFt IGxvc3QuDQo+Pj4+ID4NCj4+Pj4gPiBObyByZWFzb24gdG8gYmUgbG9zdDogUHJlZml4IG1hbmFn ZW1lbnQgaXMgaG93IGRvIEkgZ2V0IHByZWZpeCBmb3IgdGhlDQo+Pj4+ID4gTU4uIEZsb3cgbW9i aWxpdHkgaXMgaG93IHRvIEkgbW92ZSBmbG93cyBhY3Jvc3MgaW50ZXJmYWNlcy4gVGhlIHR3bw0K Pj4+PiA+IG5lZWRzIG5vdCB0byBiZSBpbnRlcnR3aW5lZCB0b2dldGhlciwgYXMgSSd2ZSBzaG93 biBpbiBteSBvdGhlciBub3Rlcy4NCj4+Pj4gPiBFLmcuLCBJIGNhbiBkbyBmbG93IG1vYmlsaXR5 IHdpdGhvdXQgYWRkaW5nL2RlbGV0aW5nIHByZWZpeGVzIGZyb20NCj4+Pj4gPiBzZXNzaW9ucywg YW5kIHZpY2UgdmVyc2EuDQo+Pj4+DQo+Pj4+IFllcywgSSBhZ3JlZSB3aXRoIHlvdS4gRmxvdyBt b2JpbGl0eSBpcyBob3cgdG8gbW92ZSBmbG93cyBhY3Jvc3MgaW50ZXJmYWNlLg0KPj4+PiBTbywg SSB0aG91Z2h0IHRoYXQgaXQgd291bGQgYmUgYmV0dGVyIHRvIGRlZmluZSAiYSBmbG93IiBleGFj dGx5IGluIG5ldGV4dA0KPj4+PiBXRyBwcmlvciB0byBkaXNjdXNzIGZsb3cgbW9iaWxpdHkgbWFu YWdlbWVudC4gQXMgdGhlIGRlZmluaXRpb24gb2YgImENCj4+Pj4gZmxvdyIsDQo+Pj4+IGFsbCBJ IGNhbiB0aGluayBpcyBhIGZpdmUtdHVwbGUgcGx1cyBzb21ldGhpbmcuIElmIHdlIGFzc3VtZSB0 aGF0IGl0IGlzDQo+Pj4+IGNvcnJlY3QsIEkgdGhpbmsgdGhhdCBmbG93IG1vYmlsaXR5IGFuZCBw cmVmaXggYWRkaXRpb24gYXJlIGluZXZpdGFibHkNCj4+Pj4gdGllZC4NCj4+Pj4gQXMgeW91IGtu b3csIFJGQzUyMTMgKGFuZCBJUHY2IHByb3RvY29sIHNwZWMpIGFscmVhZHkgYWxsb3cgdG8gYXNz aWduDQo+Pj4+IG11bHRpcGxlIHByZWZpeGVzIGFjcm9zcyBtdWx0aXBsZSBpbnRlcmZhY2VzIG9m IGFuIE1OLiBZZXMsIEkgYWxzbyBhZ3JlZQ0KPj4+PiB3aXRoIHlvdSB0aGF0IGluIHJlYWwtd29y bGQgKDNHUFApLCB0aGVyZSBtYXkgYmUgbm8gbmVlZCB0byBhc3NpZ24NCj4+Pj4gbXVsdGlwbGUN Cj4+Pj4gcHJlZml4ZXMgaW50byBhbiBNTi4gKGlmIHNvbWVib2R5IGtub3dzIGl0cyBuZWNlc3Np dHksIHBsZWFzZSB0ZWxsIG1lIHdoZW4NCj4+Pj4gaXQgc2hvdWxkIGhhcHBlbikuIFNvLCBmbG93 IG1vYmlsaXR5IGNhbiBiZSBkb25lIHdpdGhvdXQgYWRkaW5nIHByZWZpeGVzLg0KPj4+PiBIb3dl dmVyLCBkaWZmZXJlbnQgaW50ZXJmYWNlcyBhcmUgYWxsb3dlZCB0byBiZSBhc3NpZ25lZCBkaWZm ZXJlbnQNCj4+Pj4gcHJlZml4ZXMNCj4+Pj4gYnkgUkZDIDUyMTMgYW5kIElQdjYgc3BlYy4gV2Ug Y2FuJ3QgZXhwZWN0IHdoYXQga2luZCBvZiBwcmVmaXhlcyBhbiBNQUcNCj4+Pj4gYWR2ZXJ0aXNl cy4gVGhlcmVmb3JlLCBzb21ldGltZXMsIHdlIG5lZWQgcHJlZml4IGFkZGl0aW9uIHRvIG1vdmUg YSBmbG93DQo+Pj4+IHRvDQo+Pj4+IGEgbmV3IGludGVyZmFjZSBvZiB3aGljaCBNQUcgZG9lcyBu b3QgeWV0IGFkdmVydGlzZSB0aGUgcHJlZml4IG9mIHRoZSBmbG93DQo+Pj4+IGJlaW5nIG1vdmVk Lg0KPj4+Pg0KPj4+PiAoc25pcC4uLikNCj4+Pj4NCj4+Pj4gPiA+PiBJIHNlZSBubyByZWFzb24g dG8gZGVwYXJ0IGZyb20gdGhhdCBpbiB0aGUgY29udGV4dCBvZiBleHRlbmRpbmcgdGhlDQo+Pj4+ ID4gPj4gcHJvdG9jb2wgdG8gc3VwcG9ydCBtb2JpbGl0eSwgbm9yIEkgYW0gYXdhcmUgb2YgYW55 IHN5c3RlbQ0KPj4+PiA+ID4+IGFyY2hpdGVjdHVyZSB0aGF0IHdvdWxkIHJlcXVpcmUgdGhpcyBj YXBhYmlsaXR5Lg0KPj4+PiA+ID4NCj4+Pj4gPiA+IE9rYXksIHNlZSB5b3VyIHBvc2l0aW9uLiBJ IHNlZSBpdCBkaWZmZXJlbnRseS4gSSBkb24ndCBuZWVkIHRvIGJlDQo+Pj4+ID4gPiBib3VuZCBi eSBzb21lICJwcmVzdW1lZCBpbXBsZW1lbnRhdGlvbiBtb2RlbCIgb2YgUE1JUDYgYW5kIGxpbWl0 DQo+Pj4+ID4gPiBteXNlbGYgKm9ubHkqIHRvIGEgcHJlZml4IGFzc2lnbm1lbnQgbW9kZWwgeW91 IGFyZSBpbWFnaW5pbmcuDQo+Pj4+ID4NCj4+Pj4gPiBJdCdzIG5vdCBhbiBpbXBsZW1lbnRhdGlv biBtb2RlbCwgaXQgaXMgYSBwcm90b2NvbCBtb2RlbCwgYW5kIGl0J3Mgbm90DQo+Pj4+ID4gaW1h Z2luYXJ5LiBJbXBsZW1lbnRhdGlvbiBoYXMgbm90aGluZyB0byBkbyB3aXRoIHRoaXMuDQo+Pj4+ ID4NCj4+Pj4gPiBUaGVyZSdzIG5vIHJlYXNvbiB0byBleHRlbmQgcHJlZml4IGFzc2lnbm1lbnQg bW9kZWwgdG8gZG8gZmxvdyBtb2JpbGl0eQ0KPj4+PiA+IHVubGVzcyB5b3UgY2FuIHBvaW50IG1l IG91dCBpbiB3aGljaCByZWFsIHdvcmxkIGNvbnRleHQgeW91ciBzY2VuYXJpbw0KPj4+PiA+IGFj dHVhbGx5IGhhcHBlbnMuDQo+Pj4+DQo+Pj4+IEFzIEkgaW5zaXN0ZWQgaW4gdGhlIG9sZCBtYWls LCBJIGFncmVlIHdpdGggSnVsaWVuIGluIHRoaXMgcmVnYXJkLiBDdXJyZW50DQo+Pj4+IGRyYWZ0 IGFsbG93cyB0b28gbXVjaCBzcGFjZSByZWdhcmRpbmcgdGhlIHByZWZpeCBhbGxvY2F0aW9uIG1v ZGVsICh1bmlxdWUsDQo+Pj4+IHNoYXJlZCwgYW5kIGh5YnJpZCkuIFdoZW4gYSBmbG93IHNob3Vs ZCBiZSBtb3ZlZCB0byBhIG5ldyBpbnRlcmZhY2UgYW5kDQo+Pj4+IHRoZQ0KPj4+PiBwcmVmaXgg d2hpY2ggdGhlIGZsb3cgdXNlcyBpcyBub3QgeWV0IGFkdmVydGlzZWQgYnkgdGhlIG5ldyBNQUcs IGp1c3QNCj4+Pj4gaW5mb3JtDQo+Pj4+IHRoZSBwcmVmaXggdG8gdGhlIE1BRyBhbmQgdGh1cyBt YWtlIGl0IGFkdmVydGlzZSB0aGUgcHJlZml4IGFuZCBzZXR1cCB0aGUNCj4+Pj4gdHVubmVsIGJh c2VkIG9uIHRoZSBuZXcgcHJlZml4LiBUaGF0J3MgYWxsIS4gSWYgdGhlIHByZWZpeCBpcyBhbHJl YWR5DQo+Pj4+IGFkdmVydGlzZWQgYnkgdGhlIE1BRywgdGhlcmUgaXMgbm90aGluZyB0byBkbyBh bmQganVzdCBtb3ZlIHRoZSBmbG93LiBUaGlzDQo+Pj4+IGJlaGF2aW9ycyBhcmUgdmVyeSBuYXR1 cmFsIG9uZSB3aGVuIHdlIHdhbnQgdG8gc3VwcG9ydCBJUC1sZXZlbCBtb2JpbGl0eS4NCj4+Pj4N Cj4+Pj4gPiA+PiBJZiB0aGlzIGlzIHNvbWV0aGluZyByZWFsbHkgaW1wb3J0YW50LCB0aGUgV0cg Y2FuIGJlIHJlY2hhcnRlcmVkIHRvDQo+Pj4+ID4gPj4gd29yayBvbiBhIGRpZmZlcmVudCBleHRl bnNpb24gdGhhdCB3b3VsZCBhbGxvdyBhZGRpbmcvcmVtb3ZpbmcNCj4+Pj4gPiA+PiBwcmVmaXhl cyBmcm9tIGV4aXN0aW5nIFBNSVB2NiBzZXNzaW9ucy4NCj4+Pj4gPiA+DQo+Pj4+ID4gPiBIdWgu LiBXaGF0IGluIHRoZSBjdXJyZW50IGNoYXJ0ZXIgZm9yY2VzIHVzIG5vdCB0byBoYXZlIHRoZSBM TUENCj4+Pj4gPiA+IGFkZC9yZWZyZXNoL2RlbGV0ZSBhIHByZWZpeCBvbi1kZW1hbmQ/DQo+Pj4+ ID4NCj4+Pj4gPiBFbmdpbmVlcmluZyBpcyBhYm91dCBmaW5kaW5nIGEgc29sdXRpb24gdG8gYSBw cm9ibGVtLiBBZGRpbmcvZGVsZXRpbmcNCj4+Pj4gPiBwcmVmaXggb24tZGVtYW5kIGlzIG5vdCBh IHNvbHV0aW9uIHRvIGZsb3cgbW9iaWxpdHkuIEkndmUgc2hvd24geW91IGhvdw0KPj4+PiA+IHRv IGRvIGZsb3cgbW9iaWxpdHkgd2l0aG91dCB0aGlzIGNhcGFiaWxpdHkuDQo+Pj4+DQo+Pj4+IEZy b20gdGhlIHZpZXdwb2ludCBvZiBwcm90b2NvbCwgSSB0aGluayB0aGF0IGF0IGxlYXN0LCBwcmVm aXggYWRkaXRpb24gdG8NCj4+Pj4gYW4NCj4+Pj4gaW50ZXJmYWNlIGlzIGEgbmVjZXNzYXJ5IGZ1 bmN0aW9uIHRvIHN1cHBvcnQgZmxvdyBtb2JpbGl0eSwgYXMgSSBleHBsYWluZWQNCj4+Pj4gYWJv dmUuIEJ1dCwgaXQgZG9lcyBub3QgbWVhbiBwcmVmaXggYWRkaXRpb24gc2hvdWxkIGhhcHBlbiBh bHdheXMgd2hlbmV2ZXINCj4+Pj4gZmxvdyBtb2JpbGl0eSBvY2N1cnMuIEl0IGlzIHNvbWV0aW1l cyBuZWVkZWQuDQo+Pj4+DQo+Pj4+ID4gTm93IGEgZGlmZmVyZW50IGVuZ2luZWVyaW5nIHByb2Js ZW0gd291bGQgYmU6IGhvdyB0byBhZGQvZGVsZXRlIHByZWZpeGVzDQo+Pj4+ID4gdG8gYSBQTUlQ djYgc2Vzc2lvbiwgYW5kIHRoYXQgd291bGQgYmUgdXNlZnVsIGZvciBlLmcuDQo+Pj4+ID4gcmVu dW1iZXJpbmcuIFRoaXMgaXMgYSBkaWZmZXJlbnQgcHJvYmxlbSB0aGF0IHdlIGhhdmVuJ3QgYmVl biBjaGFydGVyZWQNCj4+Pj4gPiB0byB3b3JrIG9uLg0KPj4+Pg0KPj4+PiBQcmVmaXggYWRkaXRp b24gaXMganVzdCBwcmVmaXggYWRkaXRpb24uIElNSE8sIHJlbnVtYmVyaW5nIGlzIGNsb3NlciB0 bw0KPj4+PiBwcmVmaXggY2hhbmdlLiBXZSBqdXN0IGhhcm5lc3MgdGhhdCBmdW5jdGlvbiB0byBz dXBwb3J0IElQLWxldmVsIG1vYmlsaXR5Lg0KPj4+Pg0KPj4+PiBZb3VuLUhlZQ0KPj4+Pg0KPj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBu ZXRleHQgbWFpbGluZyBsaXN0DQo+Pj4+IG5ldGV4dEBpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGV4dA0KPj4+DQo+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gbmV0ZXh0IG1haWxpbmcgbGlz dA0KPj4gbmV0ZXh0QGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldGV4dA0KPj4NCj4NCj4NCj4NCj4gLS0NCj4gUGguRC4sIFNlbmlvciBNZW1iZXIN Cj4gRWxlY3Ryb25pY3MgYW5kIFRlbGVjb21tdW5pY2F0aW9ucyBSZXNlYXJjaCBJbnN0aXR1dGUN Cj4gU3RhbmRhcmRzIFJlc2VhcmNoIENlbnRlcg0KPiAxNjEgR2FqZW9uZy1Eb25nLCBZdXNlb25n LUd1LCBEYWVqZW9uLCAzMDUtMzUwLCBLT1JFQQ0KPiBUZWwgOiArODItNDItODYwLTExMzIswqDC oCBGYXggOiArODItNDItODYxLTU0MDQNCj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpuZXRleHQgbWFpbGluZyBsaXN0DQpuZXRleHRAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0ZXh0IG1haWxpbmcgbGlz dA0KbmV0ZXh0QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldGV4dA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgdHJhbnNtaXNzaW9uIChpbmNsdWRpbmcgYW55 IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24sIHByaXZp bGVnZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRlcmlhbCBwcm90ZWN0ZWQgYnkgdGhlIHNvbGlj aXRvci1jbGllbnQgb3Igb3RoZXIgYXBwbGljYWJsZSBwcml2aWxlZ2VzKSwgb3IgY29uc3RpdHV0 ZSBub24tcHVibGljIGluZm9ybWF0aW9uLiBBbnkgdXNlIG9mIHRoaXMgaW5mb3JtYXRpb24gYnkg YW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGlt bWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGluZm9ybWF0aW9u IGZyb20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvciBy ZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Npb24gYnkgdW5pbnRlbmRlZCByZWNpcGllbnRz IGlzIG5vdCBhdXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuDQo= From julien.ietf@gmail.com Wed Feb 9 10:07:21 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83A243A67EC for ; Wed, 9 Feb 2011 10:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.517 X-Spam-Level: X-Spam-Status: No, score=-3.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkZ0ClBpBXPl for ; Wed, 9 Feb 2011 10:07:20 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 2DDB33A67BD for ; Wed, 9 Feb 2011 10:07:19 -0800 (PST) Received: by ewy8 with SMTP id 8so321839ewy.31 for ; Wed, 09 Feb 2011 10:07:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0+NCMi6zr0525LWJMcwGYpUmU3xiCU+A4bN/F+Yowsc=; b=NUsCTyw8Vaz5Xp37CK/YrBUtvlc3r8IRY04CxZKLlQTLolwRW9zuyMF/xPU5gc7K/W c4HVc4Jpqk47QIRMO9ioQLD0kF/icL4h21+L4iAbyvZPRcf5ELpDqoWXT3I/ELH3t+CL fshhWpKkywU4x4qWQ6pDa9O51P9rSM6IY/s0w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pyVEKSZOUCuO4fQDbUZBc3e8PMNjfTsG9f5vXFghRvswTlNgAqkx9ybwXBWhrWubpa pHQCLcdvde4hZ+KSTWF9mQXHnQhIYI4Fl1s5xYU2hHMSZceMcNwck3wgKAUKSfYayxWH rAkW8G+CMrz+SPuyuiOM+JKIDzqI61CZedwZU= MIME-Version: 1.0 Received: by 10.103.243.16 with SMTP id v16mr14447469mur.57.1297274849106; Wed, 09 Feb 2011 10:07:29 -0800 (PST) Received: by 10.103.221.9 with HTTP; Wed, 9 Feb 2011 10:07:29 -0800 (PST) In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462017D4653@ftrdmel0.rd.francetelecom.fr> References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C462017D4653@ftrdmel0.rd.francetelecom.fr> Date: Wed, 9 Feb 2011 10:07:29 -0800 Message-ID: From: Julien Laganier To: pierrick.seite@orange-ftgroup.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Multiple prefixes indraft-bernardos-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 18:07:21 -0000 Pierrick: On Wed, Feb 9, 2011 at 1:05 AM, wrote: > > >> -----Message d'origine----- >> De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la pa= rt >> de Tran Minh Trung >> Envoy=E9=A0: mercredi 9 f=E9vrier 2011 09:46 >> =C0=A0: Giaretta, Gerardo >> Cc=A0: netext@ietf.org >> Objet=A0: Re: [netext] Multiple prefixes indraft-bernardos-netext-pmipv6= - >> flowmob >> >> On Wed, Feb 9, 2011 at 3:33 PM, Giaretta, Gerardo >> wrote: >> > Hi all, >> > >> > I am starting a new thread to understand the use case this draft is >> trying to solve when referring to multiple prefixes. I think there has >> been some discussion already in the list but I did not get a good >> understanding of the rationale. >> > >> > My understanding is that the goal of the draft is to define a flow >> mobility solution for PMIP. This implies that a given PMIP session is >> shared across multiple interfaces and some IP flows belonging to that >> session are sent over one interface and some others over another interfa= ce. >> This is equivalent to the RFC6089: IP flows which are tied to the same >> HoA/HNP can be sent over one CoA/BID or another CoA/BID. >> > >> > Is this the correct understanding of the goals of the I-D? Is this a >> common understanding of the term Flow Mobility? >> > >> >> Yes you are right. >> >> > If this is the case, then I don't understand why the draft is >> introducing text about the LMA creating a different session. Is this >> needed for Flow Mobility? If so, for which scenario? >> > >> > Going back to Pierrick's example: >> > >> > when the MN attaches to MAG1 via If1, the LMA creates session 1: >> > >> > =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] >> > >> > Then, if the MN attaches to MAG2 via If2, there is no reason for the L= MA >> to create session 2. The LMA just needs to update session 1 with If2: >> > >> >> We just follow the basic operation of the RFC5213 that a new prefix >> will be assigned to new attachment. >> >> Then we extend it to support flow mobility by allowing interfaces to >> be attached to multiple sessions. >> >> > =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] >> > >> > In this way MAG/LMA/MN can send over IF2 a TCP connection which earlie= r >> was sent over IF1. This is Flow Mobility. >> > >> >> It only works for the flows in the session1. However session 2,3..n >> can be created at anytime in the future. We have to attach all working >> interfaces in the set to a new session whenever it is created. >> > > IMU, the current draft allows different sessions with same prefix, e.g: > > Session1: [Pref1, MAG1, IF1, IF2] > Session2: [Pref1, MAG2, IF1, IF2] > > Right? In the nominal RFC 5213 model, a PMIPv6 session is defined as a prefix set, a MAG where the MN is attached, and an interface used by the MN to attach (i.e., ATT and LLID.) Session1: [{Pref_11,..., Pref_1p}, (MAG1, IF1)] Session2: [{Pref_21,..., Pref_2q}, (MAG2, IF2)] In flow mobility extension, I am proposing that we generalize this definition to allow for multiple attachment, as it's IMO the only _required_ extension to support flow mobility: Session1: [{Pref_11,..., Pref_1p}, {(MAG1, IF1), (MAG2, IF2)}] Session2: [{Pref_21,..., Pref_2q}, {(MAG2, IF2)}] --julien From sgundave@cisco.com Wed Feb 9 10:10:58 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 980E23A69F2 for ; Wed, 9 Feb 2011 10:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.981 X-Spam-Level: X-Spam-Status: No, score=-9.981 tagged_above=-999 required=5 tests=[AWL=0.618, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouiw6kDs7ruS for ; Wed, 9 Feb 2011 10:10:53 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id C39DA3A67A4 for ; Wed, 9 Feb 2011 10:10:52 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABhnUk2rRN+J/2dsb2JhbAClSHOgdJsqgwGCWwSEf4ZxgziDBA Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 09 Feb 2011 18:11:02 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p19IB2YI020725; Wed, 9 Feb 2011 18:11:02 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Feb 2011 10:11:02 -0800 Received: from 10.32.246.213 ([10.32.246.213]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Wed, 9 Feb 2011 18:11:01 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Wed, 09 Feb 2011 10:11:42 -0800 From: Sri Gundavelli To: Julien Laganier , Rajeev Koodli Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvIhM2N1y/VSwURHkWg8a8Va7guIQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 09 Feb 2011 18:11:02.0585 (UTC) FILETIME=[B60EC290:01CBC884] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 18:10:59 -0000 We want the LMA to dynamically add prefixes, pick a prefix based on the hour of the day, or based on the weather, create sessions unilaterally and also reboot the MN at its mercy. We can assume the LMA some how knows and is in communication with the oracle that has all the interfaces in place from the radio network, and has all the needed heuristics in place which tells as when to make all the state changes. Sure, we can define any thing we want, but we cannot completely ignore the target system architecture. Each requirement has to have some meaningful use-case with general consensus to do that work and the charter has to reflect that. To support this wish list, we can assume the mobile node has all the needed framework in place. It can mirror flows, it knows when to switch flows, it has an understanding of the completion of the network side signaling. Still its a simple mobile node, unmodified, but it is DPI enabled, which tracks what flows are coming what interfaces, so it can mirror. Who is building this UE ? We don't have to be restricted with the RFC-5213 signaling. If its needed or not, we should define a new signaling plane. One message interface from LMA to MAG and the other from MAG to LMA. We will define new sets of messages, new options, new number space and the MAG implementations will have two sets of timers and an advanced state machine. All of this to support a remote case of policy change. This is an impact to the implementations. We can do all of this, but before we make fundamental changes to the protocol that was discussed for over a period of two years and with industry-wide participation, we cannot allow it be undone in WG which has (7) people participation, with a single tone enforcing decisions, with unilateral wish list, backed by no framework that supports such requirements in any target system architecture. Finally, if we are talking about fundamental changes to the signaling model, it should be reflected in the charter. The AD needs to approve. As many pointed out, all the basic flow mobility functional requirements can be met, without "updating the legacy 5213 model". If the goal is to update that legacy model, we should start with a new protocol. Sri > In 3GPP, the prefix is assigned when the PDN connection is created, > and is then unchanged for the reminder of the lifetime of this PDN > connection. > On 2/8/11 7:07 PM, "Julien Laganier" wrote: > Hi Rajeev, > > On Tue, Feb 8, 2011 at 6:51 PM, Rajeev Koodli wrote: >> >> Hi Julien, >> >> On 2/8/11 5:25 PM, "Julien Laganier" wrote: >> >>> What would actually really helps all of us to make progress is that >>> instead of telling what you'd like, as in >> >> It would also help if you didn't generalize your reservation to what I am >> stating as in "..helps *all* of us..". > > I simply wanted to say that since I see no usecase to justify the type > of features you'd like to have in, having a usecase outlined would > help this discussion to converge, which seems to be helpful to people > on this mailing list. There was certainly no intent to say that my > reservations are shared by the whole working group. > > That being said, > >> I see you have a model in mind (which is pretty close to what is in the >> draft already), which is fine. I fail to see why you are restricted to that >> alone. But, perhaps that's less fruitful to delve into now. >> >> >>>> I would like LMA-initiated signaling (FMI/FMA) for this (i.e., signaling to >>>> MAG1 with Pref2) as well as for the above (i.e., being able to signal MAG2 >>>> with Pref1) *whenever* the LMA wants. >>> >>> you'd rather tell us why this is needed, by whom, and where... I've >>> been asking the same question over and over but nobody writes down an >>> answer to this in this thread. >> >> I have mentioned why I need it a few times. 1) I am not required to assign >> all the applicable prefixes at the time of attach *in anticipation* of >> *potential* flow mobility. I will assign a relevant prefix *if and when* I >> need to move a flow over. > > In 3GPP, the prefix is assigned when the PDN connection is created, > and is then unchanged for the reminder of the lifetime of this PDN > connection. > > So in your own words: You are not required to assign all the > applicable prefixes at the time of attach *in anticipation* of > *potential* flow mobility. You will assign the relevant prefix *if and > when* I you need a PDN connection. > > If you have another target system than 3GPP, what is it? > >> It makes no sense for me to be *forced* to assign >> all the prefixes at the time of attach (just because it is aligned with >> legacy RFC 5213 "model"). > > Assigning all the prefixes at time of attaches isn't a requirement for > flow mobility. You can very well have a single prefix and do flow > mobility across multiple interfaces. > > 2) I want to assign a > prefix based on policy >> triggers, including the TOD rules. > > I don't see how useful it is to assign prefixes based on time of day. > I understand you might want to move flows based on time of day, but as > I said above, you can already move flows with a single prefix when the > time is good for you. > > I want to > move certain type of traffic >> over to a different interface based on peak hour bulk stats, the volume of >> traffic the user is consuming at a particular instance, the amount of quota >> left and so on. > > All capabilities that are perfectly available without juggling with > multiple prefixes, as above. > >> I want to be able to refresh the lifetime of >> that prefix and >> revoke it back to its "natural interface" when I want. > > This is renumbering - a different interface. I also don't know what a > natural interface is when prefixes are assigned from withing an > overlay... > >> I want to be able to offer this for my customers. > > Most of which you can, as I stated above, independently of prefix juggling... > >>> Absent that, will I be forced to conclude that this needed by no-one? >> >> If I don't need something that does not imply the rest don't either! :-) > > Can they speak up then? :-) > > --julien > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From cjbc@it.uc3m.es Wed Feb 9 11:30:24 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A87A63A69F9 for ; Wed, 9 Feb 2011 11:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHrsFPNNTPve for ; Wed, 9 Feb 2011 11:30:22 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id B83283A6816 for ; Wed, 9 Feb 2011 11:30:22 -0800 (PST) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id EFE607F2F90; Wed, 9 Feb 2011 20:30:31 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Sri Gundavelli In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-gMm9wHQVBHG1qotObooK" Organization: Universidad Carlos III de Madrid Date: Wed, 09 Feb 2011 20:31:41 +0100 Message-ID: <1297279901.3444.32.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17946.000 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 19:30:24 -0000 --=-gMm9wHQVBHG1qotObooK Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Sri, On Tue, 2011-02-08 at 19:06 -0800, Sri Gundavelli wrote: >=20 >=20 > On 2/7/11 4:57 PM, "Carlos Jes=FAs Bernardos Cano" wrot= e: >=20 >=20 > >>=20 > >> I cannot emphasize more than this. We are not looking at flow manageme= nt as > >> an extended state of BCE entry, rather as some thing new. BCE state is > >> different and flow mobility state is different. We want to define our = own > >> brand of messages. > >>=20 > >> MAG is responsible for creating the session state and the request for = flow > >> mobility is carried right in that PBU message. The trigger from LMA to= MAG > >> is needed when policy changes and that is when it can send an FMI trig= ger. > >> No need for FMA, session management is always initiated by MAG. > >>=20 > >> The trigger in 99.99% of the times is coming from MAG. MN brings up an > >> interface/pulls down an interface and that triggers the LMA to apply a= flow > >> policy rules. But, the MAG sending a PBU is the trigger for flow mobil= ity. > >> LMA in most cases is learning the triggers from MAG, which is attached= to > >> MN, except for reasons of policy change, where there is a need to send= a > >> trigger to MAG to send a PBU and that is FMI message. > >=20 > > So we need to support both cases, agree? > >=20 >=20 > Both cases ? Do you agree, a simple FMI trigger is sufficient ? Both cases meaning trigger from MAG in PBU or LMA-initiated FMI/FMA. Whether its FMI/FMA or FMI/PBU/PBA is a very minor detail in this discussion (at this stage) Carlos >=20 >=20 >=20 > Sri >=20 >=20 >=20 >=20 > > Carlos > >=20 > >>=20 > >> Hope we can get some sense into this draft. > >>=20 > >>=20 > >> Sri > >>=20 > >>=20 >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-gMm9wHQVBHG1qotObooK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1S650ACgkQNdy6TdFwT2em8QCg4fFsu/DbXJIXQqpCdl/PRYkR VycAoL92p0U2YSdTf1UAEXTnSrmf4TXj =Jk/b -----END PGP SIGNATURE----- --=-gMm9wHQVBHG1qotObooK-- From sgundave@cisco.com Wed Feb 9 11:39:21 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35DCA3A6838 for ; Wed, 9 Feb 2011 11:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.406 X-Spam-Level: X-Spam-Status: No, score=-9.406 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9YDxoNiRBOl for ; Wed, 9 Feb 2011 11:39:20 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 5E7413A6821 for ; Wed, 9 Feb 2011 11:39:20 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAGADF8Uk2rRN+K/2dsb2JhbACXM403ZnOgQ5s1hVwEhH+GcYM4 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 09 Feb 2011 19:39:30 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p19JdUbt016277; Wed, 9 Feb 2011 19:39:30 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Feb 2011 11:39:30 -0800 Received: from 10.32.246.213 ([10.32.246.213]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Wed, 9 Feb 2011 19:39:30 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Wed, 09 Feb 2011 11:40:12 -0800 From: Sri Gundavelli To: Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvIkSqOzqLybhb3Q0+QMTVERJBm7w== In-Reply-To: <1297279901.3444.32.camel@acorde.it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 09 Feb 2011 19:39:30.0682 (UTC) FILETIME=[11EE15A0:01CBC891] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 19:39:21 -0000 Hi Carlos: On 2/9/11 11:31 AM, "Carlos Jes=FAs Bernardos Cano" wrote: > Hi Sri, >=20 > On Tue, 2011-02-08 at 19:06 -0800, Sri Gundavelli wrote: >>=20 >>=20 >> On 2/7/11 4:57 PM, "Carlos Jes=FAs Bernardos Cano" wrote= : >>=20 >>=20 >>>>=20 >>>> I cannot emphasize more than this. We are not looking at flow manageme= nt as >>>> an extended state of BCE entry, rather as some thing new. BCE state is >>>> different and flow mobility state is different. We want to define our = own >>>> brand of messages. >>>>=20 >>>> MAG is responsible for creating the session state and the request for = flow >>>> mobility is carried right in that PBU message. The trigger from LMA to= MAG >>>> is needed when policy changes and that is when it can send an FMI trig= ger. >>>> No need for FMA, session management is always initiated by MAG. >>>>=20 >>>> The trigger in 99.99% of the times is coming from MAG. MN brings up an >>>> interface/pulls down an interface and that triggers the LMA to apply a= flow >>>> policy rules. But, the MAG sending a PBU is the trigger for flow mobil= ity. >>>> LMA in most cases is learning the triggers from MAG, which is attached= to >>>> MN, except for reasons of policy change, where there is a need to send= a >>>> trigger to MAG to send a PBU and that is FMI message. >>>=20 >>> So we need to support both cases, agree? >>>=20 >>=20 >> Both cases ? Do you agree, a simple FMI trigger is sufficient ? >=20 > Both cases meaning trigger from MAG in PBU or LMA-initiated FMI/FMA. > Whether its FMI/FMA or FMI/PBU/PBA is a very minor detail in this > discussion (at this stage) >=20 Sure. The need for the trigger is the first issue to be resolved. Sri From julien.ietf@gmail.com Wed Feb 9 11:39:41 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7B963A69E2 for ; Wed, 9 Feb 2011 11:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.522 X-Spam-Level: X-Spam-Status: No, score=-3.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVKa-rBFL0ve for ; Wed, 9 Feb 2011 11:39:40 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 2359C3A6901 for ; Wed, 9 Feb 2011 11:39:39 -0800 (PST) Received: by ewy8 with SMTP id 8so395576ewy.31 for ; Wed, 09 Feb 2011 11:39:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nXBCRxj/6tUkH9IYMUSHgYsfHKzwMQtsD+cONW66PwQ=; b=jJWSyaVjJTjsbW/06pcbaDkij3dLxZsBVwM7MzLc3lKPuXZs3GdYs3gCLpeSGUHIR9 ASdcdYupEyeJkFrx1xlaG06dKiKG6SXfsXM3TzlzzvlPoXRrvBeYa/yCI7a8nPeRYsHp 36XRKwPI3X/2TokBM6PNIAdvOC4p8YMhRL5l4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=a9dFLFIyUMZ4yFYKTEjqRXZqnPd0BzNA+NL6kx8qmZxra58Pv2abjW/HFmc51OrikC O+f+VaBkHCof5ZWqJIAJQ9l9GLlOMnM5cT/5goA/13V6qVsTXQh1/zi/BCLLMMScum4K CFHBPV5zd24AJYjem2sQ1D6p/AVwVLVDSg40A= MIME-Version: 1.0 Received: by 10.103.192.12 with SMTP id u12mr11915951mup.75.1297280389435; Wed, 09 Feb 2011 11:39:49 -0800 (PST) Received: by 10.103.221.9 with HTTP; Wed, 9 Feb 2011 11:39:49 -0800 (PST) In-Reply-To: References: Date: Wed, 9 Feb 2011 11:39:49 -0800 Message-ID: From: Julien Laganier To: Sri Gundavelli Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 19:39:41 -0000 Sri: Well said. I couldn't agree more. --julien On Wed, Feb 9, 2011 at 10:11 AM, Sri Gundavelli wrote: > > We want the LMA to dynamically add prefixes, pick a prefix based on the h= our > of the day, or based on the weather, create sessions unilaterally and als= o > reboot the MN at its mercy. We can assume the LMA some how knows and is i= n > communication with the oracle that has all the interfaces in place from t= he > radio network, and has all the needed heuristics in place which tells as > when to make all the state changes. Sure, we can define any thing we want= , > but we cannot completely ignore the target system architecture. Each > requirement has to have some meaningful use-case with general consensus t= o > do that work and the charter has to reflect that. > > To support this wish list, we can assume the mobile node has all the need= ed > framework in place. It can mirror flows, it knows when to switch flows, i= t > has an understanding of the completion of the network side signaling. Sti= ll > its a simple mobile node, unmodified, but it is DPI enabled, which tracks > what flows are coming what interfaces, so it can mirror. Who is building > this UE ? > > We don't have to be restricted with the RFC-5213 signaling. If its needed= or > not, we should define a new signaling plane. One message interface from L= MA > to MAG and the other from MAG to LMA. We will define new sets of messages= , > new options, new number space and the MAG implementations will have two s= ets > of timers and an advanced state machine. All of this to support a remote > case of policy change. This is an impact to the implementations. > > We can do all of this, but before we make fundamental changes to the > protocol that was discussed for over a period of two years and with > industry-wide participation, we cannot allow it be undone in WG which has > (7) people participation, with a single tone enforcing decisions, with > unilateral wish list, backed by no framework that supports such requireme= nts > in any target system architecture. > > Finally, if we are talking about fundamental changes to the signaling mod= el, > it should be reflected in the charter. The AD needs to approve. As many > pointed out, all the basic flow mobility functional requirements can be m= et, > without "updating the legacy 5213 model". If the goal is to update that > legacy model, we should start with a new protocol. > > > > Sri > > > > > > >> In 3GPP, the prefix is assigned when the PDN connection is created, >> and is then unchanged for the reminder of the lifetime of this PDN >> connection. >> > > > > > On 2/8/11 7:07 PM, "Julien Laganier" wrote: > >> Hi Rajeev, >> >> On Tue, Feb 8, 2011 at 6:51 PM, Rajeev Koodli wrote: >>> >>> Hi Julien, >>> >>> On 2/8/11 5:25 PM, "Julien Laganier" wrote: >>> >>>> What would actually really helps all of us to make progress is that >>>> instead of telling what you'd like, as in >>> >>> It would also help if you didn't generalize your reservation to what I = am >>> stating as in "..helps *all* of us..". >> >> I simply wanted to say that since I see no usecase to justify the type >> of features you'd like to have in, having a usecase outlined would >> help this discussion to converge, which seems to be helpful to people >> on this mailing list. There was certainly no intent to say that my >> reservations are shared by the whole working group. >> >> That being said, >> >>> I see you have a model in mind (which is pretty close to what is in the >>> draft already), which is fine. I fail to see why you are restricted to = that >>> alone. But, perhaps that's less fruitful to delve into now. >>> >>> >>>>> I would like LMA-initiated signaling (FMI/FMA) for this (i.e., signal= ing to >>>>> MAG1 with Pref2) as well as for the above (i.e., being able to signal= MAG2 >>>>> with Pref1) *whenever* the LMA wants. >>>> >>>> you'd rather tell us why this is needed, by whom, and where... I've >>>> been asking the same question over and over but nobody writes down an >>>> answer to this in this thread. >>> >>> I have mentioned why I need it a few times. 1) I am not required to ass= ign >>> all the applicable prefixes at the time of attach *in anticipation* of >>> *potential* flow mobility. I will assign a relevant prefix *if and when= * I >>> need to move a flow over. >> >> In 3GPP, the prefix is assigned when the PDN connection is created, >> and is then unchanged for the reminder of the lifetime of this PDN >> connection. >> >> So in your own words: You are not required to assign all the >> applicable prefixes at the time of attach *in anticipation* of >> *potential* flow mobility. You will assign the relevant prefix *if and >> when* I you need a PDN connection. >> >> If you have another target system than 3GPP, what is it? >> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 It makes no sense f= or me to be *forced* to assign >>> all the prefixes at the time of attach (just because it is aligned with >>> legacy RFC 5213 "model"). >> >> Assigning all the prefixes at time of attaches isn't a requirement for >> flow mobility. You can very well have a single prefix and do flow >> mobility across multiple interfaces. >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 2) I want to assign a >> prefix based on policy >>> triggers, including the TOD rules. >> >> I don't see how useful it is to assign prefixes based on time of day. >> I understand you might want to move flows based on time of day, but as >> I said above, you can already move flows with a single prefix when the >> time is good for you. >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0I want to >> move certain type of traffic >>> over to a different interface based on peak hour bulk stats, the volume= of >>> traffic the user is consuming at a particular instance, the amount of q= uota >>> left and so on. >> >> All capabilities that are perfectly available without juggling with >> multiple prefixes, as above. >> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I want = to be able to refresh the lifetime of >>> that prefix and >>> revoke it back to its "natural interface" when I want. >> >> This is renumbering - a different interface. I also don't know what a >> natural interface is when prefixes are assigned from withing an >> overlay... >> >>> I want to be able to offer this for my customers. >> >> Most of which you can, as I stated above, independently of prefix juggli= ng... >> >>>> Absent that, will I be forced to conclude that this needed by no-one? >>> >>> If I don't need something that does not imply the rest don't either! :-= ) >> >> Can they speak up then? :-) >> >> --julien >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > > From julien.ietf@gmail.com Wed Feb 9 11:44:11 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEDD23A69CE for ; Wed, 9 Feb 2011 11:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.525 X-Spam-Level: X-Spam-Status: No, score=-3.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BW8rO9Id4IzD for ; Wed, 9 Feb 2011 11:44:11 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id B19F83A683D for ; Wed, 9 Feb 2011 11:44:10 -0800 (PST) Received: by eyd10 with SMTP id 10so390786eyd.31 for ; Wed, 09 Feb 2011 11:44:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HdYfkgeFzBybo7IsC72/ZYRTGjxG/2a1OwP0c5t+YXA=; b=FDke6db+Q6HO8aZqT7H431Z+4yaPKJefpRTIsjWV+SQjwx4WEra8AGDHigNnLKq64Z rcKwAEuPUcD/Xm3vwqPq5XdvLByj8ahX7WFNoneo48R6EXrW93itUQxV3gKYvBfzeIuL oB5b9lLx9VLHdCyJWpJZz5hSKH63Qc2yFW0Hc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Jqj+rYwB8CuXoRweO8uRZrbU0bmY8M4f2Xz9Bz9/a902Fu+qnup6RtjIEuOqwlWsVM QDmcUUWChoWJe6WviVc516/f7z8ca+EcWxnSyH+17tNkIDALhovwY3Mg2ZF9IZUx5xSO j8b3zIFeP++mRtYJR8SnAjvw6caqHD2T3Gm3I= MIME-Version: 1.0 Received: by 10.103.226.2 with SMTP id d2mr14738054mur.111.1297280660224; Wed, 09 Feb 2011 11:44:20 -0800 (PST) Received: by 10.103.221.9 with HTTP; Wed, 9 Feb 2011 11:44:20 -0800 (PST) In-Reply-To: <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CFFD@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> References: <1296920511.3773.25.camel@acorde.it.uc3m.es> <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6CFFD@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> Date: Wed, 9 Feb 2011 11:44:20 -0800 Message-ID: From: Julien Laganier To: "MELIA, TELEMACO (TELEMACO)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 19:44:11 -0000 Telemaco: On Tue, Feb 8, 2011 at 2:55 AM, MELIA, TELEMACO (TELEMACO) wrote: >> > The LMA needs to provide the prefix info to the MAG. This can be either in >> > PBA or in FMI (if not provided in PBA). >> >> The LMA can provide the prefix to the MAG at session creation, i.e., >> in the PBU. This information does not need to be (re)conveyed at flow >> movement. > > If different prefixes are assigned for different sessions, and we want > to move flows across interfaces, we need some kind of signaling to make > the MAG aware of the prefixes. It cannot be done at session creation, > since not all the interfaces necessarily attach simultaneously, > > Carlos > > > Exactly, in the charter we say sequentially or simultaneously. > We need to cover both cases. If we're about to do exegesis on our charter, let's get it done right. Exactly Not: The charter says sequentially or simulateously w.r.t. attachment, to cover the case of inter-technology handoffs (MN attaching to network with one interface instead of another, sequential attachment) and flow mobility (MN attaching simultaneously with more than one interface.) --julien From julien.ietf@gmail.com Wed Feb 9 11:50:28 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E2CF3A69E2 for ; Wed, 9 Feb 2011 11:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.907 X-Spam-Level: X-Spam-Status: No, score=-2.907 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4YgLMS5Fx3C for ; Wed, 9 Feb 2011 11:50:27 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 5F84D3A69BC for ; Wed, 9 Feb 2011 11:50:27 -0800 (PST) Received: by ewy8 with SMTP id 8so404584ewy.31 for ; Wed, 09 Feb 2011 11:50:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6AUmBBIznRWWEg3pDqlDuF/DgWMksCytuGhA46NAS98=; b=O8tpubEGhkMVZrcajvJ5ehSlQdQv1xTh+2uSHdmOuuEDoA4taA7vGec7FsR+LGxIV2 zgECpNCDsU7ASeSGW6iF5bUICyCulT+XYwHF2mcfRfccU5C20dPJZK3Fu9djm9pihCh9 h9Cm3FD83s8cy0v4iLgCMriDcHQOkscDmRsN4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ffLusqUs9Y+rhLqCeXwClcuZCPflWtxCf04Xz3W1b7X+XiNaP41/flgYATP0LBBtyV jIV4IxlZUXtiHd4c1dpcUvjxonkoz/4/Z0hXJR909viF2s4TstTu670iDVhIz+Rhll7W TqIncu0/E3e5FxucQP7WNzZsNHRXPvfo5myeU= MIME-Version: 1.0 Received: by 10.103.243.16 with SMTP id v16mr14585474mur.57.1297281036823; Wed, 09 Feb 2011 11:50:36 -0800 (PST) Received: by 10.103.221.9 with HTTP; Wed, 9 Feb 2011 11:50:36 -0800 (PST) In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462017D475F@ftrdmel0.rd.francetelecom.fr> References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C462017D475F@ftrdmel0.rd.francetelecom.fr> Date: Wed, 9 Feb 2011 11:50:36 -0800 Message-ID: From: Julien Laganier To: pierrick.seite@orange-ftgroup.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 19:50:28 -0000 Hi Pierrick, Please see my anwer inline below: On Wed, Feb 9, 2011 at 4:29 AM, wrote: > > Hi, > > My only concern is on step 8, Please see inline. > > Pierrick > >> -----Message d'origine----- >> De=A0: Julien Laganier [mailto:julien.ietf@gmail.com] >> Envoy=E9=A0: mardi 8 f=E9vrier 2011 23:19 >> =C0=A0: SEITE Pierrick RD-RESA-REN >> Cc=A0: yh21.han@gmail.com; rkoodli@cisco.com; netext@ietf.org; >> Basavaraj.Patil@nokia.com >> Objet=A0: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netex= t- >> pmipv6-flowmob as WG doc >> >> Hi Pierrick, >> >> I am going to intertwine the steps in your scenario below with the >> missing pieces of the big picture so that we are not doing an academic >> exercise but focusing on the real world: >> >> 1. when the MN first attaches with if1 to a network, MAG1 requests >> attachment of if1 to a session1 by sending a PBU to LMA >> >> 2. because the MN add no session1 previously, the LMA creates session >> 1 and allocates a prefix for it. The prefix is sent back to MAG1 in >> the PBA: >> >> =A0=A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1-IF1] >> >> 3. then, if the MN attaches with if2 to another network, but does not >> request this interface be attached to a distinct session, MAG2 >> requests attachemnt of If2 to session1 by sending a PBU to LMA >> >> 4. Because the MN already has session 1, the LMA updates session1 with >> if2, and send the pref1 back to MAG2 in the PBA: >> >> =A0=A0 =A0 =A0 =A0 Session1: [Pref1, MAG1-IF1, MAG2-IF2] >> >> 5. Creation of a new session 2 for if2 is requested by either of MN >> requests via L2 triggers, or a change in policy profile. As a result, >> MAG2 requests attachment of if2 to session2 by sending a PBU to LMA. >> >> 6. because the MN add no session2 previously, the LMA creates session >> 2 and allocates a prefix for it. The prefix pref2 is sent back to MAG2 >> in the PBA: >> >> =A0=A0 =A0 =A0 =A0 =A0Session2: [Pref2, MAG2-IF2] >> >> 7. Flow2 starts over if2 with prefix2. >> >> 8. Attachment of if1 to session2 is requested by either of MN requests >> via L2 triggers, or a change in policy profile. As a result, MAG1 >> requests attachment of if1 to session2 by sending a PBU to LMA. >> > > But the MN is already attached to MAG1 via If1. So, without being too 3GP= P specific, what kind of L2 triggers can be used? Being 3GPP specific: Additional PDN Connectivity Request. Without being 3GPP specific, a L2 trigger requesting creation of an additional session. > To be more generic, I think that, for this case (attach a working interfa= ce to a new session), we could have LMA/MAG signalling, maybe as an option?= The use-case I have in mind is a short-term deployment of PMIP IP flow mob= ility over WiFi and 3GPP networks. Because, it is a short term deployment, = I have to use legacy 3G network (i.e. without LTE or inter-systems mobility= mechanisms); so the 3G network must be agnostic of PMIP support and I can'= t rely on L2 to trigger PMIP. If you have no L2 trigger you cannot even use RFC5213 PMIP as the MAG has no way to detect a MN attached and initiate PBU towards LMA. If your "3G network must be agnostic of PMIP support", PMIP is a no go. (you could use MIPv6, it works well over an unmodified 3G network as it is a full overlay.) --julien From julien.ietf@gmail.com Wed Feb 9 11:58:44 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 332803A6901 for ; Wed, 9 Feb 2011 11:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6RgQrxATl2K for ; Wed, 9 Feb 2011 11:58:43 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 133903A6826 for ; Wed, 9 Feb 2011 11:58:42 -0800 (PST) Received: by eyd10 with SMTP id 10so401940eyd.31 for ; Wed, 09 Feb 2011 11:58:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zMnBXEPvNnW1vpZRaUACE3kUV8zx/8+F3I+8E57Sy0E=; b=IW1j/gsygGCuNcOjlDlA/WdmMPX99gScjcs/l8HoZ/rDJ/rA9xGXr+oP/J2l981ykZ NTMIB/SqR40C+5iJ6dBTX2ea1XUoY9/z+mLHUL116WnaH0N84FmhG6uZE5PdS5Cwl2DM FfXn77IDeuxBTEOKK5njM3YlxDO//zAtvmxkQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Q/y0DtT63XAOWQ0E3pFrwhBuwl5IfmWF+jjnr/PpwmhPXpJSTPAZmWngu+m6XrTQE2 Lcc6+3hlkgQv4yTeCprrd5D902/UonHJQywlsMj0qKMk8AwoELtu5obWih/fsS+x42s8 pypL31Phb8EdkpotkYd99yBk5HA+FbxjZ5eTA= MIME-Version: 1.0 Received: by 10.103.199.18 with SMTP id b18mr14574400muq.21.1297281532508; Wed, 09 Feb 2011 11:58:52 -0800 (PST) Received: by 10.103.221.9 with HTTP; Wed, 9 Feb 2011 11:58:52 -0800 (PST) In-Reply-To: <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6D1F7@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> References: <1296920514.3773.26.camel@acorde.it.uc3m.es> <1297017501.4715.2.camel@acorde.it.uc3m.es> <1297019696.4715.5.camel@acorde.it.uc3m.es> <1297115574.3099.3.camel@acorde.it.uc3m.es> <1297126584.3099.96.camel@acorde.it.uc3m.es> <1297129998.3099.140.camel@acorde.it.uc3m.es> <1297208236.5169.80.camel@acorde.it.uc3m.es> <1297217553.5169.88.camel@acorde.it.uc3m.es> <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6D1F7@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> Date: Wed, 9 Feb 2011 11:58:52 -0800 Message-ID: From: Julien Laganier To: "MELIA, TELEMACO (TELEMACO)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 19:58:44 -0000 Telemaco, On Wed, Feb 9, 2011 at 7:17 AM, MELIA, TELEMACO (TELEMACO) wrote: > But why we cannot design a model where we can dynamically group sessions? > Mobile operators have been fighting hard in the past years the disconnection between ARPU and associated cost per users (in other words costs increase but revenues continue to fall). Data explosion is one of the reasons for such disconnection. > I believe that network operators would be eager to learn about innovating technologies to reduce costs expenditures. The work we are pushing with this ID falls exactly in this category. Restricting to the legacy PMIPv6 model is a limitation. > > I would be glad to hear opinions from other (different) voices. It could indeed be interesting to hear from network operators that are eager to learn about innovating technologies to reduce costs expenditures :-) I however don't understand what is the relation between an hypothetical eagerness to learn about innovating technologies to reduce costs expenditures on one hand, and the design of a flow mobility extension for PMIPv6 on the other hand. Neither with ARPU, revenue, and data explosion. Can we stay focused on technical discussions that in-scope for this ML please? --julien From julien.ietf@gmail.com Wed Feb 9 12:05:18 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 647ED3A69E3 for ; Wed, 9 Feb 2011 12:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=-0.992, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SY3vWosO+pd for ; Wed, 9 Feb 2011 12:05:17 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 99C3C3A69CE for ; Wed, 9 Feb 2011 12:05:16 -0800 (PST) Received: by eyd10 with SMTP id 10so406711eyd.31 for ; Wed, 09 Feb 2011 12:05:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YLRAV4pdmrntHMPk58PB2WeqMR/1wdDaa1g4dBSLCFM=; b=JNhhnu0q9d/+LSinek+NmVwfEKWOZB8WNoub7qaphPoLYOvoSyJYEfFN16YS57IkSX bSMqHWZtEiTnvvnxXNtLC4F12cHfQHdA37F+6OrayuxiFTXRe6x57p95WZcN9DEm2HZr Wr1sv3xAgtiKZBRQRSGWstHPe6Z8xWf+xXrQI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YLfM/1f31a8/NbLwwOpkfv4pTXvjog5wjdPtKYeMF5uu0SCGE68qu3ptxBIob+S6b/ 8FqUFf7PctSzkBsSvFYP3s3sqA7YDxGhMENqE3F6OdKAfsY8mllGCJWRRjV4T83MIBW+ fBwV1Tupnv6r+l+XUm3UGLqMJ+ApHywbOBTOg= MIME-Version: 1.0 Received: by 10.103.243.16 with SMTP id v16mr14604037mur.57.1297281925934; Wed, 09 Feb 2011 12:05:25 -0800 (PST) Received: by 10.103.221.9 with HTTP; Wed, 9 Feb 2011 12:05:25 -0800 (PST) In-Reply-To: <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6D206@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6D206@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> Date: Wed, 9 Feb 2011 12:05:25 -0800 Message-ID: From: Julien Laganier To: "MELIA, TELEMACO (TELEMACO)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 20:05:18 -0000 Telemaco: You prove my point. To your "Why?", I answer -- Because: Q: How does the LMA knows the terminal is connected? A: Because the MAG sent a PBU based on an L2 trigger. Q: How does the LMA knows coverage is OK? A: It has no clue. WiFi could be terrible and the MN still attached to it. Q: How does the LMA know the terminal is ready to receive traffic on any interfaces? A: It doesn't know, unless all prefixes of the prefix set associated to a session are made available through all of the interface. Which is incidentally exactly the model I am advocating for since the beginning of this discussion on the basis that it is the only thing needed for flow mobility. --julien On Wed, Feb 9, 2011 at 7:35 AM, MELIA, TELEMACO (TELEMACO) wrote: > Why? If the terminal is connected and radio coverage is ok it also means = it is ready to receive traffic on any of the interfaces right? Up the LMA t= o route flows. > > telemaco > > -----Message d'origine----- > De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la par= t de Julien Laganier > Envoy=E9=A0: mercredi 9 f=E9vrier 2011 03:54 > =C0=A0: Tran Minh Trung > Cc=A0: netext@ietf.org; Basavaraj.Patil@nokia.com > Objet=A0: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext= -pmipv6-flowmob as WG doc > > Changing the policy on the network side alone isn't sufficient. You'd > have to change the policy on the host, too (e.g., using ADNSF in 3GPP) > which will trigger the MN to attach IF1 to session 2. > > This is the system view picture which seems we're missing in this discuss= ion. > > --julien > > On Tue, Feb 8, 2011 at 6:49 PM, Tran Minh Trung w= rote: >> Hi Julien, >> >> Let me show a real case for the scenario that we are discussing bellow: >> >> The network policy is changed and the LMA decides to move flow 2 from >> IF2 to IF1 before MAG1 received L2 trigger from the MN (say before >> step #8) >> In that case, the LMA should signal MAG1 to send PBU to attach IF1 to >> session 2. >> >> Without signaling from LMA how can you do in this case? Just wait >> until receiving L2 trigger from the MN? >> >> On Wed, Feb 9, 2011 at 7:18 AM, Julien Laganier = wrote: >>> Hi Pierrick, >>> >>> I am going to intertwine the steps in your scenario below with the >>> missing pieces of the big picture so that we are not doing an academic >>> exercise but focusing on the real world: >>> >>> 1. when the MN first attaches with if1 to a network, MAG1 requests >>> attachment of if1 to a session1 by sending a PBU to LMA >>> >>> 2. because the MN add no session1 previously, the LMA creates session >>> 1 and allocates a prefix for it. The prefix is sent back to MAG1 in >>> the PBA: >>> >>> =A0=A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1-IF1] >>> >>> 3. then, if the MN attaches with if2 to another network, but does not >>> request this interface be attached to a distinct session, MAG2 >>> requests attachemnt of If2 to session1 by sending a PBU to LMA >>> >>> 4. Because the MN already has session 1, the LMA updates session1 with >>> if2, and send the pref1 back to MAG2 in the PBA: >>> >>> =A0=A0 =A0 =A0 =A0 Session1: [Pref1, MAG1-IF1, MAG2-IF2] >>> >>> 5. Creation of a new session 2 for if2 is requested by either of MN >>> requests via L2 triggers, or a change in policy profile. As a result, >>> MAG2 requests attachment of if2 to session2 by sending a PBU to LMA. >>> >>> 6. because the MN add no session2 previously, the LMA creates session >>> 2 and allocates a prefix for it. The prefix pref2 is sent back to MAG2 >>> in the PBA: >>> >>> =A0=A0 =A0 =A0 =A0 =A0Session2: [Pref2, MAG2-IF2] >>> >>> 7. Flow2 starts over if2 with prefix2. >>> >>> 8. Attachment of if1 to session2 is requested by either of MN requests >>> via L2 triggers, or a change in policy profile. As a result, MAG1 >>> requests attachment of if1 to session2 by sending a PBU to LMA. >>> >>> 9. Because the MN already has session 2, the LMA updates session2 with = if1: >>> >>> =A0=A0 =A0 =A0 =A0 Session2: [Pref2, MAG2-IF2, MAG1-IF1] >>> >>> 10. At any point, the LMA decides to move Flow2 between two interfaces >>> of session 2, and it does so. >>> >>> That's all that needed. It maps perfectly to 3GPP. If you have in mind >>> a different system in whcih that doesn't map, please let me know. >>> >>> --julien >>> >>> On Tue, Feb 8, 2011 at 8:25 AM, =A0 = wrote: >>>> Hi, >>>> >>>> Going through this long thread :-), it seems we could agree on the fol= lowing (just a tentative to summarize): >>>> >>>> Sessions should be created/updated with all available interfaces. Rewr= iting Tran's example: when the MN attaches to MAG1 via If1, the LMA creates= session 1: >>>> >>>> =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] >>>> >>>> Then, if the MN attaches to MAG2 via If2, the LMA creates session 2 wi= th both If1 and If2. The LMA also updates session 1 with If2: >>>> >>>> =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] >>>> =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2, IF1] >>>> >>>> MAG2 receives prefixes 1 and 2 in PBA but MAG1 is not sending PBU. So,= if the LMA wants to move flow with Pref2 from if2 to If1, the LMA needs to= provide Pref2 to MAG1. Also, the LMA should be able to create new sessions= with already up interfaces, e.g. if1 and if2. To address both issues, PBU = from MAG1 could be triggered (triggering is to be clarified) or we could de= fine LMA/MAG specific L3 signalling (FMI/FMA). >>>> >>>> My 2 cents, >>>> Pierrick >>>> >>>>> -----Message d'origine----- >>>>> De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la= part >>>>> de Youn-Hee Han >>>>> Envoy=E9=A0: mardi 8 f=E9vrier 2011 12:00 >>>>> =C0=A0: 'Julien Laganier'; 'Rajeev Koodli' >>>>> Cc=A0: netext@ietf.org; Basavaraj.Patil@nokia.com >>>>> Objet=A0: Re: [netext] Consensus call to adopt I-D:draft-bernardos-ne= text- >>>>> pmipv6-flowmob as WG doc >>>>> >>>>> Hi Julien, >>>>> >>>>> > -----Original Message----- >>>>> > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On B= ehalf >>>>> > Of Julien Laganier >>>>> > Sent: Tuesday, February 08, 2011 1:38 PM >>>>> > To: Rajeev Koodli >>>>> > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com >>>>> > Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos- >>>>> > netext-pmipv6-flowmob as WG doc >>>>> > >>>>> > On Mon, Feb 7, 2011 at 6:15 PM, Rajeev Koodli w= rote: >>>>> > > >>>>> > > If flow mobility has nothing do with prefix management, I am lost= . >>>>> > >>>>> > No reason to be lost: Prefix management is how do I get prefix for = the >>>>> > MN. Flow mobility is how to I move flows across interfaces. The two >>>>> > needs not to be intertwined together, as I've shown in my other not= es. >>>>> > E.g., I can do flow mobility without adding/deleting prefixes from >>>>> > sessions, and vice versa. >>>>> >>>>> Yes, I agree with you. Flow mobility is how to move flows across inte= rface. >>>>> So, I thought that it would be better to define "a flow" exactly in n= etext >>>>> WG prior to discuss flow mobility management. As the definition of "a >>>>> flow", >>>>> all I can think is a five-tuple plus something. If we assume that it = is >>>>> correct, I think that flow mobility and prefix addition are inevitabl= y >>>>> tied. >>>>> As you know, RFC5213 (and IPv6 protocol spec) already allow to assign >>>>> multiple prefixes across multiple interfaces of an MN. Yes, I also ag= ree >>>>> with you that in real-world (3GPP), there may be no need to assign >>>>> multiple >>>>> prefixes into an MN. (if somebody knows its necessity, please tell me= when >>>>> it should happen). So, flow mobility can be done without adding prefi= xes. >>>>> However, different interfaces are allowed to be assigned different >>>>> prefixes >>>>> by RFC 5213 and IPv6 spec. We can't expect what kind of prefixes an M= AG >>>>> advertises. Therefore, sometimes, we need prefix addition to move a f= low >>>>> to >>>>> a new interface of which MAG does not yet advertise the prefix of the= flow >>>>> being moved. >>>>> >>>>> (snip...) >>>>> >>>>> > >> I see no reason to depart from that in the context of extending = the >>>>> > >> protocol to support mobility, nor I am aware of any system >>>>> > >> architecture that would require this capability. >>>>> > > >>>>> > > Okay, see your position. I see it differently. I don't need to be >>>>> > > bound by some "presumed implementation model" of PMIP6 and limit >>>>> > > myself *only* to a prefix assignment model you are imagining. >>>>> > >>>>> > It's not an implementation model, it is a protocol model, and it's = not >>>>> > imaginary. Implementation has nothing to do with this. >>>>> > >>>>> > There's no reason to extend prefix assignment model to do flow mobi= lity >>>>> > unless you can point me out in which real world context your scenar= io >>>>> > actually happens. >>>>> >>>>> As I insisted in the old mail, I agree with Julien in this regard. Cu= rrent >>>>> draft allows too much space regarding the prefix allocation model (un= ique, >>>>> shared, and hybrid). When a flow should be moved to a new interface a= nd >>>>> the >>>>> prefix which the flow uses is not yet advertised by the new MAG, just >>>>> inform >>>>> the prefix to the MAG and thus make it advertise the prefix and setup= the >>>>> tunnel based on the new prefix. That's all!. If the prefix is already >>>>> advertised by the MAG, there is nothing to do and just move the flow.= This >>>>> behaviors are very natural one when we want to support IP-level mobil= ity. >>>>> >>>>> > >> If this is something really important, the WG can be rechartered= to >>>>> > >> work on a different extension that would allow adding/removing >>>>> > >> prefixes from existing PMIPv6 sessions. >>>>> > > >>>>> > > Huh.. What in the current charter forces us not to have the LMA >>>>> > > add/refresh/delete a prefix on-demand? >>>>> > >>>>> > Engineering is about finding a solution to a problem. Adding/deleti= ng >>>>> > prefix on-demand is not a solution to flow mobility. I've shown you= how >>>>> > to do flow mobility without this capability. >>>>> >>>>> From the viewpoint of protocol, I think that at least, prefix additio= n to >>>>> an >>>>> interface is a necessary function to support flow mobility, as I expl= ained >>>>> above. But, it does not mean prefix addition should happen always whe= never >>>>> flow mobility occurs. It is sometimes needed. >>>>> >>>>> > Now a different engineering problem would be: how to add/delete pre= fixes >>>>> > to a PMIPv6 session, and that would be useful for e.g. >>>>> > renumbering. This is a different problem that we haven't been chart= ered >>>>> > to work on. >>>>> >>>>> Prefix addition is just prefix addition. IMHO, renumbering is closer = to >>>>> prefix change. We just harness that function to support IP-level mobi= lity. >>>>> >>>>> Youn-Hee >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> >> >> -- >> Ph.D., Senior Member >> Electronics and Telecommunications Research Institute >> Standards Research Center >> 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA >> Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 >> > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From julien.ietf@gmail.com Wed Feb 9 12:11:49 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD8163A6901 for ; Wed, 9 Feb 2011 12:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnPMFuTAp4BA for ; Wed, 9 Feb 2011 12:11:48 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 9E6003A6826 for ; Wed, 9 Feb 2011 12:11:48 -0800 (PST) Received: by eyd10 with SMTP id 10so411200eyd.31 for ; Wed, 09 Feb 2011 12:11:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jL58s93dGE/6C6cbZesHNtMlASntoim7E8Wh3sQMpo0=; b=WJcEpFW98KlmtgaLPLIF2pV15P7TbYa3SKcBnUwNN/Re1r180ErMwbG5Jut5mkm7Yw NDsi6z2OIe4EHHzeHVOehSTk+JDv6mWvdXMgha4l1e8in6GUFAhEfntWcsSxNjQcsMyr 7v9H68D/o33rNh5sNyjEHzB36PhfMdgNJuyzU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ez9csTwB19aVSNw1z+LUWLYQjeQ/p+TNbymNEV1BwR5WZt6bstXWAnChdUbjvmd5af fCBp8vTarJYv0/4gL2VzhK9aIBq330ShEkO0pyxlErJyADu/7OjG5KgAL9HKkbSM4NNg s5Z/I6u4ZXx0AwIJ/BllegtAg3Rnn4jeVN1v4= MIME-Version: 1.0 Received: by 10.103.108.10 with SMTP id k10mr3146684mum.39.1297282317884; Wed, 09 Feb 2011 12:11:57 -0800 (PST) Received: by 10.103.221.9 with HTTP; Wed, 9 Feb 2011 12:11:57 -0800 (PST) In-Reply-To: References: Date: Wed, 9 Feb 2011 12:11:57 -0800 Message-ID: From: Julien Laganier To: Rajeev Koodli Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 20:11:49 -0000 On Wed, Feb 9, 2011 at 9:15 AM, Rajeev Koodli wrote: > > On 2/8/11 7:10 PM, "Tran Minh Trung" wrote: > >> On Wed, Feb 9, 2011 at 12:00 PM, Julien Laganier >> wrote: >>> Network based flow mobility cannot be entirely transparent to the MN. >>> It can be made transparent to the *IP layer* on the MN, but at minimum >>> the layer 2 will have to change to decide where to send uplink >>> packets. >>> >> >> Did we agreed that the logical interface can send uplink packets >> following the path that down-link packets received?. > > I thought we did, a while back. I don't think we did agree on this. To start with there are a number of situations where the logical interfaces can match uplink packets with downlink packets from a same flow. >> The key purpose of network-based solution is minimize the involvement of the >> MN. >> IMHO, both vendors and network operator prefer that way. > > I tend to agree. It's all nice to hear your guys opinion on what operators preferences are but that is pretty useless in this discussion unless said operator speak up for themselves. --julien From julien.ietf@gmail.com Wed Feb 9 12:13:33 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D45683A69E2 for ; Wed, 9 Feb 2011 12:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.49 X-Spam-Level: X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgBmr8SE77LE for ; Wed, 9 Feb 2011 12:13:30 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 13A433A69CE for ; Wed, 9 Feb 2011 12:13:29 -0800 (PST) Received: by eyd10 with SMTP id 10so412375eyd.31 for ; Wed, 09 Feb 2011 12:13:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xsM9xCdbr/lQqDx+A7xp0kA0P6T2yhAthnl7j9nVSbg=; b=dN8RAA1DF1EBY6EXqEB3VKdrXL+BJbB+4KmZWeMpjZVWScAO+g2w+bibf3J8Nt/FSb h+oQdCVan60AvkZt8TFX5gRMKfNa/YdQa7syEEVu6Ig92OkfZfltoxRxsl1JlYO8PVGZ L+6z/UIfouVFn4A3JtJpdgYa6SwJdTDIZF0ZU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Kd6+Jw7iN5ahlA/Db0T1F1QV9ycTRZIHcB1a5lH3doe35/ixEeCJjcLBhOpnuOR3Ht ggliH6gkYCvQYOJ6UjA/8HxBa6wTL1sAbasyMSyzZr0QZG2WC6r6wezFlTEmljhD7k7J +nwgIbratVnjnDOrxDNESDx1Tqq3gDhN8YpQI= MIME-Version: 1.0 Received: by 10.103.243.16 with SMTP id v16mr14614598mur.57.1297282419455; Wed, 09 Feb 2011 12:13:39 -0800 (PST) Received: by 10.103.221.9 with HTTP; Wed, 9 Feb 2011 12:13:39 -0800 (PST) In-Reply-To: References: <680854867F7FD04BB9B06EB8ACA8D5AC05EFEC1B@XCH02DFW.rim.net> Date: Wed, 9 Feb 2011 12:13:39 -0800 Message-ID: From: Julien Laganier To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 20:13:33 -0000 Raj, I'd go a bit further than you did below and say that IMHO "Understanding the use cases for the feature is a requirement." --julien On Wed, Feb 9, 2011 at 9:19 AM, wrote: > > Stefano, > > Lets not talk about ARPU or other aspects of operator issues which are IM= O > not really helping this discussion. > > But regarding the question of whether there is an open and declared > customer, I don=E2=80=99t know if the WG really needs to answer that. > The point is that we have defined a network based mobility protocol > (RFC5213) in the IETF. There is a community of people in the WG which > believes that extending the protocol to support flow mobility will addres= s > some scenarios and use cases. The applicability =C2=A0of such a feature i= n 3GPP > architectures is to some extent open. > I think we should be doing the work and specifying the solution. > Understanding the use cases for the feature is good. But I think we do no= t > have to go overboard in terms of verifying the customer existence or > interest. > > -Raj > > On 2/9/11 11:08 AM, "ext Stefano Faccin" wrote: > >>Telemaco, >>All that you say is good, apart from one detail. I do not believe that >>here in IETF we should be talking about ARPU and costs and so on. We are >>just not capable of evaluating them. If indeed as you say this solution >>were the magic answer to operator issues, I am sure operators in 3GPP >>would have shown a bigger interest in it. My previous question on whether >>we have an open and declared customer for this solution (i.e. that >>clearly stated this is needed) is still unanswered, so perhaps there >>isn't indeed such an interest in this magic solution? >>Cheers, >>Stefano Faccin >> >>Standards Manager >>Research In Motion Corporation >>5000 Riverside Drive >>Building 6, Brazos East, Ste. 100 >>Irving, Texas 75039 USA >>Office: (972) 910 3451 >>Internal: 820.63451 >>: (510) 230 8422 >>www.rim.com; www.blackberry.com >> >> >> >>=EF=81=90 Consider the environment before printing. >> >> >>-----Original Message----- >>From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf >>Of MELIA, TELEMACO (TELEMACO) >>Sent: Wednesday, February 09, 2011 7:18 AM >>To: Julien Laganier; cjbc@it.uc3m.es >>Cc: netext@ietf.org; Basavaraj.Patil@nokia.com >>Subject: Re: [netext] Consensus call to adopt I-D: >>draft-bernardos-netext-pmipv6-flowmob as WG doc >> >>But why we cannot design a model where we can dynamically group sessions? >>Mobile operators have been fighting hard in the past years the >>disconnection between ARPU and associated cost per users (in other words >>costs increase but revenues continue to fall). Data explosion is one of >>the reasons for such disconnection. >>I believe that network operators would be eager to learn about innovating >>technologies to reduce costs expenditures. The work we are pushing with >>this ID falls exactly in this category. Restricting to the legacy PMIPv6 >>model is a limitation. >> >>I would be glad to hear opinions from other (different) voices. >> >>telemaco >> >>-----Message d'origine----- >>De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part >>de Julien Laganier >>Envoy=C3=A9 : mercredi 9 f=C3=A9vrier 2011 03:20 >>=C3=80 : cjbc@it.uc3m.es >>Cc : Basavaraj.Patil@nokia.com; netext@ietf.org >>Objet : Re: [netext] Consensus call to adopt I-D: >>draft-bernardos-netext-pmipv6-flowmob as WG doc >> >>Hi Carlos, >> >>2011/2/8 Carlos Jes=C3=BAs Bernardos Cano : >>> Hi Julien, >>> >>> On Tue, 2011-02-08 at 17:21 -0800, Julien Laganier wrote: >>>> Hi Carlos, >>>> >>>> I am glad to see you agree with me :-) >>>> >>>> You're actually proving my point. >>>> >>>> To run any of the flow mobility stuff on a host, you will need either >>>> layer 2 to hide the dissimilar interfaces (virtual interface thing), >>>> in which case you do have L2 triggers, or to modify the layer 3, which >>>> this WG is explicitly prevented from doing assuming that's even >>>> possible. >>>> >>>> So you need layer 2. And that is actually exactly how netext could get >>>> chartered to work on flow mobility, because we assumed layer 2 would >>>> be there to help with all the stuff we're not allowed to do at layer >>>> 3. >>> >>> Exactly, you need layer 2 to help with all the stuff we are not allowed >>> to do at layer 3, _but_ not to do things that we don't need to do at th= e >>> MN, and can be trivially done with LMA-MAG signaling without putting >>> strong requirements on the layer 2. >>> >>> The signaling we define in our draft (or variations around that) allows >>> to support all the scenarios that have been mentioned so far, and does >>> not break any PMIPv6 concept -- just extends it. It does not require >>> complex layer 2 triggers/policies to be in place and it's therefore mor= e >>> layer-2 agnostic. Still, you prefers to go for the "lets redo MIP at >>> layer-2", and I keep failing to see why >> >>PMIPv6 as per RFC5213 doesn't work without L2 triggers, so there's no >>value in extending PMIPv6 to spare relying on L2 triggers that are >>required anyway. >> >>--julien >> >>--julien >>_______________________________________________ >>netext mailing list >>netext@ietf.org >>https://www.ietf.org/mailman/listinfo/netext >>_______________________________________________ >>netext mailing list >>netext@ietf.org >>https://www.ietf.org/mailman/listinfo/netext >> >>--------------------------------------------------------------------- >>This transmission (including any attachments) may contain confidential >>information, privileged material (including material protected by the >>solicitor-client or other applicable privileges), or constitute >>non-public information. Any use of this information by anyone other than >>the intended recipient is prohibited. If you have received this >>transmission in error, please immediately reply to the sender and delete >>this information from your system. Use, dissemination, distribution, or >>reproduction of this transmission by unintended recipients is not >>authorized and may be unlawful. > > From julien.ietf@gmail.com Wed Feb 9 12:15:40 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD1193A69F8 for ; Wed, 9 Feb 2011 12:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.493 X-Spam-Level: X-Spam-Status: No, score=-3.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ao05hN1ypBKm for ; Wed, 9 Feb 2011 12:15:39 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id F01C43A69F1 for ; Wed, 9 Feb 2011 12:15:38 -0800 (PST) Received: by eyd10 with SMTP id 10so413863eyd.31 for ; Wed, 09 Feb 2011 12:15:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0Ne2noyCpNdIlHaEFWexX6TTYPkSMROb/55PQe3dA6g=; b=wrPqJLP1Cuzho2fNESDLkG6YN7nhvjZuAzd4fOTp5OVhbOtmUuYBhvZVH8boRCKysa 6WL6PH1m2S2YF4cukegGO/VkWlHErHDqzyWH1RyiIJKb9Ucz8PkPWfyCUjFxWY+azHeQ 42C5demgzdkP57sH9NV+ny/hSB4BgaG73Z1oY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=MxnPABDcZ9GIE7MVPGrhGyEiFiqwhxOwxowBeGbpxmW/fmTVTa2K9bOv2obefvA29F 09znELRbzwz+oxwjIqrXoG93ClIrYkZfUTx9pvClPNsZ9inguKArOtlU8JEM3r5Ojk5u ModkOg5Wv7Bcu5liKtncc10SqEvN/7E3pIxZw= MIME-Version: 1.0 Received: by 10.103.124.3 with SMTP id b3mr791926mun.3.1297282547758; Wed, 09 Feb 2011 12:15:47 -0800 (PST) Received: by 10.103.221.9 with HTTP; Wed, 9 Feb 2011 12:15:47 -0800 (PST) In-Reply-To: References: <680854867F7FD04BB9B06EB8ACA8D5AC05EFEC1B@XCH02DFW.rim.net> Date: Wed, 9 Feb 2011 12:15:47 -0800 Message-ID: From: Julien Laganier To: "Zuniga, Juan Carlos" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 20:15:40 -0000 Juan-Carlos - I am a bit puzzled by your statement below. Which arguments in this discussion do you consider as religious? Thanks, --julien On Wed, Feb 9, 2011 at 9:44 AM, Zuniga, Juan Carlos wrote: > +1 > > I support the idea from Pierrick and Raj to stop going in circles with re= ligious arguments and concentrate on the solution at hand, which responds t= o what the WG is chartered to do. > > >> -----Original Message----- >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On >> Behalf Of Basavaraj.Patil@nokia.com >> Sent: February 9, 2011 12:19 PM >> To: sfaccin@rim.com; telemaco.melia@alcatel-lucent.com; >> julien.ietf@gmail.com; cjbc@it.uc3m.es >> Cc: netext@ietf.org >> Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos- >> netext-pmipv6-flowmob as WG doc >> >> >> Stefano, >> >> Lets not talk about ARPU or other aspects of operator issues which are >> IMO >> not really helping this discussion. >> >> But regarding the question of whether there is an open and declared >> customer, I don=E2=80=99t know if the WG really needs to answer that. >> The point is that we have defined a network based mobility protocol >> (RFC5213) in the IETF. There is a community of people in the WG which >> believes that extending the protocol to support flow mobility will >> address >> some scenarios and use cases. The applicability =C2=A0of such a feature = in >> 3GPP >> architectures is to some extent open. >> I think we should be doing the work and specifying the solution. >> Understanding the use cases for the feature is good. But I think we do >> not >> have to go overboard in terms of verifying the customer existence or >> interest. >> >> -Raj >> >> On 2/9/11 11:08 AM, "ext Stefano Faccin" wrote: >> >> >Telemaco, >> >All that you say is good, apart from one detail. I do not believe that >> >here in IETF we should be talking about ARPU and costs and so on. We >> are >> >just not capable of evaluating them. If indeed as you say this >> solution >> >were the magic answer to operator issues, I am sure operators in 3GPP >> >would have shown a bigger interest in it. My previous question on >> whether >> >we have an open and declared customer for this solution (i.e. that >> >clearly stated this is needed) is still unanswered, so perhaps there >> >isn't indeed such an interest in this magic solution? >> >Cheers, >> >Stefano Faccin >> > >> >Standards Manager >> >Research In Motion Corporation >> >5000 Riverside Drive >> >Building 6, Brazos East, Ste. 100 >> >Irving, Texas 75039 USA >> >Office: (972) 910 3451 >> >Internal: 820.63451 >> >: (510) 230 8422 >> >www.rim.com; www.blackberry.com >> > >> > >> > >> >=EF=81=90 Consider the environment before printing. >> > >> > >> >-----Original Message----- >> >From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On >> Behalf >> >Of MELIA, TELEMACO (TELEMACO) >> >Sent: Wednesday, February 09, 2011 7:18 AM >> >To: Julien Laganier; cjbc@it.uc3m.es >> >Cc: netext@ietf.org; Basavaraj.Patil@nokia.com >> >Subject: Re: [netext] Consensus call to adopt I-D: >> >draft-bernardos-netext-pmipv6-flowmob as WG doc >> > >> >But why we cannot design a model where we can dynamically group >> sessions? >> >Mobile operators have been fighting hard in the past years the >> >disconnection between ARPU and associated cost per users (in other >> words >> >costs increase but revenues continue to fall). Data explosion is one >> of >> >the reasons for such disconnection. >> >I believe that network operators would be eager to learn about >> innovating >> >technologies to reduce costs expenditures. The work we are pushing >> with >> >this ID falls exactly in this category. Restricting to the legacy >> PMIPv6 >> >model is a limitation. >> > >> >I would be glad to hear opinions from other (different) voices. >> > >> >telemaco >> > >> >-----Message d'origine----- >> >De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la >> part >> >de Julien Laganier >> >Envoy=C3=A9 : mercredi 9 f=C3=A9vrier 2011 03:20 >> >=C3=80 : cjbc@it.uc3m.es >> >Cc : Basavaraj.Patil@nokia.com; netext@ietf.org >> >Objet : Re: [netext] Consensus call to adopt I-D: >> >draft-bernardos-netext-pmipv6-flowmob as WG doc >> > >> >Hi Carlos, >> > >> >2011/2/8 Carlos Jes=C3=BAs Bernardos Cano : >> >> Hi Julien, >> >> >> >> On Tue, 2011-02-08 at 17:21 -0800, Julien Laganier wrote: >> >>> Hi Carlos, >> >>> >> >>> I am glad to see you agree with me :-) >> >>> >> >>> You're actually proving my point. >> >>> >> >>> To run any of the flow mobility stuff on a host, you will need >> either >> >>> layer 2 to hide the dissimilar interfaces (virtual interface >> thing), >> >>> in which case you do have L2 triggers, or to modify the layer 3, >> which >> >>> this WG is explicitly prevented from doing assuming that's even >> >>> possible. >> >>> >> >>> So you need layer 2. And that is actually exactly how netext could >> get >> >>> chartered to work on flow mobility, because we assumed layer 2 >> would >> >>> be there to help with all the stuff we're not allowed to do at >> layer >> >>> 3. >> >> >> >> Exactly, you need layer 2 to help with all the stuff we are not >> allowed >> >> to do at layer 3, _but_ not to do things that we don't need to do at >> the >> >> MN, and can be trivially done with LMA-MAG signaling without putting >> >> strong requirements on the layer 2. >> >> >> >> The signaling we define in our draft (or variations around that) >> allows >> >> to support all the scenarios that have been mentioned so far, and >> does >> >> not break any PMIPv6 concept -- just extends it. It does not require >> >> complex layer 2 triggers/policies to be in place and it's therefore >> more >> >> layer-2 agnostic. Still, you prefers to go for the "lets redo MIP at >> >> layer-2", and I keep failing to see why >> > >> >PMIPv6 as per RFC5213 doesn't work without L2 triggers, so there's no >> >value in extending PMIPv6 to spare relying on L2 triggers that are >> >required anyway. >> > >> >--julien >> > >> >--julien >> >_______________________________________________ >> >netext mailing list >> >netext@ietf.org >> >https://www.ietf.org/mailman/listinfo/netext >> >_______________________________________________ >> >netext mailing list >> >netext@ietf.org >> >https://www.ietf.org/mailman/listinfo/netext >> > >> >--------------------------------------------------------------------- >> >This transmission (including any attachments) may contain confidential >> >information, privileged material (including material protected by the >> >solicitor-client or other applicable privileges), or constitute >> >non-public information. Any use of this information by anyone other >> than >> >the intended recipient is prohibited. If you have received this >> >transmission in error, please immediately reply to the sender and >> delete >> >this information from your system. Use, dissemination, distribution, >> or >> >reproduction of this transmission by unintended recipients is not >> >authorized and may be unlawful. >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > From julien.ietf@gmail.com Wed Feb 9 12:25:23 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C7B63A67B7 for ; Wed, 9 Feb 2011 12:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=-0.973, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cPPlVeyY43W for ; Wed, 9 Feb 2011 12:25:21 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 05C1B3A67D7 for ; Wed, 9 Feb 2011 12:25:20 -0800 (PST) Received: by ewy8 with SMTP id 8so433478ewy.31 for ; Wed, 09 Feb 2011 12:25:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TtK7/FEi65ZMqrABNd0B8/I3gE9oHc/yjyE6172nInQ=; b=kaXunmohqHDpqaKlDPmGpQNZe3BtOKhS6r3W5AVNsSTuln3sOw9m01RPrhHHzLkVia YditeFQ7pQc5kKUDrLRMw8Jb4W/qKLDlDMrYuC0wtv75YPtEj99/d9+nE7x7ZinjhGB0 nC//uvsI1ivcgwLwn0KVqQ90wGCWxN522K9Hs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BRRJ0MdlzEvebgHDnFtIjYY4k8LLgZVFRUqYgutOPis9BQyOINflPqwaYVRAfk8D5X U1MQGo8x+ECnXkPkgJ2KQgLbg8NCFg6aI6ahwJ+9KkIHcHIJSmrl+fKWyRasowu+xbkY xXMVYeIFra2NlxOpuqWLc07e+2I0XVr+U7mkg= MIME-Version: 1.0 Received: by 10.103.243.16 with SMTP id v16mr14629479mur.57.1297283130165; Wed, 09 Feb 2011 12:25:30 -0800 (PST) Received: by 10.103.221.9 with HTTP; Wed, 9 Feb 2011 12:25:30 -0800 (PST) In-Reply-To: <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6D23C@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6D206@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> <680854867F7FD04BB9B06EB8ACA8D5AC05EFEC2B@XCH02DFW.rim.net> <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6D23C@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> Date: Wed, 9 Feb 2011 12:25:30 -0800 Message-ID: From: Julien Laganier To: "MELIA, TELEMACO (TELEMACO)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Basavaraj.Patil@nokia.com" , "netext@ietf.org" Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 20:25:23 -0000 Telemaco, At the risk of sounding extremely repetitive too :) I believe I have not obtained satisfactory answers to my question on why is the usecase that necessitates addition of prefixes to sessions is of any relevance in the completing a work item for the flow mobility deliverable. I have also see other people questioning other aspects of the usecase. On the other hand, I've been offering an extension to the PMIPv6 session model that is minimal yet provides the feature of moving flow between accesses. And there again there was no convincing rebuttal other than the fact that it doesn't solve the usecase that we don't know why it is important, except a bunch of individuals insist that they want it. IMHO, "cutting the line" and "void[ing] endless discussions" won't help to resolve the above two issues I have. Answering them would, FWIW. --julien On Wed, Feb 9, 2011 at 9:53 AM, MELIA, TELEMACO (TELEMACO) wrote: > Stefano, > > At the risk of sounding extremely repetitive I believe the authors at dif= ferent stages did answer the questions posed from the audience. To void end= less discussions I'd leave the chairs to cut the line... > > telemaco > > -----Message d'origine----- > De=C2=A0: Stefano Faccin [mailto:sfaccin@rim.com] > Envoy=C3=A9=C2=A0: mercredi 9 f=C3=A9vrier 2011 18:14 > =C3=80=C2=A0: MELIA, TELEMACO (TELEMACO); Julien Laganier; Tran Minh Trun= g > Cc=C2=A0: netext@ietf.org; Basavaraj.Patil@nokia.com > Objet=C2=A0: RE: [netext] Consensus call to adopt I-D:draft-bernardos-net= ext-pmipv6-flowmob as WG doc > > Telemaco, > At the risk of sounding awfully repetitive, I must disagree on the " it i= s ready to receive traffic on any of the interfaces right". Especially beca= use you are implying "any traffic". Once again, the current solution does n= ot support the scenarios currently supported in 3GPP were the decision on I= P flow routing can be based on the specific access network (e.g. SSID) wrt = access technology. I still have not heard an answer on why we think it woul= d be worth proposing a solution that gives less functionality than what is = out there and does not meet real use case scenarios like the ones I describ= ed before. I also have not heard anybody demonstrating me that the use case= s I raised are real and very current. > > Cheers, > > Stefano Faccin > > Standards Manager > Research In Motion Corporation > 5000 Riverside Drive > Building 6, Brazos East, Ste. 100 > Irving, Texas 75039 USA > Office: (972) 910 3451 > Internal: 820.63451 > : (510) 230 8422 > www.rim.com; www.blackberry.com > > > > =EF=81=90 Consider the environment before printing. > > > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of MELIA, TELEMACO (TELEMACO) > Sent: Wednesday, February 09, 2011 7:35 AM > To: Julien Laganier; Tran Minh Trung > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-= pmipv6-flowmob as WG doc > > Why? If the terminal is connected and radio coverage is ok it also means = it is ready to receive traffic on any of the interfaces right? Up the LMA t= o route flows. > > telemaco > > -----Message d'origine----- > De=C2=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la = part de Julien Laganier > Envoy=C3=A9=C2=A0: mercredi 9 f=C3=A9vrier 2011 03:54 > =C3=80=C2=A0: Tran Minh Trung > Cc=C2=A0: netext@ietf.org; Basavaraj.Patil@nokia.com > Objet=C2=A0: Re: [netext] Consensus call to adopt I-D:draft-bernardos-net= ext-pmipv6-flowmob as WG doc > > Changing the policy on the network side alone isn't sufficient. You'd > have to change the policy on the host, too (e.g., using ADNSF in 3GPP) > which will trigger the MN to attach IF1 to session 2. > > This is the system view picture which seems we're missing in this discuss= ion. > > --julien > > On Tue, Feb 8, 2011 at 6:49 PM, Tran Minh Trung w= rote: >> Hi Julien, >> >> Let me show a real case for the scenario that we are discussing bellow: >> >> The network policy is changed and the LMA decides to move flow 2 from >> IF2 to IF1 before MAG1 received L2 trigger from the MN (say before >> step #8) >> In that case, the LMA should signal MAG1 to send PBU to attach IF1 to >> session 2. >> >> Without signaling from LMA how can you do in this case? Just wait >> until receiving L2 trigger from the MN? >> >> On Wed, Feb 9, 2011 at 7:18 AM, Julien Laganier = wrote: >>> Hi Pierrick, >>> >>> I am going to intertwine the steps in your scenario below with the >>> missing pieces of the big picture so that we are not doing an academic >>> exercise but focusing on the real world: >>> >>> 1. when the MN first attaches with if1 to a network, MAG1 requests >>> attachment of if1 to a session1 by sending a PBU to LMA >>> >>> 2. because the MN add no session1 previously, the LMA creates session >>> 1 and allocates a prefix for it. The prefix is sent back to MAG1 in >>> the PBA: >>> >>> =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Session1: [Pref1, MAG1-IF1] >>> >>> 3. then, if the MN attaches with if2 to another network, but does not >>> request this interface be attached to a distinct session, MAG2 >>> requests attachemnt of If2 to session1 by sending a PBU to LMA >>> >>> 4. Because the MN already has session 1, the LMA updates session1 with >>> if2, and send the pref1 back to MAG2 in the PBA: >>> >>> =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 Session1: [Pref1, MAG1-IF1, MAG2-IF2] >>> >>> 5. Creation of a new session 2 for if2 is requested by either of MN >>> requests via L2 triggers, or a change in policy profile. As a result, >>> MAG2 requests attachment of if2 to session2 by sending a PBU to LMA. >>> >>> 6. because the MN add no session2 previously, the LMA creates session >>> 2 and allocates a prefix for it. The prefix pref2 is sent back to MAG2 >>> in the PBA: >>> >>> =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Session2: [Pref2, MAG2-IF2] >>> >>> 7. Flow2 starts over if2 with prefix2. >>> >>> 8. Attachment of if1 to session2 is requested by either of MN requests >>> via L2 triggers, or a change in policy profile. As a result, MAG1 >>> requests attachment of if1 to session2 by sending a PBU to LMA. >>> >>> 9. Because the MN already has session 2, the LMA updates session2 with = if1: >>> >>> =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 Session2: [Pref2, MAG2-IF2, MAG1-IF1] >>> >>> 10. At any point, the LMA decides to move Flow2 between two interfaces >>> of session 2, and it does so. >>> >>> That's all that needed. It maps perfectly to 3GPP. If you have in mind >>> a different system in whcih that doesn't map, please let me know. >>> >>> --julien >>> >>> On Tue, Feb 8, 2011 at 8:25 AM, =C2=A0 wrote: >>>> Hi, >>>> >>>> Going through this long thread :-), it seems we could agree on the fol= lowing (just a tentative to summarize): >>>> >>>> Sessions should be created/updated with all available interfaces. Rewr= iting Tran's example: when the MN attaches to MAG1 via If1, the LMA creates= session 1: >>>> >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Session1: [Pref1, MAG1, IF1] >>>> >>>> Then, if the MN attaches to MAG2 via If2, the LMA creates session 2 wi= th both If1 and If2. The LMA also updates session 1 with If2: >>>> >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Session1: [Pref1, MAG1, IF1, IF2] >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Session2: [Pref2, MAG2, IF2, IF1] >>>> >>>> MAG2 receives prefixes 1 and 2 in PBA but MAG1 is not sending PBU. So,= if the LMA wants to move flow with Pref2 from if2 to If1, the LMA needs to= provide Pref2 to MAG1. Also, the LMA should be able to create new sessions= with already up interfaces, e.g. if1 and if2. To address both issues, PBU = from MAG1 could be triggered (triggering is to be clarified) or we could de= fine LMA/MAG specific L3 signalling (FMI/FMA). >>>> >>>> My 2 cents, >>>> Pierrick >>>> >>>>> -----Message d'origine----- >>>>> De=C2=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De= la part >>>>> de Youn-Hee Han >>>>> Envoy=C3=A9=C2=A0: mardi 8 f=C3=A9vrier 2011 12:00 >>>>> =C3=80=C2=A0: 'Julien Laganier'; 'Rajeev Koodli' >>>>> Cc=C2=A0: netext@ietf.org; Basavaraj.Patil@nokia.com >>>>> Objet=C2=A0: Re: [netext] Consensus call to adopt I-D:draft-bernardos= -netext- >>>>> pmipv6-flowmob as WG doc >>>>> >>>>> Hi Julien, >>>>> >>>>> > -----Original Message----- >>>>> > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On B= ehalf >>>>> > Of Julien Laganier >>>>> > Sent: Tuesday, February 08, 2011 1:38 PM >>>>> > To: Rajeev Koodli >>>>> > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com >>>>> > Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos- >>>>> > netext-pmipv6-flowmob as WG doc >>>>> > >>>>> > On Mon, Feb 7, 2011 at 6:15 PM, Rajeev Koodli w= rote: >>>>> > > >>>>> > > If flow mobility has nothing do with prefix management, I am lost= . >>>>> > >>>>> > No reason to be lost: Prefix management is how do I get prefix for = the >>>>> > MN. Flow mobility is how to I move flows across interfaces. The two >>>>> > needs not to be intertwined together, as I've shown in my other not= es. >>>>> > E.g., I can do flow mobility without adding/deleting prefixes from >>>>> > sessions, and vice versa. >>>>> >>>>> Yes, I agree with you. Flow mobility is how to move flows across inte= rface. >>>>> So, I thought that it would be better to define "a flow" exactly in n= etext >>>>> WG prior to discuss flow mobility management. As the definition of "a >>>>> flow", >>>>> all I can think is a five-tuple plus something. If we assume that it = is >>>>> correct, I think that flow mobility and prefix addition are inevitabl= y >>>>> tied. >>>>> As you know, RFC5213 (and IPv6 protocol spec) already allow to assign >>>>> multiple prefixes across multiple interfaces of an MN. Yes, I also ag= ree >>>>> with you that in real-world (3GPP), there may be no need to assign >>>>> multiple >>>>> prefixes into an MN. (if somebody knows its necessity, please tell me= when >>>>> it should happen). So, flow mobility can be done without adding prefi= xes. >>>>> However, different interfaces are allowed to be assigned different >>>>> prefixes >>>>> by RFC 5213 and IPv6 spec. We can't expect what kind of prefixes an M= AG >>>>> advertises. Therefore, sometimes, we need prefix addition to move a f= low >>>>> to >>>>> a new interface of which MAG does not yet advertise the prefix of the= flow >>>>> being moved. >>>>> >>>>> (snip...) >>>>> >>>>> > >> I see no reason to depart from that in the context of extending = the >>>>> > >> protocol to support mobility, nor I am aware of any system >>>>> > >> architecture that would require this capability. >>>>> > > >>>>> > > Okay, see your position. I see it differently. I don't need to be >>>>> > > bound by some "presumed implementation model" of PMIP6 and limit >>>>> > > myself *only* to a prefix assignment model you are imagining. >>>>> > >>>>> > It's not an implementation model, it is a protocol model, and it's = not >>>>> > imaginary. Implementation has nothing to do with this. >>>>> > >>>>> > There's no reason to extend prefix assignment model to do flow mobi= lity >>>>> > unless you can point me out in which real world context your scenar= io >>>>> > actually happens. >>>>> >>>>> As I insisted in the old mail, I agree with Julien in this regard. Cu= rrent >>>>> draft allows too much space regarding the prefix allocation model (un= ique, >>>>> shared, and hybrid). When a flow should be moved to a new interface a= nd >>>>> the >>>>> prefix which the flow uses is not yet advertised by the new MAG, just >>>>> inform >>>>> the prefix to the MAG and thus make it advertise the prefix and setup= the >>>>> tunnel based on the new prefix. That's all!. If the prefix is already >>>>> advertised by the MAG, there is nothing to do and just move the flow.= This >>>>> behaviors are very natural one when we want to support IP-level mobil= ity. >>>>> >>>>> > >> If this is something really important, the WG can be rechartered= to >>>>> > >> work on a different extension that would allow adding/removing >>>>> > >> prefixes from existing PMIPv6 sessions. >>>>> > > >>>>> > > Huh.. What in the current charter forces us not to have the LMA >>>>> > > add/refresh/delete a prefix on-demand? >>>>> > >>>>> > Engineering is about finding a solution to a problem. Adding/deleti= ng >>>>> > prefix on-demand is not a solution to flow mobility. I've shown you= how >>>>> > to do flow mobility without this capability. >>>>> >>>>> From the viewpoint of protocol, I think that at least, prefix additio= n to >>>>> an >>>>> interface is a necessary function to support flow mobility, as I expl= ained >>>>> above. But, it does not mean prefix addition should happen always whe= never >>>>> flow mobility occurs. It is sometimes needed. >>>>> >>>>> > Now a different engineering problem would be: how to add/delete pre= fixes >>>>> > to a PMIPv6 session, and that would be useful for e.g. >>>>> > renumbering. This is a different problem that we haven't been chart= ered >>>>> > to work on. >>>>> >>>>> Prefix addition is just prefix addition. IMHO, renumbering is closer = to >>>>> prefix change. We just harness that function to support IP-level mobi= lity. >>>>> >>>>> Youn-Hee >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> >> >> -- >> Ph.D., Senior Member >> Electronics and Telecommunications Research Institute >> Standards Research Center >> 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA >> Tel : +82-42-860-1132,=C2=A0=C2=A0 Fax : +82-42-861-5404 >> > _______________________________________________ > 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 > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > From rkoodli@cisco.com Wed Feb 9 12:32:06 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D1F93A6839 for ; Wed, 9 Feb 2011 12:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.104 X-Spam-Level: X-Spam-Status: No, score=-110.104 tagged_above=-999 required=5 tests=[AWL=0.495, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQ6AyUzDXfxn for ; Wed, 9 Feb 2011 12:32:05 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 79CCA3A6826 for ; Wed, 9 Feb 2011 12:32:05 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMuIUk2tJV2d/2dsb2JhbAClVnOgSps1gwGCWwSEf4ZxgziDBA Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-2.cisco.com with ESMTP; 09 Feb 2011 20:32:15 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p19KWFsh024692; Wed, 9 Feb 2011 20:32:15 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Feb 2011 14:32:15 -0600 Received: from 10.21.75.210 ([10.21.75.210]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Wed, 9 Feb 2011 20:32:14 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Wed, 09 Feb 2011 12:51:03 -0800 From: Rajeev Koodli To: Julien Laganier Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvImxBZ5PJvFIC04UiJMSQGwY4jGA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 09 Feb 2011 20:32:15.0073 (UTC) FILETIME=[700DD510:01CBC898] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 20:32:06 -0000 Hi, I am beginning to think I must be really missing something.. Or, this is turning out to be running in circles. General comment: 3GPP is good source of input, we should use it. However, if something is not there in 3GPP today, that cannot be held against proposals here. On 2/8/11 7:07 PM, "Julien Laganier" wrote: > > In 3GPP, the prefix is assigned when the PDN connection is created, > and is then unchanged for the reminder of the lifetime of this PDN > connection. > > So in your own words: You are not required to assign all the > applicable prefixes at the time of attach *in anticipation* of > *potential* flow mobility. You will assign the relevant prefix *if and > when* I you need a PDN connection. No. You assign the prefix relevant for that interface. On if0, p0. On if1, p1. I am saying that I am not required to assign p0 to if1 at attach. I will provide p0 if I need to, when I need to, using IP signaling this group capable of producing. > > If you have another target system than 3GPP, what is it? > See above comment. >> It makes no sense for me to be *forced* to assign >> all the prefixes at the time of attach (just because it is aligned with >> legacy RFC 5213 "model"). > > Assigning all the prefixes at time of attaches isn't a requirement for > flow mobility. You can very well have a single prefix and do flow > mobility across multiple interfaces. > So, how can I move a flow belonging to p0 onto if1 without the LMA first informing the MAG? I don't want any L2 hand-waving. I have an eerie feeling that I have asked this more than I should..sigh. > 2) I want to assign a prefix based on policy triggers, including the TOD rules. > > I don't see how useful it is to assign prefixes based on time of day. > I understand you might want to move flows based on time of day, but as > I said above, you can already move flows with a single prefix when the > time is good for you. If I want to move flows, I need to ensure that the corresponding prefix is valid on the target interface. That's the extent of "assigning" prefixes on-demand. See also Youn-Hee's e-mail earlier. I don't have anything else to say on this. Thanks, -Rajeev > >> I want to move certain type of traffic >> over to a different interface based on peak hour bulk stats, the volume of >> traffic the user is consuming at a particular instance, the amount of quota >> left and so on. > > All capabilities that are perfectly available without juggling with > multiple prefixes, as above. > >> I want to be able to refresh the lifetime of >> that prefix and >> revoke it back to its "natural interface" when I want. > > This is renumbering - a different interface. I also don't know what a > natural interface is when prefixes are assigned from withing an > overlay... > >> I want to be able to offer this for my customers. > > Most of which you can, as I stated above, independently of prefix juggling... > >>> Absent that, will I be forced to conclude that this needed by no-one? >> >> If I don't need something that does not imply the rest don't either! :-) > > Can they speak up then? :-) > > --julien From julien.ietf@gmail.com Wed Feb 9 12:42:31 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 206053A67B7 for ; Wed, 9 Feb 2011 12:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.471 X-Spam-Level: X-Spam-Status: No, score=-3.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fW3bAy3tIZ32 for ; Wed, 9 Feb 2011 12:42:30 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id E78C73A672E for ; Wed, 9 Feb 2011 12:42:29 -0800 (PST) Received: by ewy8 with SMTP id 8so444925ewy.31 for ; Wed, 09 Feb 2011 12:42:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tkXzhZBUU4g7EZmZqQqJOpQa22INPTIyeNdgawRFvv8=; b=FtYMWzHpwPkcbihp9jFFTSDTdYD9IlxPWNsdxiv9s4y2xT4YQnEVKalw12u++XfYr3 2nV3laGoh2aUDS2cTWqHNKaCFp3JRxL7a3mKSrx2XyjwFVwt9MtgEhooD0j3E7OgyjeE kLA7SPQKkJaU4QqUXLYJJIcxCyvpb7sZnBYbg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ppMGcwbRbRrObk9yk3cJrGPxmNo/qX9wjsL4zjDnOsXGx5FHqFsz9z7jXXjB63nAWm K7m7YCHQ0NTNH1hRF4ylXWvWkVj8xq9A/BcIMsrvUywPSjbX184gQFMXFnXoRXFigkjs tKmxFEG4edIDCBjjndp8UlQ9KWyvkAPKDazes= MIME-Version: 1.0 Received: by 10.103.199.18 with SMTP id b18mr14628951muq.21.1297284159050; Wed, 09 Feb 2011 12:42:39 -0800 (PST) Received: by 10.103.221.9 with HTTP; Wed, 9 Feb 2011 12:42:39 -0800 (PST) In-Reply-To: References: Date: Wed, 9 Feb 2011 12:42:39 -0800 Message-ID: From: Julien Laganier To: Rajeev Koodli Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 20:42:31 -0000 Hi Rajeev, On Wed, Feb 9, 2011 at 12:51 PM, Rajeev Koodli wrote: > > Hi, > > I am beginning to think I must be really missing something.. > Or, this is turning out to be running in circles. FWIW the feeling is shared. > General comment: 3GPP is good source of input, we should use it. However,= if > something is not there in 3GPP today, that cannot be held against proposa= ls > here. I've been using 3GPP as example of usecase because it is real and out there. I am happy to hear about any usecase that necessitates the sort of features you've been advocating. > On 2/8/11 7:07 PM, "Julien Laganier" wrote: > >> >> In 3GPP, the prefix is assigned when the PDN connection is created, >> and is then unchanged for the reminder of the lifetime of this PDN >> connection. >> >> So in your own words: You are not required to assign all the >> applicable prefixes at the time of attach *in anticipation* of >> *potential* flow mobility. You will assign the relevant prefix *if and >> when* I you need a PDN connection. > > No. > You assign the prefix relevant for that interface. On if0, p0. On if1, p1= . I > am saying that I am not required to assign p0 to if1 at attach. I will > provide p0 if I need to, when I need to, using IP signaling this group > capable of producing. You are starting my making up a requirement on how you assign prefixes to interface which has nothing to do with the feature of providing flow mobility. Once you have allocated p0 to the _MN_, and p1 to the _MN_ the cost of having those avalaible on all interfaces of a session (if0 and if1) is the same as having them segregated on if0 and if1. The segregation of prefixes to interfaces is also not useful in terms of providing flow mobility -- one can do flow mobility with both p0 and p1 being available to interfaces of the session, if0 and if1. So what is it that justifies this requirement, in the context of extending PMIP to support flow mobility? [...] >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 It makes no sense f= or me to be *forced* to assign >>> all the prefixes at the time of attach (just because it is aligned with >>> legacy RFC 5213 "model"). >> >> Assigning all the prefixes at time of attaches isn't a requirement for >> flow mobility. You can very well have a single prefix and do flow >> mobility across multiple interfaces. >> > > So, how can I move a flow belonging to p0 onto if1 without the LMA first > informing the MAG? I don't want any L2 hand-waving. I have an eerie feeli= ng > that I have asked this more than I should..sigh. See above. Prefixes don't need to be segregated to interfaces. They only be need to segregated to sessions. >> 2) I want to assign a prefix based on policy triggers, including the TOD > rules. >> >> I don't see how useful it is to assign prefixes based on time of day. >> I understand you might want to move flows based on time of day, but as >> I said above, you can already move flows with a single prefix when the >> time is good for you. > > If I want to move flows, I need to ensure that the corresponding prefix i= s > valid on the target interface. That's the extent of "assigning" prefixes > on-demand. See also Youn-Hee's e-mail earlier. No you don't need to ensure that the corresponding prefix is valid on the target interface. Why would you?! > I don't have anything else to say on this. I do: Please answer my questions. --julien From gerardog@qualcomm.com Wed Feb 9 14:23:34 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8BAC3A685A for ; Wed, 9 Feb 2011 14:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.24 X-Spam-Level: X-Spam-Status: No, score=-106.24 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvws2KpcHf5k for ; Wed, 9 Feb 2011 14:23:32 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 504EA3A684F for ; Wed, 9 Feb 2011 14:23:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1297290222; x=1328826222; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:content-transfer-encoding: mime-version; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20Tran=20Minh=20Trung=20|CC: =20"netext@ietf.org"=20|Subject:=20RE: =20[netext]=20Multiple=20prefixes=20in=0D=0A=20draft-bern ardos-netext-pmipv6-flowmob|Thread-Topic:=20[netext]=20Mu ltiple=20prefixes=20in=0D=0A=20draft-bernardos-netext-pmi pv6-flowmob|Thread-Index:=20AQHLyDXGJnkg9YHtTEu5LO9i+xKLr JP5vwCw|Date:=20Wed,=209=20Feb=202011=2022:23:35=20+0000 |Message-ID:=20|References:=20=0D=0A=09=0D=0A=09=0D=0A =09<015b01cbc77f$69f132e0$3dd398a0$@gmail.com>=0D=0A=09<8 43DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.franc etelecom.fr>=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=20|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|x-originating-ip: =20[172.30.39.5]|Content-Type:=20text/plain=3B=20charset =3D"iso-8859-1"|Content-Transfer-Encoding:=20quoted-print able|MIME-Version:=201.0; bh=vzDEN5vRJN4bw4V5cB9FMc171/jvsyn0d+76gmc47I0=; b=g3q8bcj4gsD14/HMDfiJz8MCx0d14Eorb5zMHvrmTZi0cfECMbZqrP8o jh7e44Rg3/W5MAlpVdiTyvHp/uJogXRGB106ROf+0n4OzkT93oUmTpiTS cVt40wpmkUtyfrMlReIWAAyMbDe29C+9ffdgsDnHMxAyfeQeH6sOhajro c=; X-IronPort-AV: E=McAfee;i="5400,1158,6252"; a="73616854" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 09 Feb 2011 14:23:35 -0800 X-IronPort-AV: E=Sophos;i="4.60,446,1291622400"; d="scan'208";a="114905392" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 09 Feb 2011 14:23:35 -0800 Received: from NASANEXD01E.na.qualcomm.com ([fe80::6555:8c37:4ee3:efc4]) by nasanexhc04.na.qualcomm.com ([::1]) with mapi id 14.01.0270.001; Wed, 9 Feb 2011 14:23:35 -0800 From: "Giaretta, Gerardo" To: Tran Minh Trung Thread-Topic: [netext] Multiple prefixes in draft-bernardos-netext-pmipv6-flowmob Thread-Index: AQHLyDXGJnkg9YHtTEu5LO9i+xKLrJP5vwCw Date: Wed, 9 Feb 2011 22:23:35 +0000 Message-ID: References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" Subject: Re: [netext] Multiple prefixes in draft-bernardos-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 22:23:34 -0000 Hi, Please see inline > -----Original Message----- > From: Tran Minh Trung [mailto:trungtm2909@gmail.com] > Sent: Wednesday, February 09, 2011 12:46 AM > To: Giaretta, Gerardo > Cc: netext@ietf.org > Subject: Re: [netext] Multiple prefixes in draft-bernardos-netext- > pmipv6-flowmob >=20 > On Wed, Feb 9, 2011 at 3:33 PM, Giaretta, Gerardo > wrote: > > Hi all, > > > > I am starting a new thread to understand the use case this draft is > trying to solve when referring to multiple prefixes. I think there has > been some discussion already in the list but I did not get a good > understanding of the rationale. > > > > My understanding is that the goal of the draft is to define a flow > mobility solution for PMIP. This implies that a given PMIP session is > shared across multiple interfaces and some IP flows belonging to that > session are sent over one interface and some others over another > interface. This is equivalent to the RFC6089: IP flows which are tied > to the same HoA/HNP can be sent over one CoA/BID or another CoA/BID. > > > > Is this the correct understanding of the goals of the I-D? Is this a > common understanding of the term Flow Mobility? > > >=20 > Yes you are right. >=20 Good at least we agree on the definition. > > If this is the case, then I don't understand why the draft is > introducing text about the LMA creating a different session. Is this > needed for Flow Mobility? If so, for which scenario? > > > > Going back to Pierrick's example: > > > > when the MN attaches to MAG1 via If1, the LMA creates session 1: > > > > =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] > > > > Then, if the MN attaches to MAG2 via If2, there is no reason for the > LMA to create session 2. The LMA just needs to update session 1 with > If2: > > >=20 > We just follow the basic operation of the RFC5213 that a new prefix > will be assigned to new attachment. >=20 RFC5213 does not assign a NEW prefix but A prefix when there is an attachme= nt. If there is the handover indication in the PBU for example the same pre= fix is attached. Given that flow mobility is a particular type of handover,= there is no need to assign a new prefix for flow mobility purposes. > Then we extend it to support flow mobility by allowing interfaces to > be attached to multiple sessions. >=20 > > =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] > > > > In this way MAG/LMA/MN can send over IF2 a TCP connection which > earlier was sent over IF1. This is Flow Mobility. > > >=20 > It only works for the flows in the session1. However session 2,3..n > can be created at anytime in the future. We have to attach all working > interfaces in the set to a new session whenever it is created. >=20 Flow mobility is not about creating new sessions based on the definition yo= u just agreed.=20 Gerardo=20 > Regards, > TrungTM >=20 > > Thanks > > Gerardo > > > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > > >=20 >=20 >=20 > -- > Ph.D., Senior Member > Electronics and Telecommunications Research Institute > Standards Research Center > 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA > Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 From gerardog@qualcomm.com Wed Feb 9 14:26:52 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0434B3A67D2 for ; Wed, 9 Feb 2011 14:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.33 X-Spam-Level: X-Spam-Status: No, score=-106.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fH+FZR+i5Rt0 for ; Wed, 9 Feb 2011 14:26:51 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id F1EEE3A67CF for ; Wed, 9 Feb 2011 14:26:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1297290421; x=1328826421; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:content-transfer-encoding: mime-version; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20Tran=20Minh=20Trung=20|CC: =20"netext@ietf.org"=20|Subject:=20RE: =20[netext]=20Policy=20assumptions=20in=0D=0A=20draft-ber nardos-netext-pmipv6-flowmob|Thread-Topic:=20[netext]=20P olicy=20assumptions=20in=0D=0A=20draft-bernardos-netext-p mipv6-flowmob|Thread-Index:=20AQHLyDO7cGN/rUAHwkScnv6oeHv JCZP5wFEQ|Date:=20Wed,=209=20Feb=202011=2022:27:00=20+000 0|Message-ID:=20|References:=20=0D =0A=20|In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|x-originating-ip:=20[172.30.39.5] |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=435nzOJJWxhyo9kSCTseywV5u4rgVp/fdmtQXYGFeao=; b=Efp0J6HSe5hsPXiGuqDcHnuQhfUTgqSo8+4NHnbOVtJ75lrEQJNHy5lu Ug/wv+o5sQSTD5sqJi0V3gfp7xLYCEMUid8ieG5d/Za3DzozB5ASYueQg SLLixkrGRweIeJkU7oJt75BXnILFHzOGW3A+V2EWf2neSb2w2zeVzModW o=; X-IronPort-AV: E=McAfee;i="5400,1158,6252"; a="73827657" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 09 Feb 2011 14:27:01 -0800 X-IronPort-AV: E=Sophos;i="4.60,446,1291622400"; d="scan'208";a="49527445" Received: from nasanexhc09.na.qualcomm.com ([172.30.39.8]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 09 Feb 2011 14:27:01 -0800 Received: from NASANEXD01E.na.qualcomm.com ([fe80::6555:8c37:4ee3:efc4]) by nasanexhc09.na.qualcomm.com ([::1]) with mapi id 14.01.0270.001; Wed, 9 Feb 2011 14:27:01 -0800 From: "Giaretta, Gerardo" To: Tran Minh Trung Thread-Topic: [netext] Policy assumptions in draft-bernardos-netext-pmipv6-flowmob Thread-Index: AQHLyDO7cGN/rUAHwkScnv6oeHvJCZP5wFEQ Date: Wed, 9 Feb 2011 22:27:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" Subject: Re: [netext] Policy assumptions in draft-bernardos-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 22:26:52 -0000 Hello, > -----Original Message----- > From: Tran Minh Trung [mailto:trungtm2909@gmail.com] > Sent: Wednesday, February 09, 2011 12:31 AM > To: Giaretta, Gerardo > Cc: netext@ietf.org > Subject: Re: [netext] Policy assumptions in draft-bernardos-netext- > pmipv6-flowmob >=20 > On Wed, Feb 9, 2011 at 3:36 PM, Giaretta, Gerardo > wrote: > > I want to go back to the point raised by Stefano which was somehow > lost in the long thread. > > > > I need some clarifications on which is the assumption in terms of > policies in the draft. In particular: > > > > - Is it correct that there is an assumption that MN and LMA have the > same policies and behave accordingly? > > >=20 > Yes, they should have the same policies. >=20 Then, the scenario of change of policy in the LMA is conflicting with this = assumption unless policies changed also on MN. Gerardo=20 > > - Does the MN need to have knowledge of the policy at all? > > >=20 > Yes, it needs to have knowledge of the policy. > It is necessary for the MN to send the packet of a NEW flow (not > ongoing flow) to the right interface. >=20 > Regards, > TrungTM >=20 >=20 > > Thanks > > Gerardo > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > > >=20 >=20 >=20 > -- > Ph.D., Senior Member > Electronics and Telecommunications Research Institute > Standards Research Center > 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA > Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 From gerardog@qualcomm.com Wed Feb 9 14:29:19 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C09B3A6859 for ; Wed, 9 Feb 2011 14:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.307 X-Spam-Level: X-Spam-Status: No, score=-105.307 tagged_above=-999 required=5 tests=[AWL=-0.862, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0v19AQOrmix for ; Wed, 9 Feb 2011 14:29:16 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 28E863A6849 for ; Wed, 9 Feb 2011 14:29:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1297290565; x=1328826565; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:content-transfer-encoding: mime-version; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20Rajeev=20Koodli=20,=20Tran=20Mi nh=20Trung=0D=0A=09,=20Sri=20Gunda velli=20|CC:=20"netext@ietf.org"=20,=20"Basavaraj.Patil@nokia.com"=0D=0A=09|Subject:=20RE:=20[netext]=20Con sensus=20call=20to=20adopt=0D=0A=20I-D:draft-bernardos-ne text-pmipv6-flowmob=20as=20WG=20doc|Thread-Topic:=20[nete xt]=20Consensus=20call=20to=20adopt=0D=0A=20I-D:draft-ber nardos-netext-pmipv6-flowmob=20as=20WG=20doc |Thread-Index:=20AQHLx94soydSZ0L5ekCHxlX1jM06mpP4/lqAgAAD 6ACAAALEAIAA77iA///NDOA=3D|Date:=20Wed,=209=20Feb=202011 =2022:29:25=20+0000|Message-ID:=20|References: =20=0D=0A=20 |In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|x-originating-ip: =20[172.30.39.5]|Content-Type:=20text/plain=3B=20charset =3D"iso-8859-1"|Content-Transfer-Encoding:=20quoted-print able|MIME-Version:=201.0; bh=a+15PBsvPz4jignujmLuCI+47EE8xqTE5Vo3RgfFAyw=; b=fs+FTON7E4mjUvvsmlZ0wzvIxE3mK6xTeUOoSz4jhcfoHFvFPi+2T6YE msKsJ56HNpYim02jAq/VwFgAvZMZO96KJLOyZJlHKyCakSi2QV/o+x9DK 88T3PXUO0DI12KbX1QSodIrI5sY/wDrhquhuobShKmWUvNsOFSyZvyDOk s=; X-IronPort-AV: E=McAfee;i="5400,1158,6252"; a="73827915" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 09 Feb 2011 14:29:25 -0800 X-IronPort-AV: E=Sophos;i="4.60,446,1291622400"; d="scan'208";a="49527661" Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 09 Feb 2011 14:29:25 -0800 Received: from NASANEXD01E.na.qualcomm.com ([fe80::6555:8c37:4ee3:efc4]) by nasanexhc05.na.qualcomm.com ([::1]) with mapi id 14.01.0270.001; Wed, 9 Feb 2011 14:29:25 -0800 From: "Giaretta, Gerardo" To: Rajeev Koodli , Tran Minh Trung , Sri Gundavelli Thread-Topic: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLx94soydSZ0L5ekCHxlX1jM06mpP4/lqAgAAD6ACAAALEAIAA77iA///NDOA= Date: Wed, 9 Feb 2011 22:29:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 22:29:19 -0000 I don't understand what this has to do with flow mobility Gerardo=20 > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > Behalf Of Rajeev Koodli > Sent: Wednesday, February 09, 2011 9:31 AM > To: Tran Minh Trung; Sri Gundavelli > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos- > netext-pmipv6-flowmob as WG doc >=20 >=20 > We can argue about what is "general case" and what is not. IMO, it's > not for > us to decide, let the marketplace make that call. >=20 > As protocol designers, I would like to ensure that we provide the > necessary > tools to address the problems, rather than debate "who wants to play > oracle". >=20 > 1. I just don't see why anyone should be forced assign all prefixes > proactively. Parsimonious protocol design has its place - LMA should be > able > to assign prefixes on-demand, when necessary. And, not clump stuff (all > prefixes) under the guise of legacy RFC 5213 design, which BTW, feel > free to > do if you so choose; but just don't make it the only way. >=20 > 2. FMI is the message to inform the MAG to add a new prefix to BUL, and > to > advertise the new prefix in RA, just as it should. FMA is a response to > FMI, > saying I got the message with the disposition of the Status code. > Simple, > like other stuff we have in Netext, e.g., Localized Routing. This will > do > the job for the case. Why do I need PBU/PBA again? Other than to > (wastefully) satisfy some vague "PMIP6 model", I don't see anything > else. > This is not protocol design, it's continued adherence to bad design > decisions. >=20 > -Rajeev >=20 >=20 >=20 >=20 > On 2/8/11 7:13 PM, "Tran Minh Trung" wrote: >=20 > > Hi Sri, > > > > If all of us are agree that it is not a general case and we can > ignore > > it then I think the Julien's solution is sufficient. > > > > I am going out for lunch now. > > > > Talk to you later. > > Regards, > > TrungTM > > > > On Wed, Feb 9, 2011 at 12:03 PM, Sri Gundavelli > wrote: > >> Hi Tran: > >> > >> Policy change is not a general case, it is a special case. It can > indeed > >> take affect after a lapse of time. Either way, the trigger from LMA > to MAG > >> is one option, I'm still not convinced why I'd need FMA. The trigger > should > >> force the MAG to send a PBU and per RFC-5213, it should get a set of > >> prefixes that its hosting on the access link. This essentially, > forces the > >> approach of session state creation at the request of the MAG. If > policy > >> change is a valid case, a simple trigger is sufficient. > >> > >> > >> Regards > >> Sri > >> > >> > >> > >> > >> > >> On 2/8/11 6:49 PM, "Tran Minh Trung" wrote: > >> > >>> Hi Julien, > >>> > >>> Let me show a real case for the scenario that we are discussing > bellow: > >>> > >>> The network policy is changed and the LMA decides to move flow 2 > from > >>> IF2 to IF1 before MAG1 received L2 trigger from the MN (say before > >>> step #8) > >>> In that case, the LMA should signal MAG1 to send PBU to attach IF1 > to > >>> session 2. > >>> > >>> Without signaling from LMA how can you do in this case? Just wait > >>> until receiving L2 trigger from the MN? > >>> > >>> On Wed, Feb 9, 2011 at 7:18 AM, Julien Laganier > > >>> wrote: > >>>> Hi Pierrick, > >>>> > >>>> I am going to intertwine the steps in your scenario below with the > >>>> missing pieces of the big picture so that we are not doing an > academic > >>>> exercise but focusing on the real world: > >>>> > >>>> 1. when the MN first attaches with if1 to a network, MAG1 requests > >>>> attachment of if1 to a session1 by sending a PBU to LMA > >>>> > >>>> 2. because the MN add no session1 previously, the LMA creates > session > >>>> 1 and allocates a prefix for it. The prefix is sent back to MAG1 > in > >>>> the PBA: > >>>> > >>>> =A0=A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1-IF1] > >>>> > >>>> 3. then, if the MN attaches with if2 to another network, but does > not > >>>> request this interface be attached to a distinct session, MAG2 > >>>> requests attachemnt of If2 to session1 by sending a PBU to LMA > >>>> > >>>> 4. Because the MN already has session 1, the LMA updates session1 > with > >>>> if2, and send the pref1 back to MAG2 in the PBA: > >>>> > >>>> =A0=A0 =A0 =A0 =A0 Session1: [Pref1, MAG1-IF1, MAG2-IF2] > >>>> > >>>> 5. Creation of a new session 2 for if2 is requested by either of > MN > >>>> requests via L2 triggers, or a change in policy profile. As a > result, > >>>> MAG2 requests attachment of if2 to session2 by sending a PBU to > LMA. > >>>> > >>>> 6. because the MN add no session2 previously, the LMA creates > session > >>>> 2 and allocates a prefix for it. The prefix pref2 is sent back to > MAG2 > >>>> in the PBA: > >>>> > >>>> =A0=A0 =A0 =A0 =A0 =A0Session2: [Pref2, MAG2-IF2] > >>>> > >>>> 7. Flow2 starts over if2 with prefix2. > >>>> > >>>> 8. Attachment of if1 to session2 is requested by either of MN > requests > >>>> via L2 triggers, or a change in policy profile. As a result, MAG1 > >>>> requests attachment of if1 to session2 by sending a PBU to LMA. > >>>> > >>>> 9. Because the MN already has session 2, the LMA updates session2 > with if1: > >>>> > >>>> =A0=A0 =A0 =A0 =A0 Session2: [Pref2, MAG2-IF2, MAG1-IF1] > >>>> > >>>> 10. At any point, the LMA decides to move Flow2 between two > interfaces > >>>> of session 2, and it does so. > >>>> > >>>> That's all that needed. It maps perfectly to 3GPP. If you have in > mind > >>>> a different system in whcih that doesn't map, please let me know. > >>>> > >>>> --julien > >>>> > >>>> On Tue, Feb 8, 2011 at 8:25 AM, =A0 ftgroup.com> wrote: > >>>>> Hi, > >>>>> > >>>>> Going through this long thread :-), it seems we could agree on > the > >>>>> following > >>>>> (just a tentative to summarize): > >>>>> > >>>>> Sessions should be created/updated with all available interfaces. > >>>>> Rewriting > >>>>> Tran's example: when the MN attaches to MAG1 via If1, the LMA > creates > >>>>> session 1: > >>>>> > >>>>> =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] > >>>>> > >>>>> Then, if the MN attaches to MAG2 via If2, the LMA creates session > 2 with > >>>>> both If1 and If2. The LMA also updates session 1 with If2: > >>>>> > >>>>> =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] > >>>>> =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2, IF1] > >>>>> > >>>>> MAG2 receives prefixes 1 and 2 in PBA but MAG1 is not sending > PBU. So, if > >>>>> the LMA wants to move flow with Pref2 from if2 to If1, the LMA > needs to > >>>>> provide Pref2 to MAG1. Also, the LMA should be able to create new > sessions > >>>>> with already up interfaces, e.g. if1 and if2. To address both > issues, PBU > >>>>> from MAG1 could be triggered (triggering is to be clarified) or > we could > >>>>> define LMA/MAG specific L3 signalling (FMI/FMA). > >>>>> > >>>>> My 2 cents, > >>>>> Pierrick > >>>>> > >>>>>> -----Message d'origine----- > >>>>>> De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De > la part > >>>>>> de Youn-Hee Han > >>>>>> Envoy=E9=A0: mardi 8 f=E9vrier 2011 12:00 > >>>>>> =C0=A0: 'Julien Laganier'; 'Rajeev Koodli' > >>>>>> Cc=A0: netext@ietf.org; Basavaraj.Patil@nokia.com > >>>>>> Objet=A0: Re: [netext] Consensus call to adopt I-D:draft- > bernardos-netext- > >>>>>> pmipv6-flowmob as WG doc > >>>>>> > >>>>>> Hi Julien, > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] > On Behalf > >>>>>>> Of Julien Laganier > >>>>>>> Sent: Tuesday, February 08, 2011 1:38 PM > >>>>>>> To: Rajeev Koodli > >>>>>>> Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > >>>>>>> Subject: Re: [netext] Consensus call to adopt I-D: draft- > bernardos- > >>>>>>> netext-pmipv6-flowmob as WG doc > >>>>>>> > >>>>>>> On Mon, Feb 7, 2011 at 6:15 PM, Rajeev Koodli > wrote: > >>>>>>>> > >>>>>>>> If flow mobility has nothing do with prefix management, I am > lost. > >>>>>>> > >>>>>>> No reason to be lost: Prefix management is how do I get prefix > for the > >>>>>>> MN. Flow mobility is how to I move flows across interfaces. The > two > >>>>>>> needs not to be intertwined together, as I've shown in my other > notes. > >>>>>>> E.g., I can do flow mobility without adding/deleting prefixes > from > >>>>>>> sessions, and vice versa. > >>>>>> > >>>>>> Yes, I agree with you. Flow mobility is how to move flows across > >>>>>> interface. > >>>>>> So, I thought that it would be better to define "a flow" exactly > in > >>>>>> netext > >>>>>> WG prior to discuss flow mobility management. As the definition > of "a > >>>>>> flow", > >>>>>> all I can think is a five-tuple plus something. If we assume > that it is > >>>>>> correct, I think that flow mobility and prefix addition are > inevitably > >>>>>> tied. > >>>>>> As you know, RFC5213 (and IPv6 protocol spec) already allow to > assign > >>>>>> multiple prefixes across multiple interfaces of an MN. Yes, I > also agree > >>>>>> with you that in real-world (3GPP), there may be no need to > assign > >>>>>> multiple > >>>>>> prefixes into an MN. (if somebody knows its necessity, please > tell me > >>>>>> when > >>>>>> it should happen). So, flow mobility can be done without adding > prefixes. > >>>>>> However, different interfaces are allowed to be assigned > different > >>>>>> prefixes > >>>>>> by RFC 5213 and IPv6 spec. We can't expect what kind of prefixes > an MAG > >>>>>> advertises. Therefore, sometimes, we need prefix addition to > move a flow > >>>>>> to > >>>>>> a new interface of which MAG does not yet advertise the prefix > of the > >>>>>> flow > >>>>>> being moved. > >>>>>> > >>>>>> (snip...) > >>>>>> > >>>>>>>>> I see no reason to depart from that in the context of > extending the > >>>>>>>>> protocol to support mobility, nor I am aware of any system > >>>>>>>>> architecture that would require this capability. > >>>>>>>> > >>>>>>>> Okay, see your position. I see it differently. I don't need to > be > >>>>>>>> bound by some "presumed implementation model" of PMIP6 and > limit > >>>>>>>> myself *only* to a prefix assignment model you are imagining. > >>>>>>> > >>>>>>> It's not an implementation model, it is a protocol model, and > it's not > >>>>>>> imaginary. Implementation has nothing to do with this. > >>>>>>> > >>>>>>> There's no reason to extend prefix assignment model to do flow > mobility > >>>>>>> unless you can point me out in which real world context your > scenario > >>>>>>> actually happens. > >>>>>> > >>>>>> As I insisted in the old mail, I agree with Julien in this > regard. > >>>>>> Current > >>>>>> draft allows too much space regarding the prefix allocation > model > >>>>>> (unique, > >>>>>> shared, and hybrid). When a flow should be moved to a new > interface and > >>>>>> the > >>>>>> prefix which the flow uses is not yet advertised by the new MAG, > just > >>>>>> inform > >>>>>> the prefix to the MAG and thus make it advertise the prefix and > setup the > >>>>>> tunnel based on the new prefix. That's all!. If the prefix is > already > >>>>>> advertised by the MAG, there is nothing to do and just move the > flow. > >>>>>> This > >>>>>> behaviors are very natural one when we want to support IP-level > mobility. > >>>>>> > >>>>>>>>> If this is something really important, the WG can be > rechartered to > >>>>>>>>> work on a different extension that would allow > adding/removing > >>>>>>>>> prefixes from existing PMIPv6 sessions. > >>>>>>>> > >>>>>>>> Huh.. What in the current charter forces us not to have the > LMA > >>>>>>>> add/refresh/delete a prefix on-demand? > >>>>>>> > >>>>>>> Engineering is about finding a solution to a problem. > Adding/deleting > >>>>>>> prefix on-demand is not a solution to flow mobility. I've shown > you how > >>>>>>> to do flow mobility without this capability. > >>>>>> > >>>>>> From the viewpoint of protocol, I think that at least, prefix > addition to > >>>>>> an > >>>>>> interface is a necessary function to support flow mobility, as I > >>>>>> explained > >>>>>> above. But, it does not mean prefix addition should happen > always > >>>>>> whenever > >>>>>> flow mobility occurs. It is sometimes needed. > >>>>>> > >>>>>>> Now a different engineering problem would be: how to add/delete > prefixes > >>>>>>> to a PMIPv6 session, and that would be useful for e.g. > >>>>>>> renumbering. This is a different problem that we haven't been > chartered > >>>>>>> to work on. > >>>>>> > >>>>>> Prefix addition is just prefix addition. IMHO, renumbering is > closer to > >>>>>> prefix change. We just harness that function to support IP-level > >>>>>> mobility. > >>>>>> > >>>>>> Youn-Hee > >>>>>> > >>>>>> _______________________________________________ > >>>>>> netext mailing list > >>>>>> netext@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/netext > >>>>> > >>>> _______________________________________________ > >>>> netext mailing list > >>>> netext@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/netext > >>>> > >>> > >>> > >> > >> > > > > >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From gerardog@qualcomm.com Wed Feb 9 14:33:11 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C56F3A672E for ; Wed, 9 Feb 2011 14:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.24 X-Spam-Level: X-Spam-Status: No, score=-106.24 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-GRVIYcOshW for ; Wed, 9 Feb 2011 14:33:08 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 41A583A6868 for ; Wed, 9 Feb 2011 14:33:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1297290799; x=1328826799; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:content-transfer-encoding: mime-version; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20"Zuniga,=20Juan=20Carlos"=20,=0D=0A=09"Basavaraj.Patil@nokia.com"=20,=20"sfaccin@rim.com"=0D=0A=09,=20"telemaco.melia@alcatel-lucent.com"=0D =0A=09,=20"julien.ietf @gmail.com"=0D=0A=09,=20"cjbc@it.u c3m.es"=20|CC:=20"netext@ietf.org"=20|Subject:=20RE:=20[netext]=20Consensus=20ca ll=20to=20adopt=20I-D:=0D=0A=09draft-bernardos-netext-pmi pv6-flowmob=20as=20WG=20doc|Thread-Topic:=20[netext]=20Co nsensus=20call=20to=20adopt=20I-D:=0D=0A=09draft-bernardo s-netext-pmipv6-flowmob=20as=20WG=20doc|Thread-Index:=20A QHLyIEDYFIG8HSGyk+jR8KcbhlST5P5wT7A|Date:=20Wed,=209=20Fe b=202011=2022:33:18=20+0000|Message-ID:=20 |References:=20<680854867F7FD04BB9B06EB8ACA8D5AC05EFEC1B@ XCH02DFW.rim.net>=0D=0A=09=0D=0A=20|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|x-originating-ip: =20[172.30.39.5]|Content-Type:=20text/plain=3B=20charset =3D"utf-8"|Content-Transfer-Encoding:=20base64 |MIME-Version:=201.0; bh=eFKomJ7u/GxE+SwVj1k5RlHRc6xtriQX2kzNKzcM6hA=; b=eGvSHz1/3LG+KKHcOHg3RXV90+jnh3Ho1eW4yJ8VVWsZhHf1ePu7Mas7 bYbHEJBASoI3YdKrz4aMdhn3kF99wZjNfZ9SXwOa732vWKSX2/FrgX1I5 tyvopjkYgEp/CKaMkzf+dtTUSwM77b+EvqMxzoYGGbo33xuuj4U6V0jp8 s=; X-IronPort-AV: E=McAfee;i="5400,1158,6252"; a="73617709" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 09 Feb 2011 14:33:18 -0800 X-IronPort-AV: E=Sophos;i="4.60,446,1291622400"; d="scan'208";a="49528199" Received: from nasanexhc06.na.qualcomm.com ([172.30.48.21]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 09 Feb 2011 14:33:18 -0800 Received: from NASANEXD01E.na.qualcomm.com ([fe80::6555:8c37:4ee3:efc4]) by nasanexhc06.na.qualcomm.com ([172.30.48.21]) with mapi id 14.01.0270.001; Wed, 9 Feb 2011 14:33:18 -0800 From: "Giaretta, Gerardo" To: "Zuniga, Juan Carlos" , "Basavaraj.Patil@nokia.com" , "sfaccin@rim.com" , "telemaco.melia@alcatel-lucent.com" , "julien.ietf@gmail.com" , "cjbc@it.uc3m.es" Thread-Topic: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLyIEDYFIG8HSGyk+jR8KcbhlST5P5wT7A Date: Wed, 9 Feb 2011 22:33:18 +0000 Message-ID: References: <680854867F7FD04BB9B06EB8ACA8D5AC05EFEC1B@XCH02DFW.rim.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "netext@ietf.org" Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 22:33:11 -0000 U29sdXRpb24gZm9jdXNlcyBvbiBhc3NpZ25pbmcgbXVsdGlwbGUgcHJlZml4ZXMgb24gZGVtYW5k IGJhc2VkIG9uIHNvbWUgbWFnaWMga25vd2xlZGdlIG9mIHRoZSBMTUEgYW5kIHRoaXMgaGFzIG5v dGhpbmcgdG8gZG8gd2l0aCB0aGUgV0cgaXMgY2hhcnRlcmVkIHRvIGRvLg0KDQpBbHNvLCBJIGRv bid0IGxpa2UgdGhhdCBldmVyeXRpbWUgdGhlcmUgYXJlIGNvbW1lbnRzIG9uIFBNSVAgdGhlcmUg YXJlIHBlb3BsZSBjbGFpbWluZyB0aGUgY29tbWVudHMgYXJlIG5vdCB0ZWNobmljYWwgYnV0IHJl bGlnaW91cy4gSSBoYXZlIHJlYWQgbWFueSB0ZWNobmljYWwgY29tbWVudHMgZnJvbSBwZW9wbGUg ZnJvbSBkaWZmZXJlbnQgY29tcGFuaWVzIGluIHRoaXMgdGhyZWFkDQoNCkdlcmFyZG8gDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbmV0ZXh0LWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpuZXRleHQtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9mIFp1bmln YSwgSnVhbiBDYXJsb3MNCj4gU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwOSwgMjAxMSA5OjQ0 IEFNDQo+IFRvOiBCYXNhdmFyYWouUGF0aWxAbm9raWEuY29tOyBzZmFjY2luQHJpbS5jb207IHRl bGVtYWNvLm1lbGlhQGFsY2F0ZWwtDQo+IGx1Y2VudC5jb207IGp1bGllbi5pZXRmQGdtYWlsLmNv bTsgY2piY0BpdC51YzNtLmVzDQo+IENjOiBuZXRleHRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6 IFtuZXRleHRdIENvbnNlbnN1cyBjYWxsIHRvIGFkb3B0IEktRDogZHJhZnQtYmVybmFyZG9zLQ0K PiBuZXRleHQtcG1pcHY2LWZsb3dtb2IgYXMgV0cgZG9jDQo+IA0KPiArMQ0KPiANCj4gSSBzdXBw b3J0IHRoZSBpZGVhIGZyb20gUGllcnJpY2sgYW5kIFJhaiB0byBzdG9wIGdvaW5nIGluIGNpcmNs ZXMgd2l0aA0KPiByZWxpZ2lvdXMgYXJndW1lbnRzIGFuZCBjb25jZW50cmF0ZSBvbiB0aGUgc29s dXRpb24gYXQgaGFuZCwgd2hpY2gNCj4gcmVzcG9uZHMgdG8gd2hhdCB0aGUgV0cgaXMgY2hhcnRl cmVkIHRvIGRvLg0KPiANCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBG cm9tOiBuZXRleHQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5ldGV4dC1ib3VuY2VzQGlldGYu b3JnXSBPbg0KPiA+IEJlaGFsZiBPZiBCYXNhdmFyYWouUGF0aWxAbm9raWEuY29tDQo+ID4gU2Vu dDogRmVicnVhcnkgOSwgMjAxMSAxMjoxOSBQTQ0KPiA+IFRvOiBzZmFjY2luQHJpbS5jb207IHRl bGVtYWNvLm1lbGlhQGFsY2F0ZWwtbHVjZW50LmNvbTsNCj4gPiBqdWxpZW4uaWV0ZkBnbWFpbC5j b207IGNqYmNAaXQudWMzbS5lcw0KPiA+IENjOiBuZXRleHRAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0 OiBSZTogW25ldGV4dF0gQ29uc2Vuc3VzIGNhbGwgdG8gYWRvcHQgSS1EOiBkcmFmdC1iZXJuYXJk b3MtDQo+ID4gbmV0ZXh0LXBtaXB2Ni1mbG93bW9iIGFzIFdHIGRvYw0KPiA+DQo+ID4NCj4gPiBT dGVmYW5vLA0KPiA+DQo+ID4gTGV0cyBub3QgdGFsayBhYm91dCBBUlBVIG9yIG90aGVyIGFzcGVj dHMgb2Ygb3BlcmF0b3IgaXNzdWVzIHdoaWNoDQo+IGFyZQ0KPiA+IElNTw0KPiA+IG5vdCByZWFs bHkgaGVscGluZyB0aGlzIGRpc2N1c3Npb24uDQo+ID4NCj4gPiBCdXQgcmVnYXJkaW5nIHRoZSBx dWVzdGlvbiBvZiB3aGV0aGVyIHRoZXJlIGlzIGFuIG9wZW4gYW5kIGRlY2xhcmVkDQo+ID4gY3Vz dG9tZXIsIEkgZG9u4oCZdCBrbm93IGlmIHRoZSBXRyByZWFsbHkgbmVlZHMgdG8gYW5zd2VyIHRo YXQuDQo+ID4gVGhlIHBvaW50IGlzIHRoYXQgd2UgaGF2ZSBkZWZpbmVkIGEgbmV0d29yayBiYXNl ZCBtb2JpbGl0eSBwcm90b2NvbA0KPiA+IChSRkM1MjEzKSBpbiB0aGUgSUVURi4gVGhlcmUgaXMg YSBjb21tdW5pdHkgb2YgcGVvcGxlIGluIHRoZSBXRyB3aGljaA0KPiA+IGJlbGlldmVzIHRoYXQg ZXh0ZW5kaW5nIHRoZSBwcm90b2NvbCB0byBzdXBwb3J0IGZsb3cgbW9iaWxpdHkgd2lsbA0KPiA+ IGFkZHJlc3MNCj4gPiBzb21lIHNjZW5hcmlvcyBhbmQgdXNlIGNhc2VzLiBUaGUgYXBwbGljYWJp bGl0eSAgb2Ygc3VjaCBhIGZlYXR1cmUgaW4NCj4gPiAzR1BQDQo+ID4gYXJjaGl0ZWN0dXJlcyBp cyB0byBzb21lIGV4dGVudCBvcGVuLg0KPiA+IEkgdGhpbmsgd2Ugc2hvdWxkIGJlIGRvaW5nIHRo ZSB3b3JrIGFuZCBzcGVjaWZ5aW5nIHRoZSBzb2x1dGlvbi4NCj4gPiBVbmRlcnN0YW5kaW5nIHRo ZSB1c2UgY2FzZXMgZm9yIHRoZSBmZWF0dXJlIGlzIGdvb2QuIEJ1dCBJIHRoaW5rIHdlDQo+IGRv DQo+ID4gbm90DQo+ID4gaGF2ZSB0byBnbyBvdmVyYm9hcmQgaW4gdGVybXMgb2YgdmVyaWZ5aW5n IHRoZSBjdXN0b21lciBleGlzdGVuY2Ugb3INCj4gPiBpbnRlcmVzdC4NCj4gPg0KPiA+IC1SYWoN Cj4gPg0KPiA+IE9uIDIvOS8xMSAxMTowOCBBTSwgImV4dCBTdGVmYW5vIEZhY2NpbiIgPHNmYWNj aW5AcmltLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiA+VGVsZW1hY28sDQo+ID4gPkFsbCB0aGF0IHlv dSBzYXkgaXMgZ29vZCwgYXBhcnQgZnJvbSBvbmUgZGV0YWlsLiBJIGRvIG5vdCBiZWxpZXZlDQo+ IHRoYXQNCj4gPiA+aGVyZSBpbiBJRVRGIHdlIHNob3VsZCBiZSB0YWxraW5nIGFib3V0IEFSUFUg YW5kIGNvc3RzIGFuZCBzbyBvbi4gV2UNCj4gPiBhcmUNCj4gPiA+anVzdCBub3QgY2FwYWJsZSBv ZiBldmFsdWF0aW5nIHRoZW0uIElmIGluZGVlZCBhcyB5b3Ugc2F5IHRoaXMNCj4gPiBzb2x1dGlv bg0KPiA+ID53ZXJlIHRoZSBtYWdpYyBhbnN3ZXIgdG8gb3BlcmF0b3IgaXNzdWVzLCBJIGFtIHN1 cmUgb3BlcmF0b3JzIGluDQo+IDNHUFANCj4gPiA+d291bGQgaGF2ZSBzaG93biBhIGJpZ2dlciBp bnRlcmVzdCBpbiBpdC4gTXkgcHJldmlvdXMgcXVlc3Rpb24gb24NCj4gPiB3aGV0aGVyDQo+ID4g PndlIGhhdmUgYW4gb3BlbiBhbmQgZGVjbGFyZWQgY3VzdG9tZXIgZm9yIHRoaXMgc29sdXRpb24g KGkuZS4gdGhhdA0KPiA+ID5jbGVhcmx5IHN0YXRlZCB0aGlzIGlzIG5lZWRlZCkgaXMgc3RpbGwg dW5hbnN3ZXJlZCwgc28gcGVyaGFwcyB0aGVyZQ0KPiA+ID5pc24ndCBpbmRlZWQgc3VjaCBhbiBp bnRlcmVzdCBpbiB0aGlzIG1hZ2ljIHNvbHV0aW9uPw0KPiA+ID5DaGVlcnMsDQo+ID4gPlN0ZWZh bm8gRmFjY2luDQo+ID4gPg0KPiA+ID5TdGFuZGFyZHMgTWFuYWdlcg0KPiA+ID5SZXNlYXJjaCBJ biBNb3Rpb24gQ29ycG9yYXRpb24NCj4gPiA+NTAwMCBSaXZlcnNpZGUgRHJpdmUNCj4gPiA+QnVp bGRpbmcgNiwgQnJhem9zIEVhc3QsIFN0ZS4gMTAwDQo+ID4gPklydmluZywgVGV4YXMgNzUwMzkg VVNBDQo+ID4gPk9mZmljZTogKDk3MikgOTEwIDM0NTENCj4gPiA+SW50ZXJuYWw6IDgyMC42MzQ1 MQ0KPiA+ID46ICg1MTApIDIzMCA4NDIyDQo+ID4gPnd3dy5yaW0uY29tOyB3d3cuYmxhY2tiZXJy eS5jb20NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+74GQIENvbnNpZGVyIHRoZSBlbnZpcm9u bWVudCBiZWZvcmUgcHJpbnRpbmcuDQo+ID4gPg0KPiA+ID4NCj4gPiA+LS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPiA+RnJvbTogbmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpu ZXRleHQtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gPiBCZWhhbGYNCj4gPiA+T2YgTUVMSUEsIFRF TEVNQUNPIChURUxFTUFDTykNCj4gPiA+U2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwOSwgMjAx MSA3OjE4IEFNDQo+ID4gPlRvOiBKdWxpZW4gTGFnYW5pZXI7IGNqYmNAaXQudWMzbS5lcw0KPiA+ ID5DYzogbmV0ZXh0QGlldGYub3JnOyBCYXNhdmFyYWouUGF0aWxAbm9raWEuY29tDQo+ID4gPlN1 YmplY3Q6IFJlOiBbbmV0ZXh0XSBDb25zZW5zdXMgY2FsbCB0byBhZG9wdCBJLUQ6DQo+ID4gPmRy YWZ0LWJlcm5hcmRvcy1uZXRleHQtcG1pcHY2LWZsb3dtb2IgYXMgV0cgZG9jDQo+ID4gPg0KPiA+ ID5CdXQgd2h5IHdlIGNhbm5vdCBkZXNpZ24gYSBtb2RlbCB3aGVyZSB3ZSBjYW4gZHluYW1pY2Fs bHkgZ3JvdXANCj4gPiBzZXNzaW9ucz8NCj4gPiA+TW9iaWxlIG9wZXJhdG9ycyBoYXZlIGJlZW4g ZmlnaHRpbmcgaGFyZCBpbiB0aGUgcGFzdCB5ZWFycyB0aGUNCj4gPiA+ZGlzY29ubmVjdGlvbiBi ZXR3ZWVuIEFSUFUgYW5kIGFzc29jaWF0ZWQgY29zdCBwZXIgdXNlcnMgKGluIG90aGVyDQo+ID4g d29yZHMNCj4gPiA+Y29zdHMgaW5jcmVhc2UgYnV0IHJldmVudWVzIGNvbnRpbnVlIHRvIGZhbGwp LiBEYXRhIGV4cGxvc2lvbiBpcyBvbmUNCj4gPiBvZg0KPiA+ID50aGUgcmVhc29ucyBmb3Igc3Vj aCBkaXNjb25uZWN0aW9uLg0KPiA+ID5JIGJlbGlldmUgdGhhdCBuZXR3b3JrIG9wZXJhdG9ycyB3 b3VsZCBiZSBlYWdlciB0byBsZWFybiBhYm91dA0KPiA+IGlubm92YXRpbmcNCj4gPiA+dGVjaG5v bG9naWVzIHRvIHJlZHVjZSBjb3N0cyBleHBlbmRpdHVyZXMuIFRoZSB3b3JrIHdlIGFyZSBwdXNo aW5nDQo+ID4gd2l0aA0KPiA+ID50aGlzIElEIGZhbGxzIGV4YWN0bHkgaW4gdGhpcyBjYXRlZ29y eS4gUmVzdHJpY3RpbmcgdG8gdGhlIGxlZ2FjeQ0KPiA+IFBNSVB2Ng0KPiA+ID5tb2RlbCBpcyBh IGxpbWl0YXRpb24uDQo+ID4gPg0KPiA+ID5JIHdvdWxkIGJlIGdsYWQgdG8gaGVhciBvcGluaW9u cyBmcm9tIG90aGVyIChkaWZmZXJlbnQpIHZvaWNlcy4NCj4gPiA+DQo+ID4gPnRlbGVtYWNvDQo+ ID4gPg0KPiA+ID4tLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPiA+RGUgOiBuZXRleHQt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5ldGV4dC1ib3VuY2VzQGlldGYub3JnXSBEZSBsYQ0K PiA+IHBhcnQNCj4gPiA+ZGUgSnVsaWVuIExhZ2FuaWVyDQo+ID4gPkVudm95w6kgOiBtZXJjcmVk aSA5IGbDqXZyaWVyIDIwMTEgMDM6MjANCj4gPiA+w4AgOiBjamJjQGl0LnVjM20uZXMNCj4gPiA+ Q2MgOiBCYXNhdmFyYWouUGF0aWxAbm9raWEuY29tOyBuZXRleHRAaWV0Zi5vcmcNCj4gPiA+T2Jq ZXQgOiBSZTogW25ldGV4dF0gQ29uc2Vuc3VzIGNhbGwgdG8gYWRvcHQgSS1EOg0KPiA+ID5kcmFm dC1iZXJuYXJkb3MtbmV0ZXh0LXBtaXB2Ni1mbG93bW9iIGFzIFdHIGRvYw0KPiA+ID4NCj4gPiA+ SGkgQ2FybG9zLA0KPiA+ID4NCj4gPiA+MjAxMS8yLzggQ2FybG9zIEplc8O6cyBCZXJuYXJkb3Mg Q2FubyA8Y2piY0BpdC51YzNtLmVzPjoNCj4gPiA+PiBIaSBKdWxpZW4sDQo+ID4gPj4NCj4gPiA+ PiBPbiBUdWUsIDIwMTEtMDItMDggYXQgMTc6MjEgLTA4MDAsIEp1bGllbiBMYWdhbmllciB3cm90 ZToNCj4gPiA+Pj4gSGkgQ2FybG9zLA0KPiA+ID4+Pg0KPiA+ID4+PiBJIGFtIGdsYWQgdG8gc2Vl IHlvdSBhZ3JlZSB3aXRoIG1lIDotKQ0KPiA+ID4+Pg0KPiA+ID4+PiBZb3UncmUgYWN0dWFsbHkg cHJvdmluZyBteSBwb2ludC4NCj4gPiA+Pj4NCj4gPiA+Pj4gVG8gcnVuIGFueSBvZiB0aGUgZmxv dyBtb2JpbGl0eSBzdHVmZiBvbiBhIGhvc3QsIHlvdSB3aWxsIG5lZWQNCj4gPiBlaXRoZXINCj4g PiA+Pj4gbGF5ZXIgMiB0byBoaWRlIHRoZSBkaXNzaW1pbGFyIGludGVyZmFjZXMgKHZpcnR1YWwg aW50ZXJmYWNlDQo+ID4gdGhpbmcpLA0KPiA+ID4+PiBpbiB3aGljaCBjYXNlIHlvdSBkbyBoYXZl IEwyIHRyaWdnZXJzLCBvciB0byBtb2RpZnkgdGhlIGxheWVyIDMsDQo+ID4gd2hpY2gNCj4gPiA+ Pj4gdGhpcyBXRyBpcyBleHBsaWNpdGx5IHByZXZlbnRlZCBmcm9tIGRvaW5nIGFzc3VtaW5nIHRo YXQncyBldmVuDQo+ID4gPj4+IHBvc3NpYmxlLg0KPiA+ID4+Pg0KPiA+ID4+PiBTbyB5b3UgbmVl ZCBsYXllciAyLiBBbmQgdGhhdCBpcyBhY3R1YWxseSBleGFjdGx5IGhvdyBuZXRleHQNCj4gY291 bGQNCj4gPiBnZXQNCj4gPiA+Pj4gY2hhcnRlcmVkIHRvIHdvcmsgb24gZmxvdyBtb2JpbGl0eSwg YmVjYXVzZSB3ZSBhc3N1bWVkIGxheWVyIDINCj4gPiB3b3VsZA0KPiA+ID4+PiBiZSB0aGVyZSB0 byBoZWxwIHdpdGggYWxsIHRoZSBzdHVmZiB3ZSdyZSBub3QgYWxsb3dlZCB0byBkbyBhdA0KPiA+ IGxheWVyDQo+ID4gPj4+IDMuDQo+ID4gPj4NCj4gPiA+PiBFeGFjdGx5LCB5b3UgbmVlZCBsYXll ciAyIHRvIGhlbHAgd2l0aCBhbGwgdGhlIHN0dWZmIHdlIGFyZSBub3QNCj4gPiBhbGxvd2VkDQo+ ID4gPj4gdG8gZG8gYXQgbGF5ZXIgMywgX2J1dF8gbm90IHRvIGRvIHRoaW5ncyB0aGF0IHdlIGRv bid0IG5lZWQgdG8gZG8NCj4gYXQNCj4gPiB0aGUNCj4gPiA+PiBNTiwgYW5kIGNhbiBiZSB0cml2 aWFsbHkgZG9uZSB3aXRoIExNQS1NQUcgc2lnbmFsaW5nIHdpdGhvdXQNCj4gcHV0dGluZw0KPiA+ ID4+IHN0cm9uZyByZXF1aXJlbWVudHMgb24gdGhlIGxheWVyIDIuDQo+ID4gPj4NCj4gPiA+PiBU aGUgc2lnbmFsaW5nIHdlIGRlZmluZSBpbiBvdXIgZHJhZnQgKG9yIHZhcmlhdGlvbnMgYXJvdW5k IHRoYXQpDQo+ID4gYWxsb3dzDQo+ID4gPj4gdG8gc3VwcG9ydCBhbGwgdGhlIHNjZW5hcmlvcyB0 aGF0IGhhdmUgYmVlbiBtZW50aW9uZWQgc28gZmFyLCBhbmQNCj4gPiBkb2VzDQo+ID4gPj4gbm90 IGJyZWFrIGFueSBQTUlQdjYgY29uY2VwdCAtLSBqdXN0IGV4dGVuZHMgaXQuIEl0IGRvZXMgbm90 DQo+IHJlcXVpcmUNCj4gPiA+PiBjb21wbGV4IGxheWVyIDIgdHJpZ2dlcnMvcG9saWNpZXMgdG8g YmUgaW4gcGxhY2UgYW5kIGl0J3MNCj4gdGhlcmVmb3JlDQo+ID4gbW9yZQ0KPiA+ID4+IGxheWVy LTIgYWdub3N0aWMuIFN0aWxsLCB5b3UgcHJlZmVycyB0byBnbyBmb3IgdGhlICJsZXRzIHJlZG8g TUlQDQo+IGF0DQo+ID4gPj4gbGF5ZXItMiIsIGFuZCBJIGtlZXAgZmFpbGluZyB0byBzZWUgd2h5 DQo+ID4gPg0KPiA+ID5QTUlQdjYgYXMgcGVyIFJGQzUyMTMgZG9lc24ndCB3b3JrIHdpdGhvdXQg TDIgdHJpZ2dlcnMsIHNvIHRoZXJlJ3MNCj4gbm8NCj4gPiA+dmFsdWUgaW4gZXh0ZW5kaW5nIFBN SVB2NiB0byBzcGFyZSByZWx5aW5nIG9uIEwyIHRyaWdnZXJzIHRoYXQgYXJlDQo+ID4gPnJlcXVp cmVkIGFueXdheS4NCj4gPiA+DQo+ID4gPi0tanVsaWVuDQo+ID4gPg0KPiA+ID4tLWp1bGllbg0K PiA+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ ID5uZXRleHQgbWFpbGluZyBsaXN0DQo+ID4gPm5ldGV4dEBpZXRmLm9yZw0KPiA+ID5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGV4dA0KPiA+ID5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID5uZXRleHQgbWFpbGluZyBs aXN0DQo+ID4gPm5ldGV4dEBpZXRmLm9yZw0KPiA+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldGV4dA0KPiA+ID4NCj4gPiA+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLQ0KPiA+ID5U aGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5IGNvbnRhaW4N Cj4gY29uZmlkZW50aWFsDQo+ID4gPmluZm9ybWF0aW9uLCBwcml2aWxlZ2VkIG1hdGVyaWFsIChp bmNsdWRpbmcgbWF0ZXJpYWwgcHJvdGVjdGVkIGJ5DQo+IHRoZQ0KPiA+ID5zb2xpY2l0b3ItY2xp ZW50IG9yIG90aGVyIGFwcGxpY2FibGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1dGUNCj4gPiA+ bm9uLXB1YmxpYyBpbmZvcm1hdGlvbi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5IGFu eW9uZSBvdGhlcg0KPiA+IHRoYW4NCj4gPiA+dGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9o aWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzDQo+ID4gPnRyYW5zbWlzc2lvbiBpbiBl cnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5kDQo+ID4gZGVs ZXRlDQo+ID4gPnRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4gVXNlLCBkaXNzZW1p bmF0aW9uLCBkaXN0cmlidXRpb24sDQo+ID4gb3INCj4gPiA+cmVwcm9kdWN0aW9uIG9mIHRoaXMg dHJhbnNtaXNzaW9uIGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50cyBpcyBub3QNCj4gPiA+YXV0aG9y aXplZCBhbmQgbWF5IGJlIHVubGF3ZnVsLg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBuZXRleHQgbWFpbGluZyBsaXN0DQo+ID4g bmV0ZXh0QGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRleHQNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gbmV0ZXh0IG1haWxpbmcgbGlzdA0KPiBuZXRleHRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRleHQNCg== From gerardog@qualcomm.com Wed Feb 9 14:36:20 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26CD93A6870 for ; Wed, 9 Feb 2011 14:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.671 X-Spam-Level: X-Spam-Status: No, score=-105.671 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFivFbHUnPQp for ; Wed, 9 Feb 2011 14:36:18 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id C4B053A686E for ; Wed, 9 Feb 2011 14:36:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1297290989; x=1328826989; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:content-transfer-encoding: mime-version; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20Julien=20Laganier=20,=0D=0A =09"pierrick.seite@orange-ftgroup.com"=20|CC:=20"Basavaraj.Patil@nokia.com"=20< Basavaraj.Patil@nokia.com>,=20"netext@ietf.org"=0D=0A=09< netext@ietf.org>|Subject:=20RE:=20[netext]=20Consensus=20 call=20to=20adopt=0D=0A=20I-D:draft-bernardos-netext-pmip v6-flowmob=20as=20WG=20doc|Thread-Topic:=20[netext]=20Con sensus=20call=20to=20adopt=0D=0A=20I-D:draft-bernardos-ne text-pmipv6-flowmob=20as=20WG=20doc|Thread-Index:=20AQHLy JKxXDqI2rPEWUKfVh28UPFIJJP5wi/w|Date:=20Wed,=209=20Feb=20 2011=2022:36:15=20+0000|Message-ID:=20 |References:=20=0D=0A=09=0D=0A=09=0D=0A=09<015b01cbc77f$69f132e0$3d d398a0$@gmail.com>=0D=0A=09<843DA8228A1BA74CA31FB4E111A5C 462017D4533@ftrdmel0.rd.francetelecom.fr>=0D=0A=09 =0D=0A=09<843DA8228A1BA74CA31FB4E111A5C462017D475F@ftrdme l0.rd.francetelecom.fr>=0D=0A=20|In-Reply-To:=20|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|x-originating-ip: =20[172.30.39.5]|Content-Type:=20text/plain=3B=20charset =3D"iso-8859-1"|Content-Transfer-Encoding:=20quoted-print able|MIME-Version:=201.0; bh=ARwAuE8bgV4c2A4SNDfFh1AUIby1IChYuKSDTXuEq4g=; b=ubv2ecvi9DcEzOSwf+Tw/d6BZEjHK6JAFhFJo4zvWEDBNoDOi8jfq6ho DrLogdf6KX1eAE2d5+D58OjbJwrd+xso9asppzACuPlBAiFTllCNypxvj 0xoXHbkZ+2Xf6Cxw+E7cnBJdF0v3YNuinkGglKGUwkOXSSoTUG1lwoqCU w=; X-IronPort-AV: E=McAfee;i="5400,1158,6252"; a="73828671" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 09 Feb 2011 14:36:16 -0800 X-IronPort-AV: E=Sophos;i="4.60,446,1291622400"; d="scan'208";a="49528482" Received: from nasanexhc06.na.qualcomm.com ([172.30.48.21]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 09 Feb 2011 14:36:16 -0800 Received: from NASANEXD01E.na.qualcomm.com ([fe80::6555:8c37:4ee3:efc4]) by nasanexhc06.na.qualcomm.com ([172.30.48.21]) with mapi id 14.01.0270.001; Wed, 9 Feb 2011 14:36:16 -0800 From: "Giaretta, Gerardo" To: Julien Laganier , "pierrick.seite@orange-ftgroup.com" Thread-Topic: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLyJKxXDqI2rPEWUKfVh28UPFIJJP5wi/w Date: Wed, 9 Feb 2011 22:36:15 +0000 Message-ID: References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C462017D475F@ftrdmel0.rd.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 22:36:20 -0000 > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > Behalf Of Julien Laganier > Sent: Wednesday, February 09, 2011 11:51 AM > To: pierrick.seite@orange-ftgroup.com > Cc: Basavaraj.Patil@nokia.com; netext@ietf.org > Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos- > netext-pmipv6-flowmob as WG doc >=20 > Hi Pierrick, >=20 > Please see my anwer inline below: >=20 > On Wed, Feb 9, 2011 at 4:29 AM, > wrote: > > > > Hi, > > > > My only concern is on step 8, Please see inline. > > > > Pierrick > > > >> -----Message d'origine----- > >> De=A0: Julien Laganier [mailto:julien.ietf@gmail.com] > >> Envoy=E9=A0: mardi 8 f=E9vrier 2011 23:19 > >> =C0=A0: SEITE Pierrick RD-RESA-REN > >> Cc=A0: yh21.han@gmail.com; rkoodli@cisco.com; netext@ietf.org; > >> Basavaraj.Patil@nokia.com > >> Objet=A0: Re: [netext] Consensus call to adopt I-D:draft-bernardos- > netext- > >> pmipv6-flowmob as WG doc > >> > >> Hi Pierrick, > >> > >> I am going to intertwine the steps in your scenario below with the > >> missing pieces of the big picture so that we are not doing an > academic > >> exercise but focusing on the real world: > >> > >> 1. when the MN first attaches with if1 to a network, MAG1 requests > >> attachment of if1 to a session1 by sending a PBU to LMA > >> > >> 2. because the MN add no session1 previously, the LMA creates > session > >> 1 and allocates a prefix for it. The prefix is sent back to MAG1 in > >> the PBA: > >> > >> =A0=A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1-IF1] > >> > >> 3. then, if the MN attaches with if2 to another network, but does > not > >> request this interface be attached to a distinct session, MAG2 > >> requests attachemnt of If2 to session1 by sending a PBU to LMA > >> > >> 4. Because the MN already has session 1, the LMA updates session1 > with > >> if2, and send the pref1 back to MAG2 in the PBA: > >> > >> =A0=A0 =A0 =A0 =A0 Session1: [Pref1, MAG1-IF1, MAG2-IF2] > >> > >> 5. Creation of a new session 2 for if2 is requested by either of MN > >> requests via L2 triggers, or a change in policy profile. As a > result, > >> MAG2 requests attachment of if2 to session2 by sending a PBU to LMA. > >> > >> 6. because the MN add no session2 previously, the LMA creates > session > >> 2 and allocates a prefix for it. The prefix pref2 is sent back to > MAG2 > >> in the PBA: > >> > >> =A0=A0 =A0 =A0 =A0 =A0Session2: [Pref2, MAG2-IF2] > >> > >> 7. Flow2 starts over if2 with prefix2. > >> > >> 8. Attachment of if1 to session2 is requested by either of MN > requests > >> via L2 triggers, or a change in policy profile. As a result, MAG1 > >> requests attachment of if1 to session2 by sending a PBU to LMA. > >> > > > > But the MN is already attached to MAG1 via If1. So, without being too > 3GPP specific, what kind of L2 triggers can be used? >=20 > Being 3GPP specific: Additional PDN Connectivity Request. >=20 > Without being 3GPP specific, a L2 trigger requesting creation of an > additional session. >=20 > > To be more generic, I think that, for this case (attach a working > interface to a new session), we could have LMA/MAG signalling, maybe as > an option? The use-case I have in mind is a short-term deployment of > PMIP IP flow mobility over WiFi and 3GPP networks. Because, it is a > short term deployment, I have to use legacy 3G network (i.e. without > LTE or inter-systems mobility mechanisms); so the 3G network must be > agnostic of PMIP support and I can't rely on L2 to trigger PMIP. >=20 > If you have no L2 trigger you cannot even use RFC5213 PMIP as the MAG > has no way to detect a MN attached and initiate PBU towards LMA. >=20 > If your "3G network must be agnostic of PMIP support", PMIP is a no > go. (you could use MIPv6, it works well over an unmodified 3G network > as it is a full overlay.) >=20 And it is also RFC and specified by 3GPP Release 8 with the spec being aske= d by a French operator :-) Gerardo=20 > --julien > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From gerardog@qualcomm.com Wed Feb 9 15:14:19 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A9453A67F3 for ; Wed, 9 Feb 2011 15:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.175 X-Spam-Level: X-Spam-Status: No, score=-105.175 tagged_above=-999 required=5 tests=[AWL=-0.730, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2zX0qRJAXKs for ; Wed, 9 Feb 2011 15:14:17 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 979303A67AC for ; Wed, 9 Feb 2011 15:14:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1297293268; x=1328829268; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:content-transfer-encoding: mime-version; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20"MELIA,=20TELEMACO=20(TELEMACO)"=20,=20Julien=0D=0A=20Laganier=20,=20Tran=20Minh=20Trung=20|CC:=20"netext@ietf.org"=20,=20" Basavaraj.Patil@nokia.com"=0D=0A=09|Subject:=20RE:=20[netext]=20Consensus=20call=20to =20adopt=0D=0A=20I-D:draft-bernardos-netext-pmipv6-flowmo b=20as=20WG=20doc|Thread-Topic:=20[netext]=20Consensus=20 call=20to=20adopt=0D=0A=20I-D:draft-bernardos-netext-pmip v6-flowmob=20as=20WG=20doc|Thread-Index:=20AQHLx94soydSZ0 L5ekCHxlX1jM06mpP4/lqAgAABKoCAANS/AP//+aeA|Date:=20Wed, =209=20Feb=202011=2023:14:26=20+0000|Message-ID:=20|References:=20=0D=0A=09=0D=0A=09=0D=0A=09<015b01cbc77f$69f132 e0$3dd398a0$@gmail.com>=0D=0A=09<843DA8228A1BA74CA31FB4E1 11A5C462017D4533@ftrdmel0.rd.francetelecom.fr>=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=20<3D6C64F2D792B5 40BAAEBCEF6509363B0EE6D6D206@FRMRSSXCHMBSE1.dc-m.alcatel- lucent.com>|In-Reply-To:=20<3D6C64F2D792B540BAAEBCEF65093 63B0EE6D6D206@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|x-originating-ip: =20[172.30.39.5]|Content-Type:=20text/plain=3B=20charset =3D"iso-8859-1"|Content-Transfer-Encoding:=20quoted-print able|MIME-Version:=201.0; bh=7xx7ZuTbRuD9AEzJk2EUDGmHDOogySdBWxofkLFv93g=; b=BNG0iAQ/vTANRYw+FtIvXi60Om05bL7lO0SfynDQfu2KSH6iej5gWiRY xsoRQWJYVSdIj4ypfOcNM6s9iZlqLKjJg0PC0UOQN5Qo9ALb5QdqEhTtj Z+CpIuNNPk8lzJeVg3e/FcgvA0sQEHnXGAzqFpx4PowrQ/FRbqaoXDsQq U=; X-IronPort-AV: E=McAfee;i="5400,1158,6252"; a="73622259" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 09 Feb 2011 15:14:27 -0800 X-IronPort-AV: E=Sophos;i="4.60,446,1291622400"; d="scan'208";a="28864155" Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 09 Feb 2011 15:14:27 -0800 Received: from NASANEXD01E.na.qualcomm.com ([fe80::6555:8c37:4ee3:efc4]) by nasanexhc05.na.qualcomm.com ([::1]) with mapi id 14.01.0270.001; Wed, 9 Feb 2011 15:14:28 -0800 From: "Giaretta, Gerardo" To: "MELIA, TELEMACO (TELEMACO)" , Julien Laganier , Tran Minh Trung Thread-Topic: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AQHLx94soydSZ0L5ekCHxlX1jM06mpP4/lqAgAABKoCAANS/AP//+aeA Date: Wed, 9 Feb 2011 23:14:26 +0000 Message-ID: References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6D206@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> In-Reply-To: <3D6C64F2D792B540BAAEBCEF6509363B0EE6D6D206@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 23:14:19 -0000 How does the LMA know the channel conditions of each radio?=20 How does the LMA know the radio coverage?=20 How does the LMA know the application requirements of the apps running in t= he UE? What happens if an app bind() to a radio?=20 How does the LMA know to not move the corresponding flow? I can add more when I have answers on these fundamental questions. Gerardo=20 > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > Behalf Of MELIA, TELEMACO (TELEMACO) > Sent: Wednesday, February 09, 2011 7:35 AM > To: Julien Laganier; Tran Minh Trung > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos- > netext-pmipv6-flowmob as WG doc >=20 > Why? If the terminal is connected and radio coverage is ok it also > means it is ready to receive traffic on any of the interfaces right? Up > the LMA to route flows. >=20 > telemaco >=20 > -----Message d'origine----- > De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la > part de Julien Laganier > Envoy=E9=A0: mercredi 9 f=E9vrier 2011 03:54 > =C0=A0: Tran Minh Trung > Cc=A0: netext@ietf.org; Basavaraj.Patil@nokia.com > Objet=A0: Re: [netext] Consensus call to adopt I-D:draft-bernardos- > netext-pmipv6-flowmob as WG doc >=20 > Changing the policy on the network side alone isn't sufficient. You'd > have to change the policy on the host, too (e.g., using ADNSF in 3GPP) > which will trigger the MN to attach IF1 to session 2. >=20 > This is the system view picture which seems we're missing in this > discussion. >=20 > --julien >=20 > On Tue, Feb 8, 2011 at 6:49 PM, Tran Minh Trung > wrote: > > Hi Julien, > > > > Let me show a real case for the scenario that we are discussing > bellow: > > > > The network policy is changed and the LMA decides to move flow 2 from > > IF2 to IF1 before MAG1 received L2 trigger from the MN (say before > > step #8) > > In that case, the LMA should signal MAG1 to send PBU to attach IF1 to > > session 2. > > > > Without signaling from LMA how can you do in this case? Just wait > > until receiving L2 trigger from the MN? > > > > On Wed, Feb 9, 2011 at 7:18 AM, Julien Laganier > wrote: > >> Hi Pierrick, > >> > >> I am going to intertwine the steps in your scenario below with the > >> missing pieces of the big picture so that we are not doing an > academic > >> exercise but focusing on the real world: > >> > >> 1. when the MN first attaches with if1 to a network, MAG1 requests > >> attachment of if1 to a session1 by sending a PBU to LMA > >> > >> 2. because the MN add no session1 previously, the LMA creates > session > >> 1 and allocates a prefix for it. The prefix is sent back to MAG1 in > >> the PBA: > >> > >> =A0=A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1-IF1] > >> > >> 3. then, if the MN attaches with if2 to another network, but does > not > >> request this interface be attached to a distinct session, MAG2 > >> requests attachemnt of If2 to session1 by sending a PBU to LMA > >> > >> 4. Because the MN already has session 1, the LMA updates session1 > with > >> if2, and send the pref1 back to MAG2 in the PBA: > >> > >> =A0=A0 =A0 =A0 =A0 Session1: [Pref1, MAG1-IF1, MAG2-IF2] > >> > >> 5. Creation of a new session 2 for if2 is requested by either of MN > >> requests via L2 triggers, or a change in policy profile. As a > result, > >> MAG2 requests attachment of if2 to session2 by sending a PBU to LMA. > >> > >> 6. because the MN add no session2 previously, the LMA creates > session > >> 2 and allocates a prefix for it. The prefix pref2 is sent back to > MAG2 > >> in the PBA: > >> > >> =A0=A0 =A0 =A0 =A0 =A0Session2: [Pref2, MAG2-IF2] > >> > >> 7. Flow2 starts over if2 with prefix2. > >> > >> 8. Attachment of if1 to session2 is requested by either of MN > requests > >> via L2 triggers, or a change in policy profile. As a result, MAG1 > >> requests attachment of if1 to session2 by sending a PBU to LMA. > >> > >> 9. Because the MN already has session 2, the LMA updates session2 > with if1: > >> > >> =A0=A0 =A0 =A0 =A0 Session2: [Pref2, MAG2-IF2, MAG1-IF1] > >> > >> 10. At any point, the LMA decides to move Flow2 between two > interfaces > >> of session 2, and it does so. > >> > >> That's all that needed. It maps perfectly to 3GPP. If you have in > mind > >> a different system in whcih that doesn't map, please let me know. > >> > >> --julien > >> > >> On Tue, Feb 8, 2011 at 8:25 AM, =A0 > wrote: > >>> Hi, > >>> > >>> Going through this long thread :-), it seems we could agree on the > following (just a tentative to summarize): > >>> > >>> Sessions should be created/updated with all available interfaces. > Rewriting Tran's example: when the MN attaches to MAG1 via If1, the LMA > creates session 1: > >>> > >>> =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] > >>> > >>> Then, if the MN attaches to MAG2 via If2, the LMA creates session 2 > with both If1 and If2. The LMA also updates session 1 with If2: > >>> > >>> =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] > >>> =A0 =A0 =A0 =A0 Session2: [Pref2, MAG2, IF2, IF1] > >>> > >>> MAG2 receives prefixes 1 and 2 in PBA but MAG1 is not sending PBU. > So, if the LMA wants to move flow with Pref2 from if2 to If1, the LMA > needs to provide Pref2 to MAG1. Also, the LMA should be able to create > new sessions with already up interfaces, e.g. if1 and if2. To address > both issues, PBU from MAG1 could be triggered (triggering is to be > clarified) or we could define LMA/MAG specific L3 signalling (FMI/FMA). > >>> > >>> My 2 cents, > >>> Pierrick > >>> > >>>> -----Message d'origine----- > >>>> De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De > la part > >>>> de Youn-Hee Han > >>>> Envoy=E9=A0: mardi 8 f=E9vrier 2011 12:00 > >>>> =C0=A0: 'Julien Laganier'; 'Rajeev Koodli' > >>>> Cc=A0: netext@ietf.org; Basavaraj.Patil@nokia.com > >>>> Objet=A0: Re: [netext] Consensus call to adopt I-D:draft-bernardos- > netext- > >>>> pmipv6-flowmob as WG doc > >>>> > >>>> Hi Julien, > >>>> > >>>> > -----Original Message----- > >>>> > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] > On Behalf > >>>> > Of Julien Laganier > >>>> > Sent: Tuesday, February 08, 2011 1:38 PM > >>>> > To: Rajeev Koodli > >>>> > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > >>>> > Subject: Re: [netext] Consensus call to adopt I-D: draft- > bernardos- > >>>> > netext-pmipv6-flowmob as WG doc > >>>> > > >>>> > On Mon, Feb 7, 2011 at 6:15 PM, Rajeev Koodli > wrote: > >>>> > > > >>>> > > If flow mobility has nothing do with prefix management, I am > lost. > >>>> > > >>>> > No reason to be lost: Prefix management is how do I get prefix > for the > >>>> > MN. Flow mobility is how to I move flows across interfaces. The > two > >>>> > needs not to be intertwined together, as I've shown in my other > notes. > >>>> > E.g., I can do flow mobility without adding/deleting prefixes > from > >>>> > sessions, and vice versa. > >>>> > >>>> Yes, I agree with you. Flow mobility is how to move flows across > interface. > >>>> So, I thought that it would be better to define "a flow" exactly > in netext > >>>> WG prior to discuss flow mobility management. As the definition of > "a > >>>> flow", > >>>> all I can think is a five-tuple plus something. If we assume that > it is > >>>> correct, I think that flow mobility and prefix addition are > inevitably > >>>> tied. > >>>> As you know, RFC5213 (and IPv6 protocol spec) already allow to > assign > >>>> multiple prefixes across multiple interfaces of an MN. Yes, I also > agree > >>>> with you that in real-world (3GPP), there may be no need to assign > >>>> multiple > >>>> prefixes into an MN. (if somebody knows its necessity, please tell > me when > >>>> it should happen). So, flow mobility can be done without adding > prefixes. > >>>> However, different interfaces are allowed to be assigned different > >>>> prefixes > >>>> by RFC 5213 and IPv6 spec. We can't expect what kind of prefixes > an MAG > >>>> advertises. Therefore, sometimes, we need prefix addition to move > a flow > >>>> to > >>>> a new interface of which MAG does not yet advertise the prefix of > the flow > >>>> being moved. > >>>> > >>>> (snip...) > >>>> > >>>> > >> I see no reason to depart from that in the context of > extending the > >>>> > >> protocol to support mobility, nor I am aware of any system > >>>> > >> architecture that would require this capability. > >>>> > > > >>>> > > Okay, see your position. I see it differently. I don't need to > be > >>>> > > bound by some "presumed implementation model" of PMIP6 and > limit > >>>> > > myself *only* to a prefix assignment model you are imagining. > >>>> > > >>>> > It's not an implementation model, it is a protocol model, and > it's not > >>>> > imaginary. Implementation has nothing to do with this. > >>>> > > >>>> > There's no reason to extend prefix assignment model to do flow > mobility > >>>> > unless you can point me out in which real world context your > scenario > >>>> > actually happens. > >>>> > >>>> As I insisted in the old mail, I agree with Julien in this regard. > Current > >>>> draft allows too much space regarding the prefix allocation model > (unique, > >>>> shared, and hybrid). When a flow should be moved to a new > interface and > >>>> the > >>>> prefix which the flow uses is not yet advertised by the new MAG, > just > >>>> inform > >>>> the prefix to the MAG and thus make it advertise the prefix and > setup the > >>>> tunnel based on the new prefix. That's all!. If the prefix is > already > >>>> advertised by the MAG, there is nothing to do and just move the > flow. This > >>>> behaviors are very natural one when we want to support IP-level > mobility. > >>>> > >>>> > >> If this is something really important, the WG can be > rechartered to > >>>> > >> work on a different extension that would allow > adding/removing > >>>> > >> prefixes from existing PMIPv6 sessions. > >>>> > > > >>>> > > Huh.. What in the current charter forces us not to have the > LMA > >>>> > > add/refresh/delete a prefix on-demand? > >>>> > > >>>> > Engineering is about finding a solution to a problem. > Adding/deleting > >>>> > prefix on-demand is not a solution to flow mobility. I've shown > you how > >>>> > to do flow mobility without this capability. > >>>> > >>>> From the viewpoint of protocol, I think that at least, prefix > addition to > >>>> an > >>>> interface is a necessary function to support flow mobility, as I > explained > >>>> above. But, it does not mean prefix addition should happen always > whenever > >>>> flow mobility occurs. It is sometimes needed. > >>>> > >>>> > Now a different engineering problem would be: how to add/delete > prefixes > >>>> > to a PMIPv6 session, and that would be useful for e.g. > >>>> > renumbering. This is a different problem that we haven't been > chartered > >>>> > to work on. > >>>> > >>>> Prefix addition is just prefix addition. IMHO, renumbering is > closer to > >>>> prefix change. We just harness that function to support IP-level > mobility. > >>>> > >>>> Youn-Hee > >>>> > >>>> _______________________________________________ > >>>> 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 > >> > > > > > > > > -- > > Ph.D., Senior Member > > Electronics and Telecommunications Research Institute > > Standards Research Center > > 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA > > Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 > > > _______________________________________________ > 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 rkoodli@cisco.com Wed Feb 9 15:49:06 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABEBB3A67D4 for ; Wed, 9 Feb 2011 15:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.451 X-Spam-Level: X-Spam-Status: No, score=-109.451 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmEKGnTMecFA for ; Wed, 9 Feb 2011 15:49:05 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 276C73A67FA for ; Wed, 9 Feb 2011 15:49:05 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMi2Uk2tJXG+/2dsb2JhbACkf2ZzoDqbLYMBglsEhH+GcYM4gwQ X-IronPort-AV: E=Sophos;i="4.60,448,1291593600"; d="scan'208";a="213861746" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rtp-iport-2.cisco.com with ESMTP; 09 Feb 2011 23:49:15 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p19NnF9i007100; Wed, 9 Feb 2011 23:49:15 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Feb 2011 17:49:14 -0600 Received: from 10.21.75.210 ([10.21.75.210]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Wed, 9 Feb 2011 23:49:14 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Wed, 09 Feb 2011 16:08:03 -0800 From: Rajeev Koodli To: Julien Laganier , Sri Gundavelli Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvItpWeJms7su/AMk2xF1Y1ib7tZQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 09 Feb 2011 23:49:14.0858 (UTC) FILETIME=[F531E4A0:01CBC8B3] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 23:49:06 -0000 Hello Folks, Protocols evolve in IETF, that's just how it goes. It's not a criticism of the previous design per se. The same goes for PMIPv6 here. To be very clear, what's being proposed is not to undo something, but add new functionality, without affecting the baseline functionality. OTOH, if the claim here is that two years of design could not be worked on AND 7 people on this list cannot possibly do anything to evolve it, that's news to me, in IETF. -Rajeev On 2/9/11 11:39 AM, "Julien Laganier" wrote: > Sri: >=20 > Well said. I couldn't agree more. >=20 > --julien >=20 > On Wed, Feb 9, 2011 at 10:11 AM, Sri Gundavelli wrot= e: >>=20 >> We want the LMA to dynamically add prefixes, pick a prefix based on the = hour >> of the day, or based on the weather, create sessions unilaterally and al= so >> reboot the MN at its mercy. We can assume the LMA some how knows and is = in >> communication with the oracle that has all the interfaces in place from = the >> radio network, and has all the needed heuristics in place which tells as >> when to make all the state changes. Sure, we can define any thing we wan= t, >> but we cannot completely ignore the target system architecture. Each >> requirement has to have some meaningful use-case with general consensus = to >> do that work and the charter has to reflect that. >>=20 >> To support this wish list, we can assume the mobile node has all the nee= ded >> framework in place. It can mirror flows, it knows when to switch flows, = it >> has an understanding of the completion of the network side signaling. St= ill >> its a simple mobile node, unmodified, but it is DPI enabled, which track= s >> what flows are coming what interfaces, so it can mirror. Who is building >> this UE ? >>=20 >> We don't have to be restricted with the RFC-5213 signaling. If its neede= d or >> not, we should define a new signaling plane. One message interface from = LMA >> to MAG and the other from MAG to LMA. We will define new sets of message= s, >> new options, new number space and the MAG implementations will have two = sets >> of timers and an advanced state machine. All of this to support a remote >> case of policy change. This is an impact to the implementations. >>=20 >> We can do all of this, but before we make fundamental changes to the >> protocol that was discussed for over a period of two years and with >> industry-wide participation, we cannot allow it be undone in WG which ha= s >> (7) people participation, with a single tone enforcing decisions, with >> unilateral wish list, backed by no framework that supports such requirem= ents >> in any target system architecture. >>=20 >> Finally, if we are talking about fundamental changes to the signaling mo= del, >> it should be reflected in the charter. The AD needs to approve. As many >> pointed out, all the basic flow mobility functional requirements can be = met, >> without "updating the legacy 5213 model". If the goal is to update that >> legacy model, we should start with a new protocol. >>=20 >>=20 >>=20 >> Sri >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>> In 3GPP, the prefix is assigned when the PDN connection is created, >>> and is then unchanged for the reminder of the lifetime of this PDN >>> connection. >>>=20 >>=20 >>=20 >>=20 >>=20 >> On 2/8/11 7:07 PM, "Julien Laganier" wrote: >>=20 >>> Hi Rajeev, >>>=20 >>> On Tue, Feb 8, 2011 at 6:51 PM, Rajeev Koodli wrote= : >>>>=20 >>>> Hi Julien, >>>>=20 >>>> On 2/8/11 5:25 PM, "Julien Laganier" wrote: >>>>=20 >>>>> What would actually really helps all of us to make progress is that >>>>> instead of telling what you'd like, as in >>>>=20 >>>> It would also help if you didn't generalize your reservation to what I= am >>>> stating as in "..helps *all* of us..". >>>=20 >>> I simply wanted to say that since I see no usecase to justify the type >>> of features you'd like to have in, having a usecase outlined would >>> help this discussion to converge, which seems to be helpful to people >>> on this mailing list. There was certainly no intent to say that my >>> reservations are shared by the whole working group. >>>=20 >>> That being said, >>>=20 >>>> I see you have a model in mind (which is pretty close to what is in th= e >>>> draft already), which is fine. I fail to see why you are restricted to= that >>>> alone. But, perhaps that's less fruitful to delve into now. >>>>=20 >>>>=20 >>>>>> I would like LMA-initiated signaling (FMI/FMA) for this (i.e., signa= ling >>>>>> to >>>>>> MAG1 with Pref2) as well as for the above (i.e., being able to signa= l >>>>>> MAG2 >>>>>> with Pref1) *whenever* the LMA wants. >>>>>=20 >>>>> you'd rather tell us why this is needed, by whom, and where... I've >>>>> been asking the same question over and over but nobody writes down an >>>>> answer to this in this thread. >>>>=20 >>>> I have mentioned why I need it a few times. 1) I am not required to as= sign >>>> all the applicable prefixes at the time of attach *in anticipation* of >>>> *potential* flow mobility. I will assign a relevant prefix *if and whe= n* I >>>> need to move a flow over. >>>=20 >>> In 3GPP, the prefix is assigned when the PDN connection is created, >>> and is then unchanged for the reminder of the lifetime of this PDN >>> connection. >>>=20 >>> So in your own words: You are not required to assign all the >>> applicable prefixes at the time of attach *in anticipation* of >>> *potential* flow mobility. You will assign the relevant prefix *if and >>> when* I you need a PDN connection. >>>=20 >>> If you have another target system than 3GPP, what is it? >>>=20 >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 It makes no sense for me to be *forced* to a= ssign >>>> all the prefixes at the time of attach (just because it is aligned wit= h >>>> legacy RFC 5213 "model"). >>>=20 >>> Assigning all the prefixes at time of attaches isn't a requirement for >>> flow mobility. You can very well have a single prefix and do flow >>> mobility across multiple interfaces. >>>=20 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2) I want to assign a >>> prefix based on policy >>>> triggers, including the TOD rules. >>>=20 >>> I don't see how useful it is to assign prefixes based on time of day. >>> I understand you might want to move flows based on time of day, but as >>> I said above, you can already move flows with a single prefix when the >>> time is good for you. >>>=20 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0I want to >>> move certain type of traffic >>>> over to a different interface based on peak hour bulk stats, the volum= e of >>>> traffic the user is consuming at a particular instance, the amount of = quota >>>> left and so on. >>>=20 >>> All capabilities that are perfectly available without juggling with >>> multiple prefixes, as above. >>>=20 >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I want to be able to refresh the lifet= ime >>>> of >>>> that prefix and >>>> revoke it back to its "natural interface" when I want. >>>=20 >>> This is renumbering - a different interface. I also don't know what a >>> natural interface is when prefixes are assigned from withing an >>> overlay... >>>=20 >>>> I want to be able to offer this for my customers. >>>=20 >>> Most of which you can, as I stated above, independently of prefix >>> juggling... >>>=20 >>>>> Absent that, will I be forced to conclude that this needed by no-one? >>>>=20 >>>> If I don't need something that does not imply the rest don't either! := -) >>>=20 >>> Can they speak up then? :-) >>>=20 >>> --julien >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>=20 >>=20 From trungtm2909@gmail.com Wed Feb 9 16:41:17 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B33C3A672F for ; Wed, 9 Feb 2011 16:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.162 X-Spam-Level: X-Spam-Status: No, score=-3.162 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9BiHfDEMOwu for ; Wed, 9 Feb 2011 16:41:16 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id E39BA3A6826 for ; Wed, 9 Feb 2011 16:41:15 -0800 (PST) Received: by iwc10 with SMTP id 10so782832iwc.31 for ; Wed, 09 Feb 2011 16:41:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Lvm2EXVscijlir/sgWgdRJZihGNFg0ckCmV3CLCtL/o=; b=IX0JlGxZOEiBOCD9iUOxSesX3NBn1xGQFNvCExthNBlEfjXnOI/9nu8ff1KCxL91yU ykPHNiJuAPzBhHM40p/3KbecJm0GrDa7IuFjbrnvm6CBPSEn8rojevwfD+w9ZVrQuIYE 3pXwETrKTwrg0oqkdUgwGhbF7RzgZsTrkG/m4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XL5+/Xe58qr3nUoU+XTjip8Tans2SmjXvI7gu11lG9IwkSBeA7XaheqfyipMoDD+Qj l/WFMq+Y0DTDW5wuII+lEvVDWDrimKX1GX4KSlJwbYaJ4pdfEJNCsfUUXat4B13JYhEp DhxqK35Z4fwN14eGWrZnVCRRe7l1iWJLYUsdU= MIME-Version: 1.0 Received: by 10.42.220.8 with SMTP id hw8mr8966516icb.111.1297298486437; Wed, 09 Feb 2011 16:41:26 -0800 (PST) Received: by 10.42.171.74 with HTTP; Wed, 9 Feb 2011 16:41:26 -0800 (PST) In-Reply-To: References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> Date: Thu, 10 Feb 2011 09:41:26 +0900 Message-ID: From: Tran Minh Trung To: "Giaretta, Gerardo" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "netext@ietf.org" Subject: Re: [netext] Multiple prefixes in draft-bernardos-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 10 Feb 2011 00:41:17 -0000 Hi Gerardo, On Thu, Feb 10, 2011 at 7:23 AM, Giaretta, Gerardo wrote: > Hi, > > Please see inline > >> -----Original Message----- >> From: Tran Minh Trung [mailto:trungtm2909@gmail.com] >> Sent: Wednesday, February 09, 2011 12:46 AM >> To: Giaretta, Gerardo >> Cc: netext@ietf.org >> Subject: Re: [netext] Multiple prefixes in draft-bernardos-netext- >> pmipv6-flowmob >> >> On Wed, Feb 9, 2011 at 3:33 PM, Giaretta, Gerardo >> wrote: >> > Hi all, >> > >> > I am starting a new thread to understand the use case this draft is >> trying to solve when referring to multiple prefixes. I think there has >> been some discussion already in the list but I did not get a good >> understanding of the rationale. >> > >> > My understanding is that the goal of the draft is to define a flow >> mobility solution for PMIP. This implies that a given PMIP session is >> shared across multiple interfaces and some IP flows belonging to that >> session are sent over one interface and some others over another >> interface. This is equivalent to the RFC6089: IP flows which are tied >> to the same HoA/HNP can be sent over one CoA/BID or another CoA/BID. >> > >> > Is this the correct understanding of the goals of the I-D? Is this a >> common understanding of the term Flow Mobility? >> > >> >> Yes you are right. >> > > Good at least we agree on the definition. > >> > If this is the case, then I don't understand why the draft is >> introducing text about the LMA creating a different session. Is this >> needed for Flow Mobility? If so, for which scenario? >> > >> > Going back to Pierrick's example: >> > >> > when the MN attaches to MAG1 via If1, the LMA creates session 1: >> > >> > =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] >> > >> > Then, if the MN attaches to MAG2 via If2, there is no reason for the >> LMA to create session 2. The LMA just needs to update session 1 with >> If2: >> > >> >> We just follow the basic operation of the RFC5213 that a new prefix >> will be assigned to new attachment. >> > > RFC5213 does not assign a NEW prefix but A prefix when there is an attach= ment. If there is the handover indication in the PBU for example the same p= refix is attached. Given that flow mobility is a particular type of handove= r, there is no need to assign a new prefix for flow mobility purposes. > RFC5213 do assign a NEW prefix to a NEW attachment if there is an existing attachment as IF1 in the example (Please check session 5.4. Multihoming Support) The necessary extension is that if interfaces are in the same set then to support flow mobility we should enable them to share sessions. >> Then we extend it to support flow mobility by allowing interfaces to >> be attached to multiple sessions. >> >> > =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] >> > >> > In this way MAG/LMA/MN can send over IF2 a TCP connection which >> earlier was sent over IF1. This is Flow Mobility. >> > >> >> It only works for the flows in the session1. However session 2,3..n >> can be created at anytime in the future. We have to attach all working >> interfaces in the set to a new session whenever it is created. >> > > Flow mobility is not about creating new sessions based on the definition = you just agreed. > New session can be created at any time (due to L2 triggers or policy profile change as Julien said or network policy is changed as I mentioned) We should attach all working interfaces in the set to that new session to allow flows can be moved across interfaces. Is that right? Regards, TrungTM > Gerardo > >> Regards, >> TrungTM >> >> > Thanks >> > Gerardo >> > >> > _______________________________________________ >> > netext mailing list >> > netext@ietf.org >> > https://www.ietf.org/mailman/listinfo/netext >> > >> >> >> >> -- >> Ph.D., Senior Member >> Electronics and Telecommunications Research Institute >> Standards Research Center >> 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA >> Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 From trungtm2909@gmail.com Wed Feb 9 17:03:19 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EA7F3A682D for ; Wed, 9 Feb 2011 17:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.193 X-Spam-Level: X-Spam-Status: No, score=-3.193 tagged_above=-999 required=5 tests=[AWL=0.406, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2G-IvOcQEWkX for ; Wed, 9 Feb 2011 17:03:18 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 4ED1E3A682C for ; Wed, 9 Feb 2011 17:03:17 -0800 (PST) Received: by iwc10 with SMTP id 10so797740iwc.31 for ; Wed, 09 Feb 2011 17:03:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xHg7/S+TsfFJLK414WyJs2GVTm/CEIG0jkfVSjy6L6c=; b=q/D6i6L5dB9HQzXdCbOSGsTcYguS8aprKS0T9VtHP8kK6VjcPDxrAzmNZZYH9mBtBb hLf1MRZK8javVKlfDqkb5cDdyWhj5uPG0KuRfyLl+xwhAaMASftmQZXZZXU4IIYAJDVy GfiPHh4Sdroq07pmbpAWb0YNQcqLh3/uS1Rgo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=h6nH3aiLZ+6/+J5UpUBrSDaXqhKDmXiCGkYp1phspJOhkp/jNvO4Sw/t4qwELOkH5H lGITxcAcSCFzjj9DW9sy6+PulwR5uv2fNTACLtgSsYU0L05MISHVOYLipeLJLeb6zwhf H9cR7TiHrOEsDjOPZLe+D2r0UtxrRe0WwzOvk= MIME-Version: 1.0 Received: by 10.42.177.137 with SMTP id bi9mr23170098icb.245.1297299808408; Wed, 09 Feb 2011 17:03:28 -0800 (PST) Received: by 10.42.171.74 with HTTP; Wed, 9 Feb 2011 17:03:28 -0800 (PST) In-Reply-To: References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C462017D4653@ftrdmel0.rd.francetelecom.fr> Date: Thu, 10 Feb 2011 10:03:28 +0900 Message-ID: From: Tran Minh Trung To: Julien Laganier Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Multiple prefixes indraft-bernardos-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 10 Feb 2011 01:03:19 -0000 On Thu, Feb 10, 2011 at 3:07 AM, Julien Laganier wr= ote: > Pierrick: > > On Wed, Feb 9, 2011 at 1:05 AM, =A0 wr= ote: >> >> >>> -----Message d'origine----- >>> De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la p= art >>> de Tran Minh Trung >>> Envoy=E9=A0: mercredi 9 f=E9vrier 2011 09:46 >>> =C0=A0: Giaretta, Gerardo >>> Cc=A0: netext@ietf.org >>> Objet=A0: Re: [netext] Multiple prefixes indraft-bernardos-netext-pmipv= 6- >>> flowmob >>> >>> On Wed, Feb 9, 2011 at 3:33 PM, Giaretta, Gerardo >>> wrote: >>> > Hi all, >>> > >>> > I am starting a new thread to understand the use case this draft is >>> trying to solve when referring to multiple prefixes. I think there has >>> been some discussion already in the list but I did not get a good >>> understanding of the rationale. >>> > >>> > My understanding is that the goal of the draft is to define a flow >>> mobility solution for PMIP. This implies that a given PMIP session is >>> shared across multiple interfaces and some IP flows belonging to that >>> session are sent over one interface and some others over another interf= ace. >>> This is equivalent to the RFC6089: IP flows which are tied to the same >>> HoA/HNP can be sent over one CoA/BID or another CoA/BID. >>> > >>> > Is this the correct understanding of the goals of the I-D? Is this a >>> common understanding of the term Flow Mobility? >>> > >>> >>> Yes you are right. >>> >>> > If this is the case, then I don't understand why the draft is >>> introducing text about the LMA creating a different session. Is this >>> needed for Flow Mobility? If so, for which scenario? >>> > >>> > Going back to Pierrick's example: >>> > >>> > when the MN attaches to MAG1 via If1, the LMA creates session 1: >>> > >>> > =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] >>> > >>> > Then, if the MN attaches to MAG2 via If2, there is no reason for the = LMA >>> to create session 2. The LMA just needs to update session 1 with If2: >>> > >>> >>> We just follow the basic operation of the RFC5213 that a new prefix >>> will be assigned to new attachment. >>> >>> Then we extend it to support flow mobility by allowing interfaces to >>> be attached to multiple sessions. >>> >>> > =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] >>> > >>> > In this way MAG/LMA/MN can send over IF2 a TCP connection which earli= er >>> was sent over IF1. This is Flow Mobility. >>> > >>> >>> It only works for the flows in the session1. However session 2,3..n >>> can be created at anytime in the future. We have to attach all working >>> interfaces in the set to a new session whenever it is created. >>> >> >> IMU, the current draft allows different sessions with same prefix, e.g: >> >> Session1: [Pref1, MAG1, IF1, IF2] >> Session2: [Pref1, MAG2, IF1, IF2] >> >> Right? > > In the nominal RFC 5213 model, a PMIPv6 session is defined as a prefix > set, a MAG where the MN is attached, and an interface used by the MN > to attach (i.e., ATT and LLID.) > > =A0Session1: [{Pref_11,..., Pref_1p}, (MAG1, IF1)] > =A0Session2: [{Pref_21,..., Pref_2q}, (MAG2, IF2)] > > In flow mobility extension, I am proposing that we generalize this > definition to allow for multiple attachment, as it's IMO the only > _required_ extension to support flow mobility: > > =A0Session1: [{Pref_11,..., Pref_1p}, {(MAG1, IF1), (MAG2, IF2)}] > =A0Session2: [{Pref_21,..., Pref_2q}, {(MAG2, IF2)}] > The session in current draft is: Session1: [{Pref_11,..., Pref_1p,Pref_21,..., Pref_2q}, {(MAG1, IF1)}] Session2: [{Pref_21,..., Pref_2q,Pref_11,..., Pref_1p}, {(MAG2, IF2)}] Julien adds interface, while we add prefix(es) to session. Both of them has the same function is to allow prefix(es) to be shared across interface. Should we waste time to debate on it to select one? Regards, TrungTM > --julien > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 From julien.ietf@gmail.com Wed Feb 9 17:12:35 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36DD93A682B for ; Wed, 9 Feb 2011 17:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=-0.824, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDz4hpmaYwRy for ; Wed, 9 Feb 2011 17:12:34 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id EBAB93A6875 for ; Wed, 9 Feb 2011 17:12:24 -0800 (PST) Received: by fxm9 with SMTP id 9so902701fxm.31 for ; Wed, 09 Feb 2011 17:12:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pnAgeyz45GPAjOWEV8nEGu0qRBHFM78U/qbJv2HcM/g=; b=DceKLfCpcL4Z70YDhb56qAUZZKtXb4UcrXFqhehJIPYJuqaJ6oXcAi3yOOmwR0I6uN Qo1UHklElQ9x8LbHGrjdQ0kEO+XKJ7FAfC+5VELc1QyxTnlizCOBmjQneUlN5u3a8cvj lSBxWsXtvrS4WntXfNwkrDV9yLXDilx2goEcE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=lF0n0h1N8edVHm6Pd/lcYcsMM2l7y01OOL7jGs6w6aRppNy7DvCxJQkJG8ye9y7DV5 CgAuHAhw6TRg4rq2HYCKZFXDOs3M+2T3e4AU/KB5evBCGSkX++hO8WcFoFfKnKQkr/03 CucBK8+jL8BjtajCG8I1w0ZGFAUBru6nUc3nw= MIME-Version: 1.0 Received: by 10.103.124.3 with SMTP id b3mr1120412mun.3.1297300355213; Wed, 09 Feb 2011 17:12:35 -0800 (PST) Received: by 10.103.221.9 with HTTP; Wed, 9 Feb 2011 17:12:35 -0800 (PST) In-Reply-To: References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> Date: Wed, 9 Feb 2011 17:12:35 -0800 Message-ID: From: Julien Laganier To: Tran Minh Trung Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "netext@ietf.org" Subject: Re: [netext] Multiple prefixes in draft-bernardos-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 10 Feb 2011 01:12:35 -0000 On Wed, Feb 9, 2011 at 4:41 PM, Tran Minh Trung wro= te: > Hi Gerardo, > > On Thu, Feb 10, 2011 at 7:23 AM, Giaretta, Gerardo > wrote: >> Hi, >> >> Please see inline >> >>> -----Original Message----- >>> From: Tran Minh Trung [mailto:trungtm2909@gmail.com] >>> Sent: Wednesday, February 09, 2011 12:46 AM >>> To: Giaretta, Gerardo >>> Cc: netext@ietf.org >>> Subject: Re: [netext] Multiple prefixes in draft-bernardos-netext- >>> pmipv6-flowmob >>> >>> On Wed, Feb 9, 2011 at 3:33 PM, Giaretta, Gerardo >>> wrote: >>> > Hi all, >>> > >>> > I am starting a new thread to understand the use case this draft is >>> trying to solve when referring to multiple prefixes. I think there has >>> been some discussion already in the list but I did not get a good >>> understanding of the rationale. >>> > >>> > My understanding is that the goal of the draft is to define a flow >>> mobility solution for PMIP. This implies that a given PMIP session is >>> shared across multiple interfaces and some IP flows belonging to that >>> session are sent over one interface and some others over another >>> interface. This is equivalent to the RFC6089: IP flows which are tied >>> to the same HoA/HNP can be sent over one CoA/BID or another CoA/BID. >>> > >>> > Is this the correct understanding of the goals of the I-D? Is this a >>> common understanding of the term Flow Mobility? >>> > >>> >>> Yes you are right. >>> >> >> Good at least we agree on the definition. >> >>> > If this is the case, then I don't understand why the draft is >>> introducing text about the LMA creating a different session. Is this >>> needed for Flow Mobility? If so, for which scenario? >>> > >>> > Going back to Pierrick's example: >>> > >>> > when the MN attaches to MAG1 via If1, the LMA creates session 1: >>> > >>> > =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] >>> > >>> > Then, if the MN attaches to MAG2 via If2, there is no reason for the >>> LMA to create session 2. The LMA just needs to update session 1 with >>> If2: >>> > >>> >>> We just follow the basic operation of the RFC5213 that a new prefix >>> will be assigned to new attachment. >>> >> >> RFC5213 does not assign a NEW prefix but A prefix when there is an attac= hment. If there is the handover indication in the PBU for example the same = prefix is attached. Given that flow mobility is a particular type of handov= er, there is no need to assign a new prefix for flow mobility purposes. >> > > RFC5213 do assign a NEW prefix to a NEW attachment if there is an > existing attachment as IF1 in the example (Please check session 5.4. > Multihoming Support) It only does so to the extent that the MAG does not know if the MN supports inter-interface handover, and that was for the sake of avoinding breaking IP connectivity on such hosts. If the host does supports inter-interface handover, MAG sets corresponding HI value, and SAME prefix is used for NEW attachment. Following these same guidelines, if the host supports logical interface for flow mobility, MAG sets corresdponding HI value (attach interface to flow mobility session), and SAME prefix is used for NEW attachment. > The necessary extension is that if interfaces are in the same set then > to support flow mobility we should enable them to share sessions. The necessary extension is simply a new HI value to attach an interface to a session, and a new HI value to detach an interface to a session. Nothing complicated. --julien From trungtm2909@gmail.com Wed Feb 9 18:13:06 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B5F83A6846 for ; Wed, 9 Feb 2011 18:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.22 X-Spam-Level: X-Spam-Status: No, score=-3.22 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WydR21vg5tfD for ; Wed, 9 Feb 2011 18:13:05 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 6EA7F3A6826 for ; Wed, 9 Feb 2011 18:13:05 -0800 (PST) Received: by iwc10 with SMTP id 10so846518iwc.31 for ; Wed, 09 Feb 2011 18:13:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jHyDjTF8dQPRn84xbRhkOIPi2uF4uUhUlLUKc6KNrFE=; b=U0qzrjvRyXur5w99ed55kgvxsxY6IQLB5k6cbUthezEXUHsoGCeLhG4ZqU0xPRuzfa zwzCZA1ecpspeVNEmmnBNE+UJfACT7sl9/lEAetiWWSwsUAP/zynbaUP0eE4JybL804q 4XkOBpaEDxk3DMIVIOiL1u3lr5sMISc5TbEpQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FqPVxgMFucVKX0E3iuVOD+UQcARcDco3esW7oj6pDERkvtWK76nLM8Xt2xRM6SGR4p 7uQb6VpiJvzugliRkE2uwMmWgeXmS3f7t6hselCWY1MaJCqYq6VEfhmAB5HZQpj/tFi1 IPEt60TmXQRxZ9hFbPBdnfVil1WQuXfM2t4N0= MIME-Version: 1.0 Received: by 10.42.177.137 with SMTP id bi9mr23235871icb.245.1297303996179; Wed, 09 Feb 2011 18:13:16 -0800 (PST) Received: by 10.42.171.74 with HTTP; Wed, 9 Feb 2011 18:13:16 -0800 (PST) In-Reply-To: References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> Date: Thu, 10 Feb 2011 11:13:16 +0900 Message-ID: From: Tran Minh Trung To: Julien Laganier Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "netext@ietf.org" Subject: Re: [netext] Multiple prefixes in draft-bernardos-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 10 Feb 2011 02:13:06 -0000 On Thu, Feb 10, 2011 at 10:12 AM, Julien Laganier w= rote: > On Wed, Feb 9, 2011 at 4:41 PM, Tran Minh Trung w= rote: >> Hi Gerardo, >> >> On Thu, Feb 10, 2011 at 7:23 AM, Giaretta, Gerardo >> wrote: >>> Hi, >>> >>> Please see inline >>> >>>> -----Original Message----- >>>> From: Tran Minh Trung [mailto:trungtm2909@gmail.com] >>>> Sent: Wednesday, February 09, 2011 12:46 AM >>>> To: Giaretta, Gerardo >>>> Cc: netext@ietf.org >>>> Subject: Re: [netext] Multiple prefixes in draft-bernardos-netext- >>>> pmipv6-flowmob >>>> >>>> On Wed, Feb 9, 2011 at 3:33 PM, Giaretta, Gerardo >>>> wrote: >>>> > Hi all, >>>> > >>>> > I am starting a new thread to understand the use case this draft is >>>> trying to solve when referring to multiple prefixes. I think there has >>>> been some discussion already in the list but I did not get a good >>>> understanding of the rationale. >>>> > >>>> > My understanding is that the goal of the draft is to define a flow >>>> mobility solution for PMIP. This implies that a given PMIP session is >>>> shared across multiple interfaces and some IP flows belonging to that >>>> session are sent over one interface and some others over another >>>> interface. This is equivalent to the RFC6089: IP flows which are tied >>>> to the same HoA/HNP can be sent over one CoA/BID or another CoA/BID. >>>> > >>>> > Is this the correct understanding of the goals of the I-D? Is this a >>>> common understanding of the term Flow Mobility? >>>> > >>>> >>>> Yes you are right. >>>> >>> >>> Good at least we agree on the definition. >>> >>>> > If this is the case, then I don't understand why the draft is >>>> introducing text about the LMA creating a different session. Is this >>>> needed for Flow Mobility? If so, for which scenario? >>>> > >>>> > Going back to Pierrick's example: >>>> > >>>> > when the MN attaches to MAG1 via If1, the LMA creates session 1: >>>> > >>>> > =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] >>>> > >>>> > Then, if the MN attaches to MAG2 via If2, there is no reason for the >>>> LMA to create session 2. The LMA just needs to update session 1 with >>>> If2: >>>> > >>>> >>>> We just follow the basic operation of the RFC5213 that a new prefix >>>> will be assigned to new attachment. >>>> >>> >>> RFC5213 does not assign a NEW prefix but A prefix when there is an atta= chment. If there is the handover indication in the PBU for example the same= prefix is attached. Given that flow mobility is a particular type of hando= ver, there is no need to assign a new prefix for flow mobility purposes. >>> >> >> RFC5213 do assign a NEW prefix to a NEW attachment if there is an >> existing attachment as IF1 in the example (Please check session 5.4. >> Multihoming Support) > > It only does so to the extent that the MAG does not know if the MN > supports inter-interface handover, and that was for the sake of > avoinding breaking IP connectivity on such hosts. > > If the host does supports inter-interface handover, MAG sets > corresponding HI value, and SAME prefix is used for NEW attachment. > I just want to emphasize here is that RFC5213 dose not support that. We need to extend it as your suggestion. > Following these same guidelines, if the host supports logical > interface for flow mobility, MAG sets corresdponding HI value (attach > interface to flow mobility session), and SAME prefix is used for NEW > attachment. > >> The necessary extension is that if interfaces are in the same set then >> to support flow mobility we should enable them to share sessions. > > The necessary extension is simply a new HI value to attach an > interface to a session, and a new HI value to detach an interface to a > session. > Julien, I think your solution and the solution in the draft have the same function and result. No big different. Both of them are Ok. Let me analyze it again as following: 1. Your solution: Adding interface to session Session1: [{Pref_11,..., Pref_1p}, (MAG1, IF1)] Session2: [{Pref_21,..., Pref_2q}, (MAG2, IF2)] In flow mobility extension, I am proposing that we generalize this definition to allow for multiple attachment, as it's IMO the only _required_ extension to support flow mobility: Session1: [{Pref_11,..., Pref_1p}, {(MAG1, IF1), (MAG2, IF2)}] Session2: [{Pref_21,..., Pref_2q}, {(MAG2, IF2)}] 2. Solution in current draft: Adding prefix to session Session1: [{Pref_11,..., Pref_1p,Pref_21,..., Pref_2q}, {(MAG1, IF1)}] Session2: [{Pref_21,..., Pref_2q,Pref_11,..., Pref_1p}, {(MAG2, IF2)}] Both of them have the same function is to allow prefix(es) to be shared across interface. Is that right? Now, if IF1 detaches from network. Your solution removes IF from session 1 while or solution remove session 1. Other flows on IF2 are kept continue. That's all, they have same function and result. There is no big different!. Hope we can agree on this and save our time :-). Regards, TrungTM > Nothing complicated. > > --julien > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 From julien.ietf@gmail.com Wed Feb 9 18:31:15 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9122E3A680C for ; Wed, 9 Feb 2011 18:31:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=-0.806, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TB9119PqUk-0 for ; Wed, 9 Feb 2011 18:31:14 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 39A263A67FA for ; Wed, 9 Feb 2011 18:31:13 -0800 (PST) Received: by fxm9 with SMTP id 9so970504fxm.31 for ; Wed, 09 Feb 2011 18:31:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fo2wYpWbw2mP5nqCFq83BE5n4dnquHxGMsL14jNRSkM=; b=Gyavfky5T/uOOnvSBVxlFm+d89aJKndjaCjj1omOyA3Mr84amvEtX/xixXgq9lRra0 pETYRTwxPrBiLBLFi2muusZL+jjnDtt30aLrQCv839Il/TYuCHq+iTAyuYAasS7eFS2f tJkucq17yt4sB6+YbtPoV2jDP87tOVyqUn+O0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KDMq/JzYvbDd1qkXxXJMe9SVgeu5+5k8xkIwDrV31zalU8OgqMqpR/MDFjAMEMlaWB Hs8Zd6R5IwJYl1hAtDQaspZ/e0xYFVKZ7dLOT3l7PKbxzPiPHw+YPcG/h22rbjFTZe7Q K8UUUPlGzneY76dM9m2sbDgbZYWplsU43bAyk= MIME-Version: 1.0 Received: by 10.103.233.4 with SMTP id k4mr14976229mur.129.1297305084242; Wed, 09 Feb 2011 18:31:24 -0800 (PST) Received: by 10.103.221.9 with HTTP; Wed, 9 Feb 2011 18:31:24 -0800 (PST) In-Reply-To: References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> Date: Wed, 9 Feb 2011 18:31:24 -0800 Message-ID: From: Julien Laganier To: Tran Minh Trung Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "netext@ietf.org" Subject: Re: [netext] Multiple prefixes in draft-bernardos-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 10 Feb 2011 02:31:15 -0000 Tran, On Wed, Feb 9, 2011 at 6:13 PM, Tran Minh Trung wro= te: > On Thu, Feb 10, 2011 at 10:12 AM, Julien Laganier = wrote: >> On Wed, Feb 9, 2011 at 4:41 PM, Tran Minh Trung = wrote: >>> On Thu, Feb 10, 2011 at 7:23 AM, Giaretta, Gerardo wrote: >>>> Tran Minh Trung wrote >>>>> >>>>> We just follow the basic operation of the RFC5213 that a new prefix >>>>> will be assigned to new attachment. >>>>> >>>> >>>> RFC5213 does not assign a NEW prefix but A prefix when there is an att= achment. If there is the handover indication in the PBU for example the sam= e prefix is attached. Given that flow mobility is a particular type of hand= over, there is no need to assign a new prefix for flow mobility purposes. >>>> >>> >>> RFC5213 do assign a NEW prefix to a NEW attachment if there is an >>> existing attachment as IF1 in the example (Please check session 5.4. >>> Multihoming Support) >> >> It only does so to the extent that the MAG does not know if the MN >> supports inter-interface handover, and that was for the sake of >> avoinding breaking IP connectivity on such hosts. >> >> If the host does supports inter-interface handover, MAG sets >> corresponding HI value, and SAME prefix is used for NEW attachment. >> > > I just want to emphasize here is that RFC5213 dose not support that. > We need to extend it as your suggestion. Right. And that is exactly what I've been repeating over and over... >> Following these same guidelines, if the host supports logical >> interface for flow mobility, MAG sets corresdponding HI value (attach >> interface to flow mobility session), and SAME prefix is used for NEW >> attachment. >> >>> The necessary extension is that if interfaces are in the same set then >>> to support flow mobility we should enable them to share sessions. >> >> The necessary extension is simply a new HI value to attach an >> interface to a session, and a new HI value to detach an interface to a >> session. > > Julien, I think your solution and the solution in the draft have the > same function and result. > > No big different. Both of them are Ok. No. My solution allows flow mobility at the cost of two new HI values. The solution in the draft allows flow mobility plus a bunch of other things that have nothing to do with flow mobility, at the cost of new messages, new state machines etc. > Let me analyze it again as following: > > 1. Your solution: Adding interface to session > > Session1: [{Pref_11,..., Pref_1p}, (MAG1, IF1)] > Session2: [{Pref_21,..., Pref_2q}, (MAG2, IF2)] > > In flow mobility extension, I am proposing that we generalize this > definition to allow for multiple attachment, as it's IMO the only > =A0_required_ extension to support flow mobility: > > Session1: [{Pref_11,..., Pref_1p}, {(MAG1, IF1), (MAG2, IF2)}] > Session2: [{Pref_21,..., Pref_2q}, {(MAG2, IF2)}] > > > 2. Solution in current draft: Adding prefix to session > > Session1: [{Pref_11,..., Pref_1p,Pref_21,..., Pref_2q}, {(MAG1, IF1)}] > Session2: [{Pref_21,..., Pref_2q,Pref_11,..., Pref_1p}, {(MAG2, IF2)}] > > Both of them have the same function is to allow prefix(es) to be shared > across interface. > > Is that right? I would say #1 allows flow mobility by sharing sessions (and corresponding prefix set) across interfaces, while #2 allows for things that unrelated to flow mobility at the cost of added complexity. Let me now follow the KISS principle: Keep It Simple, Stupid! Then I pick #1. There are no good reasons to go for #2 unless a clear case is made why #1 is required. Note: You can't say we need different prefixes on different interfaces and therefore flow mobility needs to allow different prefix on different interfaces. It's not even tautologic! > Now, if IF1 detaches from network. > Your solution removes IF from session 1 while or solution remove session = 1. > Other flows on IF2 are kept continue. > > That's all, they have same function and result. There is no big different= !. The function differs. The result differ. #1 is simple flow mobility, #2 is flow mobility bloated with something that nobody needs for flow mobility. > Hope we can agree on this and save our time :-). By all means! Hope you will agree with applying KISS principle and pick #1 = :-) --julien From trungtm2909@gmail.com Wed Feb 9 19:03:30 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87C883A6806 for ; Wed, 9 Feb 2011 19:03:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.244 X-Spam-Level: X-Spam-Status: No, score=-3.244 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSSbjfdLq9Kg for ; Wed, 9 Feb 2011 19:03:29 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 6AC493A680C for ; Wed, 9 Feb 2011 19:03:29 -0800 (PST) Received: by iym1 with SMTP id 1so899165iym.31 for ; Wed, 09 Feb 2011 19:03:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CWfqOvu/AV9Gc1kOwG/SCUixKtJe5TU088RvuOELQkk=; b=FduSoOyvhrRXnyKsAZX4IE9TrjNvB1tXmuUncfj/mxeGN1PnYoj4r1IfjzrMWRB033 +7CB0CBU/yZQSDKhyqPInUDqdTqTauYVGyg+HW5cM2pxnkYMHw+XNgdMPzZLQY/H2slt fYvaHc03+eUy/vJCrJKX7yPHCkqEOML9OfHtY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RK3YIUrQvlP0mZ3YjZ7XPKBgKZNHnCEXw3Otsnk9LSVnDxnSFAy/7p0PZCgX3xIaoT 4uTXA67cswuCHu7qAEwhBJIKgnMGA9A5W28qDZQIOWYBgQOidLTE61aIUqQDanNf0i9F c2NphJ5D9rPCmyie87jL0pQ1M234Nb1rYWK5E= MIME-Version: 1.0 Received: by 10.42.175.6 with SMTP id ay6mr8824520icb.470.1297307019962; Wed, 09 Feb 2011 19:03:39 -0800 (PST) Received: by 10.42.171.74 with HTTP; Wed, 9 Feb 2011 19:03:39 -0800 (PST) In-Reply-To: References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> Date: Thu, 10 Feb 2011 12:03:39 +0900 Message-ID: From: Tran Minh Trung To: Julien Laganier Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "netext@ietf.org" Subject: Re: [netext] Multiple prefixes in draft-bernardos-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 10 Feb 2011 03:03:31 -0000 [Snip.] >> Julien, I think your solution and the solution in the draft have the >> same function and result. >> >> No big different. Both of them are Ok. > > No. > > My solution allows flow mobility at the cost of two new HI values. > > The solution in the draft allows flow mobility plus a bunch of other > things that have nothing to do with flow mobility, at the cost of new > messages, new state machines etc. > >> Let me analyze it again as following: >> >> 1. Your solution: Adding interface to session >> >> Session1: [{Pref_11,..., Pref_1p}, (MAG1, IF1)] >> Session2: [{Pref_21,..., Pref_2q}, (MAG2, IF2)] >> >> In flow mobility extension, I am proposing that we generalize this >> definition to allow for multiple attachment, as it's IMO the only >> =A0_required_ extension to support flow mobility: >> >> Session1: [{Pref_11,..., Pref_1p}, {(MAG1, IF1), (MAG2, IF2)}] >> Session2: [{Pref_21,..., Pref_2q}, {(MAG2, IF2)}] >> >> >> 2. Solution in current draft: Adding prefix to session >> >> Session1: [{Pref_11,..., Pref_1p,Pref_21,..., Pref_2q}, {(MAG1, IF1)}] >> Session2: [{Pref_21,..., Pref_2q,Pref_11,..., Pref_1p}, {(MAG2, IF2)}] >> >> Both of them have the same function is to allow prefix(es) to be shared >> across interface. >> >> Is that right? > > I would say #1 allows flow mobility by sharing sessions (and > corresponding prefix set) across interfaces, while #2 allows for > things that unrelated to flow mobility at the cost of added > complexity. > Can the session defined in #2 support flow mobility? The answer is clearly Yes. Now how to do it: We can use HI as your suggestion. > Let me now follow the KISS principle: Keep It Simple, Stupid! > > Then I pick #1. There are no good reasons to go for #2 unless a clear > case is made why #1 is required. There is a key reason for me to prefer the solution #2. The RFC5213 maintains separate session for each interface (Please see 5.4. Multihoming Support, item 1). It dose not maintain one session for multiple interfaces. Solution #2 does the same as RFC5213, while solution#1 maintains session for each set of prefix. It is not original session definition of RFC5213, right? However I think solution #1 also Ok since it gives the same result. >Note: You can't say we need different > prefixes on different interfaces and therefore flow mobility needs to > allow different prefix on different interfaces. It's not even > tautologic! > >> Now, if IF1 detaches from network. >> Your solution removes IF from session 1 while or solution remove session= 1. >> Other flows on IF2 are kept continue. >> >> That's all, they have same function and result. There is no big differen= t!. > > The function differs. The result differ. #1 is simple flow mobility, > #2 is flow mobility bloated with something that nobody needs for flow > mobility. > What are something that you are refer to? >> Hope we can agree on this and save our time :-). > > By all means! Hope you will agree with applying KISS principle and pick #= 1 :-) > I like KISS principle also :-). For me both two session definitions above are ok. I can see only one point different between your solution and current draft's solution is signaling between LMA and MAG. You prefer to use L2 triggers and policy profile update to trigger MAGs to send PBU message while the current draft prefers to allow LMA to send trigger to MAG. The question here is that which one is better and best-match with the real system. That's point we need to discuss more, especially the case that network policy is changed. Regards, TrungTM > --julien > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 From julien.ietf@gmail.com Wed Feb 9 22:45:11 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FB793A68B6 for ; Wed, 9 Feb 2011 22:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjATtXvQl7Qd for ; Wed, 9 Feb 2011 22:45:07 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 543743A68B0 for ; Wed, 9 Feb 2011 22:45:02 -0800 (PST) Received: by fxm9 with SMTP id 9so1171630fxm.31 for ; Wed, 09 Feb 2011 22:45:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+TP7QZhe1tx2/vLWSb2S0N6rf6qtPaNSUQDFGgyweWg=; b=ZPAyR9Y/6lHDV938ueYkrtBcbBm9g6se8mea72DA1DXjAPuGPI2g0TOipIbEAqv28P LofPM+MNHTvgsn9EeU/TE1UooVA2TT37bRvmgebfgnbEmemFZbAY04vzGpM6+PMQXn05 0dbHY+KL60q58aBS1tBMfqsfaLuEGSbdEfhSU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=iyQ7tuox+n9vy5qk6Fdeaj3formKsvw3BhRxA2UlxV8zKuleVSTQPMjPRT1/gCx4BS qlODZEM66VDwVTNRAsFI6dR7uEfFulkoyGp6f4KQcTA7LWlcyZH4Swofz2oXd2Zj71u9 7m6teadEiPMoNaYZ0wMRl8YY39yBS1QOxVey4= MIME-Version: 1.0 Received: by 10.103.2.8 with SMTP id e8mr176403mui.93.1297320312800; Wed, 09 Feb 2011 22:45:12 -0800 (PST) Received: by 10.103.221.9 with HTTP; Wed, 9 Feb 2011 22:45:12 -0800 (PST) In-Reply-To: References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> Date: Wed, 9 Feb 2011 22:45:12 -0800 Message-ID: From: Julien Laganier To: Tran Minh Trung Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "netext@ietf.org" Subject: Re: [netext] Multiple prefixes in draft-bernardos-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 10 Feb 2011 06:45:11 -0000 On Wed, Feb 9, 2011 at 7:03 PM, Tran Minh Trung wro= te: > [Snip.] > >>> Julien, I think your solution and the solution in the draft have the >>> same function and result. >>> >>> No big different. Both of them are Ok. >> >> No. >> >> My solution allows flow mobility at the cost of two new HI values. >> >> The solution in the draft allows flow mobility plus a bunch of other >> things that have nothing to do with flow mobility, at the cost of new >> messages, new state machines etc. >> >>> Let me analyze it again as following: >>> >>> 1. Your solution: Adding interface to session >>> >>> Session1: [{Pref_11,..., Pref_1p}, (MAG1, IF1)] >>> Session2: [{Pref_21,..., Pref_2q}, (MAG2, IF2)] >>> >>> In flow mobility extension, I am proposing that we generalize this >>> definition to allow for multiple attachment, as it's IMO the only >>> =A0_required_ extension to support flow mobility: >>> >>> Session1: [{Pref_11,..., Pref_1p}, {(MAG1, IF1), (MAG2, IF2)}] >>> Session2: [{Pref_21,..., Pref_2q}, {(MAG2, IF2)}] >>> >>> >>> 2. Solution in current draft: Adding prefix to session >>> >>> Session1: [{Pref_11,..., Pref_1p,Pref_21,..., Pref_2q}, {(MAG1, IF1)}] >>> Session2: [{Pref_21,..., Pref_2q,Pref_11,..., Pref_1p}, {(MAG2, IF2)}] >>> >>> Both of them have the same function is to allow prefix(es) to be shared >>> across interface. >>> >>> Is that right? >> >> I would say #1 allows flow mobility by sharing sessions (and >> corresponding prefix set) across interfaces, while #2 allows for >> things that unrelated to flow mobility at the cost of added >> complexity. >> > > Can the session defined in #2 support flow mobility? > The answer is clearly Yes. > > Now how to do it: We can use HI as your suggestion. > >> Let me now follow the KISS principle: Keep It Simple, Stupid! >> >> Then I pick #1. There are no good reasons to go for #2 unless a clear >> case is made why #1 is required. > > There is a key reason for me to prefer the solution #2. > > The RFC5213 maintains separate session for each interface (Please see > 5.4. =A0Multihoming Support, item 1). It dose not maintain one session > for multiple interfaces. RFC 5213 only maintains different session for different interfaces if the MAG doesn't know if the host supports inter-interface handovers and thus doesn't set the HI indicator to "handoff between different interfaces." If the MAG knows that the host supports inter-interface handovers, it sets the HI indicator to "handoff between different interfaces." and the same session is changed from one interface to another. > Solution #2 does the same as RFC5213, while solution#1 maintains > session for each set of prefix. It is not original session definition > of RFC5213, right? Solution #2 artificially generalizes the case where RFC 5213 MAG doesn't know if the host supports inter-interface handovers to the flow mobility case where we know that the host supports inter-interface handovers since it has the logical interface! This doesn't make sense. > However I think solution #1 also Ok since it gives the same result. So you agree #1 is Ok. >>Note: You can't say we need different >> prefixes on different interfaces and therefore flow mobility needs to >> allow different prefix on different interfaces. It's not even >> tautologic! >> >>> Now, if IF1 detaches from network. >>> Your solution removes IF from session 1 while or solution remove sessio= n 1. >>> Other flows on IF2 are kept continue. >>> >>> That's all, they have same function and result. There is no big differe= nt!. >> >> The function differs. The result differ. #1 is simple flow mobility, >> #2 is flow mobility bloated with something that nobody needs for flow >> mobility. > > What are something that you are refer to? Artificially binds prefixes to interfaces, thus introducing the need to update the prefix-interface mapping. This is not needed for flow mobility, as proven by the fact that solution #1 works ok without binding prefixes to interfaces. >>> Hope we can agree on this and save our time :-). >> >> By all means! Hope you will agree with applying KISS principle and pick = #1 :-) >> > > I like KISS principle also :-). > For me both two session definitions above are ok. > I can see only one point different between your solution and current > draft's solution is signaling between LMA and MAG. > > You prefer to use L2 triggers and policy profile update to trigger > MAGs to send PBU message while the current draft prefers to allow LMA > to send trigger to MAG. L2 triggers are needed anyway for PMIP thus it makes no sense to try to do without them. > The question here is that which one is better and best-match with the > real system. The only real system I know is 3GPP and it has L2 triggers. Otherwise PMIP doesn't work. > That's point we need to discuss more, especially the case that network > policy is changed. I think everything has been said on why #2 brings nothing more than #1, including the case where network policy is changed. --julien From trungtm2909@gmail.com Thu Feb 10 00:07:28 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2D8B3A68D2 for ; Thu, 10 Feb 2011 00:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knsw008T356Z for ; Thu, 10 Feb 2011 00:07:27 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 09C2F3A68B1 for ; Thu, 10 Feb 2011 00:07:26 -0800 (PST) Received: by iwc10 with SMTP id 10so1083817iwc.31 for ; Thu, 10 Feb 2011 00:07:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NAWIk6vWoyP0DUp2V0m/eqs63RuAVOVifx2r+1W3ro8=; b=UEUmCFtV8VWzgLfPChOIDAyFKS5Jo7RDUFjYXKpcnsDbLHotlCO5dhRzvUgWPdVS78 xT6B5UN+JMOLdLnHKpNppXGBCrgofcGXBL+LBBUcKNTgCvRhhsC4uFuPEcP6W8oHrcVv MBFmgujQoKzBs80bDPpGPeL0jxtpCbFxbsIcg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=abjczxwvQZ5FBYcFNqcp0PyGkZK2ijFysUc/MM1YBGFr0gv5evQdyX3uTF44FYrAZD hwe1j8mFiZ9jQ2u0ybMUdcGGj6YEKrAxwG5XmI8y9636fFfTEJWeGJfvb+FdaAq774tI qLVzHsOQtx8nizj0lxyV9dD1JTr1APcvfY5EM= MIME-Version: 1.0 Received: by 10.42.177.137 with SMTP id bi9mr23578853icb.245.1297325258393; Thu, 10 Feb 2011 00:07:38 -0800 (PST) Received: by 10.42.171.74 with HTTP; Thu, 10 Feb 2011 00:07:38 -0800 (PST) In-Reply-To: References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> Date: Thu, 10 Feb 2011 17:07:38 +0900 Message-ID: From: Tran Minh Trung To: Julien Laganier Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "netext@ietf.org" Subject: Re: [netext] Multiple prefixes in draft-bernardos-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 10 Feb 2011 08:07:28 -0000 On Thu, Feb 10, 2011 at 3:45 PM, Julien Laganier wr= ote: > On Wed, Feb 9, 2011 at 7:03 PM, Tran Minh Trung w= rote: >> [Snip.] >> >>>> Julien, I think your solution and the solution in the draft have the >>>> same function and result. >>>> >>>> No big different. Both of them are Ok. >>> >>> No. >>> >>> My solution allows flow mobility at the cost of two new HI values. >>> >>> The solution in the draft allows flow mobility plus a bunch of other >>> things that have nothing to do with flow mobility, at the cost of new >>> messages, new state machines etc. >>> >>>> Let me analyze it again as following: >>>> >>>> 1. Your solution: Adding interface to session >>>> >>>> Session1: [{Pref_11,..., Pref_1p}, (MAG1, IF1)] >>>> Session2: [{Pref_21,..., Pref_2q}, (MAG2, IF2)] >>>> >>>> In flow mobility extension, I am proposing that we generalize this >>>> definition to allow for multiple attachment, as it's IMO the only >>>> =A0_required_ extension to support flow mobility: >>>> >>>> Session1: [{Pref_11,..., Pref_1p}, {(MAG1, IF1), (MAG2, IF2)}] >>>> Session2: [{Pref_21,..., Pref_2q}, {(MAG2, IF2)}] >>>> >>>> >>>> 2. Solution in current draft: Adding prefix to session >>>> >>>> Session1: [{Pref_11,..., Pref_1p,Pref_21,..., Pref_2q}, {(MAG1, IF1)}] >>>> Session2: [{Pref_21,..., Pref_2q,Pref_11,..., Pref_1p}, {(MAG2, IF2)}] >>>> >>>> Both of them have the same function is to allow prefix(es) to be share= d >>>> across interface. >>>> >>>> Is that right? >>> >>> I would say #1 allows flow mobility by sharing sessions (and >>> corresponding prefix set) across interfaces, while #2 allows for >>> things that unrelated to flow mobility at the cost of added >>> complexity. >>> >> >> Can the session defined in #2 support flow mobility? >> The answer is clearly Yes. >> >> Now how to do it: We can use HI as your suggestion. >> >>> Let me now follow the KISS principle: Keep It Simple, Stupid! >>> >>> Then I pick #1. There are no good reasons to go for #2 unless a clear >>> case is made why #1 is required. >> >> There is a key reason for me to prefer the solution #2. >> >> The RFC5213 maintains separate session for each interface (Please see >> 5.4. =A0Multihoming Support, item 1). It dose not maintain one session >> for multiple interfaces. > > RFC 5213 only maintains different session for different interfaces if > the MAG doesn't know if the host supports inter-interface handovers > and thus doesn't set the HI indicator to "handoff between different > interfaces." If the MAG knows that the host supports inter-interface > handovers, it sets the HI indicator to "handoff between different > interfaces." and the same session is changed from one interface to > another. > >> Solution #2 does the same as RFC5213, while solution#1 maintains >> session for each set of prefix. It is not original session definition >> of RFC5213, right? > > Solution #2 artificially generalizes the case where RFC 5213 MAG > doesn't know if the host supports inter-interface handovers to the > flow mobility case where we know that the host supports > inter-interface handovers since it has the logical interface! This > doesn't make sense. > Ok I agree. If the network knows that the MN can support inter-interface handovers then multiple interfaces can be managed by a session. >> However I think solution #1 also Ok since it gives the same result. > > So you agree #1 is Ok. > >>>Note: You can't say we need different >>> prefixes on different interfaces and therefore flow mobility needs to >>> allow different prefix on different interfaces. It's not even >>> tautologic! >>> >>>> Now, if IF1 detaches from network. >>>> Your solution removes IF from session 1 while or solution remove sessi= on 1. >>>> Other flows on IF2 are kept continue. >>>> >>>> That's all, they have same function and result. There is no big differ= ent!. >>> >>> The function differs. The result differ. #1 is simple flow mobility, >>> #2 is flow mobility bloated with something that nobody needs for flow >>> mobility. >> >> What are something that you are refer to? > > Artificially binds prefixes to interfaces, thus introducing the need > to update the prefix-interface mapping. This is not needed for flow > mobility, as proven by the fact that solution #1 works ok without > binding prefixes to interfaces. > >>>> Hope we can agree on this and save our time :-). >>> >>> By all means! Hope you will agree with applying KISS principle and pick= #1 :-) >>> >> >> I like KISS principle also :-). >> For me both two session definitions above are ok. >> I can see only one point different between your solution and current >> draft's solution is signaling between LMA and MAG. >> >> You prefer to use L2 triggers and policy profile update to trigger >> MAGs to send PBU message while the current draft prefers to allow LMA >> to send trigger to MAG. > > L2 triggers are needed anyway for PMIP thus it makes no sense to try > to do without them. > >> The question here is that which one is better and best-match with the >> real system. > > The only real system I know is 3GPP and it has L2 triggers. Otherwise > PMIP doesn't work. > I agree. One more thing is that in 3GPP when the network policy change the ANDSF can send SMS to UE to update policy to UE (MN) via S14 interface using push model. >> That's point we need to discuss more, especially the case that network >> policy is changed. > > I think everything has been said on why #2 brings nothing more than > #1, including the case where network policy is changed. > Julien, I think we are almost on the same page now :-) Thank you for your discussion. Regards, TrungTM > --julien > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 From pierrick.seite@orange-ftgroup.com Thu Feb 10 00:41:18 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DB043A69F4 for ; Thu, 10 Feb 2011 00:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.876 X-Spam-Level: X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hly+xlb4vIAz for ; Thu, 10 Feb 2011 00:41:17 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id A4C2E3A69F3 for ; Thu, 10 Feb 2011 00:41:16 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 700E46C0013; Thu, 10 Feb 2011 09:41:56 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 63ABB6C0011; Thu, 10 Feb 2011 09:41:56 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Feb 2011 09:41:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Feb 2011 09:41:25 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462017D4991@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Multiple prefixes indraft-bernardos-netext-pmipv6-flowmob Thread-Index: AcvIhEsFl7sUjO8GQl6vUBkPdfJrOwAedK2Q References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com><843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr><843DA8228A1BA74CA31FB4E111A5C462017D4653@ftrdmel0.rd.francetelecom.fr> From: To: X-OriginalArrivalTime: 10 Feb 2011 08:41:26.0125 (UTC) FILETIME=[4DB691D0:01CBC8FE] Cc: netext@ietf.org Subject: Re: [netext] Multiple prefixes indraft-bernardos-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 10 Feb 2011 08:41:18 -0000 > -----Message d'origine----- > De=A0: Julien Laganier [mailto:julien.ietf@gmail.com] > Envoy=E9=A0: mercredi 9 f=E9vrier 2011 19:07 > =C0=A0: SEITE Pierrick RD-RESA-REN > Cc=A0: trungtm2909@gmail.com; gerardog@qualcomm.com; netext@ietf.org > Objet=A0: Re: [netext] Multiple prefixes = indraft-bernardos-netext-pmipv6- > flowmob >=20 > Pierrick: >=20 > On Wed, Feb 9, 2011 at 1:05 AM, > wrote: > > > > > >> -----Message d'origine----- > >> De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De = la > part > >> de Tran Minh Trung > >> Envoy=E9=A0: mercredi 9 f=E9vrier 2011 09:46 > >> =C0=A0: Giaretta, Gerardo > >> Cc=A0: netext@ietf.org > >> Objet=A0: Re: [netext] Multiple prefixes = indraft-bernardos-netext-pmipv6- > >> flowmob > >> > >> On Wed, Feb 9, 2011 at 3:33 PM, Giaretta, Gerardo > > >> wrote: > >> > Hi all, > >> > > >> > I am starting a new thread to understand the use case this draft = is > >> trying to solve when referring to multiple prefixes. I think there = has > >> been some discussion already in the list but I did not get a good > >> understanding of the rationale. > >> > > >> > My understanding is that the goal of the draft is to define a = flow > >> mobility solution for PMIP. This implies that a given PMIP session = is > >> shared across multiple interfaces and some IP flows belonging to = that > >> session are sent over one interface and some others over another > interface. > >> This is equivalent to the RFC6089: IP flows which are tied to the = same > >> HoA/HNP can be sent over one CoA/BID or another CoA/BID. > >> > > >> > Is this the correct understanding of the goals of the I-D? Is = this a > >> common understanding of the term Flow Mobility? > >> > > >> > >> Yes you are right. > >> > >> > If this is the case, then I don't understand why the draft is > >> introducing text about the LMA creating a different session. Is = this > >> needed for Flow Mobility? If so, for which scenario? > >> > > >> > Going back to Pierrick's example: > >> > > >> > when the MN attaches to MAG1 via If1, the LMA creates session 1: > >> > > >> > =A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1, IF1] > >> > > >> > Then, if the MN attaches to MAG2 via If2, there is no reason for = the > LMA > >> to create session 2. The LMA just needs to update session 1 with = If2: > >> > > >> > >> We just follow the basic operation of the RFC5213 that a new prefix > >> will be assigned to new attachment. > >> > >> Then we extend it to support flow mobility by allowing interfaces = to > >> be attached to multiple sessions. > >> > >> > =A0 =A0 =A0 =A0 Session1: [Pref1, MAG1, IF1, IF2] > >> > > >> > In this way MAG/LMA/MN can send over IF2 a TCP connection which > earlier > >> was sent over IF1. This is Flow Mobility. > >> > > >> > >> It only works for the flows in the session1. However session 2,3..n > >> can be created at anytime in the future. We have to attach all = working > >> interfaces in the set to a new session whenever it is created. > >> > > > > IMU, the current draft allows different sessions with same prefix, = e.g: > > > > Session1: [Pref1, MAG1, IF1, IF2] > > Session2: [Pref1, MAG2, IF1, IF2] > > > > Right? >=20 > In the nominal RFC 5213 model, a PMIPv6 session is defined as a prefix > set, a MAG where the MN is attached, and an interface used by the MN > to attach (i.e., ATT and LLID.) >=20 > Session1: [{Pref_11,..., Pref_1p}, (MAG1, IF1)] > Session2: [{Pref_21,..., Pref_2q}, (MAG2, IF2)] >=20 > In flow mobility extension, I am proposing that we generalize this > definition to allow for multiple attachment, as it's IMO the only > _required_ extension to support flow mobility: >=20 > Session1: [{Pref_11,..., Pref_1p}, {(MAG1, IF1), (MAG2, IF2)}] > Session2: [{Pref_21,..., Pref_2q}, {(MAG2, IF2)}] >=20 Agreed > --julien From pierrick.seite@orange-ftgroup.com Thu Feb 10 00:50:37 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B45B43A693C for ; Thu, 10 Feb 2011 00:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fn4BjZ3gQXJs for ; Thu, 10 Feb 2011 00:50:35 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 521673A69EA for ; Thu, 10 Feb 2011 00:50:35 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 696A08B8007; Thu, 10 Feb 2011 09:51:51 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 5B7BA8B8003; Thu, 10 Feb 2011 09:51:51 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Feb 2011 09:50:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Feb 2011 09:50:45 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462017D49A1@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvIkrLuaaFjOG94SiShezyxsbrZPAAbGEDg References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com><843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr><843DA8228A1BA74CA31FB4E111A5C462017D475F@ftrdmel0.rd.francetelecom.fr> From: To: X-OriginalArrivalTime: 10 Feb 2011 08:50:46.0354 (UTC) FILETIME=[9BA2BB20:01CBC8FF] Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 10 Feb 2011 08:50:37 -0000 Hi, > -----Message d'origine----- > De=A0: Julien Laganier [mailto:julien.ietf@gmail.com] > Envoy=E9=A0: mercredi 9 f=E9vrier 2011 20:51 > =C0=A0: SEITE Pierrick RD-RESA-REN > Cc=A0: yh21.han@gmail.com; rkoodli@cisco.com; netext@ietf.org; > Basavaraj.Patil@nokia.com > Objet=A0: Re: [netext] Consensus call to adopt = I-D:draft-bernardos-netext- > pmipv6-flowmob as WG doc >=20 > Hi Pierrick, >=20 > Please see my anwer inline below: >=20 > On Wed, Feb 9, 2011 at 4:29 AM, > wrote: > > > > Hi, > > > > My only concern is on step 8, Please see inline. > > > > Pierrick > > > >> -----Message d'origine----- > >> De=A0: Julien Laganier [mailto:julien.ietf@gmail.com] > >> Envoy=E9=A0: mardi 8 f=E9vrier 2011 23:19 > >> =C0=A0: SEITE Pierrick RD-RESA-REN > >> Cc=A0: yh21.han@gmail.com; rkoodli@cisco.com; netext@ietf.org; > >> Basavaraj.Patil@nokia.com > >> Objet=A0: Re: [netext] Consensus call to adopt I-D:draft-bernardos- > netext- > >> pmipv6-flowmob as WG doc > >> > >> Hi Pierrick, > >> > >> I am going to intertwine the steps in your scenario below with the > >> missing pieces of the big picture so that we are not doing an = academic > >> exercise but focusing on the real world: > >> > >> 1. when the MN first attaches with if1 to a network, MAG1 requests > >> attachment of if1 to a session1 by sending a PBU to LMA > >> > >> 2. because the MN add no session1 previously, the LMA creates = session > >> 1 and allocates a prefix for it. The prefix is sent back to MAG1 in > >> the PBA: > >> > >> =A0=A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1-IF1] > >> > >> 3. then, if the MN attaches with if2 to another network, but does = not > >> request this interface be attached to a distinct session, MAG2 > >> requests attachemnt of If2 to session1 by sending a PBU to LMA > >> > >> 4. Because the MN already has session 1, the LMA updates session1 = with > >> if2, and send the pref1 back to MAG2 in the PBA: > >> > >> =A0=A0 =A0 =A0 =A0 Session1: [Pref1, MAG1-IF1, MAG2-IF2] > >> > >> 5. Creation of a new session 2 for if2 is requested by either of MN > >> requests via L2 triggers, or a change in policy profile. As a = result, > >> MAG2 requests attachment of if2 to session2 by sending a PBU to = LMA. > >> > >> 6. because the MN add no session2 previously, the LMA creates = session > >> 2 and allocates a prefix for it. The prefix pref2 is sent back to = MAG2 > >> in the PBA: > >> > >> =A0=A0 =A0 =A0 =A0 =A0Session2: [Pref2, MAG2-IF2] > >> > >> 7. Flow2 starts over if2 with prefix2. > >> > >> 8. Attachment of if1 to session2 is requested by either of MN = requests > >> via L2 triggers, or a change in policy profile. As a result, MAG1 > >> requests attachment of if1 to session2 by sending a PBU to LMA. > >> > > > > But the MN is already attached to MAG1 via If1. So, without being = too > 3GPP specific, what kind of L2 triggers can be used? >=20 > Being 3GPP specific: Additional PDN Connectivity Request. >=20 > Without being 3GPP specific, a L2 trigger requesting creation of an > additional session. >=20 > > To be more generic, I think that, for this case (attach a working > interface to a new session), we could have LMA/MAG signalling, maybe = as an > option? The use-case I have in mind is a short-term deployment of PMIP = IP > flow mobility over WiFi and 3GPP networks. Because, it is a short term > deployment, I have to use legacy 3G network (i.e. without LTE or = inter- > systems mobility mechanisms); so the 3G network must be agnostic of = PMIP > support and I can't rely on L2 to trigger PMIP. >=20 > If you have no L2 trigger you cannot even use RFC5213 PMIP as the MAG > has no way to detect a MN attached and initiate PBU towards LMA. >=20 Actually, we can't leverage on 3GPP L2 specific trigger but, of course, = we still have RS/RA between MAG and MN.=20 > If your "3G network must be agnostic of PMIP support", PMIP is a no > go. (you could use MIPv6, it works well over an unmodified 3G network > as it is a full overlay.) >=20 > --julien From julien.ietf@gmail.com Thu Feb 10 07:21:02 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 877023A6956 for ; Thu, 10 Feb 2011 07:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.392 X-Spam-Level: X-Spam-Status: No, score=-3.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0IzuoY6N5YV for ; Thu, 10 Feb 2011 07:21:01 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id ECD923A67AC for ; Thu, 10 Feb 2011 07:21:00 -0800 (PST) Received: by eyd10 with SMTP id 10so823290eyd.31 for ; Thu, 10 Feb 2011 07:21:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=v7vVZ4108KM3Dp06mba5pRFYv1Y+chwcq59VR8FP6ik=; b=GMD/9meiYyYjTU9jEufEY7n8Ln5PjPzQRfdeyxY+GpXBpTgQeirYSX+W3vCFSMJ/jo afys+HBbfZUoc7hheqp1Z0ecEaH/hQW7rjVQrZqGAbpQaftd7yp/RmcSYrFIYfB79SMx cKau5h94hXX7FeOi5TjENOMoO3WZ27O6gqevQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=o7oMcznmazAlM1IFytCaJ0BTP+XSqxt2aW+CRlcZssXDlhLri9vJqiHjtW1b2AnUU1 AXDb0z765kR/h2CJsgx+GlGSJrLkSOQSJkD3ZmhVPUDkK0XJXfzBw9MCYWaWspyuLHHk RecMizPrchMCW1oehtJk7bo7lFO3hQrTmvLgA= MIME-Version: 1.0 Received: by 10.103.199.18 with SMTP id b18mr15835303muq.21.1297351272129; Thu, 10 Feb 2011 07:21:12 -0800 (PST) Received: by 10.103.221.9 with HTTP; Thu, 10 Feb 2011 07:21:12 -0800 (PST) In-Reply-To: References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> Date: Thu, 10 Feb 2011 07:21:12 -0800 Message-ID: From: Julien Laganier To: Tran Minh Trung Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "netext@ietf.org" Subject: Re: [netext] Multiple prefixes in draft-bernardos-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 10 Feb 2011 15:21:02 -0000 Tran, Thanks for the discussion as well. Glad I could eventually convey my point to you. Best, --julien On Thu, Feb 10, 2011 at 12:07 AM, Tran Minh Trung w= rote: > On Thu, Feb 10, 2011 at 3:45 PM, Julien Laganier = wrote: >> On Wed, Feb 9, 2011 at 7:03 PM, Tran Minh Trung = wrote: >>> [Snip.] >>> >>>>> Julien, I think your solution and the solution in the draft have the >>>>> same function and result. >>>>> >>>>> No big different. Both of them are Ok. >>>> >>>> No. >>>> >>>> My solution allows flow mobility at the cost of two new HI values. >>>> >>>> The solution in the draft allows flow mobility plus a bunch of other >>>> things that have nothing to do with flow mobility, at the cost of new >>>> messages, new state machines etc. >>>> >>>>> Let me analyze it again as following: >>>>> >>>>> 1. Your solution: Adding interface to session >>>>> >>>>> Session1: [{Pref_11,..., Pref_1p}, (MAG1, IF1)] >>>>> Session2: [{Pref_21,..., Pref_2q}, (MAG2, IF2)] >>>>> >>>>> In flow mobility extension, I am proposing that we generalize this >>>>> definition to allow for multiple attachment, as it's IMO the only >>>>> =A0_required_ extension to support flow mobility: >>>>> >>>>> Session1: [{Pref_11,..., Pref_1p}, {(MAG1, IF1), (MAG2, IF2)}] >>>>> Session2: [{Pref_21,..., Pref_2q}, {(MAG2, IF2)}] >>>>> >>>>> >>>>> 2. Solution in current draft: Adding prefix to session >>>>> >>>>> Session1: [{Pref_11,..., Pref_1p,Pref_21,..., Pref_2q}, {(MAG1, IF1)}= ] >>>>> Session2: [{Pref_21,..., Pref_2q,Pref_11,..., Pref_1p}, {(MAG2, IF2)}= ] >>>>> >>>>> Both of them have the same function is to allow prefix(es) to be shar= ed >>>>> across interface. >>>>> >>>>> Is that right? >>>> >>>> I would say #1 allows flow mobility by sharing sessions (and >>>> corresponding prefix set) across interfaces, while #2 allows for >>>> things that unrelated to flow mobility at the cost of added >>>> complexity. >>>> >>> >>> Can the session defined in #2 support flow mobility? >>> The answer is clearly Yes. >>> >>> Now how to do it: We can use HI as your suggestion. >>> >>>> Let me now follow the KISS principle: Keep It Simple, Stupid! >>>> >>>> Then I pick #1. There are no good reasons to go for #2 unless a clear >>>> case is made why #1 is required. >>> >>> There is a key reason for me to prefer the solution #2. >>> >>> The RFC5213 maintains separate session for each interface (Please see >>> 5.4. =A0Multihoming Support, item 1). It dose not maintain one session >>> for multiple interfaces. >> >> RFC 5213 only maintains different session for different interfaces if >> the MAG doesn't know if the host supports inter-interface handovers >> and thus doesn't set the HI indicator to "handoff between different >> interfaces." If the MAG knows that the host supports inter-interface >> handovers, it sets the HI indicator to "handoff between different >> interfaces." and the same session is changed from one interface to >> another. >> >>> Solution #2 does the same as RFC5213, while solution#1 maintains >>> session for each set of prefix. It is not original session definition >>> of RFC5213, right? >> >> Solution #2 artificially generalizes the case where RFC 5213 MAG >> doesn't know if the host supports inter-interface handovers to the >> flow mobility case where we know that the host supports >> inter-interface handovers since it has the logical interface! This >> doesn't make sense. >> > > Ok I agree. If the network knows that the MN can support > inter-interface handovers then multiple interfaces can be managed by a > session. > >>> However I think solution #1 also Ok since it gives the same result. >> >> So you agree #1 is Ok. >> >>>>Note: You can't say we need different >>>> prefixes on different interfaces and therefore flow mobility needs to >>>> allow different prefix on different interfaces. It's not even >>>> tautologic! >>>> >>>>> Now, if IF1 detaches from network. >>>>> Your solution removes IF from session 1 while or solution remove sess= ion 1. >>>>> Other flows on IF2 are kept continue. >>>>> >>>>> That's all, they have same function and result. There is no big diffe= rent!. >>>> >>>> The function differs. The result differ. #1 is simple flow mobility, >>>> #2 is flow mobility bloated with something that nobody needs for flow >>>> mobility. >>> >>> What are something that you are refer to? >> >> Artificially binds prefixes to interfaces, thus introducing the need >> to update the prefix-interface mapping. This is not needed for flow >> mobility, as proven by the fact that solution #1 works ok without >> binding prefixes to interfaces. >> >>>>> Hope we can agree on this and save our time :-). >>>> >>>> By all means! Hope you will agree with applying KISS principle and pic= k #1 :-) >>>> >>> >>> I like KISS principle also :-). >>> For me both two session definitions above are ok. >>> I can see only one point different between your solution and current >>> draft's solution is signaling between LMA and MAG. >>> >>> You prefer to use L2 triggers and policy profile update to trigger >>> MAGs to send PBU message while the current draft prefers to allow LMA >>> to send trigger to MAG. >> >> L2 triggers are needed anyway for PMIP thus it makes no sense to try >> to do without them. >> >>> The question here is that which one is better and best-match with the >>> real system. >> >> The only real system I know is 3GPP and it has L2 triggers. Otherwise >> PMIP doesn't work. >> > > I agree. One more thing is that in 3GPP when the network policy change > the ANDSF can send SMS to UE to > update policy to UE (MN) via S14 interface using push model. > >>> That's point we need to discuss more, especially the case that network >>> policy is changed. >> >> I think everything has been said on why #2 brings nothing more than >> #1, including the case where network policy is changed. >> > > Julien, I think we are almost on the same page now :-) > Thank you for your discussion. > > Regards, > TrungTM > >> --julien >> > > > > -- > Ph.D., Senior Member > Electronics and Telecommunications Research Institute > Standards Research Center > 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA > Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 > From julien.ietf@gmail.com Thu Feb 10 07:36:18 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A40C3A699E for ; Thu, 10 Feb 2011 07:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.776 X-Spam-Level: X-Spam-Status: No, score=-2.776 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIN1ILJB3UwU for ; Thu, 10 Feb 2011 07:36:17 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 812243A67EC for ; Thu, 10 Feb 2011 07:36:16 -0800 (PST) Received: by ewy8 with SMTP id 8so864845ewy.31 for ; Thu, 10 Feb 2011 07:36:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fAiLpFK6jeKO/zxsnm0IOV8Ah408HhzLGoJcLBH5XRA=; b=pFesvY/ow0xhH0MUOdaM8TeCur0maEMetxTCOK7n+XA7Y+bM+PL0W6Q8XlgEdfOoi6 Rm1/ALISgzoeRijbLMqFtgcUuYP7q6QAx3vvRxcUqErCuaD3ooU0c3KuQurV8m3vAV42 eHyoQ5hVX7VOMP988Gx3aA+kojtvX5VUWlO5g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pKZ/XDzi/fKHFCny9bvWXevdi8BolF0l/7drj1aPyKFwPhPjoJ6eZ948GwbmhpU+hz 7AeLQF/SNKMyBYeJULuqRn+mWXL2AsSb2bDwsGJEgG29us7kJ4b4jzbZJPW/jh/uGVaZ HePI2l64SaAkSnFgzJ4f6t/w7vA6rDCXg7Fes= MIME-Version: 1.0 Received: by 10.103.108.10 with SMTP id k10mr4429140mum.39.1297352187709; Thu, 10 Feb 2011 07:36:27 -0800 (PST) Received: by 10.103.221.9 with HTTP; Thu, 10 Feb 2011 07:36:27 -0800 (PST) In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462017D49A1@ftrdmel0.rd.francetelecom.fr> References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C462017D475F@ftrdmel0.rd.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C462017D49A1@ftrdmel0.rd.francetelecom.fr> Date: Thu, 10 Feb 2011 07:36:27 -0800 Message-ID: From: Julien Laganier To: pierrick.seite@orange-ftgroup.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 10 Feb 2011 15:36:18 -0000 On Thu, Feb 10, 2011 at 12:50 AM, wrot= e: > > Hi, > >> -----Message d'origine----- >> De=A0: Julien Laganier [mailto:julien.ietf@gmail.com] >> Envoy=E9=A0: mercredi 9 f=E9vrier 2011 20:51 >> =C0=A0: SEITE Pierrick RD-RESA-REN >> Cc=A0: yh21.han@gmail.com; rkoodli@cisco.com; netext@ietf.org; >> Basavaraj.Patil@nokia.com >> Objet=A0: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netex= t- >> pmipv6-flowmob as WG doc >> >> Hi Pierrick, >> >> Please see my anwer inline below: >> >> On Wed, Feb 9, 2011 at 4:29 AM, =A0 >> wrote: >> > >> > Hi, >> > >> > My only concern is on step 8, Please see inline. >> > >> > Pierrick >> > >> >> -----Message d'origine----- >> >> De=A0: Julien Laganier [mailto:julien.ietf@gmail.com] >> >> Envoy=E9=A0: mardi 8 f=E9vrier 2011 23:19 >> >> =C0=A0: SEITE Pierrick RD-RESA-REN >> >> Cc=A0: yh21.han@gmail.com; rkoodli@cisco.com; netext@ietf.org; >> >> Basavaraj.Patil@nokia.com >> >> Objet=A0: Re: [netext] Consensus call to adopt I-D:draft-bernardos- >> netext- >> >> pmipv6-flowmob as WG doc >> >> >> >> Hi Pierrick, >> >> >> >> I am going to intertwine the steps in your scenario below with the >> >> missing pieces of the big picture so that we are not doing an academi= c >> >> exercise but focusing on the real world: >> >> >> >> 1. when the MN first attaches with if1 to a network, MAG1 requests >> >> attachment of if1 to a session1 by sending a PBU to LMA >> >> >> >> 2. because the MN add no session1 previously, the LMA creates session >> >> 1 and allocates a prefix for it. The prefix is sent back to MAG1 in >> >> the PBA: >> >> >> >> =A0=A0 =A0 =A0 =A0 =A0Session1: [Pref1, MAG1-IF1] >> >> >> >> 3. then, if the MN attaches with if2 to another network, but does not >> >> request this interface be attached to a distinct session, MAG2 >> >> requests attachemnt of If2 to session1 by sending a PBU to LMA >> >> >> >> 4. Because the MN already has session 1, the LMA updates session1 wit= h >> >> if2, and send the pref1 back to MAG2 in the PBA: >> >> >> >> =A0=A0 =A0 =A0 =A0 Session1: [Pref1, MAG1-IF1, MAG2-IF2] >> >> >> >> 5. Creation of a new session 2 for if2 is requested by either of MN >> >> requests via L2 triggers, or a change in policy profile. As a result, >> >> MAG2 requests attachment of if2 to session2 by sending a PBU to LMA. >> >> >> >> 6. because the MN add no session2 previously, the LMA creates session >> >> 2 and allocates a prefix for it. The prefix pref2 is sent back to MAG= 2 >> >> in the PBA: >> >> >> >> =A0=A0 =A0 =A0 =A0 =A0Session2: [Pref2, MAG2-IF2] >> >> >> >> 7. Flow2 starts over if2 with prefix2. >> >> >> >> 8. Attachment of if1 to session2 is requested by either of MN request= s >> >> via L2 triggers, or a change in policy profile. As a result, MAG1 >> >> requests attachment of if1 to session2 by sending a PBU to LMA. >> >> >> > >> > But the MN is already attached to MAG1 via If1. So, without being too >> 3GPP specific, what kind of L2 triggers can be used? >> >> Being 3GPP specific: Additional PDN Connectivity Request. >> >> Without being 3GPP specific, a L2 trigger requesting creation of an >> additional session. >> >> > To be more generic, I think that, for this case (attach a working >> interface to a new session), we could have LMA/MAG signalling, maybe as = an >> option? The use-case I have in mind is a short-term deployment of PMIP I= P >> flow mobility over WiFi and 3GPP networks. Because, it is a short term >> deployment, I have to use legacy 3G network (i.e. without LTE or inter- >> systems mobility mechanisms); so the 3G network must be agnostic of PMIP >> support and I can't rely on L2 to trigger PMIP. >> >> If you have no L2 trigger you cannot even use RFC5213 PMIP as the MAG >> has no way to detect a MN attached and initiate PBU towards LMA. >> > > Actually, we can't leverage on 3GPP L2 specific trigger but, of course, w= e still have RS/RA between MAG and MN. Agree you can't list specific 3GPP triggers, except maybe as example of what L2 triggers could be (might be a good idea actually.) On the other hand you can actually leverage on *generic* L2 triggers, just explain what they are. I believe we only need two: "MN attaches interfaces to session" , and " MN detaches interface from session." There used to be an MN-AR interface drafts that listed the triggers used by RFC 5213, but in the end it was abandoned as RFC 5213 did a good job at describing the L2 triggers it relied on, i.e., attach, and detach, see quotes below: 1. After detecting a new mobile node on its access link, the mobile access gateway MUST identify the mobile node and acquire its MN- Identifier. [...] The specific detection mechanism of the loss of a visiting mobile node on the connected link is specific to the access link between the mobile node and the mobile access gateway and is outside the scope of this document. Typically, there are various link-layer-specific events specific to each access technology that the mobile access gateway can depend on for detecting the node loss. In general, the mobile access gateway can depend on one or more of the following methods for the detection presence of the mobile node on the connected link: o Link-layer event specific to the access technology o Session termination event on point-to-point link types o IPv6 Neighbor Unreachability Detection event from IPv6 stack o Notification event from the local mobility anchor [...] When a mobile node enters a Proxy Mobile IPv6 domain and attaches to an access network, the mobile access gateway on the access link detects the attachment of the mobile node and completes the binding registration with the mobile node's local mobility anchor. RS seems not like a good trigger because it does not give the MAG the session information, the MNID, etc. --julien From trungtm2909@gmail.com Thu Feb 10 17:21:47 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C33613A67D2 for ; Thu, 10 Feb 2011 17:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.283 X-Spam-Level: X-Spam-Status: No, score=-3.283 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h62xnz8q2jtT for ; Thu, 10 Feb 2011 17:21:46 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id C8D983A672F for ; Thu, 10 Feb 2011 17:21:46 -0800 (PST) Received: by iym1 with SMTP id 1so2069262iym.31 for ; Thu, 10 Feb 2011 17:22:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wbrIYFQGvvqTD3Ig+ENOz9yipxz3zPa4Jki1vPkaBTE=; b=urBeSEGvMK0drmsAh+xQZQij2RhHbcma235GhVcJ07URKEFAcjEHMWbs2tgEV8npIA DiYTPOdIkAGz25yGBGqL1bB9cG+TdwZ5vG2GjLX/1W+DpViKdeTUCBEMu9sHtTz/ebXb +TSPVMORuM/3O5midF/edGUDgUdXDRfnhpaWU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=JHYwWNhBUmgH/lxQjjS57agsVvPOpRh9x63LZ0+jLrZ7wTftmP/p+FDkxvZbmUXEKJ tkpkrRKzGQDedwFidVmx0sHtJjgv5OrLOaAxy6FAx3Xi0Aodq+kENHN01cZ/MyCU5Uui DgDE1Y+Vlk7LBrNaofJ+dJM9AMsnEOM6BgHN4= MIME-Version: 1.0 Received: by 10.42.2.142 with SMTP id 14mr10866625ick.44.1297387318248; Thu, 10 Feb 2011 17:21:58 -0800 (PST) Received: by 10.42.72.199 with HTTP; Thu, 10 Feb 2011 17:21:58 -0800 (PST) In-Reply-To: References: <015b01cbc77f$69f132e0$3dd398a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C462017D4533@ftrdmel0.rd.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C462017D475F@ftrdmel0.rd.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C462017D49A1@ftrdmel0.rd.francetelecom.fr> Date: Fri, 11 Feb 2011 10:21:58 +0900 Message-ID: From: Tran Minh Trung To: Julien Laganier Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 01:21:47 -0000 [Snip.] >> >> Actually, we can't leverage on 3GPP L2 specific trigger but, of course, = we still have RS/RA between MAG and MN. > > Agree you can't list specific 3GPP triggers, except maybe as example > of what L2 triggers could be (might be a good idea actually.) On the > other hand you can actually leverage on *generic* =A0L2 triggers, just > explain what they are. I believe we only need two: "MN attaches > interfaces to session" , and " MN detaches interface from session." IMO, It would be better to say that: MN attaches to/detaches from MAGs. MAGs attach/detach MN's attachments to/from session. Regards, TrungTM > There used to be an MN-AR interface drafts that listed the triggers > used by RFC 5213, but in the end it was abandoned as RFC 5213 did a > good job at describing the L2 triggers it relied on, i.e., attach, and > detach, see quotes below: > > =A0 1. =A0 After detecting a new mobile node on its access link, the mobi= le > =A0 =A0 =A0 =A0access gateway MUST identify the mobile node and acquire i= ts MN- > =A0 =A0 =A0 =A0Identifier. > > [...] > > =A0 The specific detection mechanism of the loss of a visiting mobile > =A0 node on the connected link is specific to the access link between the > =A0 mobile node and the mobile access gateway and is outside the scope of > =A0 this document. =A0Typically, there are various link-layer-specific > =A0 events specific to each access technology that the mobile access > =A0 gateway can depend on for detecting the node loss. =A0In general, the > =A0 mobile access gateway can depend on one or more of the following > =A0 methods for the detection presence of the mobile node on the > =A0 connected link: > > =A0 o =A0Link-layer event specific to the access technology > > =A0 o =A0Session termination event on point-to-point link types > > =A0 o =A0IPv6 Neighbor Unreachability Detection event from IPv6 stack > > =A0 o =A0Notification event from the local mobility anchor > > [...] > > =A0 When a mobile node enters a Proxy Mobile IPv6 domain and attaches to > =A0 an access network, the mobile access gateway on the access link > =A0 detects the attachment of the mobile node and completes the binding > =A0 registration with the mobile node's local mobility anchor. > > RS seems not like a good trigger because it does not give the MAG the > session information, the MNID, etc. > > --julien > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 From zhou.xingyue@zte.com.cn Thu Feb 10 17:26:39 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABA3C3A694F; Thu, 10 Feb 2011 17:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.79 X-Spam-Level: X-Spam-Status: No, score=-92.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5h4U7JYF56Lt; Thu, 10 Feb 2011 17:26:38 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id D0B693A6849; Thu, 10 Feb 2011 17:26:37 -0800 (PST) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35103502467742; Fri, 11 Feb 2011 09:24:44 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 96520.6324253867; Fri, 11 Feb 2011 09:26:46 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p1B1QfHB056950; Fri, 11 Feb 2011 09:26:41 +0800 (GMT-8) (envelope-from zhou.xingyue@zte.com.cn) In-Reply-To: To: "Giaretta, Gerardo" MIME-Version: 1.0 X-KeepSent: F5E22876:67D52EA2-48257834:0005C6AB; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.xingyue@zte.com.cn Date: Fri, 11 Feb 2011 09:26:29 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-02-11 09:26:42, Serialize complete at 2011-02-11 09:26:42 Content-Type: multipart/alternative; boundary="=_alternative 0007EF3D48257834_=" X-MAIL: mse02.zte.com.cn p1B1QfHB056950 Cc: "netext@ietf.org" , netext-bounces@ietf.org Subject: [netext] =?gb2312?b?tPC4tDogUmU6ICBQb2xpY3kgYXNzdW1wdGlvbnMgaW4g?= =?gb2312?b?ZHJhZnQtYmVybmFyZG9zLW5ldGV4dC1wbWlwdjYtZmxvd21vYg==?= X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 01:26:39 -0000 This is a multipart message in MIME format. --=_alternative 0007EF3D48257834_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCm5ldGV4dC1ib3VuY2VzQGlldGYub3JnINC009ogMjAxMS0wMi0xMCDJz87nIDA2 OjI3OjAwOg0KDQo+IEhlbGxvLA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiA+IEZyb206IFRyYW4gTWluaCBUcnVuZyBbbWFpbHRvOnRydW5ndG0yOTA5QGdtYWlsLmNvbV0N Cj4gPiBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA5LCAyMDExIDEyOjMxIEFNDQo+ID4gVG86 IEdpYXJldHRhLCBHZXJhcmRvDQo+ID4gQ2M6IG5ldGV4dEBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6 IFJlOiBbbmV0ZXh0XSBQb2xpY3kgYXNzdW1wdGlvbnMgaW4gZHJhZnQtYmVybmFyZG9zLW5ldGV4 dC0NCj4gPiBwbWlwdjYtZmxvd21vYg0KPiA+IA0KPiA+IE9uIFdlZCwgRmViIDksIDIwMTEgYXQg MzozNiBQTSwgR2lhcmV0dGEsIEdlcmFyZG8NCj4gPiA8Z2VyYXJkb2dAcXVhbGNvbW0uY29tPiB3 cm90ZToNCj4gPiA+IEkgd2FudCB0byBnbyBiYWNrIHRvIHRoZSBwb2ludCByYWlzZWQgYnkgU3Rl ZmFubyB3aGljaCB3YXMgc29tZWhvdw0KPiA+IGxvc3QgaW4gdGhlIGxvbmcgdGhyZWFkLg0KPiA+ ID4NCj4gPiA+IEkgbmVlZCBzb21lIGNsYXJpZmljYXRpb25zIG9uIHdoaWNoIGlzIHRoZSBhc3N1 bXB0aW9uIGluIHRlcm1zIG9mDQo+ID4gcG9saWNpZXMgaW4gdGhlIGRyYWZ0LiBJbiBwYXJ0aWN1 bGFyOg0KPiA+ID4NCj4gPiA+IC0gSXMgaXQgY29ycmVjdCB0aGF0IHRoZXJlIGlzIGFuIGFzc3Vt cHRpb24gdGhhdCBNTiBhbmQgTE1BIGhhdmUgdGhlDQo+ID4gc2FtZSBwb2xpY2llcyBhbmQgYmVo YXZlIGFjY29yZGluZ2x5Pw0KPiA+ID4NCj4gPiANCj4gPiBZZXMsIHRoZXkgc2hvdWxkIGhhdmUg dGhlIHNhbWUgcG9saWNpZXMuDQo+ID4gDQo+IA0KPiBUaGVuLCB0aGUgc2NlbmFyaW8gb2YgY2hh bmdlIG9mIHBvbGljeSBpbiB0aGUgTE1BIGlzIGNvbmZsaWN0aW5nIA0KPiB3aXRoIHRoaXMgYXNz dW1wdGlvbiB1bmxlc3MgcG9saWNpZXMgY2hhbmdlZCBhbHNvIG9uIE1OLg0KPiANCkFzIG1lbnRp b25lZCBieSBQaWVycmljaywgYSBwcmFnbWF0aWMgYW5kIGJhc2ljIHdheSBvbiBwb2xpY3kgY2Fu IGJlIA0KYXBwcGxpZWQgb24gTU4gaW4gZmlyc3Qgcm91bmQuIEZvciBjdXJyZW50IGZsb3csIHRo ZSBNTiBzaG91bGQgZm9sbG93IHRoZSANCkxNQSdzIGNoYW5nZSBvZiB0cmFmZmljIHJvdXRpbmcu IEFuZCB0aGUgTU4gaW5pdGF0ZXMgYW55IGZsb3cgYWNjb3JkaW5nIHRvIA0KdGhlIGRlZmF1bHQg cG9saWN5IGNvbmZpZ3VyYXRpb24uIE5vIGR5bmFtaWMgcG9saWN5IG1haW50ZW5hbmNlIGlzIG5l ZWRlZCANCm9uIE1OLg0KDQpSZWdhcmRzLA0KDQpKb3kgWmhvdQ0KWlRFIENvcnBvcmF0aW9uDQoN Cj4gR2VyYXJkbyANCj4gDQo+ID4gPiAtIERvZXMgdGhlIE1OIG5lZWQgdG8gaGF2ZSBrbm93bGVk Z2Ugb2YgdGhlIHBvbGljeSBhdCBhbGw/DQo+ID4gPg0KPiA+IA0KPiA+IFllcywgaXQgbmVlZHMg dG8gaGF2ZSBrbm93bGVkZ2Ugb2YgdGhlIHBvbGljeS4NCj4gPiBJdCBpcyBuZWNlc3NhcnkgZm9y IHRoZSBNTiB0byBzZW5kIHRoZSBwYWNrZXQgb2YgYSBORVcgZmxvdyAobm90DQo+ID4gb25nb2lu ZyBmbG93KSB0byB0aGUgcmlnaHQgaW50ZXJmYWNlLg0KPiA+IA0KPiA+IFJlZ2FyZHMsDQo+ID4g VHJ1bmdUTQ0KPiA+IA0KPiA+IA0KPiA+ID4gVGhhbmtzDQo+ID4gPiBHZXJhcmRvDQo+ID4gPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gbmV0 ZXh0IG1haWxpbmcgbGlzdA0KPiA+ID4gbmV0ZXh0QGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGV4dA0KPiA+ID4NCj4gPiANCj4gPiANCj4g PiANCj4gPiAtLQ0KPiA+IFBoLkQuLCBTZW5pb3IgTWVtYmVyDQo+ID4gRWxlY3Ryb25pY3MgYW5k IFRlbGVjb21tdW5pY2F0aW9ucyBSZXNlYXJjaCBJbnN0aXR1dGUNCj4gPiBTdGFuZGFyZHMgUmVz ZWFyY2ggQ2VudGVyDQo+ID4gMTYxIEdhamVvbmctRG9uZywgWXVzZW9uZy1HdSwgRGFlamVvbiwg MzA1LTM1MCwgS09SRUENCj4gPiBUZWwgOiArODItNDItODYwLTExMzIsICAgRmF4IDogKzgyLTQy LTg2MS01NDA0DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IG5ldGV4dCBtYWlsaW5nIGxpc3QNCj4gbmV0ZXh0QGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0DQo+IA0KDQo= --=_alternative 0007EF3D48257834_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhlbGxvLDwvZm9udD4NCjxicj4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPm5ldGV4dC1ib3VuY2VzQGlldGYub3JnINC009ogMjAxMS0w Mi0xMCDJz87nIDA2OjI3OjAwOjxicj4NCjxicj4NCiZndDsgSGVsbG8sPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7ICZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7ICZndDsgRnJv bTogVHJhbiBNaW5oIFRydW5nIFttYWlsdG86dHJ1bmd0bTI5MDlAZ21haWwuY29tXTxicj4NCiZn dDsgJmd0OyBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA5LCAyMDExIDEyOjMxIEFNPGJyPg0K Jmd0OyAmZ3Q7IFRvOiBHaWFyZXR0YSwgR2VyYXJkbzxicj4NCiZndDsgJmd0OyBDYzogbmV0ZXh0 QGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7IFN1YmplY3Q6IFJlOiBbbmV0ZXh0XSBQb2xpY3kgYXNz dW1wdGlvbnMgaW4gZHJhZnQtYmVybmFyZG9zLW5ldGV4dC08YnI+DQomZ3Q7ICZndDsgcG1pcHY2 LWZsb3dtb2I8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IE9uIFdlZCwgRmViIDksIDIw MTEgYXQgMzozNiBQTSwgR2lhcmV0dGEsIEdlcmFyZG88YnI+DQomZ3Q7ICZndDsgJmx0O2dlcmFy ZG9nQHF1YWxjb21tLmNvbSZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgSSB3YW50IHRv IGdvIGJhY2sgdG8gdGhlIHBvaW50IHJhaXNlZCBieSBTdGVmYW5vIHdoaWNoIHdhcw0Kc29tZWhv dzxicj4NCiZndDsgJmd0OyBsb3N0IGluIHRoZSBsb25nIHRocmVhZC48YnI+DQomZ3Q7ICZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IEkgbmVlZCBzb21lIGNsYXJpZmljYXRpb25zIG9uIHdo aWNoIGlzIHRoZSBhc3N1bXB0aW9uIGluDQp0ZXJtcyBvZjxicj4NCiZndDsgJmd0OyBwb2xpY2ll cyBpbiB0aGUgZHJhZnQuIEluIHBhcnRpY3VsYXI6PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgJmd0OyAtIElzIGl0IGNvcnJlY3QgdGhhdCB0aGVyZSBpcyBhbiBhc3N1bXB0aW9u IHRoYXQgTU4gYW5kDQpMTUEgaGF2ZSB0aGU8YnI+DQomZ3Q7ICZndDsgc2FtZSBwb2xpY2llcyBh bmQgYmVoYXZlIGFjY29yZGluZ2x5Pzxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 IDxicj4NCiZndDsgJmd0OyBZZXMsIHRoZXkgc2hvdWxkIGhhdmUgdGhlIHNhbWUgcG9saWNpZXMu PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGVuLCB0aGUgc2NlbmFyaW8g b2YgY2hhbmdlIG9mIHBvbGljeSBpbiB0aGUgTE1BIGlzIGNvbmZsaWN0aW5nIDxicj4NCiZndDsg d2l0aCB0aGlzIGFzc3VtcHRpb24gdW5sZXNzIHBvbGljaWVzIGNoYW5nZWQgYWxzbyBvbiBNTi48 YnI+DQomZ3Q7IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+QXMgbWVudGlvbmVk IGJ5IFBpZXJyaWNrLCBhIHByYWdtYXRpYyBhbmQgYmFzaWMgd2F5DQpvbiBwb2xpY3kgY2FuIGJl IGFwcHBsaWVkIG9uIE1OIGluIGZpcnN0IHJvdW5kLiBGb3IgY3VycmVudCBmbG93LCB0aGUgTU4N CnNob3VsZCBmb2xsb3cgdGhlIExNQSdzIGNoYW5nZSBvZiB0cmFmZmljIHJvdXRpbmcuIEFuZCB0 aGUgTU4gaW5pdGF0ZXMNCmFueSBmbG93IGFjY29yZGluZyB0byB0aGUgZGVmYXVsdCBwb2xpY3kg Y29uZmlndXJhdGlvbi4gTm8gZHluYW1pYyBwb2xpY3kNCm1haW50ZW5hbmNlIGlzIG5lZWRlZCBv biBNTi48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPlJlZ2FyZHMsPC9m b250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5Kb3kgWmhvdTwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+WlRFIENvcnBvcmF0aW9uPC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7IEdlcmFyZG8gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 ICZndDsgJmd0OyAtIERvZXMgdGhlIE1OIG5lZWQgdG8gaGF2ZSBrbm93bGVkZ2Ugb2YgdGhlIHBv bGljeSBhdCBhbGw/PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0 OyAmZ3Q7IFllcywgaXQgbmVlZHMgdG8gaGF2ZSBrbm93bGVkZ2Ugb2YgdGhlIHBvbGljeS48YnI+ DQomZ3Q7ICZndDsgSXQgaXMgbmVjZXNzYXJ5IGZvciB0aGUgTU4gdG8gc2VuZCB0aGUgcGFja2V0 IG9mIGEgTkVXIGZsb3cgKG5vdDxicj4NCiZndDsgJmd0OyBvbmdvaW5nIGZsb3cpIHRvIHRoZSBy aWdodCBpbnRlcmZhY2UuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBSZWdhcmRzLDxi cj4NCiZndDsgJmd0OyBUcnVuZ1RNPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyBUaGFua3M8YnI+DQomZ3Q7ICZndDsgJmd0OyBHZXJhcmRvPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7ICZndDsgJmd0OyBuZXRleHQgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAm Z3Q7ICZndDsgbmV0ZXh0QGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRleHQ8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4N CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0 OyAtLTxicj4NCiZndDsgJmd0OyBQaC5ELiwgU2VuaW9yIE1lbWJlcjxicj4NCiZndDsgJmd0OyBF bGVjdHJvbmljcyBhbmQgVGVsZWNvbW11bmljYXRpb25zIFJlc2VhcmNoIEluc3RpdHV0ZTxicj4N CiZndDsgJmd0OyBTdGFuZGFyZHMgUmVzZWFyY2ggQ2VudGVyPGJyPg0KJmd0OyAmZ3Q7IDE2MSBH YWplb25nLURvbmcsIFl1c2VvbmctR3UsIERhZWplb24sIDMwNS0zNTAsIEtPUkVBPGJyPg0KJmd0 OyAmZ3Q7IFRlbCA6ICs4Mi00Mi04NjAtMTEzMiwmbmJzcDsmbmJzcDsgRmF4IDogKzgyLTQyLTg2 MS01NDA0PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCiZndDsgbmV0ZXh0IG1haWxpbmcgbGlzdDxicj4NCiZndDsgbmV0ZXh0QGll dGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dGV4dDxicj4NCiZndDsgPGJyPg0KPC9mb250PjwvdHQ+DQo= --=_alternative 0007EF3D48257834_=-- From zhou.xingyue@zte.com.cn Thu Feb 10 18:12:49 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB3D63A67F6 for ; Thu, 10 Feb 2011 18:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.314 X-Spam-Level: X-Spam-Status: No, score=-97.314 tagged_above=-999 required=5 tests=[AWL=4.524, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nU-RNvLBLow for ; Thu, 10 Feb 2011 18:12:49 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 7B9603A67C1 for ; Thu, 10 Feb 2011 18:12:47 -0800 (PST) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101465182496; Fri, 11 Feb 2011 10:10:32 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 84746.1465182496; Fri, 11 Feb 2011 10:12:57 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p1B2Cqg5027638 for ; Fri, 11 Feb 2011 10:12:52 +0800 (GMT-8) (envelope-from zhou.xingyue@zte.com.cn) To: netext@ietf.org MIME-Version: 1.0 X-KeepSent: A4929F6A:54ADEABB-48257834:000BD07F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.xingyue@zte.com.cn Date: Fri, 11 Feb 2011 10:12:40 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-02-11 10:12:52, Serialize complete at 2011-02-11 10:12:52 Content-Type: multipart/alternative; boundary="=_alternative 000C29B748257834_=" X-MAIL: mse01.zte.com.cn p1B2Cqg5027638 Subject: [netext] test X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 02:12:49 -0000 This is a multipart message in MIME format. --=_alternative 000C29B748257834_= Content-Type: text/plain; charset="US-ASCII" Sorry for disturbing. Pls ignore this mail. --=_alternative 000C29B748257834_= Content-Type: text/html; charset="US-ASCII"
Sorry for disturbing.
Pls ignore this mail. --=_alternative 000C29B748257834_=-- From zhu.chunhui@zte.com.cn Thu Feb 10 20:03:22 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D7243A6AA5 for ; Thu, 10 Feb 2011 20:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.62 X-Spam-Level: X-Spam-Status: No, score=-99.62 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_DOUBLE_IP_LOOSE=0.76, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fl9Ps8OlU4f2 for ; Thu, 10 Feb 2011 20:03:16 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 418AA3A6A40 for ; Thu, 10 Feb 2011 20:03:16 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 205951465182496; Fri, 11 Feb 2011 11:58:37 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 16200.1465182496; Fri, 11 Feb 2011 11:55:03 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p1B43F62015147 for ; Fri, 11 Feb 2011 12:03:15 +0800 (GMT-8) (envelope-from zhu.chunhui@zte.com.cn) To: MIME-Version: 1.0 X-KeepSent: C3895AB4:C89A0703-48257834:0015ECAA; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhu.chunhui@zte.com.cn Date: Fri, 11 Feb 2011 12:00:22 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-02-11 12:03:16, Serialize complete at 2011-02-11 12:03:16 Content-Type: multipart/alternative; boundary="=_alternative 00161A6148257834_=" X-MAIL: mse01.zte.com.cn p1B43F62015147 Subject: [netext] test X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 04:03:22 -0000 This is a multipart message in MIME format. --=_alternative 00161A6148257834_= Content-Type: text/plain; charset="US-ASCII" --=_alternative 00161A6148257834_= Content-Type: text/html; charset="US-ASCII" --=_alternative 00161A6148257834_=-- From trungtm2909@gmail.com Fri Feb 11 00:39:56 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A4613A6A43; Fri, 11 Feb 2011 00:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.877 X-Spam-Level: X-Spam-Status: No, score=-0.877 tagged_above=-999 required=5 tests=[AWL=-2.123, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9djXGwIEu5gL; Fri, 11 Feb 2011 00:39:55 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 1F2753A6891; Fri, 11 Feb 2011 00:39:55 -0800 (PST) Received: by iym1 with SMTP id 1so2351735iym.31 for ; Fri, 11 Feb 2011 00:40:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hFVGMmwROZLjG2UOHQMnm+/57dAeSDUHoQAgEh1ywkk=; b=v4VKGka1Su1G3aGWxQOIVixsVEnS9IdSPZamnGPknrBjAQVVQggpZ2a7OVw73+d0tZ BL2NjgZAkRAjOVCof6pc+l0HRn4r3ZhJEdzLTK+c0SSyRqLXQd/cNWPe51sqfwIUwYvK Tz3Fk2Bh2PfgK2Tg3riJcNlPKBzTCtjyMn8kI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=QH+RO2Vqb6ItvS47Sxo6G5u2XNT62hdp5McWelcMz2YlyQbLQ55yom/eTpmRYbk46A ktpBTboJmKEmBQf4ZS8GAtZJnVieqMDeGiK9OKrZfmfLwKzvXswqYLWwC02CNaUF6hTw Gcy33hQVFCTcLKJuIs4GBpvbMHZV4kSZ4Z4kw= MIME-Version: 1.0 Received: by 10.42.220.8 with SMTP id hw8mr309116icb.111.1297413609149; Fri, 11 Feb 2011 00:40:09 -0800 (PST) Received: by 10.42.72.199 with HTTP; Fri, 11 Feb 2011 00:40:09 -0800 (PST) In-Reply-To: References: Date: Fri, 11 Feb 2011 17:40:09 +0900 Message-ID: From: Tran Minh Trung To: zhou.xingyue@zte.com.cn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "netext@ietf.org" , netext-bounces@ietf.org Subject: Re: [netext] =?gb2312?b?tPC4tDogUmU6ICBQb2xpY3kgYXNzdW1wdGlvbnMgaW4g?= =?gb2312?b?ZHJhZnQtYmVybmFyZG9zLW5ldGV4dC1wbWlwdjYtZmxvd21vYg==?= X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 08:39:56 -0000 Hi Joy Zhou, [Snip.] >> > >> > Yes, they should have the same policies. >> > >> >> Then, the scenario of change of policy in the LMA is conflicting >> with this assumption unless policies changed also on MN. >> > As mentioned by Pierrick, a pragmatic and basic way on policy can be > appplied on MN in first round. For current flow, the MN should follow the > LMA's change of traffic routing. And the MN initates any flow according t= o > the default policy configuration. No dynamic policy maintenance is needed= on > MN. > If the network blocks some service on default interface then how MN will do. Just try and try again on default interface? For a real example: AT&T (in the past) or KT network blocks VoIP over 3G. Then how can you do if the default interface is 3G?. The MN Just tries again and again or it should better syn. with the network policy to know that it can be done via WiFi?. Regards, TrungTM > Regards, > > Joy Zhou > ZTE Corporation > >> Gerardo >> >> > > - Does the MN need to have knowledge of the policy at all? >> > > >> > >> > Yes, it needs to have knowledge of the policy. >> > It is necessary for the MN to send the packet of a NEW flow (not >> > ongoing flow) to the right interface. >> > >> > Regards, >> > TrungTM >> > >> > >> > > Thanks >> > > Gerardo >> > > _______________________________________________ >> > > netext mailing list >> > > netext@ietf.org >> > > https://www.ietf.org/mailman/listinfo/netext >> > > >> > >> > >> > >> > -- >> > Ph.D., Senior Member >> > Electronics and Telecommunications Research Institute >> > Standards Research Center >> > 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA >> > Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 From zhou.xingyue@zte.com.cn Fri Feb 11 01:19:12 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C915C3A69DD; Fri, 11 Feb 2011 01:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.79 X-Spam-Level: X-Spam-Status: No, score=-92.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjvtVTB0Xv0t; Fri, 11 Feb 2011 01:19:11 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id D2D6C3A694F; Fri, 11 Feb 2011 01:19:10 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 205953502467742; Fri, 11 Feb 2011 17:14:18 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 16200.6324253867; Fri, 11 Feb 2011 17:10:53 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p1B9J9V9080315; Fri, 11 Feb 2011 17:19:09 +0800 (GMT-8) (envelope-from zhou.xingyue@zte.com.cn) In-Reply-To: To: Tran Minh Trung MIME-Version: 1.0 X-KeepSent: 07D71F82:59EF1496-48257834:002FF88F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.xingyue@zte.com.cn Date: Fri, 11 Feb 2011 17:18:56 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-02-11 17:19:10, Serialize complete at 2011-02-11 17:19:10 Content-Type: multipart/alternative; boundary="=_alternative 0033307D48257834_=" X-MAIL: mse01.zte.com.cn p1B9J9V9080315 Cc: "netext@ietf.org" , netext-bounces@ietf.org Subject: [netext] =?gb2312?b?tPC4tDogUmU6ILTwuLQ6IFJlOiAgUG9saWN5IGFzc3Vt?= =?gb2312?b?cHRpb25zIGluIGRyYWZ0LWJlcm5hcmRvcy1uZXRleHQtcG1pcHY2LWZsb3dt?= =?gb2312?b?b2I=?= X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 09:19:12 -0000 This is a multipart message in MIME format. --=_alternative 0033307D48257834_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgVHJ1bmcsDQoNClRyYW4gTWluaCBUcnVuZyA8dHJ1bmd0bTI5MDlAZ21haWwuY29tPiDQtNPa IDIwMTEtMDItMTEgz8LO5yAwNDo0MDowOToNCg0KPiBIaSBKb3kgWmhvdSwNCj4gDQo+IFtTbmlw Ll0NCj4gPj4gPg0KPiA+PiA+IFllcywgdGhleSBzaG91bGQgaGF2ZSB0aGUgc2FtZSBwb2xpY2ll cy4NCj4gPj4gPg0KPiA+Pg0KPiA+PiBUaGVuLCB0aGUgc2NlbmFyaW8gb2YgY2hhbmdlIG9mIHBv bGljeSBpbiB0aGUgTE1BIGlzIGNvbmZsaWN0aW5nDQo+ID4+IHdpdGggdGhpcyBhc3N1bXB0aW9u IHVubGVzcyBwb2xpY2llcyBjaGFuZ2VkIGFsc28gb24gTU4uDQo+ID4+DQo+ID4gQXMgbWVudGlv bmVkIGJ5IFBpZXJyaWNrLCBhIHByYWdtYXRpYyBhbmQgYmFzaWMgd2F5IG9uIHBvbGljeSBjYW4g YmUNCj4gPiBhcHBwbGllZCBvbiBNTiBpbiBmaXJzdCByb3VuZC4gRm9yIGN1cnJlbnQgZmxvdywg dGhlIE1OIHNob3VsZCBmb2xsb3cgDQp0aGUNCj4gPiBMTUEncyBjaGFuZ2Ugb2YgdHJhZmZpYyBy b3V0aW5nLiBBbmQgdGhlIE1OIGluaXRhdGVzIGFueSBmbG93IA0KYWNjb3JkaW5nIHRvDQo+ID4g dGhlIGRlZmF1bHQgcG9saWN5IGNvbmZpZ3VyYXRpb24uIE5vIGR5bmFtaWMgcG9saWN5IG1haW50 ZW5hbmNlIA0KaXNuZWVkZWQgb24NCj4gPiBNTi4NCj4gPg0KPiANCj4gSWYgdGhlIG5ldHdvcmsg YmxvY2tzIHNvbWUgc2VydmljZSBvbiBkZWZhdWx0IGludGVyZmFjZSB0aGVuIGhvdyBNTg0KPiB3 aWxsIGRvLiBKdXN0IHRyeSBhbmQgdHJ5IGFnYWluIG9uIGRlZmF1bHQgaW50ZXJmYWNlPw0KPiAN Cj4gRm9yIGEgcmVhbCBleGFtcGxlOiBBVCZUIChpbiB0aGUgcGFzdCkgb3IgS1QgbmV0d29yayBi bG9ja3MgVm9JUCBvdmVyDQo+IDNHLiBUaGVuIGhvdyBjYW4geW91IGRvIGlmIHRoZSBkZWZhdWx0 IGludGVyZmFjZSBpcyAzRz8uIFRoZSBNTiBKdXN0DQo+IHRyaWVzIGFnYWluIGFuZCBhZ2FpbiBv ciBpdCBzaG91bGQgYmV0dGVyIHN5bi4gd2l0aCB0aGUgbmV0d29yayBwb2xpY3kNCj4gdG8ga25v dyB0aGF0IGl0IGNhbiBiZSBkb25lIHZpYSBXaUZpPy4NCkkgdW5kZXJzdGFuZCB5b3VyIGNvbmNl cm4uIEJ1dCB3aGF0IEkgc2FpZCBpcyBvbiBhY3RpdmUgSVAgY29ubmVjdGl2aXR5LiANCldoZXRo ZXIgdGhlIE1OIHNob3VsZCByZW1lbWJlciB0aGUgY2hhbmdlIGhhcHBlbmVkIGR1cmluZyB0aGUg Y29ubmVjdGlvbiANCmlzIGltcGxlbWVudGF0aW9uIGRlcGVuZGVudCB3aXRoIHRoZSBhc3N1bXB0 aW9uIHRoYXQgdGhlIHNlcnZpY2UgY2FuIGJlIA0KaW5pdGlhdGVkIG9uIHRoZSBkZWZhdWx0IGlu dGVyZmFjZS4gVGhlIGV4YW1wbGUgeW91IG1lbnRpb25lZCBpcyBvbiBob3cgDQp0aGUgTU4gZ2V0 IHRoZSBuZXR3b3JrIHBvbGljeSBiZWZvcmUgaW5pdGlhdGluZyB0aGUgc2VydmljZSB0cmFmZmlj LiBTZWVtcyANCm5vdCBlYXN5IGZvciBMTUEgdG8gY292ZXkgdGhpcyBpbmZvIHNpbmNlIGEgZ2Fw IGV4aXN0cyBvbiBob3cgdG8gY292ZXkgDQp0aGlzIGZyb20gTUFHIHRvIE1OLiBNYXliZSB0aGUg dGhpcmQgcGFydHkgY2FuIGhlbHAgZS5nLiBBTkRTRiBkZWZpbmVkIGluIA0KM0dQUCB3aGlsZSB0 aGF0IGlzIGFub3RoZXIgc3RvcnkuDQoNClJlZ2FyZHMsDQpKb3kNCg0KPiANCj4gUmVnYXJkcywN Cj4gVHJ1bmdUTQ0KPiANCj4gPiBSZWdhcmRzLA0KPiA+DQo+ID4gSm95IFpob3UNCj4gPiBaVEUg Q29ycG9yYXRpb24NCj4gPg0KPiA+PiBHZXJhcmRvDQo+ID4+DQo+ID4+ID4gPiAtIERvZXMgdGhl IE1OIG5lZWQgdG8gaGF2ZSBrbm93bGVkZ2Ugb2YgdGhlIHBvbGljeSBhdCBhbGw/DQo+ID4+ID4g Pg0KPiA+PiA+DQo+ID4+ID4gWWVzLCBpdCBuZWVkcyB0byBoYXZlIGtub3dsZWRnZSBvZiB0aGUg cG9saWN5Lg0KPiA+PiA+IEl0IGlzIG5lY2Vzc2FyeSBmb3IgdGhlIE1OIHRvIHNlbmQgdGhlIHBh Y2tldCBvZiBhIE5FVyBmbG93IChub3QNCj4gPj4gPiBvbmdvaW5nIGZsb3cpIHRvIHRoZSByaWdo dCBpbnRlcmZhY2UuDQo+ID4+ID4NCj4gPj4gPiBSZWdhcmRzLA0KPiA+PiA+IFRydW5nVE0NCj4g Pj4gPg0KPiA+PiA+DQo+ID4+ID4gPiBUaGFua3MNCj4gPj4gPiA+IEdlcmFyZG8NCj4gPj4gPiA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ID4g PiBuZXRleHQgbWFpbGluZyBsaXN0DQo+ID4+ID4gPiBuZXRleHRAaWV0Zi5vcmcNCj4gPj4gPiA+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0DQo+ID4+ID4gPg0K PiA+PiA+DQo+ID4+ID4NCj4gPj4gPg0KPiA+PiA+IC0tDQo+ID4+ID4gUGguRC4sIFNlbmlvciBN ZW1iZXINCj4gPj4gPiBFbGVjdHJvbmljcyBhbmQgVGVsZWNvbW11bmljYXRpb25zIFJlc2VhcmNo IEluc3RpdHV0ZQ0KPiA+PiA+IFN0YW5kYXJkcyBSZXNlYXJjaCBDZW50ZXINCj4gPj4gPiAxNjEg R2FqZW9uZy1Eb25nLCBZdXNlb25nLUd1LCBEYWVqZW9uLCAzMDUtMzUwLCBLT1JFQQ0KPiA+PiA+ IFRlbCA6ICs4Mi00Mi04NjAtMTEzMiwgICBGYXggOiArODItNDItODYxLTU0MDQNCj4gPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gbmV0ZXh0 IG1haWxpbmcgbGlzdA0KPiA+PiBuZXRleHRAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRleHQNCj4gPj4NCj4gPg0KPiANCj4gDQo+IA0KPiAt LSANCj4gUGguRC4sIFNlbmlvciBNZW1iZXINCj4gRWxlY3Ryb25pY3MgYW5kIFRlbGVjb21tdW5p Y2F0aW9ucyBSZXNlYXJjaCBJbnN0aXR1dGUNCj4gU3RhbmRhcmRzIFJlc2VhcmNoIENlbnRlcg0K PiAxNjEgR2FqZW9uZy1Eb25nLCBZdXNlb25nLUd1LCBEYWVqZW9uLCAzMDUtMzUwLCBLT1JFQQ0K PiBUZWwgOiArODItNDItODYwLTExMzIsICAgRmF4IDogKzgyLTQyLTg2MS01NDA0DQo+IA0KDQo= --=_alternative 0033307D48257834_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFRydW5nLDwvZm9udD4NCjxi cj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPlRyYW4gTWluaCBUcnVuZyAmbHQ7dHJ1bmd0bTI5MDlA Z21haWwuY29tJmd0OyDQtNPaDQoyMDExLTAyLTExIM/CzucgMDQ6NDA6MDk6PGJyPg0KPGJyPg0K Jmd0OyBIaSBKb3kgWmhvdSw8YnI+DQomZ3Q7IDxicj4NCiZndDsgW1NuaXAuXTxicj4NCiZndDsg Jmd0OyZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgJmd0OyBZZXMsIHRoZXkgc2hvdWxkIGhh dmUgdGhlIHNhbWUgcG9saWNpZXMuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgVGhlbiwgdGhlIHNjZW5hcmlvIG9mIGNoYW5nZSBv ZiBwb2xpY3kgaW4gdGhlIExNQSBpcyBjb25mbGljdGluZzxicj4NCiZndDsgJmd0OyZndDsgd2l0 aCB0aGlzIGFzc3VtcHRpb24gdW5sZXNzIHBvbGljaWVzIGNoYW5nZWQgYWxzbyBvbiBNTi48YnI+ DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEFzIG1lbnRpb25lZCBieSBQaWVycmljaywg YSBwcmFnbWF0aWMgYW5kIGJhc2ljIHdheSBvbiBwb2xpY3kNCmNhbiBiZTxicj4NCiZndDsgJmd0 OyBhcHBwbGllZCBvbiBNTiBpbiBmaXJzdCByb3VuZC4gRm9yIGN1cnJlbnQgZmxvdywgdGhlIE1O IHNob3VsZA0KZm9sbG93IHRoZTxicj4NCiZndDsgJmd0OyBMTUEncyBjaGFuZ2Ugb2YgdHJhZmZp YyByb3V0aW5nLiBBbmQgdGhlIE1OIGluaXRhdGVzIGFueSBmbG93DQphY2NvcmRpbmcgdG88YnI+ DQomZ3Q7ICZndDsgdGhlIGRlZmF1bHQgcG9saWN5IGNvbmZpZ3VyYXRpb24uIE5vIGR5bmFtaWMg cG9saWN5IG1haW50ZW5hbmNlDQppc25lZWRlZCBvbjxicj4NCiZndDsgJmd0OyBNTi48YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgSWYgdGhlIG5ldHdvcmsgYmxvY2tzIHNvbWUg c2VydmljZSBvbiBkZWZhdWx0IGludGVyZmFjZSB0aGVuIGhvdyBNTjxicj4NCiZndDsgd2lsbCBk by4gSnVzdCB0cnkgYW5kIHRyeSBhZ2FpbiBvbiBkZWZhdWx0IGludGVyZmFjZT88YnI+DQomZ3Q7 IDxicj4NCiZndDsgRm9yIGEgcmVhbCBleGFtcGxlOiBBVCZhbXA7VCAoaW4gdGhlIHBhc3QpIG9y IEtUIG5ldHdvcmsgYmxvY2tzIFZvSVANCm92ZXI8YnI+DQomZ3Q7IDNHLiBUaGVuIGhvdyBjYW4g eW91IGRvIGlmIHRoZSBkZWZhdWx0IGludGVyZmFjZSBpcyAzRz8uIFRoZSBNTiBKdXN0PGJyPg0K Jmd0OyB0cmllcyBhZ2FpbiBhbmQgYWdhaW4gb3IgaXQgc2hvdWxkIGJldHRlciBzeW4uIHdpdGgg dGhlIG5ldHdvcmsgcG9saWN5PGJyPg0KJmd0OyB0byBrbm93IHRoYXQgaXQgY2FuIGJlIGRvbmUg dmlhIFdpRmk/LjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SSB1bmRlcnN0YW5k IHlvdXIgY29uY2Vybi4gQnV0IHdoYXQgSSBzYWlkIGlzIG9uIGFjdGl2ZQ0KSVAgY29ubmVjdGl2 aXR5LiBXaGV0aGVyIHRoZSBNTiBzaG91bGQgcmVtZW1iZXIgdGhlIGNoYW5nZSBoYXBwZW5lZCBk dXJpbmcNCnRoZSBjb25uZWN0aW9uIGlzIGltcGxlbWVudGF0aW9uIGRlcGVuZGVudCB3aXRoIHRo ZSBhc3N1bXB0aW9uIHRoYXQgdGhlDQpzZXJ2aWNlIGNhbiBiZSBpbml0aWF0ZWQgb24gdGhlIGRl ZmF1bHQgaW50ZXJmYWNlLiBUaGUgZXhhbXBsZSB5b3UgbWVudGlvbmVkDQppcyBvbiBob3cgdGhl IE1OIGdldCB0aGUgbmV0d29yayBwb2xpY3kgYmVmb3JlIGluaXRpYXRpbmcgdGhlIHNlcnZpY2Ug dHJhZmZpYy4NClNlZW1zIG5vdCBlYXN5IGZvciBMTUEgdG8gY292ZXkgdGhpcyBpbmZvIHNpbmNl IGEgZ2FwIGV4aXN0cyBvbiBob3cgdG8NCmNvdmV5IHRoaXMgZnJvbSBNQUcgdG8gTU4uIE1heWJl IHRoZSB0aGlyZCBwYXJ0eSBjYW4gaGVscCBlLmcuIEFORFNGIGRlZmluZWQNCmluIDNHUFAgd2hp bGUgdGhhdCBpcyBhbm90aGVyIHN0b3J5LjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+UmVnYXJkcyw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkpveTwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJl Z2FyZHMsPGJyPg0KJmd0OyBUcnVuZ1RNPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgUmVnYXJk cyw8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSm95IFpob3U8YnI+DQomZ3Q7ICZndDsg WlRFIENvcnBvcmF0aW9uPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBHZXJhcmRv PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgJmd0OyAmZ3Q7IC0gRG9lcyB0 aGUgTU4gbmVlZCB0byBoYXZlIGtub3dsZWRnZSBvZiB0aGUgcG9saWN5DQphdCBhbGw/PGJyPg0K Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsmZ3Q7ICZndDsgWWVzLCBpdCBuZWVkcyB0byBoYXZlIGtub3dsZWRnZSBvZiB0aGUgcG9s aWN5Ljxicj4NCiZndDsgJmd0OyZndDsgJmd0OyBJdCBpcyBuZWNlc3NhcnkgZm9yIHRoZSBNTiB0 byBzZW5kIHRoZSBwYWNrZXQgb2YgYSBORVcNCmZsb3cgKG5vdDxicj4NCiZndDsgJmd0OyZndDsg Jmd0OyBvbmdvaW5nIGZsb3cpIHRvIHRoZSByaWdodCBpbnRlcmZhY2UuPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyAmZ3Q7IFRydW5nVE08YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsm Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyBUaGFua3M8YnI+DQomZ3Q7ICZn dDsmZ3Q7ICZndDsgJmd0OyBHZXJhcmRvPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZn dDsmZ3Q7ICZndDsgJmd0OyBuZXRleHQgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAm Z3Q7ICZndDsgbmV0ZXh0QGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRleHQ8YnI+DQomZ3Q7ICZndDsm Z3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgJmd0OyAtLTxi cj4NCiZndDsgJmd0OyZndDsgJmd0OyBQaC5ELiwgU2VuaW9yIE1lbWJlcjxicj4NCiZndDsgJmd0 OyZndDsgJmd0OyBFbGVjdHJvbmljcyBhbmQgVGVsZWNvbW11bmljYXRpb25zIFJlc2VhcmNoIElu c3RpdHV0ZTxicj4NCiZndDsgJmd0OyZndDsgJmd0OyBTdGFuZGFyZHMgUmVzZWFyY2ggQ2VudGVy PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IDE2MSBHYWplb25nLURvbmcsIFl1c2VvbmctR3UsIERh ZWplb24sIDMwNS0zNTAsIEtPUkVBPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IFRlbCA6ICs4Mi00 Mi04NjAtMTEzMiwmbmJzcDsmbmJzcDsgRmF4IDogKzgyLTQyLTg2MS01NDA0PGJyPg0KJmd0OyAm Z3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCiZndDsgJmd0OyZndDsgbmV0ZXh0IG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyZndDsg bmV0ZXh0QGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldGV4dDxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0tIDxicj4NCiZndDsg UGguRC4sIFNlbmlvciBNZW1iZXI8YnI+DQomZ3Q7IEVsZWN0cm9uaWNzIGFuZCBUZWxlY29tbXVu aWNhdGlvbnMgUmVzZWFyY2ggSW5zdGl0dXRlPGJyPg0KJmd0OyBTdGFuZGFyZHMgUmVzZWFyY2gg Q2VudGVyPGJyPg0KJmd0OyAxNjEgR2FqZW9uZy1Eb25nLCBZdXNlb25nLUd1LCBEYWVqZW9uLCAz MDUtMzUwLCBLT1JFQTxicj4NCiZndDsgVGVsIDogKzgyLTQyLTg2MC0xMTMyLCZuYnNwOyZuYnNw OyBGYXggOiArODItNDItODYxLTU0MDQ8YnI+DQomZ3Q7IDxicj4NCjwvZm9udD48L3R0Pg0K --=_alternative 0033307D48257834_=-- From julien.ietf@gmail.com Fri Feb 11 10:09:57 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 919F13A696E; Fri, 11 Feb 2011 10:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.259 X-Spam-Level: X-Spam-Status: No, score=0.259 tagged_above=-999 required=5 tests=[AWL=-3.437, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VUngUw3Eolf; Fri, 11 Feb 2011 10:09:56 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 7CD0C3A6860; Fri, 11 Feb 2011 10:09:54 -0800 (PST) Received: by ewy8 with SMTP id 8so1657671ewy.31 for ; Fri, 11 Feb 2011 10:10:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XQ93rdYEoIVaWimzcP8SXtLtR4zBzPShdZ7LQMMXENI=; b=qQ+h7rUuC40LhQ16wVsC4byRdiO8tHID2Zg/p4nNar1Gz1n9TJIUrJUKWGDkbGOQZw Ki+1Fl3r9g+eztUpMlrVyBSVNK11F4Lr6Nt9lopggDtJ+RfZHIQVKzNzps5v+jAxquZY FIitoy5kWLhLrrv/5fcgy5+bsPck4LkIbC+9k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wTeghlbANurlrEGxAEiyf9jctxHLGyOqeFrJC9JDF3mEYrqtXdWaUQfao5sJ4Cjq2z iDL6ZqYCpBtx0W+Bqu8oFOrKMhBQGgRpldQgPpTXvvS0IW37y1xEuIiUy9lcIpOMOjDo W4uhpFDUQG7rOYbMczbJcg3hcNupbfr5A41PI= MIME-Version: 1.0 Received: by 10.103.108.10 with SMTP id k10mr527279mum.39.1297447805029; Fri, 11 Feb 2011 10:10:05 -0800 (PST) Received: by 10.103.221.9 with HTTP; Fri, 11 Feb 2011 10:10:04 -0800 (PST) In-Reply-To: References: Date: Fri, 11 Feb 2011 10:10:04 -0800 Message-ID: From: Julien Laganier To: zhou.xingyue@zte.com.cn Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: "netext@ietf.org" , netext-bounces@ietf.org Subject: Re: [netext] =?gb2312?b?tPC4tDogUmU6IFBvbGljeSBhc3N1bXB0aW9ucyBpbiBk?= =?gb2312?b?cmFmdC1iZXJuYXJkb3MtbmV0ZXh0LXBtaXB2Ni1mbG93bW9i?= X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 18:09:57 -0000 Hello - 2011/2/10 : > > Hello, > > netext-bounces@ietf.org =D0=B4=D3=DA 2011-02-10 =C9=CF=CE=E7 06:27:00: > >> Hello, >> >> > -----Original Message----- >> > From: Tran Minh Trung [mailto:trungtm2909@gmail.com] >> > Sent: Wednesday, February 09, 2011 12:31 AM >> > To: Giaretta, Gerardo >> > Cc: netext@ietf.org >> > Subject: Re: [netext] Policy assumptions in draft-bernardos-netext- >> > pmipv6-flowmob >> > >> > On Wed, Feb 9, 2011 at 3:36 PM, Giaretta, Gerardo >> > wrote: >> > > I want to go back to the point raised by Stefano which was somehow >> > lost in the long thread. >> > > >> > > I need some clarifications on which is the assumption in terms of >> > policies in the draft. In particular: >> > > >> > > - Is it correct that there is an assumption that MN and LMA have the >> > same policies and behave accordingly? >> > > >> > >> > Yes, they should have the same policies. >> > >> >> Then, the scenario of change of policy in the LMA is conflicting >> with this assumption unless policies changed also on MN. >> > As mentioned by Pierrick, a pragmatic and basic way on policy can be > appplied on MN in first round. For current flow, the MN should follow the > LMA's change of traffic routing. And the MN initates any flow according t= o > the default policy configuration. No dynamic policy maintenance is needed= on > MN. This is neither pragmatic nor practical. An LMA has no basis to unilaterally instruct a MN to route traffic on a different interface, as the MN is the only network node that really knows how good or bad that interface is. If my MN is attached to a bad WiFi (say overloaded IETF meeting hotel WiFi) and a reasonable 3G network, I don't want the LMA to force me to use the overloaded WiFi. What's pragmatic and practical is that the MN is provisioned with policies (e.g., ANDSF in 3GPP) that indicates e.g. that WiFI should be preferred over 3G, and based on this policy and the operating environment, if WiFi is considered as working by the MN (not overloaded to a point where one can barely run TCP), then the MN decides to use WiFi over 3G. Based on this, the LMA should mirror the MN's flow routing decision. --julien From sfaccin@rim.com Fri Feb 11 11:53:07 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66CBC3A698E; Fri, 11 Feb 2011 11:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.375 X-Spam-Level: X-Spam-Status: No, score=-1.375 tagged_above=-999 required=5 tests=[AWL=-4.468, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AZ0KpDVeHLH; Fri, 11 Feb 2011 11:53:05 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 021B03A6B10; Fri, 11 Feb 2011 11:52:59 -0800 (PST) X-AuditID: 0a666446-b7b92ae000000a33-a6-4d55933a8ba5 Received: from XCH139CNC.rim.net ( [10.65.10.235]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 88.1D.02611.A33955D4; Fri, 11 Feb 2011 14:51:22 -0500 (EST) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH139CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Feb 2011 14:51:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CBCA25.0DCCD1A2" Date: Fri, 11 Feb 2011 13:51:17 -0600 Message-ID: <680854867F7FD04BB9B06EB8ACA8D5AC0601BB42@XCH02DFW.rim.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?gb2312?B?W25ldGV4dF0gtPC4tDogUmU6ICBQb2xpY3kgYXNzdW1wdGlvbnMgaQ==?= =?gb2312?B?biBkcmFmdC1iZXJuYXJkb3MtbmV0ZXh0LXBtaXB2Ni1mbG93bW9i?= Thread-Index: AcvJisdmR0D28hoJQNuOUXd6SFjnxgAi4dvw References: From: "Stefano Faccin" To: , "Giaretta, Gerardo" X-OriginalArrivalTime: 11 Feb 2011 19:51:22.0484 (UTC) FILETIME=[0F05F340:01CBCA25] X-Brightmail-Tracker: AAAABgAAAZEVkWKIF2VJ8hdlSfMXZUn0F2YabQ== Cc: netext@ietf.org, netext-bounces@ietf.org Subject: Re: [netext] =?gb2312?b?tPC4tDogUmU6ICBQb2xpY3kgYXNzdW1wdGlvbnMgaW4g?= =?gb2312?b?ZHJhZnQtYmVybmFyZG9zLW5ldGV4dC1wbWlwdjYtZmxvd21vYg==?= X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 19:53:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBCA25.0DCCD1A2 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CBCA25.0DCCD1A2" ------_=_NextPart_002_01CBCA25.0DCCD1A2 Content-Type: text/plain; charset="gb2312" content-transfer-encoding: quoted-printable Hello Joy, The approach you suggest is anything but pragmatic. Let me give you a clear= example. Many smartphones today are owned by enterprises and provided to th= eir employees. Enterprises have strict rules on how a device shall use the v= arious access networks and for what traffic. These are enterprise-specific p= olicies, not operator policies, therefore, we cannot expect any operator LMA= s to have such policies. Therefore, dynamic policies in the MN are absolutel= y needed. As a matter of fact, if you pay attention to the use case of 3GPP,= it has already been defined that even in the host-based model with policies= in the MN, user settings (e.g. enterprise policies) can take priority over= the operator policies. Therefore, concluding that =A1=B0No dynamic policy m= aintenance is needed on MN=A1=B1 implies that the current use cases (includi= ng currently commercial ones deployed today) get excluded. Cheers, Stefano Faccin Standards Manager Research In Motion Corporation 5000 Riverside Drive Building 6, Brazos East, Ste. 100 Irving, Texas 75039 USA Office: (972) 910 3451 Internal: 820.63451 : (510) 230 8422 www.rim.com ; www.blackberry.com P Consider the environment before printing. From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of= zhou.xingyue@zte.com.cn Sent: Thursday, February 10, 2011 5:26 PM To: Giaretta, Gerardo Cc: netext@ietf.org; netext-bounces@ietf.org Subject: [netext] =B4=F0=B8=B4: Re: Policy assumptions in draft-bernardos-ne= text-pmipv6-flowmob Hello, netext-bounces@ietf.org =D0=B4=D3=DA 2011-02-10 =C9=CF=CE=E7 06:27:00: > Hello, > > > -----Original Message----- > > From: Tran Minh Trung [mailto:trungtm2909@gmail.com] > > Sent: Wednesday, February 09, 2011 12:31 AM > > To: Giaretta, Gerardo > > Cc: netext@ietf.org > > Subject: Re: [netext] Policy assumptions in draft-bernardos-netext- > > pmipv6-flowmob > > > > On Wed, Feb 9, 2011 at 3:36 PM, Giaretta, Gerardo > > wrote: > > > I want to go back to the point raised by Stefano which was somehow > > lost in the long thread. > > > > > > I need some clarifications on which is the assumption in terms of > > policies in the draft. In particular: > > > > > > - Is it correct that there is an assumption that MN and LMA have the > > same policies and behave accordingly? > > > > > > > Yes, they should have the same policies. > > > > Then, the scenario of change of policy in the LMA is conflicting > with this assumption unless policies changed also on MN. > As mentioned by Pierrick, a pragmatic and basic way on policy can be appplie= d on MN in first round. For current flow, the MN should follow the LMA's cha= nge of traffic routing. And the MN initates any flow according to the defaul= t policy configuration. No dynamic policy maintenance is needed on MN. Regards, Joy Zhou ZTE Corporation > Gerardo > > > > - Does the MN need to have knowledge of the policy at all? > > > > > > > Yes, it needs to have knowledge of the policy. > > It is necessary for the MN to send the packet of a NEW flow (not > > ongoing flow) to the right interface. > > > > Regards, > > TrungTM > > > > > > > Thanks > > > Gerardo > > > _______________________________________________ > > > netext mailing list > > > netext@ietf.org > > > https://www.ietf.org/mailman/listinfo/netext > > > > > > > > > > > -- > > Ph.D., Senior Member > > Electronics and Telecommunications Research Institute > > Standards Research Center > > 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA > > Tel : +82-42-860-1132, Fax : +82-42-861-5404 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_002_01CBCA25.0DCCD1A2 Content-Type: text/html; charset="gb2312" content-transfer-encoding: quoted-printable

Hello Joy,

The approach you suggest is a= nything but pragmatic. Let me give you a clear example. Many smartphones tod= ay are owned by enterprises and provided to their employees. Enterprises hav= e strict rules on how a device shall use the various access networks and for= what traffic. These are enterprise-specific policies, not operator policies= , therefore, we cannot expect any operator LMAs to have such policies. There= fore, dynamic policies in the MN are absolutely needed. As a matter of fact,= if you pay attention to the use case of 3GPP, it has already been defined t= hat even in the host-based model with policies in the MN, user settings (e.g= . enterprise policies) can take priority over the operator policies. Therefo= re, concluding that =A1=B0No dyn= amic policy maintenance is needed on MN=A1=B1 implies that= the current use cases (including currently commercial ones deployed today)= get excluded.

Cheers,=

Stefano Faccin

=  

Standards Manager

Research In Motion Corporation
5000 Riverside Drive
Building 6, Brazos East, Ste. 100

Irving, Texas 75039 U= SA
Office: (972) 910 3451 

Internal: 820.63451

: (510) 230 8422

www.ri= m.com; www.blackberry.com <= /p>

3D"cid:image004.p=

 

P <= span style=3D'font-size:9.0pt;font-family:"Calibri","sans-serif";color:#4F62= 28'>Consider the environment before printing.=

 

From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] O= n Behalf Of zhou.xingyue@zte.com.cn
Sent: Thursday, February 1= 0, 2011 5:26 PM
To: Giaretta, Gerardo
Cc: netext@ietf.or= g; netext-bounces@ietf.org
Subject: [netext] =B4=F0=B8=B4: Re: Policy assumptions in draft-= bernardos-netext-pmipv6-flowmob

 


Hello,

netext-bounces@ietf.org =D0=B4=D3= =DA 2011-02-10 =C9=CF=CE=E7 06:27:00:

> Hello,
&= gt;
> > -----Original Message-----
> >= From: Tran Minh Trung [mailto:trungtm2909@gmail.com]
> >= Sent: Wednesday, February 09, 2011 12:31 AM
> > To: Giare= tta, Gerardo
> > Cc: netext@ietf.org
> >= Subject: Re: [netext] Policy assumptions in draft-bernardos-netext-> > pmipv6-flowmob
> >
> > O= n Wed, Feb 9, 2011 at 3:36 PM, Giaretta, Gerardo
> > <g= erardog@qualcomm.com> wrote:
> > > I want to go back= to the point raised by Stefano which was somehow
> > lost= in the long thread.
> > >
> > > I= need some clarifications on which is the assumption in terms of
> > policies in the draft. In particular:
> > ><= /tt>
> > > - Is it correct that there is an assumption that= MN and LMA have the
> > same policies and behave accordin= gly?
> > >
> >
> >= Yes, they should have the same policies.
> >
>
> Then, the scenario of change of policy in the LMA is= conflicting
> with this assumption unless policies changed= also on MN.
>
As mentioned by Pierrick, a pragmatic and basic way on policy can be= appplied on MN in first round. For current flow, the MN should follow the L= MA's change of traffic routing. And the MN initates any flow according to th= e default policy configuration. No dynamic policy maintenance is needed on M= N.

Regards,<= /tt>

Joy Zhou
<= tt>ZTE Corporation

> Gerardo
>
> > > - Does the MN need to have knowledge of the policy at all?
> > >
> >
> > Yes,= it needs to have knowledge of the policy.
> > It is neces= sary for the MN to send the packet of a NEW flow (not
> >= ongoing flow) to the right interface.
> >
&g= t; > Regards,
> > TrungTM
> > > >
> > > Thanks
> > >= ; Gerardo
> > > _______________________________________= ________
> > > netext mailing list
> >= ; > netext@ietf.org
> > > https://www.ietf.org/mailm= an/listinfo/netext
> > >
> > > >
> >
> > --
= > > Ph.D., Senior Member
> > Electronics and Telecom= munications Research Institute
> > Standards Research Cent= er
> > 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOR= EA
> > Tel : +82-42-860-1132,  = Fax : +82-42-861-5404
> _______________________________________= ________
> netext mailing list
> netext@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/netext
>

-------------------------------------= --------------------------------
=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_002_01CBCA25.0DCCD1A2-- ------_=_NextPart_001_01CBCA25.0DCCD1A2 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAKAA4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDSu9Nv V0vVpbjQL2KfU7xR5T6qqmRclsrnhecDFbGl6hqL69Noem63ZRQ6faops5Y2mmiYBQdz8BuSR1qD 4pxpLdeHo5UV0N2cqwyD93tXexW0ELtJFBGjv95lQAt9T3oA/9k= ------_=_NextPart_001_01CBCA25.0DCCD1A2 Content-Type: image/png; name="image002.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.png Content-Location: image002.png iVBORw0KGgoAAAANSUhEUgAAAIoAAAA+CAIAAAB7vhRQAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAIthJREFUeF7tfAeYHdWV5q1b8eXXudXKoAyIIH1IgESwMTKDSDZebNKsZa8/ xh8MNgxj1mYxLGZtgseDDcwABsb2YH9ggglDMAiEyCIMEkkSCOWW1Orw8qt0b+1/ql4/tbJEN9t8 OxSPp3rVFc+555z//OfcUtjwLZyxAB/8I8ObUMLfGmNCYYES/Yq+63/ETyz1LdH6Hvbh4RXCwxX8 I2vrOH3tSNqK1W2X7j/78Ill4JWj5x2epaaeSPZ1qdPPUKpDs9TUs93JdrhcXflDc8X/T8+CAQ65 QWef7dJ/DbV+mf4hqjO2beNnexP7evbhtJ6d7xGOLc30pKpLJjh5nMEtsBw1kIH0hfRZUGXS7fej kUMV0elxVfyQpBts9wZ3zaE9etAiGPTtbIsciqIFwXg1MbtpkukFYkj8mxJIJv1AQtt24FUDv2rb ObfQy7xe6Zajm4dawrj0OXRyw68euBQasByxm9RzmN5wZHysXvZ2Np4IBezPgt0FziMVnFuRipRc VVTF80XOlJ1Bpada6HKKBSagGjjW2ngYkmGxP3e5h32H2dlCfpFrCWOOYgTsEKO1mZmKH4TOTYm+ EZbqPyHpaAtW9rBPwBQ1YDzA3gHgGcdvEQRCqjLgMlClbFStsWa2XUvEGPdEFffgq5zJz5Ny9ns4 DtGgqJ0GFiOZyZgD7xJ6mIRkp6cnZ3wdGovA9iAWIHboxYdiAtK1VELpS5iKpsSEwt1wi8bzOlsj c+9UOrtxB3VXO4gLD+Ghw2o9oavCHfj0D9lDo9QPNVpMH0Kt+5pP+bBwaQFXuEwF3GO8wgKLC2jL NgwWuDGcXdU8FQZIMc5PGNaIRNat5l0W+NGVDTJqstPo+vQP7pTEFW4kkBnZfKTQMEnAV/jvtsM+ 5c3XDxtu9URZYaSeIGhXE1P0BtUVUuHkmsLH/bQfWA9XpMG5w3mF+xlViWvcF76tsWygWK6iicDA h3ELu5k8meXpXr+UIzkbiFdhwqzhJAFpJfSoFMLwk/TCSUHQN6kpUlWo1iH2jcOnnn43su2BJBsX bxwDD+d6gabCfsIIM7gPsxVeIbGKRilMRfV9WRIycPA//Qefx6AxSL3ienHDsiXbKMsMcI90QzKH a+y3EODwSAF0y+H2yHhgaBBjDaX32xp8Nv40WA+9n1BosMa60/EDfD0g3DGZ8Qfb8ELMh3qG4FqQ shuoNqEJdxzQhuQbmjsc3/cRegLmqTBSSBF64tyHm1OCSlJ9Nd/TY4uqChjJkH9BC+CYYNyBp1Rt GFWAw30xUPCRkgaqB9oibipy24NZhlU90cX7zadZs2anx4wra1wEQ6QeISFftQwHJbyRrl9oG1ue d1qHLXPkqHTJJf4AyStCCkVVgRrcGN/Iq1vsfCEIDENTfYGI5UFRAVd9U2B3qZYroq9Q6S3wrm73 veV9FQCbmslggJnYVVFsYMTBaKV+7LCqZ8ATYLCNt1IzzI4OV/dcT+j6oK1HQKaA0KriBBwDPusp XVOP8A6dAyvqczyLKSaoPWgoCuTwcnBkUmM2l+vL+T78TSXlQTVkPdAwTDGkalVV182UZLphGlXb Xdvtvfpm5ePldsmDyQB7AhpWB6a6g9HT8MWe7UeIxdhIJd6hpmMe/AYH6Br0wAkQtxURI96Ae8DW Us1PODiebMhJ3ZXCkkEyCDRIWUodbiwI9EDRmQBE0asiKApfKpoCG0A2S7icQADpDw7LF7YD8qFU KuZ5UMlkxWEHJVoam/K91VK5CtRJHhPLYOMOneNzpJ7RVqZNTZquj2GKYABRcNFPXRMHF3lBCH27 TzjoMbjDuE0SQcZEcEKEyEqVJlMxlitSqJrFD5jabCSQgSIrtSBvsgYcgDPjULg7rGOroRY1v1fa Piwa8JwjRgUCvo3DlkhfgiuGYZIqQ3ARuKJcqI4ebY4+INFbKG/tiTBBPNTPYIHccKonKihEfiCl 8AOtxgbgYMQLxdAgD8arhi9U6MV3VaEHXpwMS0V8hyGE3xwUgIbwLuHpdQQRgW0QvYqggi8SO4Vw 7CVjbuClmt2JByX0uOv7psI5Zy6cFwcgQKzDChcC+ADy17ijyB7XJkRNtAQCIWmcSV1wrGnwb67n wbp0AyRUoPksnmQ9hUos5s6c0dy92d7SjcdKhuigPy59Wgc3aA//aS/cH05rxycUtYHFFV8Knfu6 qgeq5SvIUDyOtF94ug8MnILiyEoge8QDaIf8Hwa3RtEBnBoxOIFKPo1clMI0IQIV5J3p+yMVpsaz RT21STEKwquqVO7TVaFxMAdCVel0+EAd+AluSbU8FhPc8EjthkcFKD1wLGHrim0EXkwNDEjOR/YM olCtYucYCxzJ8uUzTkq0QjWspCiDhW3D7NxqGV2Irdu4OUrPxMD7g/lHFAiEJjFylbSjxzyzymI+ h7tgtpn3NN/ThVB9T3U9zXORXKq+JRwdQV1xFcVD+AZdI7jucoOrCDMSwVyyraMPVEaNM1y/xJGH 1vJ/KBXATYXwWYDBrsPwYLalwO/yq74BuEAWFLIE8Lak0uiDhf5FPoXxIaFr7EjUkRRBIq1WpbFq jT0kzm04rYd8M54vhKAZNW4oOp5cwsErAnIXGtM8riNmMAPS9aRflkKr6pqrKRUDOhS26dsxz447 +Pa49FWiviEWTxGu6vlGVcR9G5ahStf1PSeTbGZ+UlbjikyhxsAk4K8bSA80HOAD0aZS00AHBEDj vkdWqbrIh8APMFWDqYa8QY3TIe3U2AJKU8MclaIY94uFypSpMQMYe7tM6FM6mV3HnjBM7t8y8JD9 PRxjZHK8oVVJaJTBBxY4A6l1uvl8YPeygs2KCVMkY7aluczVbGFrgYEYA0emBDrkhKFb1dQi1GUq qZhiqm5cF5bhW7qIm25Mh3SrmUbnoMMbzWSFaDfdZLxk6GVVRX5FsYch52S+DACqwTKIQmB3o0Jk IPIjlCkYJwQa4P52LGiQI4U/hFtEhFQQmngAbWcakytXy3x+CJzbbtVwySWXnHvuucuWLbvyyis3 b968V11FKom+ETCj/esr9cN1Xfc87/jjj7/22muF5137s58tfO45uK1TUpNbhaa5wtWVmMs3id5J X/nKOddcVu3deufPfsRWvP+tL83u9HuThx1+0FFz0uMPhC8KwDyHIAkykqZR2fTxsof+zV2zrNkS ik+igWB9jsCD8CBEbOv0WY026wJe84HoRIoJi7wnRC8VDArHAVz2pes7rreqVFleZFqCIfkC6Pbh vuC5iELYUVxECwmDaa7PmerD0MkejWzmwSe8d5ZW9iq0ve6w3fXqwh05cuSGDRuig2+//fYLL7xw dyci/xsqIzoWgEgigMOlAzgRbagIsYv8edGiRccddxz2f/fdd08+dX7v2nXfaj4sWXA0wSqQh+0l Jh1w5ZN/yh7QhH1eeeTeRy757twJDeljjpn1kztNI7u7mym889Qj/7igI+GbQGUE2zSHJRSNV7zu bIeceEhDNegBVgMhEAYScNXEe4LlZICCBOXBw6LOwPLSX1u0t/ZWK4WgDHSQYm5UaoiiDT1tffzB h4XqUeGKgScxZmRgJha/pS5cVNir9Pe6w65jz4QJE3Ck4xAuPO200/ZwloGGgnUoA9/QDQ1eKXep G/zJNMEYMtfxJk6YOHnSBHCKloockGhI7gc5Zp/ygwXQjY0kL2CZTEvLyLEl3z/2ssugm4rwkTaW A4YPUhhHSlfKcohgY9kW3UggaxeSu4HuKDGQXhwkmV1pa0xRsMAVgIwlyn40rNCIQBgQJ2BVIcuB KMqgLJSCqdlTWpMzxzbMmtg4MqOVy6RtSrAoSwrNtT/ehAEozD/DqhKNT8L+pOohWbZTDyQbGUEk 30j0kSh3ucyePfsPf/jDzTfffMcdd8BfYZ9Jkyb95je/ufXWW2+77bYzzjhj5yA00PsZJjJ2ZCe8 mSWE42JEAgP1+bmDTjnuhL/7ZgkZkabi6Tdt3NKzsThu9ldYehJaOpBn6lxJKLALFuPM5MBnPEH3 6L/86P0lpxRoBhg0Qm4YzcB1fgWxJdVgSkgf8iMyvErx3wdmxpBA6FJNRdNBgRKoJmihigpz+jKB 0Z6MHz65beqkNLIk4YZZrI6UGfKJKGtKlQNVEMGNcwVSU6TnMcM0C7khCDx4JAS97ZZIMdFioHTV 77UG7qRpGjgsbDn77LPPO++86E8IVIlEAkq66KKLoi3z589/++23161bVz82Cjx1xVNXIIjgwBtj NRgeYJPquU4P87932/XYBzaR0Hi5u/D23XePMTZZo1sYa3Q4s+CNyptfeuwPaQvjGDCaiqJm38au F1/rW782kY2XNLNBagm7xPXNuZjVUI7HzSY37sVk0VOa/HJb0vogxpSylq3qNpQUVxJWscLUWNnw dIyIKugcoSRcUbGkV0ynSoc3j2hLO++95+Rd7qLcITQL+yHN8TQJt2YGvNJgsRxXBQxXseJVuOgq PbQK2Bj6dpgTlkho9QE6bty4fD7vum61Gu7dbxUDRb0nYL1DnK8fFl0Gy5w5c+obFy5ciPW5c+fW t7zzzju5XA66TKfTqVQqmUxGutm2UAWOJZAwuj4GpC3FSrbm76+/vnXMKOG7CYWw7FO33LVy2ZKx IxvdCkVancHI8izoefa6f1zyq58sv/nKVb/6nx/885Vv/flud8P77UY1w6oqnQnQwRRmCsEMGVRG r8TMXNlk6P4wp33VaZjRR56oL+EmY46le8W+WLkczyUwImzdaxhlN4+WBnPVzbrWKxxghc0dCeew qUaGx5Uyg2eErbsurMTlQQz9Pp7EcwW+w0gXaDXx+KYuWCF+CoSGY489FoO+Pu6jaB2LxW666aYH H3zwlltuwfpAqxgooR2tZzvx7eZHHQ7g7I899hi0tWXLlieeeAK7P/7442vWrMFtwWgQ/wuFwr33 3nvggQdCMbAtgMBot9pC0TZoDCyffFDQ7RemHTj3lEu/g3IPfpoKy6/e+O//++eHTWowdQr1OKqi aCkFoTirptvMVFzzqokA7t7xrSAh/JhbQRZKgV5Nu0q8RyDB8SiRSsIdFvq4Vu7155zw7U9eNzZt eauD61rVBYODQJVvyoh8YSxT8pVKZvp3M+MnrH70iga9YCpBoZKwjfZ4blU2npk2ofn1FR/mcn4C BJHoyeWDRMIzYJEcdgluuyHQSoKXN2+NdedqTuiCCy4oFouLFy+GAqAGGEqkCQgNIeDQQw+1bZtU vSsvRRt3qQIYAc4YhaLe3t6mJkJQ9YX4qtAS68a7B6UOxNZQ3qmnnoqdX3755aOPPhor0N8V37jA +evbqCav93v++ZGHDp5/fCGoJDxTNdSfnblgyV/uOWPGxI50Z/vJ3zrk8ju3IoEFBPCdJX+5N2Px JDyG43dvXP3BS/e1F3qaglLJ8h0lqYlMsSLTR88YP+uYl//XT6af9VUj/Xyx7cBEdsS4GdcrpTVa Kub16B8+d1mu9PERx/46M+O0/IcfaIl1nyy86oDjb0uMP6n02vc+WHhnE+oLjceMPnFB570XNZzw 3arrP3rfnbNPvPjIs35Y6vn4X2+4elP3m9847+pXX/9d58fvn3POL99a+uC6zldfeNl8+XX1xUUL m9qypmn97ne/++lPf3r55ZffcMMNn3zyCXz+hx9+WA8QkWIiSe6ch+zJue3O4iLdnHDCCRgCOCOW 9evXYyN8XfQTC1IlGE2kSFwYS7lcBo4YqEg4Hl3T04GV4tYWN/e1y34A3TghSwrdPPfHp/7jL7+f bna0N8UAq4SmIoVuQwLjVZmoHnnWeZPnnz/yb84de+aCGRdd+zfX3r3V7OjjTdJooEIA/IePdLaY POLY9JxTpl1xV3r838Wbz40Zh6DMU8h3Lbn9HN+0EtNOGTflv8cPmvv6Lcd0vnd7YswpxULQu3zh +rVvvfPSbxMNqoyxiuUnRx+/SfG9bCbPqvNO/f7EE753yYJZD/715n+4/r687Y8Ye6QWz6LY0zhq rpYcnSuZi1+177jt1s7ujZMnT8HDwGK++c1vfv/734carr76aviPMWPGQHRQSSQNiCuS5M6jfO+x Z+djopg0b968+p9GjRrV0dGBGFPf0tbWdtBBB0E9wA5nnnkmQAT2uf/++weeDXEUi6mpfTI/8uBp Z//wQoAFz7PhvsrrCndcedME1pYwAyvmoXsmRN2oNIBh1oQWp/zRd8pS5hl6A5hvtPBMu6PFcoBd qgGA35JJbl21lBV6R8w/3+9cGp84L94wS65eCdY1t+lD1tnj51ZypzvR0rJl49LCx8tXvPGIw7oV UZGsV7ELdhFZglJBkNVitm30BAkHVIWTz04ZtfI/n1j60ab/WPgo4mZTi1IpF+ySU0AEEjyRbHn6 GYo6X5p3wrL/XIqVp556Kh6PT548GYEAP//85z9/9NFHSCujUbtXemW/Obco5cTZx44di2/YxIoV K6677rrOzs6pU6diS6lU6uvru+qqq3BnEydOhG/FMOnq6gJMqOumPlKASU3V/JB1XXzlFU0jWtEL nQDKZcojt99TWd0VY2oyGVNiPgqXUXW4rGkO131gaSOua3GD63HGE4B5ne/yYpcKrg68CogWsJzg 4PxqYfOaw78yb91jv060x9rHN9tbl6LFIBMXforlWNrPWqs7l7ccMKX5qIOnzV9gsGQllgaCzCTT HdlpnqubpsoKWjyZnTLrghEjTner0worlh4ye+bXvnzet8+6xS/1yl6eSKgHHzF35qy5B0467LXX tq5cRff51LNPzvvqScfOnXvWWWfBMpB9A9lGXAnG8fLly7EC5LZLixk4gveknl0eXM+NAKBhEFDA UUcdhZiPkyIBymaz7e3tuDAuj4j34x//+IEHHsCQQST75S9/GV0YRgYUhxWPCVPVenq7jxs5e/rZ J/fYZQd2oirvvrj44d/8FrpJK4lsOmNTxT9MMZC9BgJsqKmUtix51l72vL76VfXVh1645m8X/ury RGltIy/rYFXIm2sYFvFEYuVLi9gnL/nFNyufPCr7Him6a7n/hsx3gSYz3bfHVlZobz5eevP+w8++ qjE1RikuzijehvWLY8m+KV/+uiurSECLq97a+swVo0YHPfm3mrPjVr/5l+L7//L3V19+4kktN143 R69WH/njvx4/98QfXn7PrTf+/JZbHgjrV+kf/cOljltF9vfGG29gvD700EN4/Oeff/7EE0/8+te/ juGL7x0i+s5eClt2hAYRKhsIDXp6epqbm3c4uJ7BDNyOkQL1YAvs6cUXX2xsbIRW4OKifXCLuCes tLS0ANRNnTLV4Uo1l7vizPNu/OOf0iNSwDQxeDCVXXHo8SuXLZtgzBLuu0d9mTU2+ZVNW1pPv/jI y35dCWQcBOTWj6+YPXF8BmQKM5PMSmttaCSE/nxWVlFBQx+BAWYNjQOb7E0dY+MTJigAyEBLqay+ vttrzqRjmlLOF7knsxljfc6l3ilTR3xpbNMKKP9t9VWdNbQhX4kVS23ZcUcEo8eNGTdh9dNP+92L uyt9z77FPiqw0WNYm2n2BtbmnurjT7o9pagTOR6yCvtEuNUx8C51g43bWc8Oe0dObMdkJTwTNkZh PyLWsAJ/et99990ZLtAKgBlsCx7v1XB58sknr7nmmugmIuwABxTOVgsuvOonqZZ4gN4k4UM3z/zT 799ZtqQ51l4RjmUAOVSRigegqsGWIO8BTEaJLmmMSLJRjfrYDpZJQw16V9HvdrUcHKOCD4KsCHCY 5G1ZbcKYrK5a7UmtIROD7Y1psgxe8AKU5rjerBe4bGrVW8arrR2ydQyqgDyjqa3tjAakx3wH8xry SDvNwF/5/MPFrkUGz3e0xKcfmjh4mtbYmGbxRE+X+GCZki9FbW0GSNJ91E0kit0pJtq+nfUQVxQu 8JKwRMQuhA3YJkIL4lvtgDD2gMl++OGHB0I74EXkQPWLwVBgLplMJmJIK5VKhFVwTqSosC1A/kqA Zmque4p0XMQczrXeTZtPPXhmk6eaepoXrAmZLXPmsVhQLazrbv3ad+Zc+lsknEhhVLf04M8vb08G pvT8wLLVpK76xc2rty5/O6N5BuoC0A9IHcn1ZG7q9HY0gQhWRo2Oghh1doBfhixR3AE/SLRtWGkj n4jqAkSiSir3oNMObQ/CMHNVTzPigeJlFAdO2U8k3umyXl/lbtiiLH+/vHK1ADVIsiZ2G54NKerQ dFHtQj1021IioqxcuTJaj6xkhwXbH330UUCy+vbzzz//4osvBlIAkQoG4cYbb6z/qW6UdZcIjzxz 5kyU16AuI6x0+YjyjJ9+xunPPvJoFnWYAKVKeXIzP+OkJtfOeT2lscd89ZjrnvQks9FfoCmGhwoz ckFwXgbqAzT9I8i998Bti3/7i7Y4GhDQpqHagTZiUmXC1IRQ4HeIXkG3GjVEoREIoAktOCCow177 6AnBMAUijoInNutIVtFT4NpqApexHbB4fialVCt9+U1+6sEl+r2LenttaidFGtbfUQNelmrtdbEO nhfdbb3nvffeQ9iArDHksURmCFVFJFKE2feMC+vZK8HnfrwX6eyuu+5asGCBg9ovknwfHWM6fN3d /3bPd769AGVGjSlVXIqJi6am5s1q7c11qV6p4mS/8/RaxlO4gSoGuIJ+DrR84MZQmoPrY+iYEl1v 3vnd+RmlZKGsoXBHGplGnkqDHi0rHNU2dG7gQmCqHfTdEIEJSyIvS2U3PA1WoEEk26iwGS4VSVFj 9aQjuOchkpXjQamMaxWsjj8tk0+v2KQoTeSlyW6gmGpYZajVTfu7RAeroN2qB0wR3BfC+86mE215 4YUXIpZ6v5aoIATQ8sorr4Derh/712eeOeecb/V09/T3iNGsrF/NbxqnWbbmgKdcv6Y8/Rs/+NKl NyHFpmaz/gkDEcePb5TVVj1z5+M3/ag9IQ3pUREUNuamBNqq0UtFHVGWRCeQgokj0Ca0r1OhFW3y YUEP56BWQ7UY6BW063Cpc4E+RSpKU+sPlYKAN6pcV/qsUfcuLT+zYiPjiHugjKAbKnyE56g/ECh0 3ONgvdyeitbTp09HugvcjJrCQEYPtwC68xe/+EVEFuzXUudukaldfullM2bOqLru66+/dt11/6d7 61aiOjCqkUVLFRbw+79tT26WOQ3NNiVDptcV5ZTj5h987MnZtjEoJWH8U3CFQUNhQm54/9XXHrpH K3VlkZgi+aSeNNghXJbLVJe601CLkEZoRqH5hX+l6BwW2cLm26jPEBaEPyFOGqizRlP4EaE0VuKi hDvsMttuXbT57S0guUP5R1oJvzG2+gn/qEvsM7OeutCBlevOLdqIxwDaxgoqDhGdt+8Ljo3AXkR7 t7a2wllFZ7NUtNVIZhmq7XgBnzxaufFL6dQGc2tS2mYhBipfFD1cT0tyoxFhwlKQ4viOqrhaTPVB 9FQ15sdVtHNgRJOQMewD1ZMK2jYdKIZLdIaaauDBmKgHETMLSC31MR92LUjM/DJRoGZalfw5tgBN SLRjQ1ueGbhcMzay5hueXr2aGIVIKaSc2hQT8NaRTrazpH0Xz4577rYNMUJx2B35HVijHZZIxDCp vULDHS6I0UeSC102QFKpXI6qHXA0VMDEwIVZcBPczdwpqUOTLvcMYTLHLVgq8lRmIV5wjeYOeI4m weej3uMrvp3Ah8uYTsM/RCLRKKKCBbXUUhMHSqNgFKi8GfXcADsQwUCSDGNjBN5gjGFPPOKNROGW urDJ0+G+0HmCmamSW6tyyqKPAQvgvgwUW8Nz4BqYCUTqrdlLZDyDXnarnj3LvU597u8NRBqlZfv7 h0+oEbbkX1AIFd8Ynx6ZopmFQeAkwcVxboOhpuY3TP2BP0OER20aokShE3CZOtSonR1yrk0oDZEY NRBCC4C8YeCGUqhmjvYb2nFgX1RtKhXabRBLaGTi7CgQoaSAO9AxprioAGmLVPq1TnfJRqQ5uKhH o6HmxFCKGzAxdSh0A9nuN+e2v/r4NPsHTloLWhujgEfN52HvX1hLpr4NiL023CF9GAT1SpMxh/Im kWMc1z7hBsqAqameWgFqT0wH7HLaHTWbUgsp4TuGVkgXGB1pEGVCMClNL0tjyXJyxeGJqLf3M10+ l+phTmNcTxqqcF2yFgx/ShbDcBItxDhEGqhJPPRRtclq0Xr9U1ujM0TaCw/ejVAx0xRXJI9I14Ql oU0XU1DRJEzsMo8n31tXWVFEuAV2qKGG/4LqYe1JNaa6od9AdzqaLWha2mcqCDo58jD0g8LOwuhI U63IdNBaj0urwkxWldSTb28Jx0RUZaZb+kxv6/NoPYiHk9tT8cCl8Rm2n5GtgEUboilnu1dzNIuH SGFUMAAQwDPZmM5jWGVulszWB1/bsryMGIM/omJO0/2HYg7Pnkbd51E9lspGpDCp2oagPLAzJLLI i4Vpyf43GO+32RHAI0LB9QMtnoIz09PNS9fbr3ycD0+F8QP/9v/i5TufR/XENK0xoWnCQcZBegnn 54KWq01Tp7ewRO2A+/DZjesByhrwGZhAApeHs+AolGmaZRVtv3lEx5othftfWdtFExl1pmtoBKYe s5qqPkN88HlUT3NSbUxgZrTqCY8SFHr/HmgwmuVObTlIt8IZBXv9EK+w42Q6aubEpDbCz9SESA6M 3jyBJQSJ4QxTmiCEpnaUbm0/iDV3vPJ+5x1PdXZiAiQQgRrH/Iloqnyolv4JJfttoft0wGeo+X24 PooUrop32eAfglOwFhwkTplk/Y8jUlUPbZmUH9IMjoi/IcQcvVxg7wuxcEBp1Ly5484wPw0MOSZU QTFq2N4JIhA6ozQV/W0o2pTjeM9OLF7Umx/+yPvTErSbQyMRP0K4IZLaPt3H3u90T3sMr3ow4Zfm tuE5Q+4QFRZ6v9cPDmv8b1PNzlzJMjC/wKf5GSGpFQIq6h/Z90f2qId6Z0GG7dUhpRBOHg1nFRGY Vgi7SdVMpnwttryr+tLyvufWlqm3g6ZoDZbf3Pfbru+5H4/6Kc6+50MigVMUpv2QSSgWCDHGrjmx fXqjV3YEKnSkHnRab+MYIvZx7wsN7ZChJG3Wx3nt0MAHhw1DpDwWhTcYKOgZaujWrVhFUzeUtcff Lby+BjVYcmJgb3CCWqPt3q88lHvs06MO5QUHnAtPDgGGAAhvhkJRi2azYWbUP51/gOl2YtYvKmIh /4XcEEA2OpLKnbu5n+3MJFKjRTMUIo9U90Y0KnSwAGin51rALa6iO8A0Y0m7ai9b37ukq7hso7MW 0+dIL8hv/BhoHsyG+IyksMfTDqd6UEvB5UOPjrFrYaaHIpzpTea1Z01XeteB90eiDhqSwvu2F+aC AcP+FMe38fgDifxI2VFdAKQYAj0B8tCWAAKiCEYgA3K3XKb1VN28p27I2R+u71m9tbwRE7BCeYVn xz7Ru1eiK/6Xc241QYbCQzEGz+8fPSZz5swDZK4rbBbpb9uKvFOIssMpCdgzfBsBRaSQ8yfJh6/t ILlGTg1/V3y814o8WFgbQPSXCtJMcPA9Za/L0fpcpTufhwvDZJV+Ugi0JyIizu/0GyPOhgkNOM8+ Nd8MrY0Np/VQGQE1mfBdkf20vEhREIBDq72FY9foaHtfVauGRd6r7uFCnUQGSm/co76J6N0U9IGJ bHvlAM2BDKdqI/5jwjFKqVToxFyV/rYBGhAYDUMzZWe/9De86kG8wTsd0BZDEYjIf4A3VEprXPIu 4Wu9PNnvgequaNtK/cC6A4xkQtojo8MXiG56HxL4NUzLA69G7zUIVenR/AjaGcU6HIHEK+oerpdB 90u8g915eNWDwU2tLQNielQfhsevF6IG2g+Jr//NuRHii+4/Guh1UBdtDDtwavXQunpCpaKQjf7m mm2EnEQIOcLXwVANIzST8AbIc9Yx4GBl/cXxX0jgCwl8IYEvJBBJ4P8CkLsiseCTLsQAAAAASUVO RK5CYII= ------_=_NextPart_001_01CBCA25.0DCCD1A2-- From zhou.xingyue@zte.com.cn Fri Feb 11 17:42:02 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9D9E3A6A50; Fri, 11 Feb 2011 17:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.052 X-Spam-Level: X-Spam-Status: No, score=-95.052 tagged_above=-999 required=5 tests=[AWL=-2.262, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0z3Dp1H1fnWk; Fri, 11 Feb 2011 17:42:01 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id BEA4C3A6A21; Fri, 11 Feb 2011 17:42:00 -0800 (PST) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35103502467742; Sat, 12 Feb 2011 09:40:09 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 84746.6929952697; Sat, 12 Feb 2011 09:42:11 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p1C1g73D024930; Sat, 12 Feb 2011 09:42:07 +0800 (GMT-8) (envelope-from zhou.xingyue@zte.com.cn) In-Reply-To: To: Julien Laganier MIME-Version: 1.0 X-KeepSent: E5534E2C:FB7AE42B-48257835:0007C2FF; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.xingyue@zte.com.cn Date: Sat, 12 Feb 2011 09:41:52 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-02-12 09:42:07, Serialize complete at 2011-02-12 09:42:07 Content-Type: multipart/alternative; boundary="=_alternative 000957D948257835_=" X-MAIL: mse01.zte.com.cn p1C1g73D024930 Cc: "netext@ietf.org" , netext-bounces@ietf.org Subject: [netext] =?gb2312?b?tPC4tDogUmU6ICC08Li0OiBSZTogUG9saWN5IGFzc3Vt?= =?gb2312?b?cHRpb25zIGluIGRyYWZ0LWJlcm5hcmRvcy1uZXRleHQtcG1pcHY2LWZsb3dt?= =?gb2312?b?b2I=?= X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 01:42:02 -0000 This is a multipart message in MIME format. --=_alternative 000957D948257835_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgSnVsaWVuLA0KDQpKdWxpZW4gTGFnYW5pZXIgPGp1bGllbi5pZXRmQGdtYWlsLmNvbT4g0LTT 2iAyMDExLTAyLTEyIMnPzucgMDI6MTA6MDQ6DQoNCj4gSGVsbG8gLQ0KPiANCj4gMjAxMS8yLzEw ICA8emhvdS54aW5neXVlQHp0ZS5jb20uY24+Og0KPiA+DQo+ID4gSGVsbG8sDQo+ID4NCj4gPiBu ZXRleHQtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIwMTEtMDItMTAgyc/O5yAwNjoyNzowMDoNCj4g Pg0KPiA+PiBIZWxsbywNCj4gPj4NCj4gPj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiA+PiA+IEZyb206IFRyYW4gTWluaCBUcnVuZyBbbWFpbHRvOnRydW5ndG0yOTA5QGdtYWlsLmNv bV0NCj4gPj4gPiBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA5LCAyMDExIDEyOjMxIEFNDQo+ ID4+ID4gVG86IEdpYXJldHRhLCBHZXJhcmRvDQo+ID4+ID4gQ2M6IG5ldGV4dEBpZXRmLm9yZw0K PiA+PiA+IFN1YmplY3Q6IFJlOiBbbmV0ZXh0XSBQb2xpY3kgYXNzdW1wdGlvbnMgaW4gZHJhZnQt YmVybmFyZG9zLW5ldGV4dC0NCj4gPj4gPiBwbWlwdjYtZmxvd21vYg0KPiA+PiA+DQo+ID4+ID4g T24gV2VkLCBGZWIgOSwgMjAxMSBhdCAzOjM2IFBNLCBHaWFyZXR0YSwgR2VyYXJkbw0KPiA+PiA+ IDxnZXJhcmRvZ0BxdWFsY29tbS5jb20+IHdyb3RlOg0KPiA+PiA+ID4gSSB3YW50IHRvIGdvIGJh Y2sgdG8gdGhlIHBvaW50IHJhaXNlZCBieSBTdGVmYW5vIHdoaWNoIHdhcyANCnNvbWVob3cNCj4g Pj4gPiBsb3N0IGluIHRoZSBsb25nIHRocmVhZC4NCj4gPj4gPiA+DQo+ID4+ID4gPiBJIG5lZWQg c29tZSBjbGFyaWZpY2F0aW9ucyBvbiB3aGljaCBpcyB0aGUgYXNzdW1wdGlvbiBpbiB0ZXJtcyBv Zg0KPiA+PiA+IHBvbGljaWVzIGluIHRoZSBkcmFmdC4gSW4gcGFydGljdWxhcjoNCj4gPj4gPiA+ DQo+ID4+ID4gPiAtIElzIGl0IGNvcnJlY3QgdGhhdCB0aGVyZSBpcyBhbiBhc3N1bXB0aW9uIHRo YXQgTU4gYW5kIExNQSBoYXZlIA0KdGhlDQo+ID4+ID4gc2FtZSBwb2xpY2llcyBhbmQgYmVoYXZl IGFjY29yZGluZ2x5Pw0KPiA+PiA+ID4NCj4gPj4gPg0KPiA+PiA+IFllcywgdGhleSBzaG91bGQg aGF2ZSB0aGUgc2FtZSBwb2xpY2llcy4NCj4gPj4gPg0KPiA+Pg0KPiA+PiBUaGVuLCB0aGUgc2Nl bmFyaW8gb2YgY2hhbmdlIG9mIHBvbGljeSBpbiB0aGUgTE1BIGlzIGNvbmZsaWN0aW5nDQo+ID4+ IHdpdGggdGhpcyBhc3N1bXB0aW9uIHVubGVzcyBwb2xpY2llcyBjaGFuZ2VkIGFsc28gb24gTU4u DQo+ID4+DQo+ID4gQXMgbWVudGlvbmVkIGJ5IFBpZXJyaWNrLCBhIHByYWdtYXRpYyBhbmQgYmFz aWMgd2F5IG9uIHBvbGljeSBjYW4gYmUNCj4gPiBhcHBwbGllZCBvbiBNTiBpbiBmaXJzdCByb3Vu ZC4gRm9yIGN1cnJlbnQgZmxvdywgdGhlIE1OIHNob3VsZCBmb2xsb3cgDQp0aGUNCj4gPiBMTUEn cyBjaGFuZ2Ugb2YgdHJhZmZpYyByb3V0aW5nLiBBbmQgdGhlIE1OIGluaXRhdGVzIGFueSBmbG93 IA0KYWNjb3JkaW5nIHRvDQo+ID4gdGhlIGRlZmF1bHQgcG9saWN5IGNvbmZpZ3VyYXRpb24uIE5v IGR5bmFtaWMgcG9saWN5IG1haW50ZW5hbmNlIA0KaXNuZWVkZWQgb24NCj4gPiBNTi4NCj4gDQo+ IFRoaXMgaXMgbmVpdGhlciBwcmFnbWF0aWMgbm9yIHByYWN0aWNhbC4NCj4gDQo+IEFuIExNQSBo YXMgbm8gYmFzaXMgdG8gdW5pbGF0ZXJhbGx5IGluc3RydWN0IGEgTU4gdG8gcm91dGUgdHJhZmZp YyBvbg0KPiBhIGRpZmZlcmVudCBpbnRlcmZhY2UsIGFzIHRoZSBNTiBpcyB0aGUgb25seSBuZXR3 b3JrIG5vZGUgdGhhdCByZWFsbHkNCj4ga25vd3MgaG93IGdvb2Qgb3IgYmFkIHRoYXQgaW50ZXJm YWNlIGlzLiBJZiBteSBNTiBpcyBhdHRhY2hlZCB0byBhIGJhZA0KPiBXaUZpIChzYXkgb3Zlcmxv YWRlZCBJRVRGIG1lZXRpbmcgaG90ZWwgV2lGaSkgYW5kIGEgcmVhc29uYWJsZSAzRw0KPiBuZXR3 b3JrLCBJIGRvbid0IHdhbnQgdGhlIExNQSB0byBmb3JjZSBtZSB0byB1c2UgdGhlIG92ZXJsb2Fk ZWQgV2lGaS4NCj4gDQo+IFdoYXQncyBwcmFnbWF0aWMgYW5kIHByYWN0aWNhbCBpcyB0aGF0IHRo ZSBNTiBpcyBwcm92aXNpb25lZCB3aXRoDQo+IHBvbGljaWVzIChlLmcuLCBBTkRTRiBpbiAzR1BQ KSB0aGF0IGluZGljYXRlcyBlLmcuIHRoYXQgV2lGSSBzaG91bGQgYmUNCj4gcHJlZmVycmVkIG92 ZXIgM0csIGFuZCBiYXNlZCBvbiB0aGlzIHBvbGljeSBhbmQgdGhlIG9wZXJhdGluZw0KPiBlbnZp cm9ubWVudCwgaWYgV2lGaSBpcyBjb25zaWRlcmVkIGFzIHdvcmtpbmcgYnkgdGhlIE1OIChub3QN Cj4gb3ZlcmxvYWRlZCB0byBhIHBvaW50IHdoZXJlIG9uZSBjYW4gYmFyZWx5IHJ1biBUQ1ApLCB0 aGVuIHRoZSBNTg0KPiBkZWNpZGVzIHRvIHVzZSBXaUZpIG92ZXIgM0cuIEJhc2VkIG9uIHRoaXMs IHRoZSBMTUEgc2hvdWxkIG1pcnJvciB0aGUNCj4gTU4ncyBmbG93IHJvdXRpbmcgZGVjaXNpb24u DQpUaGFua3MgZm9yIGV4cGxhaW5hdGlvbi4gSSBnZXQgeW91ciBwb2ludC4gWWVzLCB0aGUgTU4g c2hvdWxkIG1ha2UgdGhlIA0KZmluYWwgZGVjaXNpb24gb2YgdGhlIHRyYWZmaWMgcm91dGluZyBh Y2NvcmRpbmcgdG8gdGhlIHJlYWwgbG9jYWwgDQplbnZpcm9ubWVudC4gQXQgdGhpcyBwb2ludCB0 aGUgcmVjZWl2ZWluZyBwb2xpY2llcyBpcyB0YWtlbiBhcyByZWZlcmVuY2UuIA0KQXBvbG9naXpl IGZvciBXaGF0IEkgc2FpZCBwcmV2aW91cyBpcyBub3QgY2xlYXIuIE15IGNvbmNlcm4gaXMgdGhh dCANCndoZXRoZXIgdGhlIE1OIG5lZWRzIHRvIHVwZGF0ZSBsb2NhbCBwb2xpY2llcyB3aGVuIGZp bmRpbmcgZmxvdyBZIGlzIA0KbW92aW5nIGZyb20gaW50ZXJmYWNlIDEgdG8gaW50ZXJmYWNlIDIu IFRoZXJlIGlzIG5vIGV4cGxpY2l0IHN0YXRlbWVudCAgaW4gDQp0aGUgZHJhZnQgbm93Lg0KDQpS ZWdhcmRzLA0KSm95DQoNCj4gDQo+IC0tanVsaWVuDQo+IA0KDQo= --=_alternative 000957D948257835_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEp1bGllbiw8L2ZvbnQ+DQo8 YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5KdWxpZW4gTGFnYW5pZXIgJmx0O2p1bGllbi5pZXRm QGdtYWlsLmNvbSZndDsg0LTT2g0KMjAxMS0wMi0xMiDJz87nIDAyOjEwOjA0Ojxicj4NCjxicj4N CiZndDsgSGVsbG8gLTxicj4NCiZndDsgPGJyPg0KJmd0OyAyMDExLzIvMTAgJm5ic3A7Jmx0O3po b3UueGluZ3l1ZUB6dGUuY29tLmNuJmd0Ozo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsg SGVsbG8sPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IG5ldGV4dC1ib3VuY2VzQGlldGYu b3JnINC009ogMjAxMS0wMi0xMCDJz87nIDA2OjI3OjAwOjxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyZndDsgSGVsbG8sPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsg Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0OyZndDsgJmd0OyBG cm9tOiBUcmFuIE1pbmggVHJ1bmcgW21haWx0bzp0cnVuZ3RtMjkwOUBnbWFpbC5jb21dPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDksIDIwMTEgMTI6 MzEgQU08YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsgVG86IEdpYXJldHRhLCBHZXJhcmRvPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7IENjOiBuZXRleHRAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsmZ3Q7 ICZndDsgU3ViamVjdDogUmU6IFtuZXRleHRdIFBvbGljeSBhc3N1bXB0aW9ucyBpbiBkcmFmdC1i ZXJuYXJkb3MtbmV0ZXh0LTxicj4NCiZndDsgJmd0OyZndDsgJmd0OyBwbWlwdjYtZmxvd21vYjxi cj4NCiZndDsgJmd0OyZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgJmd0OyBPbiBXZWQsIEZl YiA5LCAyMDExIGF0IDM6MzYgUE0sIEdpYXJldHRhLCBHZXJhcmRvPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyAmZ3Q7ICZsdDtnZXJhcmRvZ0BxdWFsY29tbS5jb20mZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0 OyZndDsgJmd0OyAmZ3Q7IEkgd2FudCB0byBnbyBiYWNrIHRvIHRoZSBwb2ludCByYWlzZWQgYnkg U3RlZmFubw0Kd2hpY2ggd2FzIHNvbWVob3c8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsgbG9zdCBp biB0aGUgbG9uZyB0aHJlYWQuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsmZ3Q7ICZndDsgJmd0OyBJIG5lZWQgc29tZSBjbGFyaWZpY2F0aW9ucyBvbiB3aGljaCBp cyB0aGUgYXNzdW1wdGlvbg0KaW4gdGVybXMgb2Y8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsgcG9s aWNpZXMgaW4gdGhlIGRyYWZ0LiBJbiBwYXJ0aWN1bGFyOjxicj4NCiZndDsgJmd0OyZndDsgJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgLSBJcyBpdCBjb3JyZWN0IHRoYXQg dGhlcmUgaXMgYW4gYXNzdW1wdGlvbiB0aGF0DQpNTiBhbmQgTE1BIGhhdmUgdGhlPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyAmZ3Q7IHNhbWUgcG9saWNpZXMgYW5kIGJlaGF2ZSBhY2NvcmRpbmdseT88YnI+ DQomZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyZndDsgJmd0OyBZZXMsIHRoZXkgc2hvdWxkIGhhdmUgdGhlIHNhbWUgcG9saWNpZXMu PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0 OyZndDsgVGhlbiwgdGhlIHNjZW5hcmlvIG9mIGNoYW5nZSBvZiBwb2xpY3kgaW4gdGhlIExNQSBp cyBjb25mbGljdGluZzxicj4NCiZndDsgJmd0OyZndDsgd2l0aCB0aGlzIGFzc3VtcHRpb24gdW5s ZXNzIHBvbGljaWVzIGNoYW5nZWQgYWxzbyBvbiBNTi48YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IEFzIG1lbnRpb25lZCBieSBQaWVycmljaywgYSBwcmFnbWF0aWMgYW5kIGJhc2lj IHdheSBvbiBwb2xpY3kNCmNhbiBiZTxicj4NCiZndDsgJmd0OyBhcHBwbGllZCBvbiBNTiBpbiBm aXJzdCByb3VuZC4gRm9yIGN1cnJlbnQgZmxvdywgdGhlIE1OIHNob3VsZA0KZm9sbG93IHRoZTxi cj4NCiZndDsgJmd0OyBMTUEncyBjaGFuZ2Ugb2YgdHJhZmZpYyByb3V0aW5nLiBBbmQgdGhlIE1O IGluaXRhdGVzIGFueSBmbG93DQphY2NvcmRpbmcgdG88YnI+DQomZ3Q7ICZndDsgdGhlIGRlZmF1 bHQgcG9saWN5IGNvbmZpZ3VyYXRpb24uIE5vIGR5bmFtaWMgcG9saWN5IG1haW50ZW5hbmNlDQpp c25lZWRlZCBvbjxicj4NCiZndDsgJmd0OyBNTi48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhpcyBp cyBuZWl0aGVyIHByYWdtYXRpYyBub3IgcHJhY3RpY2FsLjxicj4NCiZndDsgPGJyPg0KJmd0OyBB biBMTUEgaGFzIG5vIGJhc2lzIHRvIHVuaWxhdGVyYWxseSBpbnN0cnVjdCBhIE1OIHRvIHJvdXRl IHRyYWZmaWMNCm9uPGJyPg0KJmd0OyBhIGRpZmZlcmVudCBpbnRlcmZhY2UsIGFzIHRoZSBNTiBp cyB0aGUgb25seSBuZXR3b3JrIG5vZGUgdGhhdCByZWFsbHk8YnI+DQomZ3Q7IGtub3dzIGhvdyBn b29kIG9yIGJhZCB0aGF0IGludGVyZmFjZSBpcy4gSWYgbXkgTU4gaXMgYXR0YWNoZWQgdG8gYQ0K YmFkPGJyPg0KJmd0OyBXaUZpIChzYXkgb3ZlcmxvYWRlZCBJRVRGIG1lZXRpbmcgaG90ZWwgV2lG aSkgYW5kIGEgcmVhc29uYWJsZSAzRzxicj4NCiZndDsgbmV0d29yaywgSSBkb24ndCB3YW50IHRo ZSBMTUEgdG8gZm9yY2UgbWUgdG8gdXNlIHRoZSBvdmVybG9hZGVkIFdpRmkuPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IFdoYXQncyBwcmFnbWF0aWMgYW5kIHByYWN0aWNhbCBpcyB0aGF0IHRoZSBNTiBp cyBwcm92aXNpb25lZCB3aXRoPGJyPg0KJmd0OyBwb2xpY2llcyAoZS5nLiwgQU5EU0YgaW4gM0dQ UCkgdGhhdCBpbmRpY2F0ZXMgZS5nLiB0aGF0IFdpRkkgc2hvdWxkDQpiZTxicj4NCiZndDsgcHJl ZmVycmVkIG92ZXIgM0csIGFuZCBiYXNlZCBvbiB0aGlzIHBvbGljeSBhbmQgdGhlIG9wZXJhdGlu Zzxicj4NCiZndDsgZW52aXJvbm1lbnQsIGlmIFdpRmkgaXMgY29uc2lkZXJlZCBhcyB3b3JraW5n IGJ5IHRoZSBNTiAobm90PGJyPg0KJmd0OyBvdmVybG9hZGVkIHRvIGEgcG9pbnQgd2hlcmUgb25l IGNhbiBiYXJlbHkgcnVuIFRDUCksIHRoZW4gdGhlIE1OPGJyPg0KJmd0OyBkZWNpZGVzIHRvIHVz ZSBXaUZpIG92ZXIgM0cuIEJhc2VkIG9uIHRoaXMsIHRoZSBMTUEgc2hvdWxkIG1pcnJvcg0KdGhl PGJyPg0KJmd0OyBNTidzIGZsb3cgcm91dGluZyBkZWNpc2lvbi48L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPlRoYW5rcyBmb3IgZXhwbGFpbmF0aW9uLiBJIGdldCB5b3VyIHBvaW50 LiBZZXMsIHRoZQ0KTU4gc2hvdWxkIG1ha2UgdGhlIGZpbmFsIGRlY2lzaW9uIG9mIHRoZSB0cmFm ZmljIHJvdXRpbmcgYWNjb3JkaW5nIHRvIHRoZQ0KcmVhbCBsb2NhbCBlbnZpcm9ubWVudC4gQXQg dGhpcyBwb2ludCB0aGUgcmVjZWl2ZWluZyBwb2xpY2llcyBpcyB0YWtlbg0KYXMgcmVmZXJlbmNl LiBBcG9sb2dpemUgZm9yIFdoYXQgSSBzYWlkIHByZXZpb3VzIGlzIG5vdCBjbGVhci4gTXkgY29u Y2Vybg0KaXMgdGhhdCB3aGV0aGVyIHRoZSBNTiBuZWVkcyB0byB1cGRhdGUgbG9jYWwgcG9saWNp ZXMgd2hlbiBmaW5kaW5nIGZsb3cNClkgaXMgbW92aW5nIGZyb20gaW50ZXJmYWNlIDEgdG8gaW50 ZXJmYWNlIDIuIFRoZXJlIGlzIG5vIGV4cGxpY2l0IHN0YXRlbWVudA0KJm5ic3A7aW4gdGhlIGRy YWZ0IG5vdy48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPlJlZ2FyZHMs PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5Kb3k8L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsgPGJyPg0KJmd0OyAtLWp1bGllbjxicj4NCiZndDsg PGJyPg0KPC9mb250PjwvdHQ+DQo= --=_alternative 000957D948257835_=-- From hesham@elevatemobile.com Sat Feb 12 07:08:16 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D66373A6A6D for ; Sat, 12 Feb 2011 07:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlHFk0Tb0S3z for ; Sat, 12 Feb 2011 07:08:15 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 657063A6A11 for ; Sat, 12 Feb 2011 07:08:14 -0800 (PST) Received: from [203.219.211.243] (helo=[192.168.0.7]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1PoH5G-0005Mh-7l; Sun, 13 Feb 2011 02:08:26 +1100 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Sun, 13 Feb 2011 02:08:19 +1100 From: Hesham Soliman To: Rajeev Koodli , Julien Laganier , Sri Gundavelli Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc Thread-Index: AcvItpWeJms7su/AMk2xF1Y1ib7tZQCEBjfg In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-User: hesham@elevatemobile.com Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 15:08:16 -0000 Yes but another piece of news about IETF is that you need to respond to technical discussions. You are not responding to the key points raised by Julien in his last email. I've been silently following this "debate" and it's frustrating to see people talking past each other. Hesham On 10/02/11 11:08 AM, "Rajeev Koodli" wrote: >=20 > Hello Folks, >=20 > Protocols evolve in IETF, that's just how it goes. It's not a criticism o= f > the previous design per se. The same goes for PMIPv6 here. >=20 > To be very clear, what's being proposed is not to undo something, but add > new functionality, without affecting the baseline functionality. >=20 > OTOH, if the claim here is that two years of design could not be worked o= n > AND 7 people on this list cannot possibly do anything to evolve it, that'= s > news to me, in IETF. >=20 > -Rajeev >=20 >=20 >=20 > On 2/9/11 11:39 AM, "Julien Laganier" wrote: >=20 >> Sri: >>=20 >> Well said. I couldn't agree more. >>=20 >> --julien >>=20 >> On Wed, Feb 9, 2011 at 10:11 AM, Sri Gundavelli wro= te: >>>=20 >>> We want the LMA to dynamically add prefixes, pick a prefix based on the= hour >>> of the day, or based on the weather, create sessions unilaterally and a= lso >>> reboot the MN at its mercy. We can assume the LMA some how knows and is= in >>> communication with the oracle that has all the interfaces in place from= the >>> radio network, and has all the needed heuristics in place which tells a= s >>> when to make all the state changes. Sure, we can define any thing we wa= nt, >>> but we cannot completely ignore the target system architecture. Each >>> requirement has to have some meaningful use-case with general consensus= to >>> do that work and the charter has to reflect that. >>>=20 >>> To support this wish list, we can assume the mobile node has all the ne= eded >>> framework in place. It can mirror flows, it knows when to switch flows,= it >>> has an understanding of the completion of the network side signaling. S= till >>> its a simple mobile node, unmodified, but it is DPI enabled, which trac= ks >>> what flows are coming what interfaces, so it can mirror. Who is buildin= g >>> this UE ? >>>=20 >>> We don't have to be restricted with the RFC-5213 signaling. If its need= ed or >>> not, we should define a new signaling plane. One message interface from= LMA >>> to MAG and the other from MAG to LMA. We will define new sets of messag= es, >>> new options, new number space and the MAG implementations will have two= sets >>> of timers and an advanced state machine. All of this to support a remot= e >>> case of policy change. This is an impact to the implementations. >>>=20 >>> We can do all of this, but before we make fundamental changes to the >>> protocol that was discussed for over a period of two years and with >>> industry-wide participation, we cannot allow it be undone in WG which h= as >>> (7) people participation, with a single tone enforcing decisions, with >>> unilateral wish list, backed by no framework that supports such require= ments >>> in any target system architecture. >>>=20 >>> Finally, if we are talking about fundamental changes to the signaling m= odel, >>> it should be reflected in the charter. The AD needs to approve. As many >>> pointed out, all the basic flow mobility functional requirements can be= met, >>> without "updating the legacy 5213 model". If the goal is to update that >>> legacy model, we should start with a new protocol. >>>=20 >>>=20 >>>=20 >>> Sri >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> In 3GPP, the prefix is assigned when the PDN connection is created, >>>> and is then unchanged for the reminder of the lifetime of this PDN >>>> connection. >>>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2/8/11 7:07 PM, "Julien Laganier" wrote: >>>=20 >>>> Hi Rajeev, >>>>=20 >>>> On Tue, Feb 8, 2011 at 6:51 PM, Rajeev Koodli wrot= e: >>>>>=20 >>>>> Hi Julien, >>>>>=20 >>>>> On 2/8/11 5:25 PM, "Julien Laganier" wrote: >>>>>=20 >>>>>> What would actually really helps all of us to make progress is that >>>>>> instead of telling what you'd like, as in >>>>>=20 >>>>> It would also help if you didn't generalize your reservation to what = I am >>>>> stating as in "..helps *all* of us..". >>>>=20 >>>> I simply wanted to say that since I see no usecase to justify the type >>>> of features you'd like to have in, having a usecase outlined would >>>> help this discussion to converge, which seems to be helpful to people >>>> on this mailing list. There was certainly no intent to say that my >>>> reservations are shared by the whole working group. >>>>=20 >>>> That being said, >>>>=20 >>>>> I see you have a model in mind (which is pretty close to what is in t= he >>>>> draft already), which is fine. I fail to see why you are restricted t= o >>>>> that >>>>> alone. But, perhaps that's less fruitful to delve into now. >>>>>=20 >>>>>=20 >>>>>>> I would like LMA-initiated signaling (FMI/FMA) for this (i.e., sign= aling >>>>>>> to >>>>>>> MAG1 with Pref2) as well as for the above (i.e., being able to sign= al >>>>>>> MAG2 >>>>>>> with Pref1) *whenever* the LMA wants. >>>>>>=20 >>>>>> you'd rather tell us why this is needed, by whom, and where... I've >>>>>> been asking the same question over and over but nobody writes down a= n >>>>>> answer to this in this thread. >>>>>=20 >>>>> I have mentioned why I need it a few times. 1) I am not required to a= ssign >>>>> all the applicable prefixes at the time of attach *in anticipation* o= f >>>>> *potential* flow mobility. I will assign a relevant prefix *if and wh= en* I >>>>> need to move a flow over. >>>>=20 >>>> In 3GPP, the prefix is assigned when the PDN connection is created, >>>> and is then unchanged for the reminder of the lifetime of this PDN >>>> connection. >>>>=20 >>>> So in your own words: You are not required to assign all the >>>> applicable prefixes at the time of attach *in anticipation* of >>>> *potential* flow mobility. You will assign the relevant prefix *if and >>>> when* I you need a PDN connection. >>>>=20 >>>> If you have another target system than 3GPP, what is it? >>>>=20 >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 It makes no sense for me to be *forced* to >>>>> assign >>>>> all the prefixes at the time of attach (just because it is aligned wi= th >>>>> legacy RFC 5213 "model"). >>>>=20 >>>> Assigning all the prefixes at time of attaches isn't a requirement for >>>> flow mobility. You can very well have a single prefix and do flow >>>> mobility across multiple interfaces. >>>>=20 >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2) I want to assign a >>>> prefix based on policy >>>>> triggers, including the TOD rules. >>>>=20 >>>> I don't see how useful it is to assign prefixes based on time of day. >>>> I understand you might want to move flows based on time of day, but as >>>> I said above, you can already move flows with a single prefix when the >>>> time is good for you. >>>>=20 >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0I want to >>>> move certain type of traffic >>>>> over to a different interface based on peak hour bulk stats, the volu= me of >>>>> traffic the user is consuming at a particular instance, the amount of >>>>> quota >>>>> left and so on. >>>>=20 >>>> All capabilities that are perfectly available without juggling with >>>> multiple prefixes, as above. >>>>=20 >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I want to be able to refresh the life= time >>>>> of >>>>> that prefix and >>>>> revoke it back to its "natural interface" when I want. >>>>=20 >>>> This is renumbering - a different interface. I also don't know what a >>>> natural interface is when prefixes are assigned from withing an >>>> overlay... >>>>=20 >>>>> I want to be able to offer this for my customers. >>>>=20 >>>> Most of which you can, as I stated above, independently of prefix >>>> juggling... >>>>=20 >>>>>> Absent that, will I be forced to conclude that this needed by no-one= ? >>>>>=20 >>>>> If I don't need something that does not imply the rest don't either! = :-) >>>>=20 >>>> Can they speak up then? :-) >>>>=20 >>>> --julien >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>=20 >>>=20 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From pierrick.seite@orange-ftgroup.com Mon Feb 14 01:22:50 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AA303A6C8D; Mon, 14 Feb 2011 01:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.743 X-Spam-Level: X-Spam-Status: No, score=-1.743 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CE4c4FxyLc4R; Mon, 14 Feb 2011 01:22:49 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id A8B523A6C8C; Mon, 14 Feb 2011 01:22:47 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A1ED36C001A; Mon, 14 Feb 2011 10:23:38 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 936DB6C0018; Mon, 14 Feb 2011 10:23:38 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Feb 2011 10:23:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Mon, 14 Feb 2011 10:23:06 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C4620180DB4A@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?UTF-8?B?W25ldGV4dF3nrZTlpI06IFJlOiBQb2xpY3kgYXNzdW1wdGlv?= =?UTF-8?B?bnMgaW4gZHJhZnQtYmVybmFyZG9zLW5ldGV4dC1wbWk=?= =?UTF-8?B?cHY2LWZsb3dtb2I=?= Thread-Index: AcvKFvJkMZHf1kXXQzWptv7+6Y0cpwCDilIg References: From: To: , X-OriginalArrivalTime: 14 Feb 2011 09:23:07.0811 (UTC) FILETIME=[CA7C8F30:01CBCC28] Cc: netext@ietf.org, netext-bounces@ietf.org Subject: Re: [netext] =?utf-8?b?562U5aSNOiBSZTogUG9saWN5IGFzc3VtcHRpb25zIGlu?= =?utf-8?q?_draft-bernardos-netext-pmipv6-flowmob?= X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 14 Feb 2011 09:22:50 -0000 DQpIaSwNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IG5ldGV4dC1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86bmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQN Cj4gZGUgSnVsaWVuIExhZ2FuaWVyDQo+IEVudm95w6nCoDogdmVuZHJlZGkgMTEgZsOpdnJpZXIg MjAxMSAxOToxMA0KPiDDgMKgOiB6aG91Lnhpbmd5dWVAenRlLmNvbS5jbg0KPiBDY8KgOiBuZXRl eHRAaWV0Zi5vcmc7IG5ldGV4dC1ib3VuY2VzQGlldGYub3JnDQo+IE9iamV0wqA6IFJlOiBbbmV0 ZXh0XeetlOWkjTogUmU6IFBvbGljeSBhc3N1bXB0aW9ucyBpbiBkcmFmdC1iZXJuYXJkb3MtDQo+ IG5ldGV4dC1wbWlwdjYtZmxvd21vYg0KPiANCj4gSGVsbG8gLQ0KPiANCj4gMjAxMS8yLzEwICA8 emhvdS54aW5neXVlQHp0ZS5jb20uY24+Og0KPiA+DQo+ID4gSGVsbG8sDQo+ID4NCj4gPiBuZXRl eHQtYm91bmNlc0BpZXRmLm9yZyDlhpnkuo4gMjAxMS0wMi0xMCDkuIrljYggMDY6Mjc6MDA6DQo+ ID4NCj4gPj4gSGVsbG8sDQo+ID4+DQo+ID4+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPj4gPiBGcm9tOiBUcmFuIE1pbmggVHJ1bmcgW21haWx0bzp0cnVuZ3RtMjkwOUBnbWFpbC5j b21dDQo+ID4+ID4gU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwOSwgMjAxMSAxMjozMSBBTQ0K PiA+PiA+IFRvOiBHaWFyZXR0YSwgR2VyYXJkbw0KPiA+PiA+IENjOiBuZXRleHRAaWV0Zi5vcmcN Cj4gPj4gPiBTdWJqZWN0OiBSZTogW25ldGV4dF0gUG9saWN5IGFzc3VtcHRpb25zIGluIGRyYWZ0 LWJlcm5hcmRvcy1uZXRleHQtDQo+ID4+ID4gcG1pcHY2LWZsb3dtb2INCj4gPj4gPg0KPiA+PiA+ IE9uIFdlZCwgRmViIDksIDIwMTEgYXQgMzozNiBQTSwgR2lhcmV0dGEsIEdlcmFyZG8NCj4gPj4g PiA8Z2VyYXJkb2dAcXVhbGNvbW0uY29tPiB3cm90ZToNCj4gPj4gPiA+IEkgd2FudCB0byBnbyBi YWNrIHRvIHRoZSBwb2ludCByYWlzZWQgYnkgU3RlZmFubyB3aGljaCB3YXMgc29tZWhvdw0KPiA+ PiA+IGxvc3QgaW4gdGhlIGxvbmcgdGhyZWFkLg0KPiA+PiA+ID4NCj4gPj4gPiA+IEkgbmVlZCBz b21lIGNsYXJpZmljYXRpb25zIG9uIHdoaWNoIGlzIHRoZSBhc3N1bXB0aW9uIGluIHRlcm1zIG9m DQo+ID4+ID4gcG9saWNpZXMgaW4gdGhlIGRyYWZ0LiBJbiBwYXJ0aWN1bGFyOg0KPiA+PiA+ID4N Cj4gPj4gPiA+IC0gSXMgaXQgY29ycmVjdCB0aGF0IHRoZXJlIGlzIGFuIGFzc3VtcHRpb24gdGhh dCBNTiBhbmQgTE1BIGhhdmUNCj4gdGhlDQo+ID4+ID4gc2FtZSBwb2xpY2llcyBhbmQgYmVoYXZl IGFjY29yZGluZ2x5Pw0KPiA+PiA+ID4NCj4gPj4gPg0KPiA+PiA+IFllcywgdGhleSBzaG91bGQg aGF2ZSB0aGUgc2FtZSBwb2xpY2llcy4NCj4gPj4gPg0KPiA+Pg0KPiA+PiBUaGVuLCB0aGUgc2Nl bmFyaW8gb2YgY2hhbmdlIG9mIHBvbGljeSBpbiB0aGUgTE1BIGlzIGNvbmZsaWN0aW5nDQo+ID4+ IHdpdGggdGhpcyBhc3N1bXB0aW9uIHVubGVzcyBwb2xpY2llcyBjaGFuZ2VkIGFsc28gb24gTU4u DQo+ID4+DQo+ID4gQXMgbWVudGlvbmVkIGJ5IFBpZXJyaWNrLCBhIHByYWdtYXRpYyBhbmQgYmFz aWMgd2F5IG9uIHBvbGljeSBjYW4gYmUNCj4gPiBhcHBwbGllZCBvbiBNTiBpbiBmaXJzdCByb3Vu ZC4gRm9yIGN1cnJlbnQgZmxvdywgdGhlIE1OIHNob3VsZCBmb2xsb3cNCj4gdGhlDQo+ID4gTE1B J3MgY2hhbmdlIG9mIHRyYWZmaWMgcm91dGluZy4gQW5kIHRoZSBNTiBpbml0YXRlcyBhbnkgZmxv dyBhY2NvcmRpbmcNCj4gdG8NCj4gPiB0aGUgZGVmYXVsdCBwb2xpY3kgY29uZmlndXJhdGlvbi4g Tm8gZHluYW1pYyBwb2xpY3kgbWFpbnRlbmFuY2UgaXMNCj4gbmVlZGVkIG9uDQo+ID4gTU4uDQo+ IA0KPiBUaGlzIGlzIG5laXRoZXIgcHJhZ21hdGljIG5vciBwcmFjdGljYWwuDQo+IA0KPiBBbiBM TUEgaGFzIG5vIGJhc2lzIHRvIHVuaWxhdGVyYWxseSBpbnN0cnVjdCBhIE1OIHRvIHJvdXRlIHRy YWZmaWMgb24NCj4gYSBkaWZmZXJlbnQgaW50ZXJmYWNlLCBhcyB0aGUgTU4gaXMgdGhlIG9ubHkg bmV0d29yayBub2RlIHRoYXQgcmVhbGx5DQo+IGtub3dzIGhvdyBnb29kIG9yIGJhZCB0aGF0IGlu dGVyZmFjZSBpcy4gSWYgbXkgTU4gaXMgYXR0YWNoZWQgdG8gYSBiYWQNCj4gV2lGaSAoc2F5IG92 ZXJsb2FkZWQgSUVURiBtZWV0aW5nIGhvdGVsIFdpRmkpIGFuZCBhIHJlYXNvbmFibGUgM0cNCj4g bmV0d29yaywgSSBkb24ndCB3YW50IHRoZSBMTUEgdG8gZm9yY2UgbWUgdG8gdXNlIHRoZSBvdmVy bG9hZGVkIFdpRmkuDQo+IA0KPiBXaGF0J3MgcHJhZ21hdGljIGFuZCBwcmFjdGljYWwgaXMgdGhh dCB0aGUgTU4gaXMgcHJvdmlzaW9uZWQgd2l0aA0KPiBwb2xpY2llcyAoZS5nLiwgQU5EU0YgaW4g M0dQUCkgdGhhdCBpbmRpY2F0ZXMgZS5nLiB0aGF0IFdpRkkgc2hvdWxkIGJlDQo+IHByZWZlcnJl ZCBvdmVyIDNHLCBhbmQgYmFzZWQgb24gdGhpcyBwb2xpY3kgYW5kIHRoZSBvcGVyYXRpbmcNCj4g ZW52aXJvbm1lbnQsIGlmIFdpRmkgaXMgY29uc2lkZXJlZCBhcyB3b3JraW5nIGJ5IHRoZSBNTiAo bm90DQo+IG92ZXJsb2FkZWQgdG8gYSBwb2ludCB3aGVyZSBvbmUgY2FuIGJhcmVseSBydW4gVENQ KSwgdGhlbiB0aGUgTU4NCj4gZGVjaWRlcyB0byB1c2UgV2lGaSBvdmVyIDNHLiBCYXNlZCBvbiB0 aGlzLCB0aGUgTE1BIHNob3VsZCBtaXJyb3IgdGhlDQo+IE1OJ3MgZmxvdyByb3V0aW5nIGRlY2lz aW9uLg0KPiANCg0KSW4gdGhhdCBjYXNlLCB0aGVyZSBpcyBmZXcgYWRkZWQgdmFsdWUgdG8gUE1J UDsgd2l0aCBzdWNoIGEgdGVybWluYWwgY2VudHJpYyBkZWNpc2lvbiwgTUlQIHNob3VsZCBiZSBw cmVmZXJyZWQuDQoNCklmIExNQSBjb250cm9sbGVkIGRlY2lzaW9uIGhhcyBsaW1pdGF0aW9uLCBh IHRlcm1pbmFsIGNlbnRyaWMgZGVjaXNpb24gbW9kZWwgaGFzIGFsc28gZHJhd2JhY2tzLiBBY3R1 YWxseSwgYSBnb29kIHRyYWRlLW9mZiBpcyBhIG1vZGVsIHdoZXJlIHRoZSBuZXR3b3JrIGNhbiBh c3Npc3QgdGhlIE1OIGluIGl0cyBkZWNpc2lvbiAodGhlIE1OIG1ha2VzIHRoZSBmaW5hbCBkZWNp c2lvbiwgYnV0IGdldHMgaW5mbyBmcm9tIHRoZSBuZXR3b3JrIHRvIG1ha2UgdGhhdCBkZWNpc2lv biksIHNvIGF2b2lkaW5nIHRoZSBNTiB0byBhdHRhY2ggYW4gYWNjZXNzIHdpdGggYmFkIGNvbmRp dGlvbi4gQnV0IHN1Y2ggYSBtb2RlbCBicmluZyBjb3VwbGUgb2YgaXNzdWVzIGluIFBNSVAgY29u dGV4dDsgdGhlc2UgaXNzdWVzIGhhcyBiZWVuIHJhaXNlZCB1cCBpbiB0aGUgTUwgTU4vbmV0d29y ayBpbnRlcmFjdGlvbiwgcG9saWN5IHN5bmNocm9uaXphdGlvbi4uLiBGb3Igc3VyZSB3ZSBzaG91 bGQgYWRkcmVzcyB0aGVzZSBpc3N1ZXMsIGJ1dCBpbiB0aGUgbWVhbnRpbWUgYW5kIGluIHRoZSBz Y29wZSBvZiBjdXJyZW50IG5leHQgZHJhdGZzLCBhIGRlY2lzaW9uIG1vZGVsIHdoZXJlIHRoZSBM TUEgZW5mb3JjZXMgaXRzIGRlY2lzaW9uIHRvIHRoZSBNTiBjYW4gYmUgY29uc2lkZXJlZCwga25v d2luZyB0aGF0IExNQSBkZWNpc2lvbiBlbmZvcmNlbWVudCBjYW5ub3QgYmUgdGhlIG9ubHkgYW5z d2VyLiAgDQoNClBpZXJyaWNrDQoNCj4gLS1qdWxpZW4NCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0ZXh0IG1haWxpbmcgbGlzdA0KPiBuZXRl eHRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRl eHQNCg== From cjbc@it.uc3m.es Mon Feb 14 01:58:37 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FFCD3A6C98 for ; Mon, 14 Feb 2011 01:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdBon-6JMvGO for ; Mon, 14 Feb 2011 01:58:35 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 813ED3A6C94 for ; Mon, 14 Feb 2011 01:58:34 -0800 (PST) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id D757B70DD21 for ; Mon, 14 Feb 2011 10:58:55 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: netext@ietf.org Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-AnYAtM72b6qKXTWlVUEV" Organization: Universidad Carlos III de Madrid Date: Mon, 14 Feb 2011 11:00:07 +0100 Message-ID: <1297677607.4514.71.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17954.006 Subject: [netext] On the flow mobility discussion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 09:58:37 -0000 --=-AnYAtM72b6qKXTWlVUEV Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi all, First of all, thanks for the active and lively discussion. I think that we are slowly making some progress. For the sake of making progress, let me try to summarize the discussion (well, actually, my view of it), pose some questions and propose some next steps: - Trigger for flow mobility. We have heard at least two main opinions on this: a) triggers can only come from the MAG (based on L2 signaling from the MN), and b) triggers can come from the MAG or from the LMA. Strong points of a): strictly follows current RFC 5213 and allows to support scenarios in which the MN can signal to the MAG events relevant to flow mobility via L2-specific signaling. Here it is my first question: to me L2 triggers and L2 signaling are not the same thing, RFC5213 requires L2 triggers to be in place (AFAIK, it can also work based on IPv6 ND, with some assumptions on how to get the MNID and set the HI) for example to detect when a MN has attached. However, L2 signaling between the MN and MAG are a bit different (it implies the existence of a communication channel for control purposes between MAG and MN that is able to convey information relevant/relative to a L3 protocol). Do we want to restrict the solution to the scenarios in which this L2 signaling channel is present? To cite one example, one of the approaches that has been proposed in the ML requires the MN to signal via L2 (over an attachment through iface X) about events of iface Y. Regarding b) Julien (and other folks) have asked about scenarios that require that. I think 3G offloading is one of the scenarios that requires that to be supported. If an operator has an MN that is attached to WLAN and 3G simultaneously wants (because of network load conditions) to offload some flows from 3G to WLAN on demand, I think this should be supported, and LMA initiated flow mobility is the way to do it. Some folks have said that the MN is the only one that knows the quality of the signal it receives and this is mostly true (note that there are solutions than allows the owner of the WLAN to know of the quality and status of the network), but it is also true that in current celular networks handovers are controlled by the network (based on signal quality reports from the MN). To me PMIPv6 follows the same model: network controlled __IP__ mobility. - On the RFC5213 model and extensions to it. We can debate (as we are doing) on the pros and cons of different technical approaches, that's what we can do. However, I disagree with the idea that adding new messages between LMA and MAG (if they are necessary) is fundamentally changing the protocol and that we need to change the charter, ask the ADs, etc. Current charter says on this regard: "The working group will determine what protocol extensions are required between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to support the ability for an interface (at the IP layer) to transmit packets over different media, the ability to distribute specific traffic flows on different media components of that interface, and making this work with the handover hints in the base protocol. The relevant protocol extensions will be developed as necessary." I think all technical approaches discussed so far are fine with the above text. Even one could read that text as preventing from adding new handover hints (which has been proposed as one of the solutions), though that's not my reading. - On the technical approach itself. If we forget for a second about the LMA-triggered event, and we just think of MAG triggered ones, there have been two fundamental approaches proposed so far. I think Tran summarized them very well in a previous e-mail. Let me try it again for the sake of this discussion: a) extensions to RFC5213 to support dynamically adding and removing interfaces to mobility sessions, and b) extensions to RFC5213 (based on standardized solutions developed in the MEXT WG) to allow dynamic prefix management (and use that as a way to enable flow mobility). Option a) does requires to modify conceptual data structures defined in RFC5213 as well as state machines (to support the new behavior). Option b) does not require modifications to the mobility session related data structures, but on the other hand adds new ones (related to flow bindings) and also modifies state machines. Option b) leverages on existing MEXT work. To me, in order to enable flow mobility in PMIPv6, there are two main things needed (on the network side): the ability for the LMA to perform flow routing (i.e. not just routing based on IP destination prefix) and to allow the MAG to route prefixes that have not been delegated by the LMA on the initial interface attachment of the MN (i.e. to support the dynamic modification of the prefixes -- associated to a particular MN -- that the MAG is aware of). Of course, we need on the mobile side the ability to receive and send packets simultaneously through different physical interfaces (regardless of the IPs used). IMO, both technical approaches a) and b) above meet the technical requirements without posing any issue related to implementation complexity (both follows the KISS principle) or charter compliance. To sum up this long e-mail, I see two main issues that need to be resolved to be able to progress: - Trigger issue. I see the need for both LMA and MAG initiated. Therefore I propose to work on a solution that supports BOTH. Different people have expressed their preferences to support both and I don't see any major issue on that. The only required change to support both is the addition of some signaling between LMA and MAG. - Technical approach issue (interface adding to mobility sessions vs "flow bindings based" approach). I don't see major issues in any of them. Current draft follows the second and I prefer to keep using it, unless there is a clear advantage (that I don't see at this point) of using the first. Comments? Thanks, Carlos --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-AnYAtM72b6qKXTWlVUEV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1Y/ScACgkQNdy6TdFwT2cOfQCgmTBmg6xUxc8rjvK2XUQPYuMy XrAAn1t2T0gtij8EGhi7H74gRgZ31rNU =y6tz -----END PGP SIGNATURE----- --=-AnYAtM72b6qKXTWlVUEV-- From julien.ietf@gmail.com Mon Feb 14 10:34:33 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B822A3A6CA2; Mon, 14 Feb 2011 10:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.868 X-Spam-Level: X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[AWL=-2.114, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsTBZumZW4LX; Mon, 14 Feb 2011 10:34:32 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 33ACD3A6D4D; Mon, 14 Feb 2011 10:34:32 -0800 (PST) Received: by ewy8 with SMTP id 8so2756532ewy.31 for ; Mon, 14 Feb 2011 10:34:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zX/CtPyM10lvPD5KJOiTlvrvAB5+Egs5O6veg64ju1E=; b=xgZCZEXk7bkcyGLNhy1Q9XfDtwujjaHNDoVojR4iI0HBeSC8x3uQJscbdfZAk32TFF aAuiBdwtFnIVaTBGB3pkgOknVUbK3g208qfAHnB0NdpTqUlFlyI9DtM/FaySpjJ73YPf 4/uwaXB0KKDXT2scKz/0NZ1pkBluCCGqnJzP0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=l7cjxi5MOXzuh1nEES3CFdP7vlM5UK+uebvy6tOLQqipFx5FLOO37K/THCB4ih/hE2 zKcpS2xSlNSLe11FcCjHieOc1MdcFEjZdYi6VrTgznincpw1ID+nF9m2TGcyg1dxHiZW RLtjYqEskqlMnSfK1cnob7WKtHfCziA6ngBJE= MIME-Version: 1.0 Received: by 10.223.74.15 with SMTP id s15mr4913078faj.28.1297708494634; Mon, 14 Feb 2011 10:34:54 -0800 (PST) Received: by 10.223.74.142 with HTTP; Mon, 14 Feb 2011 10:34:54 -0800 (PST) In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C4620180DB4A@ftrdmel0.rd.francetelecom.fr> References: <843DA8228A1BA74CA31FB4E111A5C4620180DB4A@ftrdmel0.rd.francetelecom.fr> Date: Mon, 14 Feb 2011 10:34:54 -0800 Message-ID: From: Julien Laganier To: pierrick.seite@orange-ftgroup.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: netext-bounces@ietf.org, netext@ietf.org Subject: Re: [netext] =?gb2312?b?tPC4tDogUmU6IFBvbGljeSBhc3N1bXB0aW9ucyBpbiBk?= =?gb2312?b?cmFmdC1iZXJuYXJkb3MtbmV0ZXh0LXBtaXB2Ni1mbG93bW9i?= X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 14 Feb 2011 18:34:33 -0000 Hi Pierrick - On Mon, Feb 14, 2011 at 1:23 AM, wrote= : > > Hi, >> -----Message d'origine----- >> De=C2=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la= part >> de Julien Laganier >> Envoy=C3=A9=C2=A0: vendredi 11 f=C3=A9vrier 2011 19:10 >> =C3=80=C2=A0: zhou.xingyue@zte.com.cn >> Cc=C2=A0: netext@ietf.org; netext-bounces@ietf.org >> Objet=C2=A0: Re: [netext]=E7=AD=94=E5=A4=8D: Re: Policy assumptions in d= raft-bernardos- >> netext-pmipv6-flowmob >> >> Hello - >> >> 2011/2/10 =C2=A0: >> > >> > Hello, >> > >> > netext-bounces@ietf.org =E5=86=99=E4=BA=8E 2011-02-10 =E4=B8=8A=E5=8D= =88 06:27:00: >> > >> >> Hello, >> >> >> >> > -----Original Message----- >> >> > From: Tran Minh Trung [mailto:trungtm2909@gmail.com] >> >> > Sent: Wednesday, February 09, 2011 12:31 AM >> >> > To: Giaretta, Gerardo >> >> > Cc: netext@ietf.org >> >> > Subject: Re: [netext] Policy assumptions in draft-bernardos-netext- >> >> > pmipv6-flowmob >> >> > >> >> > On Wed, Feb 9, 2011 at 3:36 PM, Giaretta, Gerardo >> >> > wrote: >> >> > > I want to go back to the point raised by Stefano which was someho= w >> >> > lost in the long thread. >> >> > > >> >> > > I need some clarifications on which is the assumption in terms of >> >> > policies in the draft. In particular: >> >> > > >> >> > > - Is it correct that there is an assumption that MN and LMA have >> the >> >> > same policies and behave accordingly? >> >> > > >> >> > >> >> > Yes, they should have the same policies. >> >> > >> >> >> >> Then, the scenario of change of policy in the LMA is conflicting >> >> with this assumption unless policies changed also on MN. >> >> >> > As mentioned by Pierrick, a pragmatic and basic way on policy can be >> > appplied on MN in first round. For current flow, the MN should follow >> the >> > LMA's change of traffic routing. And the MN initates any flow accordin= g >> to >> > the default policy configuration. No dynamic policy maintenance is >> needed on >> > MN. >> >> This is neither pragmatic nor practical. >> >> An LMA has no basis to unilaterally instruct a MN to route traffic on >> a different interface, as the MN is the only network node that really >> knows how good or bad that interface is. If my MN is attached to a bad >> WiFi (say overloaded IETF meeting hotel WiFi) and a reasonable 3G >> network, I don't want the LMA to force me to use the overloaded WiFi. >> >> What's pragmatic and practical is that the MN is provisioned with >> policies (e.g., ANDSF in 3GPP) that indicates e.g. that WiFI should be >> preferred over 3G, and based on this policy and the operating >> environment, if WiFi is considered as working by the MN (not >> overloaded to a point where one can barely run TCP), then the MN >> decides to use WiFi over 3G. Based on this, the LMA should mirror the >> MN's flow routing decision. >> > > In that case, there is few added value to PMIP; with such a terminal cent= ric decision, MIP should be preferred. IMHO, while designing a PMIP-based system, having a working system should prime over PMIP having added value relative to MIP. In other words, correctness trumps features. > If LMA controlled decision has limitation, a terminal centric decision mo= del has also drawbacks. Actually, a good trade-off is a model where the net= work can assist the MN in its decision (the MN makes the final decision, bu= t gets info from the network to make that decision), so avoiding the MN to = attach an access with bad condition. But such a model bring couple of issue= s in PMIP context; these issues has been raised up in the ML MN/network int= eraction, policy synchronization... For sure we should address these issues= , but in the meantime and in the scope of current next dratfs, a decision m= odel where the LMA enforces its decision to the MN can be considered, knowi= ng that LMA decision enforcement cannot be the only answer. What would be the basis for an LMA to enforce that flows are routed on a given interface if the LMA has no availability on the MN's interfaces availability? Absent that, it seems to me that the LMA will never be in a position to enforce anything... I am missing something? --julien From Basavaraj.Patil@nokia.com Mon Feb 14 10:47:10 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CD083A6A15; Mon, 14 Feb 2011 10:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.049 X-Spam-Level: X-Spam-Status: No, score=-101.049 tagged_above=-999 required=5 tests=[AWL=-1.950, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXkQE0t0jui5; Mon, 14 Feb 2011 10:47:09 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id 1C6133A6A00; Mon, 14 Feb 2011 10:47:08 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1EIlPPx028777; Mon, 14 Feb 2011 20:47:30 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Feb 2011 20:47:20 +0200 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 14 Feb 2011 19:46:54 +0100 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.11]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0270.002; Mon, 14 Feb 2011 19:46:54 +0100 From: To: , Thread-Topic: =?big5?B?W25ldGV4dF0gtarOYDogUmU6IFBvbGljeSBhc3N1bXB0aW9ucyBpbiBkcmFmdC1i?= =?big5?Q?ernardos-netext-pmipv6-flowmob?= Thread-Index: AQHLzHeMZwxjAGb1z0iaDMFEieLw7Q== Date: Mon, 14 Feb 2011 18:46:52 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [173.64.197.89] Content-Type: text/plain; charset="big5" Content-ID: <6CCB6DB5BDECDD4C803A7ED818DC4485@nokia.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 14 Feb 2011 18:47:20.0333 (UTC) FILETIME=[9C297BD0:01CBCC77] X-Nokia-AV: Clean Cc: netext-bounces@ietf.org, netext@ietf.org Subject: Re: [netext] =?big5?b?tarOYDogUmU6IFBvbGljeSBhc3N1bXB0aW9ucyBpbiBk?= =?big5?b?cmFmdC1iZXJuYXJkb3MtbmV0ZXh0LXBtaXB2Ni1mbG93bW9i?= X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 14 Feb 2011 18:47:10 -0000 SGkgSnVsaWVuLA0KDQpPbiAyLzE0LzExIDEyOjM0IFBNLCAiZXh0IEp1bGllbiBMYWdhbmllciIg PGp1bGllbi5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6DQoNCj4NCj4+IElmIExNQSBjb250cm9sbGVk IGRlY2lzaW9uIGhhcyBsaW1pdGF0aW9uLCBhIHRlcm1pbmFsIGNlbnRyaWMgZGVjaXNpb24NCj4+ bW9kZWwgaGFzIGFsc28gZHJhd2JhY2tzLiBBY3R1YWxseSwgYSBnb29kIHRyYWRlLW9mZiBpcyBh IG1vZGVsIHdoZXJlDQo+PnRoZSBuZXR3b3JrIGNhbiBhc3Npc3QgdGhlIE1OIGluIGl0cyBkZWNp c2lvbiAodGhlIE1OIG1ha2VzIHRoZSBmaW5hbA0KPj5kZWNpc2lvbiwgYnV0IGdldHMgaW5mbyBm cm9tIHRoZSBuZXR3b3JrIHRvIG1ha2UgdGhhdCBkZWNpc2lvbiksIHNvDQo+PmF2b2lkaW5nIHRo ZSBNTiB0byBhdHRhY2ggYW4gYWNjZXNzIHdpdGggYmFkIGNvbmRpdGlvbi4gQnV0IHN1Y2ggYSBt b2RlbA0KPj5icmluZyBjb3VwbGUgb2YgaXNzdWVzIGluIFBNSVAgY29udGV4dDsgdGhlc2UgaXNz dWVzIGhhcyBiZWVuIHJhaXNlZCB1cA0KPj5pbiB0aGUgTUwgTU4vbmV0d29yayBpbnRlcmFjdGlv biwgcG9saWN5IHN5bmNocm9uaXphdGlvbi4uLiBGb3Igc3VyZSB3ZQ0KPj5zaG91bGQgYWRkcmVz cyB0aGVzZSBpc3N1ZXMsIGJ1dCBpbiB0aGUgbWVhbnRpbWUgYW5kIGluIHRoZSBzY29wZSBvZg0K Pj5jdXJyZW50IG5leHQgZHJhdGZzLCBhIGRlY2lzaW9uIG1vZGVsIHdoZXJlIHRoZSBMTUEgZW5m b3JjZXMgaXRzDQo+PmRlY2lzaW9uIHRvIHRoZSBNTiBjYW4gYmUgY29uc2lkZXJlZCwga25vd2lu ZyB0aGF0IExNQSBkZWNpc2lvbg0KPj5lbmZvcmNlbWVudCBjYW5ub3QgYmUgdGhlIG9ubHkgYW5z d2VyLg0KPg0KPldoYXQgd291bGQgYmUgdGhlIGJhc2lzIGZvciBhbiBMTUEgdG8gZW5mb3JjZSB0 aGF0IGZsb3dzIGFyZSByb3V0ZWQgb24NCj5hIGdpdmVuIGludGVyZmFjZSBpZiB0aGUgTE1BIGhh cyBubyBhdmFpbGFiaWxpdHkgb24gdGhlIE1OJ3MNCj5pbnRlcmZhY2VzIGF2YWlsYWJpbGl0eT8N Cg0KR29vZCBxdWVzdGlvbi4gVGhlIExNQSBvbmx5IGtub3dzIHRoYXQgYW4gTU4gaXMgcmVnaXN0 ZXJlZCB2aWEgbXVsdGlwbGUNCk1BR3MgKGxldHMgYXNzdW1lIG92ZXIgZGlmZmVyZW50IGludGVy ZmFjZXMpLiBIZW5jZSBpdCBjYW4gcm91dGUgdHJhZmZpYw0KdmlhIGVpdGhlciBvZiB0aGVzZSBN QUdzIGJhc2VkIG9uIGp1c3QgdGhhdCBpbmZvcm1hdGlvbi4NCklmIHRoZSBNQUcgdmlhIHdoaWNo IHRoZSBwYWNrZXRzIGFyZSByb3V0ZWQgY2Fubm90IGRlbGl2ZXIgdGhlIHBhY2tldHMgdG8NCnRo ZSBNTiBvdmVyIHRoZSByZWxldmFudCBpbnRlcmZhY2UsIGl0IE1BWSBpbmRpY2F0ZSBmYWlsdXJl IHdoaWNoIGNhdXNlcw0KdGhlIExNQSB0byByb3V0ZSBwYWNrZXRzIHZpYSB0aGUgb3RoZXIgTUFH IChpbnRlcmZhY2UpLg0KDQpGcm9tIHRoZSBwb2ludCBvZiBzcGVjaWZ5aW5nIGZsb3cgbW9iaWxp dHkgdy5yLnQgUE1JUDYsIGlzIGl0IG5vdA0Kc3VmZmljaWVudCB0aGF0IHRoZSBhYmlsaXR5IHRv IHJvdXRlIHBhY2tldHMgdmlhIGFub3RoZXIgTUFHL3ByZWZpeCBpcw0KZW5hYmxlZCBmb3IgYW4g b25nb2luZyBmbG93PyBXaXRob3V0IGFuIGV4cGxpY2l0IGluZGljYXRpb24gaWYgdGhlIE1OIGlz DQphY3R1YWxseSBhdHRhY2hlZCB0byB0aGF0IE1BRyBhbmQgdGhlIGxpbmsgY29uZGl0aW9ucyBv ZiB0aGUgaW50ZXJmYWNlIHZpYQ0Kd2hpY2ggdGhlIE1OIGlzIGF0dGFjaGVkIHRvIHRoYXQgTUFH Lg0KDQoNCj4NCj5BYnNlbnQgdGhhdCwgaXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgTE1BIHdpbGwg bmV2ZXIgYmUgaW4gYSBwb3NpdGlvbg0KPnRvIGVuZm9yY2UgYW55dGhpbmcuLi4gSSBhbSBtaXNz aW5nIHNvbWV0aGluZz8NCg0KVGhlIExNQSBtYXkgc2ltcGx5IHJvdXRlIHRoZSBwYWNrZXRzIHRv IHRoZSBvdGhlciBNQUcvaW50ZXJmYWNlIGJhc2VkIG9uDQp0aGUgcG9saWN5LiANCldoZXRoZXIg aXQgd2lsbCByZXN1bHQgaW4gZHJvcHBlZCBwYWNrZXRzIGlzIGEgc2VwYXJhdGUgaXNzdWUuDQoN Ci1SYWoNCg0KPg0KPi0tanVsaWVuDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj5uZXRleHQgbWFpbGluZyBsaXN0DQo+bmV0ZXh0QGlldGYub3JnDQo+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRleHQNCg0K From gerardog@qualcomm.com Mon Feb 14 10:50:41 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 874153A6A15 for ; Mon, 14 Feb 2011 10:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.871 X-Spam-Level: X-Spam-Status: No, score=-105.871 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilvNoB6F9Y39 for ; Mon, 14 Feb 2011 10:50:38 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 4D6A23A6D55 for ; Mon, 14 Feb 2011 10:50:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1297709461; x=1329245461; h=from:to:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:content-transfer-encoding: mime-version; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20"cjbc@it.uc3m.es"=20,=20"netext@i etf.org"=20|Subject:=20RE:=20[netext]=20 On=20the=20flow=20mobility=20discussion|Thread-Topic:=20[ netext]=20On=20the=20flow=20mobility=20discussion |Thread-Index:=20AQHLzC3R7TVXS5QJdUG2WPkzXX0owpQBVcTQ |Date:=20Mon,=2014=20Feb=202011=2018:50:58=20+0000 |Message-ID:=20|References:=20<1297677607.4514 .71.camel@acorde.it.uc3m.es>|In-Reply-To:=20<1297677607.4 514.71.camel@acorde.it.uc3m.es>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|x-originating-ip:=20[172.30.48.1] |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=r/TiDV0eOoYmxqq+H7JweONpUYtGyE/3OmNkfUln5xU=; b=roWZsqK4ci7N8ckvnGz72hSzvlB9JDrOj1SPzcLsjrTS7fEBKiWbGKd2 PCK6cTLSRBuHLrPJV7BURcTqkHxtoUod/YvKjVIn2opYWgpnWGncmyzlm KMycdOHqFLMs05qmQEnbFgfRcz3+5dyOansViNGSfha0wvfrjfvI6H2ZX g=; X-IronPort-AV: E=McAfee;i="5400,1158,6257"; a="74203826" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 14 Feb 2011 10:50:59 -0800 X-IronPort-AV: E=Sophos;i="4.60,469,1291622400"; d="scan'208";a="115946447" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 14 Feb 2011 10:50:59 -0800 Received: from NASANEXD01E.na.qualcomm.com ([fe80::6555:8c37:4ee3:efc4]) by nasanexhc07.na.qualcomm.com ([172.30.39.190]) with mapi id 14.01.0270.001; Mon, 14 Feb 2011 10:50:58 -0800 From: "Giaretta, Gerardo" To: "cjbc@it.uc3m.es" , "netext@ietf.org" Thread-Topic: [netext] On the flow mobility discussion Thread-Index: AQHLzC3R7TVXS5QJdUG2WPkzXX0owpQBVcTQ Date: Mon, 14 Feb 2011 18:50:58 +0000 Message-ID: References: <1297677607.4514.71.camel@acorde.it.uc3m.es> In-Reply-To: <1297677607.4514.71.camel@acorde.it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.48.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netext] On the flow mobility discussion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 14 Feb 2011 18:50:41 -0000 Hi Carlos, Thanks for summarizing the discussion. Few points below. > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of > Carlos Jes=FAs Bernardos Cano > Sent: Monday, February 14, 2011 2:00 AM > To: netext@ietf.org > Subject: [netext] On the flow mobility discussion >=20 > Hi all, >=20 > First of all, thanks for the active and lively discussion. I think that w= e are > slowly making some progress. For the sake of making progress, let me try = to > summarize the discussion (well, actually, my view of it), pose some quest= ions > and propose some next steps: >=20 > - Trigger for flow mobility. We have heard at least two main opinions on > this: a) triggers can only come from the MAG (based on L2 signaling from = the > MN), and b) triggers can come from the MAG or from the LMA. Strong points= of > a): strictly follows current RFC 5213 and allows to support scenarios in = which > the MN can signal to the MAG events relevant to flow mobility via L2-spec= ific > signaling. Here it is my first question: to me > L2 triggers and L2 signaling are not the same thing, RFC5213 requires L2 > triggers to be in place (AFAIK, it can also work based on IPv6 ND, with s= ome > assumptions on how to get the MNID and set the HI) for example to detect = when > a MN has attached. However, L2 signaling between the MN and MAG are a bit > different (it implies the existence of a communication channel for contro= l > purposes between MAG and MN that is able to convey information > relevant/relative to a L3 protocol). Do we want to restrict the solution = to > the scenarios in which this L2 signaling channel is present? To cite one > example, one of the approaches that has been proposed in the ML requires = the > MN to signal via L2 (over an attachment through iface X) about events of = iface > Y. >=20 > Regarding b) Julien (and other folks) have asked about scenarios that req= uire > that. I think 3G offloading is one of the scenarios that requires that to= be > supported. If an operator has an MN that is attached to WLAN and 3G > simultaneously wants (because of network load conditions) to offload some > flows from 3G to WLAN on demand, I think this should be supported, and LM= A > initiated flow mobility is the way to do it. Some folks have said that th= e MN > is the only one that knows the quality of the signal it receives and this= is > mostly true (note that there are solutions than allows the owner of the W= LAN > to know of the quality and status of the network), but it is also true th= at in > current celular networks handovers are controlled by the network (based o= n > signal quality reports from the MN). To me PMIPv6 follows the same model: > network controlled __IP__ mobility. >=20 I asked few questions in an email which I think was directed to Telemaco an= d others but never got a reply. The basic point is that nobody has answered= how the LMA knows if the MN is still in a reasonable WLAN coverage, how lo= aded WLAN is, etc. There is a huge different between cellular networks and = WLANs: in cellular networks the handovers are controlled by the network bec= ause the MN always provides measurement reports about what the MN sees to t= he network. This is not in place for inter-technology handovers between WLA= N and 3G and this is why you cannot safely assume the LMA will take the cor= rect decision.=20 I don't think this approach b) brings any value and I actually think it cre= ates a lot of problems.=20 > - On the RFC5213 model and extensions to it. We can debate (as we are > doing) on the pros and cons of different technical approaches, that's wha= t we > can do. However, I disagree with the idea that adding new messages betwee= n LMA > and MAG (if they are necessary) is fundamentally changing the protocol an= d > that we need to change the charter, ask the ADs, etc. Current charter say= s on > this regard: >=20 > "The working group will determine what protocol extensions are required > between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to support th= e > ability for an interface (at the IP layer) to transmit packets over diffe= rent > media, the ability to distribute specific traffic flows on different medi= a > components of that interface, and making this work with the handover hint= s in > the base protocol. The relevant protocol extensions will be developed as > necessary." >=20 > I think all technical approaches discussed so far are fine with the above > text. Even one could read that text as preventing from adding new handove= r > hints (which has been proposed as one of the solutions), though that's no= t my > reading. >=20 > - On the technical approach itself. If we forget for a second about the L= MA- > triggered event, and we just think of MAG triggered ones, there have been= two > fundamental approaches proposed so far. I think Tran summarized them very= well > in a previous e-mail. Let me try it again for the sake of this discussion= : a) > extensions to RFC5213 to support dynamically adding and removing interfac= es to > mobility sessions, and b) extensions to > RFC5213 (based on standardized solutions developed in the MEXT WG) to all= ow > dynamic prefix management (and use that as a way to enable flow mobility)= . > Option a) does requires to modify conceptual data structures defined in > RFC5213 as well as state machines (to support the new behavior). Option b= ) > does not require modifications to the mobility session related data > structures, but on the other hand adds new ones (related to flow bindings= ) and > also modifies state machines. Option b) leverages on existing MEXT work. >=20 > To me, in order to enable flow mobility in PMIPv6, there are two main thi= ngs > needed (on the network side): the ability for the LMA to perform flow rou= ting > (i.e. not just routing based on IP destination prefix) and to allow the M= AG to > route prefixes that have not been delegated by the LMA on the initial > interface attachment of the MN (i.e. to support the dynamic modification = of > the prefixes -- associated to a particular MN -- that the MAG is aware of= ). Of > course, we need on the mobile side the ability to receive and send packet= s > simultaneously through different physical interfaces (regardless of the I= Ps > used). IMO, both technical approaches a) and b) above meet the technical > requirements without posing any issue related to implementation complexit= y > (both follows the KISS principle) or charter compliance. >=20 I think comments were made that you don't need any additional prefix manage= ment for the purpose of flow mobility, in particular if you consider the MA= G triggered scenarios. > To sum up this long e-mail, I see two main issues that need to be resolve= d to > be able to progress: >=20 > - Trigger issue. I see the need for both LMA and MAG initiated. > Therefore I propose to work on a solution that supports BOTH.=20 As mentioned above, I don't see why we should support something which is ba= sed on wrong assumptions and it does not provide any benefit. Therefore I d= isagree to support the LMA-triggered solution.=20 Thanks Gerardo=20 > Different people > have expressed their preferences to support both and I don't see any majo= r > issue on that. The only required change to support both is the addition o= f > some signaling between LMA and MAG. >=20 > - Technical approach issue (interface adding to mobility sessions vs "flo= w > bindings based" approach). I don't see major issues in any of them. Curre= nt > draft follows the second and I prefer to keep using it, unless there is a > clear advantage (that I don't see at this point) of using the first. >=20 > Comments? >=20 > Thanks, >=20 > Carlos >=20 > -- > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 From julien.ietf@gmail.com Mon Feb 14 11:02:14 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A39023A6D9B for ; Mon, 14 Feb 2011 11:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.253 X-Spam-Level: X-Spam-Status: No, score=-3.253 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkTYcvnkOg2X for ; Mon, 14 Feb 2011 11:02:13 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id C954F3A6D97 for ; Mon, 14 Feb 2011 11:02:12 -0800 (PST) Received: by ewy8 with SMTP id 8so2778997ewy.31 for ; Mon, 14 Feb 2011 11:02:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UquhGb+p13uYUYGLFxFjuD4oLGycjEklf2OzCJkMUcM=; b=gfVwBqK6rCkynrBT2MYt+AFeRn0w3PPXSLbKEv3Wy5BQH9sQIa6IX1foLdwmf8TxPx 0+g6kfnNQpvtzk7W0gzWsJhaNq02KbxzIQQ6Za/Cr7kUwt0NStHZ6V9T6L7mVMvbOq2M Zvyi44c68WeAfr48/VbYVHRa+h5Uunp2sq7LM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KeSZ/w0tibXqzrFhOSjwM2yEGVykg+RqhUouFIDaJqmLEnTW7LyAxHvba4u4ZewxYt 50aMhDoZkzE2FfwUZfQoqQG5KvYXlBRN0sYIH+dQdX6Gq6q1AbJ/vGFH8iJ3q1ExnzxK VWJXgcxKM8CORKZZsmxqhipUprkEf+DN1aif8= MIME-Version: 1.0 Received: by 10.223.74.206 with SMTP id v14mr4954694faj.66.1297710142058; Mon, 14 Feb 2011 11:02:22 -0800 (PST) Received: by 10.223.74.142 with HTTP; Mon, 14 Feb 2011 11:02:22 -0800 (PST) In-Reply-To: <1297677607.4514.71.camel@acorde.it.uc3m.es> References: <1297677607.4514.71.camel@acorde.it.uc3m.es> Date: Mon, 14 Feb 2011 11:02:22 -0800 Message-ID: From: Julien Laganier To: cjbc@it.uc3m.es Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] On the flow mobility discussion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 14 Feb 2011 19:02:14 -0000 Hi Carlos, I am trying to answer some of your questions inline below, but I am afraid this comes at the cost of having to re-ask the same questions again and again: 2011/2/14 Carlos Jes=FAs Bernardos Cano : > Hi all, > > First of all, thanks for the active and lively discussion. I think that > we are slowly making some progress. For the sake of making progress, let > me try to summarize the discussion (well, actually, my view of it), pose > some questions and propose some next steps: > > - Trigger for flow mobility. We have heard at least two main opinions on > this: a) triggers can only come from the MAG (based on L2 signaling from > the MN), and b) triggers can come from the MAG or from the LMA. Strong > points of a): strictly follows current RFC 5213 and allows to support > scenarios in which the MN can signal to the MAG events relevant to flow > mobility via L2-specific signaling. Here it is my first question: to me > L2 triggers and L2 signaling are not the same thing, RFC5213 requires L2 > triggers to be in place (AFAIK, it can also work based on IPv6 ND, with > some assumptions on how to get the MNID and set the HI) for example to > detect when a MN has attached. Well, the L2 trigger has a cause, which is most certainly that some L2 signaling occured, or, did not occured (e.g. L2 timer goes off.) As such, there is little sense in making distinction between the two in the context of that discussion. > However, L2 signaling between th= e MN and > MAG are a bit different (it implies the existence of a communication > channel for control purposes between MAG and MN that is able to convey > information relevant/relative to a L3 protocol). Do we want to restrict > the solution to the scenarios in which this L2 signaling channel is > present? See my point above. When the L2 attaches (through L2 signaling, I don't know of any wireless network attachment that happens by magic), the MAG is triggered to attach this L2 interface to a PMIPv6 session. So I don't know what restrictions we would be making by requiring L2 signaling / triggers. This is already there in RFC5213. > To cite one example, one of the approaches that ha= s been > proposed in the ML requires the MN to signal via L2 (over an attachment > through iface X) about events of iface Y. The approach I've been proposing requires MN to signal via L2 iface X that iface X be attached to a session. Nothing more, nothing less, all of which is already required per 5213. In effect, the only added requirement placed on L2 signaling compared to 5213 is that, in addition the existing inter-interface handoff indicator (attach iface X to session in lieu of iface Y), we add a new simutaneous attach handoff indicator (that is, not really a handoff, attach iface X to session along any existing ifaces Y, Z etc. that were already attached.) We'd also need the ability to selectively detach an interface and keep the other ifaces in the session attached. That could be done through use of the same HI I just introduced, but in a deregistration PBU. > Regarding b) Julien (and other folks) have asked about scenarios that > require that. I think 3G offloading is one of the scenarios that > requires that to be supported. If an operator has an MN that is attached > to WLAN and 3G simultaneously wants (because of network load conditions) > to offload some flows from 3G to WLAN on demand, I think this should be > supported, and LMA initiated flow mobility is the way to do it. As I've explained in other notes, there is no basis for the LMA to unilateraly decide where to send flows. This simply doesn't work in a variety of cases where a wireless L2 might be attached but provide no meaningful connectivity. > = Some > folks have said that the MN is the only one that knows the quality of > the signal it receives and this is mostly true (note that there are > solutions than allows the owner of the WLAN to know of the quality and > status of the network), but it is also true that in current celular > networks handovers are controlled by the network (based on signal > quality reports from the MN). To me PMIPv6 follows the same model: > network controlled __IP__ mobility. You cannot generalize what a cellular network does with a homogeneous collections of radio access technologies that are all developed in the same system, and include signaling for the terminal equipment to report to a control network node what is the signal quality, to an IP layer mobility management in which the radio techonologies were not developed to fit together, and you do not have terminal to network signaling for radio signal quality. Further, even if you could (but surely you can't), let me point out that in the network controlled cellular systems that are deployed and/or specified, the entity that takes the decision is an edge entity (e.g. SGSN, MME) which is closer to MAG rather than a hierarchical entity (e.g., GGSN, PGW) similar to LMA. Thus your statement that the LMA being in control would make PMIPv6 following the same model than cellular network seems to be factually incorrect. > - On the RFC5213 model and extensions to it. We can debate (as we are > doing) on the pros and cons of different technical approaches, that's > what we can do. However, I disagree with the idea that adding new > messages between LMA and MAG (if they are necessary) is fundamentally > changing the protocol and that we need to change the charter, ask the > ADs, etc. Current charter says on this regard: > > "The working group will determine what protocol extensions are > required between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) > to support the ability for an interface (at the IP layer) to > transmit packets over different media, the ability to distribute > specific traffic flows on different media components of that > interface, and making this work with the handover hints in the base > protocol. The relevant protocol extensions will be developed as > necessary." The point I have relentlessly making is that, in order to provide flow mobility, you do NOT need to change the basics of RFC 5213 session management, and thus, from out charter item it follows that we have determined that this needs not to be changed, and thus you need not to extend it. That, is unless somebody comes up with the killer usecase, which would have to involve more than: "I want to allocate a different prefix" because this has nothing to do with flow mobility. > I think all technical approaches discussed so far are fine with the > above text. Even one could read that text as preventing from adding new > handover hints (which has been proposed as one of the solutions), though > that's not my reading. Truly no. Instead of doing charter exegesis, let's have those who favor the alternative model come up with a valid and motivated usecase.... Please.... > - On the technical approach itself. If we forget for a second about the > LMA-triggered event, and we just think of MAG triggered ones, there have > been two fundamental approaches proposed so far. I think Tran summarized > them very well in a previous e-mail. Let me try it again for the sake of > this discussion: a) extensions to RFC5213 to support dynamically adding > and removing interfaces to mobility sessions, and b) extensions to > RFC5213 (based on standardized solutions developed in the MEXT WG) to > allow dynamic prefix management (and use that as a way to enable flow > mobility). Option a) does requires to modify conceptual data structures > defined in RFC5213 as well as state machines (to support the new > behavior). Option b) does not require modifications to the mobility > session related data structures, but on the other hand adds new ones > (related to flow bindings) and also modifies state machines. Option b) > leverages on existing MEXT work. Option b) is dynamic prefix management and is not necessary per se to do flow mobility so I am starting to really wonder why we are still discussing it in the first place. Option a) works. Unless it is not sufficient to support a motivated and real usecase, there is no reason for us to even discuss anything else. > To me, in order to enable flow mobility in PMIPv6, there are two main > things needed (on the network side): the ability for the LMA to perform > flow routing (i.e. not just routing based on IP destination prefix) and > to allow the MAG to route prefixes that have not been delegated by the > LMA on the initial interface attachment of the MN (i.e. to support the > dynamic modification of the prefixes -- associated to a particular MN -- > that the MAG is aware of). Of course, we need on the mobile side the > ability to receive and send packets simultaneously through different > physical interfaces (regardless of the IPs used). IMO, both technical > approaches a) and b) above meet the technical requirements without > posing any issue related to implementation complexity (both follows the > KISS principle) or charter compliance. a) works. b) is unecessary unless proven otherwise, which hasn't happen. > > To sum up this long e-mail, I see two main issues that need to be > resolved to be able to progress: > > - Trigger issue. I see the need for both LMA and MAG initiated. > Therefore I propose to work on a solution that supports BOTH. Different > people have expressed their preferences to support both and I don't see > any major issue on that. The only required change to support both is the > addition of some signaling between LMA and MAG. There is a major issue that there is no basis for an LMA to decide where to send flows, and nobody was able to refute the argument I put forth why this doesn't work. So I propose we work on a solution that works, that is, MAG initiated. > - Technical approach issue (interface adding to mobility sessions vs > "flow bindings based" approach). I don't see major issues in any of > them. Current draft follows the second and I prefer to keep using it, > unless there is a clear advantage (that I don't see at this point) of > using the first. The clear advantage of using the first is that it supports flow mobility. You don't need to have two ways of doing something in a standards, unless you have to. And you don't have to it seems, or I missed the email describing the valid and motivated use case to do dynamic prefix management in lieu of simple flow mobility. If we want to move forward, we have to settle for simple single model I've proposed, or the proponent of doing otherwise have to come up with answers to the questions I've put forth eventually. I'll let them choose. --julien From Basavaraj.Patil@nokia.com Mon Feb 14 11:10:28 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2A573A6DA6 for ; Mon, 14 Feb 2011 11:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.122 X-Spam-Level: X-Spam-Status: No, score=-103.122 tagged_above=-999 required=5 tests=[AWL=0.477, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6+ps4Za31ff for ; Mon, 14 Feb 2011 11:10:21 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 5A9BF3A6DA7 for ; Mon, 14 Feb 2011 11:10:21 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1EJADwn023404; Mon, 14 Feb 2011 21:10:42 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Feb 2011 21:09:27 +0200 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 14 Feb 2011 20:09:26 +0100 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.11]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0270.002; Mon, 14 Feb 2011 20:09:26 +0100 From: To: , , Thread-Topic: [netext] On the flow mobility discussion Thread-Index: AQHLzC3b2PmyCF1oA0GpKJdDZ+HPZpQBRxwA//+gkIA= Date: Mon, 14 Feb 2011 19:09:23 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [173.64.197.89] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Feb 2011 19:09:27.0251 (UTC) FILETIME=[B3111A30:01CBCC7A] X-Nokia-AV: Clean Subject: Re: [netext] On the flow mobility discussion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 14 Feb 2011 19:10:28 -0000 Gerardo, On 2/14/11 12:50 PM, "ext Giaretta, Gerardo" wrote: > >>=20 > >I asked few questions in an email which I think was directed to Telemaco >and others but never got a reply. The basic point is that nobody has >answered how the LMA knows if the MN is still in a reasonable WLAN >coverage, how loaded WLAN is, etc. There is a huge different between >cellular networks and WLANs: in cellular networks the handovers are >controlled by the network because the MN always provides measurement >reports about what the MN sees to the network. This is not in place for >inter-technology handovers between WLAN and 3G and this is why you cannot >safely assume the LMA will take the correct decision. > >I don't think this approach b) brings any value and I actually think it >creates a lot of problems. Regarding the question about whether the LMA knows the status of the MNs connectivity to a MAG and the wifi link characteristics that it is using to attach to a MAG: The LMA has no awareness of the MNs connectivity/link status to a MAG. It only knows that the MN has attached via a MAG. And if the policy indicates that traffic be routed via that MAG/interface, it will do so. It could result in packets being dropped if the MN has moved out of that wifi coverage or the link is congested. In terms of the scope of this work, the intent is on specifying how the traffic associated with a session is switched to an alternate MAG. The points that you raise are outside the scope of this work. -Raj From julien.ietf@gmail.com Mon Feb 14 11:16:14 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFA203A6DA4; Mon, 14 Feb 2011 11:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.033 X-Spam-Level: X-Spam-Status: No, score=-3.033 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+KGYtDWA0UL; Mon, 14 Feb 2011 11:16:14 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 92E8F3A6D55; Mon, 14 Feb 2011 11:16:13 -0800 (PST) Received: by ewy8 with SMTP id 8so2788994ewy.31 for ; Mon, 14 Feb 2011 11:16:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pzgp5SiyrwmTNH0fY3LTOBx3mkptVZDjT1OB4koAfKY=; b=ug76ZEC6OZ1NUhl+cuSgvXvTtyqdsfsk+6OCFEh/RjGsOSUgYhtcuRCiPAy4h568f7 74T+tAtZzxR+dWAz24DuEQoYFLZKPHUPD34H9TQnCDVOkxfC/Y4hZioOiAar3k+Di6RN UtZiZCUAb9ERYXnGZ0iyOJjjqpnGn4i8lluHM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=f87fWoUldGkdGrc0XPoipG7EDKqE565HE8ACQOF43PouXgU/Pjr6OXGOhKYL0F7AyJ XSkDxUYqKnurjv6eSU/MRf8WIma12cY4fgzJI78V2PINuu7Dp91wqNCEFWAeMYIxHBm1 Vmhw3tEkUic75dZvHX2QnjTuJg9zKSd8ricIk= MIME-Version: 1.0 Received: by 10.223.119.68 with SMTP id y4mr3341808faq.104.1297710991621; Mon, 14 Feb 2011 11:16:31 -0800 (PST) Received: by 10.223.74.142 with HTTP; Mon, 14 Feb 2011 11:16:31 -0800 (PST) In-Reply-To: References: Date: Mon, 14 Feb 2011 11:16:31 -0800 Message-ID: From: Julien Laganier To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Cc: netext-bounces@ietf.org, netext@ietf.org Subject: Re: [netext] =?utf-8?b?562U5aSNOiBSZTogUG9saWN5IGFzc3VtcHRpb25zIGlu?= =?utf-8?q?_draft-bernardos-netext-pmipv6-flowmob?= X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 14 Feb 2011 19:16:14 -0000 Hi Raj, 2011/2/14 : > Hi Julien, > > On 2/14/11 12:34 PM, "ext Julien Laganier" wrote: > >> >>> If LMA controlled decision has limitation, a terminal centric decision >>>model has also drawbacks. Actually, a good trade-off is a model where >>>the network can assist the MN in its decision (the MN makes the final >>>decision, but gets info from the network to make that decision), so >>>avoiding the MN to attach an access with bad condition. But such a model >>>bring couple of issues in PMIP context; these issues has been raised up >>>in the ML MN/network interaction, policy synchronization... For sure we >>>should address these issues, but in the meantime and in the scope of >>>current next dratfs, a decision model where the LMA enforces its >>>decision to the MN can be considered, knowing that LMA decision >>>enforcement cannot be the only answer. >> >>What would be the basis for an LMA to enforce that flows are routed on >>a given interface if the LMA has no availability on the MN's >>interfaces availability? > > Good question. Thanks :) > The LMA only knows that an MN is registered via multiple > MAGs (lets assume over different interfaces). Right. > Hence it can route traffic via either of these MAGs based on just that information. This is where we disagree. > If the MAG via which the packets are routed cannot deliver the packets to > the MN over the relevant interface, it MAY indicate failure which causes > the LMA to route packets via the other MAG (interface). How would the MAG knows that the MN doesn't receive packets over said interface? > From the point of specifying flow mobility w.r.t PMIP6, is it not > sufficient that the ability to route packets via another MAG/prefix is > enabled for an ongoing flow? Delivery of an ongoing flow started of MAG X thru MAG Y is flow mobility sure (please let's not bring the prefix discussion in there, it's something different.) That being said, I am not aware of any systems where the choice of radio interfaces is done by a hierarchical mobility anchor, and I've also pointed why that doesn't work. > Without an explicit indication if the MN is > actually attached to that MAG and the link conditions of the interface via > which the MN is attached to that MAG. No. >>Absent that, it seems to me that the LMA will never be in a position >>to enforce anything... I am missing something? > > The LMA may simply route the packets to the other MAG/interface based on > the policy. Whether it will result in dropped packets is a separate issue. If the "separate issue" result in the LMA routing all traffic through a WiFi interface where none of the packets are making it to the MN, I have to say that the separate issue makes the whole system useless, and thus unless we have a solution to the separate, there is little point in designing the system. --julien From Basavaraj.Patil@nokia.com Mon Feb 14 11:43:09 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74E5D3A6DA3 for ; Mon, 14 Feb 2011 11:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.911 X-Spam-Level: X-Spam-Status: No, score=-100.911 tagged_above=-999 required=5 tests=[AWL=-1.812, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNOZlrqsOoBR for ; Mon, 14 Feb 2011 11:43:08 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id 129113A6D9B for ; Mon, 14 Feb 2011 11:43:07 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1EJhO6L026898; Mon, 14 Feb 2011 21:43:30 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Feb 2011 21:43:22 +0200 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 14 Feb 2011 20:43:21 +0100 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.11]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0270.002; Mon, 14 Feb 2011 20:43:21 +0100 From: To: Thread-Topic: =?big5?B?W25ldGV4dF0gtarOYDogUmU6IFBvbGljeSBhc3N1bXB0aW9ucyBpbiBkcmFmdC1i?= =?big5?Q?ernardos-netext-pmipv6-flowmob?= Thread-Index: AQHLzH9ulBTOEhbIpEWGuDkfZk5ZrQ== Date: Mon, 14 Feb 2011 19:42:45 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [173.64.197.89] Content-Type: text/plain; charset="big5" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 14 Feb 2011 19:43:22.0392 (UTC) FILETIME=[701AF980:01CBCC7F] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] =?big5?b?tarOYDogUmU6IFBvbGljeSBhc3N1bXB0aW9ucyBpbiBk?= =?big5?b?cmFmdC1iZXJuYXJkb3MtbmV0ZXh0LXBtaXB2Ni1mbG93bW9i?= X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 14 Feb 2011 19:43:09 -0000 DQpJbmxpbmU6DQoNCk9uIDIvMTQvMTEgMToxNiBQTSwgImV4dCBKdWxpZW4gTGFnYW5pZXIiIDxq dWxpZW4uaWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KDQo+SGkgUmFqLA0KPg0KPjIwMTEvMi8xNCAg PEJhc2F2YXJhai5QYXRpbEBub2tpYS5jb20+Og0KPj4gSGkgSnVsaWVuLA0KPj4NCj4+IE9uIDIv MTQvMTEgMTI6MzQgUE0sICJleHQgSnVsaWVuIExhZ2FuaWVyIiA8anVsaWVuLmlldGZAZ21haWwu Y29tPg0KPj53cm90ZToNCj4+DQo+Pj4NCj4+Pj4gSWYgTE1BIGNvbnRyb2xsZWQgZGVjaXNpb24g aGFzIGxpbWl0YXRpb24sIGEgdGVybWluYWwgY2VudHJpYyBkZWNpc2lvbg0KPj4+Pm1vZGVsIGhh cyBhbHNvIGRyYXdiYWNrcy4gQWN0dWFsbHksIGEgZ29vZCB0cmFkZS1vZmYgaXMgYSBtb2RlbCB3 aGVyZQ0KPj4+PnRoZSBuZXR3b3JrIGNhbiBhc3Npc3QgdGhlIE1OIGluIGl0cyBkZWNpc2lvbiAo dGhlIE1OIG1ha2VzIHRoZSBmaW5hbA0KPj4+PmRlY2lzaW9uLCBidXQgZ2V0cyBpbmZvIGZyb20g dGhlIG5ldHdvcmsgdG8gbWFrZSB0aGF0IGRlY2lzaW9uKSwgc28NCj4+Pj5hdm9pZGluZyB0aGUg TU4gdG8gYXR0YWNoIGFuIGFjY2VzcyB3aXRoIGJhZCBjb25kaXRpb24uIEJ1dCBzdWNoIGENCj4+ Pj5tb2RlbA0KPj4+PmJyaW5nIGNvdXBsZSBvZiBpc3N1ZXMgaW4gUE1JUCBjb250ZXh0OyB0aGVz ZSBpc3N1ZXMgaGFzIGJlZW4gcmFpc2VkIHVwDQo+Pj4+aW4gdGhlIE1MIE1OL25ldHdvcmsgaW50 ZXJhY3Rpb24sIHBvbGljeSBzeW5jaHJvbml6YXRpb24uLi4gRm9yIHN1cmUgd2UNCj4+Pj5zaG91 bGQgYWRkcmVzcyB0aGVzZSBpc3N1ZXMsIGJ1dCBpbiB0aGUgbWVhbnRpbWUgYW5kIGluIHRoZSBz Y29wZSBvZg0KPj4+PmN1cnJlbnQgbmV4dCBkcmF0ZnMsIGEgZGVjaXNpb24gbW9kZWwgd2hlcmUg dGhlIExNQSBlbmZvcmNlcyBpdHMNCj4+Pj5kZWNpc2lvbiB0byB0aGUgTU4gY2FuIGJlIGNvbnNp ZGVyZWQsIGtub3dpbmcgdGhhdCBMTUEgZGVjaXNpb24NCj4+Pj5lbmZvcmNlbWVudCBjYW5ub3Qg YmUgdGhlIG9ubHkgYW5zd2VyLg0KPj4+DQo+Pj5XaGF0IHdvdWxkIGJlIHRoZSBiYXNpcyBmb3Ig YW4gTE1BIHRvIGVuZm9yY2UgdGhhdCBmbG93cyBhcmUgcm91dGVkIG9uDQo+Pj5hIGdpdmVuIGlu dGVyZmFjZSBpZiB0aGUgTE1BIGhhcyBubyBhdmFpbGFiaWxpdHkgb24gdGhlIE1OJ3MNCj4+Pmlu dGVyZmFjZXMgYXZhaWxhYmlsaXR5Pw0KPj4NCj4+IEdvb2QgcXVlc3Rpb24uDQo+DQo+VGhhbmtz IDopDQo+DQo+PiBUaGUgTE1BIG9ubHkga25vd3MgdGhhdCBhbiBNTiBpcyByZWdpc3RlcmVkIHZp YSBtdWx0aXBsZQ0KPj4gTUFHcyAobGV0cyBhc3N1bWUgb3ZlciBkaWZmZXJlbnQgaW50ZXJmYWNl cykuDQo+DQo+UmlnaHQuDQo+DQo+PiBIZW5jZSBpdCBjYW4gcm91dGUgdHJhZmZpYyB2aWEgZWl0 aGVyIG9mIHRoZXNlIE1BR3MgYmFzZWQgb24ganVzdCB0aGF0DQo+PmluZm9ybWF0aW9uLg0KPg0K PlRoaXMgaXMgd2hlcmUgd2UgZGlzYWdyZWUuDQoNCldoeT8gVGhlIExNQSBjYW4gcm91dGUgcGFj a2V0cyB0byB0aGUgTU4gZWl0aGVyIHZpYSBNQUcxIG9yIE1BRzIuIElmIHNvbWUNCnBvbGljeSBp bmRpY2F0ZXMgdGhhdCBzb21lIHRyYWZmaWMgbmVlZHMgdG8gYmUgcm91dGVkIHZpYSBNQUcyLCBp dCBjYW4gZG8NCnRoYXQgYXMgbG9uZyBhcyBpdCBpcyBhd2FyZSB0aGF0IHRoZSBNTiBpcyByZWdp c3RlcmVkIHZpYSBNQUcyLg0KTm90IHN1cmUgSSB1bmRlcnN0YW5kIHlvdXIgZGlzYWdyZWVtZW50 IG9uIHRoaXMgcG9pbnQuDQoNCj4NCj4+IElmIHRoZSBNQUcgdmlhIHdoaWNoIHRoZSBwYWNrZXRz IGFyZSByb3V0ZWQgY2Fubm90IGRlbGl2ZXIgdGhlIHBhY2tldHMNCj4+dG8NCj4+IHRoZSBNTiBv dmVyIHRoZSByZWxldmFudCBpbnRlcmZhY2UsIGl0IE1BWSBpbmRpY2F0ZSBmYWlsdXJlIHdoaWNo IGNhdXNlcw0KPj4gdGhlIExNQSB0byByb3V0ZSBwYWNrZXRzIHZpYSB0aGUgb3RoZXIgTUFHIChp bnRlcmZhY2UpLg0KPg0KPkhvdyB3b3VsZCB0aGUgTUFHIGtub3dzIHRoYXQgdGhlIE1OIGRvZXNu J3QgcmVjZWl2ZSBwYWNrZXRzIG92ZXIgc2FpZA0KPmludGVyZmFjZT8NCg0KSXQgd291bGQgbm90 LiBVbmxlc3MgdGhlcmUgYXJlIHNvbWUgb3RoZXIgb3V0LW9mLWJhbmQgbWVhbnMgd2hpY2ggYXJl DQpiZXlvbmQgdGhlIFBNSVA2IHByb3RvY29sIGl0c2VsZiB0byBkbyBzby4NCg0KPg0KPj4gRnJv bSB0aGUgcG9pbnQgb2Ygc3BlY2lmeWluZyBmbG93IG1vYmlsaXR5IHcuci50IFBNSVA2LCBpcyBp dCBub3QNCj4+IHN1ZmZpY2llbnQgdGhhdCB0aGUgYWJpbGl0eSB0byByb3V0ZSBwYWNrZXRzIHZp YSBhbm90aGVyIE1BRy9wcmVmaXggaXMNCj4+IGVuYWJsZWQgZm9yIGFuIG9uZ29pbmcgZmxvdz8N Cj4NCj5EZWxpdmVyeSBvZiBhbiBvbmdvaW5nIGZsb3cgc3RhcnRlZCBvZiBNQUcgWCB0aHJ1IE1B RyBZIGlzIGZsb3cNCj5tb2JpbGl0eSBzdXJlIChwbGVhc2UgbGV0J3Mgbm90IGJyaW5nIHRoZSBw cmVmaXggZGlzY3Vzc2lvbiBpbiB0aGVyZSwNCj5pdCdzIHNvbWV0aGluZyBkaWZmZXJlbnQuKSBU aGF0IGJlaW5nIHNhaWQsIEkgYW0gbm90IGF3YXJlIG9mIGFueQ0KPnN5c3RlbXMgd2hlcmUgdGhl IGNob2ljZSBvZiByYWRpbyBpbnRlcmZhY2VzIGlzIGRvbmUgYnkgYSBoaWVyYXJjaGljYWwNCj5t b2JpbGl0eSBhbmNob3IsIGFuZCBJJ3ZlIGFsc28gcG9pbnRlZCB3aHkgdGhhdCBkb2Vzbid0IHdv cmsuDQoNClNvIEkgZ3Vlc3Mgd2UgYWdyZWUgdGhhdCBzd2l0Y2hpbmcgYSBmbG93IGZyb20gTUFH eCB0byBNQUd5IGlzIGZsb3cNCm1vYmlsaXR5LiANClRoZSBjaG9pY2Ugb2Ygd2hpY2ggYW5jaG9y IChNQUcpIHRocnUgd2hpY2ggdHJhZmZpYyByb3V0ZWQgaXMgYSBjaG9pY2Ugb2YNCnBvbGljeSB0 aGF0IGNvdWxkIGJlIHNpbXBseSBjb25maWd1cmVkIGF0IHRoZSBMTUEuIFRoZSBMTUEga25vd3Mg dGhhdCB0aGUNCk1OIGlzIGF0dGFjaGVkIHZpYSBNQUd5IG92ZXIgYSB3aWZpIGludGVyZmFjZSB2 aWEgdGhlIEFjY2VzcyB0eXBlDQppbmRpY2F0aW9uIGluIHRoZSBQQlUuIFNvIGl0IGNvdWxkIHNp bXBseSBtYWtlIHRoZSBkZWNpc2lvbiB0byByb3V0ZSBzb21lDQp0cmFmZmljIHR5cGVzIGZyb20g TUFHeCB0byBNQUd5Lg0KV2h5IGlzIHRoaXMgbm90IGRvYWJsZT8NCg0KPg0KPj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgV2l0aG91dCBhbiBleHBsaWNpdA0K Pj5pbmRpY2F0aW9uIGlmIHRoZSBNTiBpcw0KPj4gYWN0dWFsbHkgYXR0YWNoZWQgdG8gdGhhdCBN QUcgYW5kIHRoZSBsaW5rIGNvbmRpdGlvbnMgb2YgdGhlIGludGVyZmFjZQ0KPj52aWENCj4+IHdo aWNoIHRoZSBNTiBpcyBhdHRhY2hlZCB0byB0aGF0IE1BRy4NCj4NCj5Oby4NCg0KPz8/IFRoZSBN TiBhdHRhY2hlcyB2aWEgTUFHeSAod2lmaSkgd2hpY2ggcmVzdWx0cyBpbiBpdCBiZWluZyByZWdp c3RlcmVkDQphdCB0aGUgTE1BLiBOb3cgdGhlcmUgaXMgbm8gd2F5IHRvIGluZGljYXRlIGNvbnRp bnVlZCBhdHRhY2htZW50IHRocnUgTUFHeQ0Kb3IgbGluayBjb25kaXRpb25zLiBTbyB1bmxlc3Mg dGhlcmUgaXMgYSBkZXJlZyBmcm9tIE1BRzIsIHRoZSBMTUEgd2lsbA0KcHJlc3VtZSB0aGF0IHRo ZSBNTiBpcyBhdHRhY2hlZCB2aWEgTUFHeS4NCk9mIGNvdXJzZSBvbiBhIHdpZmkgYWNjZXNzLCB0 aGUgTU4gbWF5IGV4cGxpY3RseSBkZXJlZ2lzdGVyL2Rpc2Fzc29jaWF0ZQ0Kd2hpY2ggd291bGQg Y2F1c2UgdGhlIE1BR3kgdG8gc2VuZCB0aGUgZGVyZWdpc3RlciBub3RpZmljYXRpb24gdG8gdGhl IExNQQ0KYXQgd2hpY2ggdGltZSB0aGUgTE1BIHdvdWxkIHN3aXRjaCB0cmFmZmljIGJhY2sgdG8g TUFHeC4NCg0KPg0KPj4+QWJzZW50IHRoYXQsIGl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlIExNQSB3 aWxsIG5ldmVyIGJlIGluIGEgcG9zaXRpb24NCj4+PnRvIGVuZm9yY2UgYW55dGhpbmcuLi4gSSBh bSBtaXNzaW5nIHNvbWV0aGluZz8NCj4+DQo+PiBUaGUgTE1BIG1heSBzaW1wbHkgcm91dGUgdGhl IHBhY2tldHMgdG8gdGhlIG90aGVyIE1BRy9pbnRlcmZhY2UgYmFzZWQgb24NCj4+IHRoZSBwb2xp Y3kuIFdoZXRoZXIgaXQgd2lsbCByZXN1bHQgaW4gZHJvcHBlZCBwYWNrZXRzIGlzIGEgc2VwYXJh dGUNCj4+aXNzdWUuDQo+DQo+SWYgdGhlICJzZXBhcmF0ZSBpc3N1ZSIgcmVzdWx0IGluIHRoZSBM TUEgcm91dGluZyBhbGwgdHJhZmZpYyB0aHJvdWdoDQo+YSBXaUZpIGludGVyZmFjZSB3aGVyZSBu b25lIG9mIHRoZSBwYWNrZXRzIGFyZSBtYWtpbmcgaXQgdG8gdGhlIE1OLCBJDQo+aGF2ZSB0byBz YXkgdGhhdCB0aGUgc2VwYXJhdGUgaXNzdWUgbWFrZXMgdGhlIHdob2xlIHN5c3RlbSB1c2VsZXNz LA0KPmFuZCB0aHVzIHVubGVzcyB3ZSBoYXZlIGEgc29sdXRpb24gdG8gdGhlIHNlcGFyYXRlLCB0 aGVyZSBpcyBsaXR0bGUNCj5wb2ludCBpbiBkZXNpZ25pbmcgdGhlIHN5c3RlbS4NCg0KT2theS4g VW5kZXJzdGFuZCB5b3VyIGNvbmNlcm4gYWJvdXQgdGhlIGxhY2sgb2YgY2xhcml0eSBmcm9tIGEg c3lzdGVtDQpsZXZlbCBzb2x1dGlvbiBwZXJzcGVjdGl2ZS4NCkxldHMgc2VlIGlmIHdlIGNhbiBm aW5kIHNvbWUgYW5zd2VycyBvciBvcHRpb25zIG9mIGhvdyB0byBzb2x2ZSB0aGUNCnByb2JsZW0u DQoNCi1SYWogDQoNCj4NCj4tLWp1bGllbg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+bmV0ZXh0IG1haWxpbmcgbGlzdA0KPm5ldGV4dEBpZXRmLm9y Zw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0DQoNCg== From julien.ietf@gmail.com Mon Feb 14 11:56:37 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 363323A6DA5 for ; Mon, 14 Feb 2011 11:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.055 X-Spam-Level: X-Spam-Status: No, score=-2.055 tagged_above=-999 required=5 tests=[AWL=-0.868, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yehRUaW2GdE7 for ; Mon, 14 Feb 2011 11:56:36 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id B59B23A6C4E for ; Mon, 14 Feb 2011 11:56:35 -0800 (PST) Received: by fxm9 with SMTP id 9so6105154fxm.31 for ; Mon, 14 Feb 2011 11:56:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZrA15/GqmUh5hIxS6ChxC1dCW2yrvQSREZE04hPU9x8=; b=cn/gooMt2huuumRf6GAnkdTmBtycNlvih01fS6Pt54Iysg+p8LihMJb2KAJBbZDwv7 Oy6gNM9GpTZIwdSl8SAfkoitxGDYAGW1aFHJMSeyA+LapqbHLFvgh1MTzA/GNQOt9hur pJJ0U4i/bj51Tje2cHpg7ngFF2QGU8HeY8Wlg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mvjycnGhd43rkOXTn2eR4sYjV3TuE52vwGxpTWrrAFDqckjZaxnIJCqXTEctnKM513 EeDdtxDjPvOPDIoc8vqvGc9ub7nSKFtQ3BgGRErrPorJZoYdcUNzRxHHWRuBMzkwsI6z 6iX5i0cEOGcflSmRMHMOE2haeR4oBltqXI+DE= MIME-Version: 1.0 Received: by 10.223.74.206 with SMTP id v14mr5022908faj.66.1297713384963; Mon, 14 Feb 2011 11:56:24 -0800 (PST) Received: by 10.223.74.142 with HTTP; Mon, 14 Feb 2011 11:56:24 -0800 (PST) In-Reply-To: References: Date: Mon, 14 Feb 2011 11:56:24 -0800 Message-ID: From: Julien Laganier To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] =?utf-8?b?562U5aSNOiBSZTogUG9saWN5IGFzc3VtcHRpb25zIGlu?= =?utf-8?q?_draft-bernardos-netext-pmipv6-flowmob?= X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 14 Feb 2011 19:56:37 -0000 Inline as well: 2011/2/14 : > > Inline: > > On 2/14/11 1:16 PM, "ext Julien Laganier" wrote: > >>Hi Raj, >> >>2011/2/14 =A0: >>> Hi Julien, >>> >>> On 2/14/11 12:34 PM, "ext Julien Laganier" >>>wrote: >>> >>>> >>>>> If LMA controlled decision has limitation, a terminal centric decisio= n >>>>>model has also drawbacks. Actually, a good trade-off is a model where >>>>>the network can assist the MN in its decision (the MN makes the final >>>>>decision, but gets info from the network to make that decision), so >>>>>avoiding the MN to attach an access with bad condition. But such a >>>>>model >>>>>bring couple of issues in PMIP context; these issues has been raised u= p >>>>>in the ML MN/network interaction, policy synchronization... For sure w= e >>>>>should address these issues, but in the meantime and in the scope of >>>>>current next dratfs, a decision model where the LMA enforces its >>>>>decision to the MN can be considered, knowing that LMA decision >>>>>enforcement cannot be the only answer. >>>> >>>>What would be the basis for an LMA to enforce that flows are routed on >>>>a given interface if the LMA has no availability on the MN's >>>>interfaces availability? >>> >>> Good question. >> >>Thanks :) >> >>> The LMA only knows that an MN is registered via multiple >>> MAGs (lets assume over different interfaces). >> >>Right. >> >>> Hence it can route traffic via either of these MAGs based on just that >>>information. >> >>This is where we disagree. > > Why? The LMA can route packets to the MN either via MAG1 or MAG2. If some > policy indicates that some traffic needs to be routed via MAG2, it can do > that as long as it is aware that the MN is registered via MAG2. > Not sure I understand your disagreement on this point. As per what follows. The MAG2 can register the MN based on the MN being attached there, but if the radio link is terrible and MN receives nothing from MAG2, there's little point in routing traffic to MAG2. Or does offload means we're developing a solution blackholes part of the traffic? >>> If the MAG via which the packets are routed cannot deliver the packets >>>to >>> the MN over the relevant interface, it MAY indicate failure which cause= s >>> the LMA to route packets via the other MAG (interface). >> >>How would the MAG knows that the MN doesn't receive packets over said >>interface? > > It would not. So LMA would send part of the traffic into a blackhole. > Unless there are some other out-of-band means which are > beyond the PMIP6 protocol itself to do so. They are not only beyond the PMIPv6 protocol, they do not exist! So we'd be designing a PMIPv6 extension that doesn't work in the real world, really? >>> From the point of specifying flow mobility w.r.t PMIP6, is it not >>> sufficient that the ability to route packets via another MAG/prefix is >>> enabled for an ongoing flow? >> >>Delivery of an ongoing flow started of MAG X thru MAG Y is flow >>mobility sure (please let's not bring the prefix discussion in there, >>it's something different.) That being said, I am not aware of any >>systems where the choice of radio interfaces is done by a hierarchical >>mobility anchor, and I've also pointed why that doesn't work. > > So I guess we agree that switching a flow from MAGx to MAGy is flow > mobility. Yes. > The choice of which anchor (MAG) thru which traffic routed is a choice of > policy that could be simply configured at the LMA. The LMA knows that the > MN is attached via MAGy over a wifi interface via the Access type > indication in the PBU. So it could simply make the decision to route some > traffic types from MAGx to MAGy. > Why is this not doable? Because beyond the fact that MN is attached at MAGy, the LMA know nothing about actual connectivity beyond MN and MAGy. It's not a policy choice that has to be made, it is a contextual choice, with policy as input to the decision. In the current state of affair the only entity that has the context is the MN. Thus, the LMA deciding all by himself based on policy is not doable. >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0Without an explicit >>>indication if the MN is >>> actually attached to that MAG and the link conditions of the interface >>>via >>> which the MN is attached to that MAG. >> >>No. > > ??? The MN attaches via MAGy (wifi) which results in it being registered > at the LMA. Now there is no way to indicate continued attachment thru MAG= y > or link conditions. So unless there is a dereg from MAG2, the LMA will > presume that the MN is attached via MAGy. And possibly send traffic into a blackhole. You're proving my point. > Of course on a wifi access, the MN may explictly deregister/disassociate > which would cause the MAGy to send the deregister notification to the LMA > at which time the LMA would switch traffic back to MAGx. In which case the MN has the final say. So in the system you're advocating, the only way by which a MN can avoid having traffic blackholed on a bad WiFi is by not attaching the WiFi at all... But then we don't need flow mobility do we? >>>>Absent that, it seems to me that the LMA will never be in a position >>>>to enforce anything... I am missing something? >>> >>> The LMA may simply route the packets to the other MAG/interface based o= n >>> the policy. Whether it will result in dropped packets is a separate >>>issue. >> >>If the "separate issue" result in the LMA routing all traffic through >>a WiFi interface where none of the packets are making it to the MN, I >>have to say that the separate issue makes the whole system useless, >>and thus unless we have a solution to the separate, there is little >>point in designing the system. > > Okay. Understand your concern about the lack of clarity from a system > level solution perspective. Ok you see my point. Good. > Lets see if we can find some answers or options of how to solve the > problem. Thanks, I'm waiting. --julien From julien.ietf@gmail.com Mon Feb 14 15:21:54 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51F963A6DDC for ; Mon, 14 Feb 2011 15:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=-0.627, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9xH0mPIgYoa for ; Mon, 14 Feb 2011 15:21:53 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 491C63A6DDA for ; Mon, 14 Feb 2011 15:21:53 -0800 (PST) Received: by fxm9 with SMTP id 9so6307709fxm.31 for ; Mon, 14 Feb 2011 15:22:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8qTVqPf5+jjl/XNSkCtpQDZbgPaIAGvBgOiKwgPmbNw=; b=SONgBBWML8Pk7HESYzCrC5rHFHC39ZBQSVTsnjyxpC0MkfeLiDpr7QMY7Gsh0ukPiD +lJrOww9cuZX+/U+f74ysJOU8ItheOZQO0PWDWvgLqE/OZBj61UBirN3qlRQN4uGmKPg C41T10cBtaNWPxHKR6d/6fcOpchqNJ+YIT40k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=mDSh6MB562zVcwIrsHdKI9C+XfQyB/DboU8dQ6ChCF3UQcHMgAIo3dCx7IRwStNv2Q x1ZvnGfkbKmPVNc1qML4XTPkXHgOIfGp5CWIETzx6Z/u3xZgGePqzPp/m+YKSOOeWqPj kfa6HgrBo8MIXSIWBXYo+K7rzxW0wkA/J5qv0= MIME-Version: 1.0 Received: by 10.223.71.200 with SMTP id i8mr4195823faj.142.1297725455430; Mon, 14 Feb 2011 15:17:35 -0800 (PST) Received: by 10.223.74.142 with HTTP; Mon, 14 Feb 2011 15:17:35 -0800 (PST) In-Reply-To: References: Date: Mon, 14 Feb 2011 15:17:35 -0800 Message-ID: From: Julien Laganier To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org Subject: Re: [netext] On the flow mobility discussion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 14 Feb 2011 23:21:54 -0000 Raj, On Mon, Feb 14, 2011 at 11:09 AM, wrote: > > Gerardo, > > On 2/14/11 12:50 PM, "ext Giaretta, Gerardo" wrote: > >> >> >>I asked few questions in an email which I think was directed to Telemaco >>and others but never got a reply. The basic point is that nobody has >>answered how the LMA knows if the MN is still in a reasonable WLAN >>coverage, how loaded WLAN is, etc. There is a huge different between >>cellular networks and WLANs: in cellular networks the handovers are >>controlled by the network because the MN always provides measurement >>reports about what the MN sees to the network. This is not in place for >>inter-technology handovers between WLAN and 3G and this is why you cannot >>safely assume the LMA will take the correct decision. >> >>I don't think this approach b) brings any value and I actually think it >>creates a lot of problems. > > > Regarding the question about whether the LMA knows the status of the MNs > connectivity to a MAG and the wifi link characteristics that it is using > to attach to a MAG: > The LMA has no awareness of the MNs connectivity/link status to a MAG. It > only knows that the MN has attached via a MAG. And if the policy indicates > that traffic be routed via that MAG/interface, it will do so. > > It could result in packets being dropped if the MN has moved out of that > wifi coverage or the link is congested. In terms of the scope of this > work, the intent is on specifying how the traffic associated with a > session is switched to an alternate MAG. The points that you raise are > outside the scope of this work. I apologize if I start to sound sarcastic, but the only thing that seems in scope of this work is how to realize a function (LMA-initiated flow handoffs) that cannot be possibly used meaningfully without a bunch of other mechanisms (MN-LMA policy coordination, MN-LMA radio quality reporting, etc. ) that do not exist in any form and are also out of scope of this work... As I said, absent these mechanisms, or a usecase and proof of feasibility, developing an LMA-initiated flow handof function makes no sense to me. --julien From sfaccin@rim.com Mon Feb 14 15:25:20 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BB4F3A6DCE for ; Mon, 14 Feb 2011 15:25:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.724 X-Spam-Level: X-Spam-Status: No, score=-5.724 tagged_above=-999 required=5 tests=[AWL=0.875, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmjRFl1+B0OV for ; Mon, 14 Feb 2011 15:25:19 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id B762B3A6DA9 for ; Mon, 14 Feb 2011 15:25:18 -0800 (PST) X-AuditID: 0a666446-b7bb4ae00000372f-49-4d59b9f4ef1c Received: from XCH138CNC.rim.net ( [10.65.20.127]) by mhs04ykf.rim.net (RIM Mail) with SMTP id DA.77.14127.4F9B95D4; Mon, 14 Feb 2011 18:25:41 -0500 (EST) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH138CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Feb 2011 18:25:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" content-transfer-encoding: base64 Date: Mon, 14 Feb 2011 17:25:39 -0600 Message-ID: <680854867F7FD04BB9B06EB8ACA8D5AC0601C1C9@XCH02DFW.rim.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] On the flow mobility discussion Thread-Index: AcvMng1W8FEWVyaxTSOT1+asY0Y6LwAADCMw References: From: "Stefano Faccin" To: "Julien Laganier" , X-OriginalArrivalTime: 14 Feb 2011 23:25:41.0174 (UTC) FILETIME=[7EA39560:01CBCC9E] X-Brightmail-Tracker: AAAAAgAAAZEXZhpt Cc: netext@ietf.org Subject: Re: [netext] On the flow mobility discussion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 14 Feb 2011 23:25:20 -0000 SnVsaWVuLA0KQXMgb25lIGNhbiBpbWFnaW5lIGNvbnNpZGVyaW5nIG15IHByZXZpb3VzIGNv bW1lbnRzIEkgZnVsbHkgc3VwcG9ydCB5b3VyIHBvaW50IGJlbG93LiBBcyBJIGluZGljYXRl ZCBwcmV2aW91c2x5LCB0aGVyZSBpcyBpbiBhZGRpdGlvbiB0aGUgZmFjdCB0aGF0IHdoYXQg aXMgYmVpbmcgZGV2ZWxvcGVkIHdpbGwgbm90IGJlIGFibGUgdG8gc3VwcG9ydCBjdXJyZW50 IGRldmVsb3BtZW50IHNjZW5hcmlvcywgd2hpY2ggcmVzdHJpY3RzIHRoZSBhcHBsaWNhYmls aXR5IG9mIHRoZSBzb2x1dGlvbi4gDQpDaGVlcnMsDQoNClN0ZWZhbm8gRmFjY2luDQoNClN0 YW5kYXJkcyBNYW5hZ2VyDQpSZXNlYXJjaCBJbiBNb3Rpb24gQ29ycG9yYXRpb24gDQo1MDAw IFJpdmVyc2lkZSBEcml2ZSANCkJ1aWxkaW5nIDYsIEJyYXpvcyBFYXN0LCBTdGUuIDEwMA0K SXJ2aW5nLCBUZXhhcyA3NTAzOSBVU0EgDQpPZmZpY2U6ICg5NzIpIDkxMCAzNDUxwqAgDQpJ bnRlcm5hbDogODIwLjYzNDUxDQo6ICg1MTApIDIzMCA4NDIyDQp3d3cucmltLmNvbTsgd3d3 LmJsYWNrYmVycnkuY29tIA0KDQoNCg0K74GQIENvbnNpZGVyIHRoZSBlbnZpcm9ubWVudCBi ZWZvcmUgcHJpbnRpbmcuDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IG5ldGV4dC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bmV0ZXh0LWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBKdWxpZW4gTGFnYW5pZXINClNlbnQ6IE1vbmRheSwgRmVicnVh cnkgMTQsIDIwMTEgMzoxOCBQTQ0KVG86IEJhc2F2YXJhai5QYXRpbEBub2tpYS5jb20NCkNj OiBuZXRleHRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbmV0ZXh0XSBPbiB0aGUgZmxvdyBt b2JpbGl0eSBkaXNjdXNzaW9uDQoNClJhaiwNCg0KT24gTW9uLCBGZWIgMTQsIDIwMTEgYXQg MTE6MDkgQU0sICA8QmFzYXZhcmFqLlBhdGlsQG5va2lhLmNvbT4gd3JvdGU6DQo+DQo+IEdl cmFyZG8sDQo+DQo+IE9uIDIvMTQvMTEgMTI6NTAgUE0sICJleHQgR2lhcmV0dGEsIEdlcmFy ZG8iIDxnZXJhcmRvZ0BxdWFsY29tbS5jb20+IHdyb3RlOg0KPg0KPj4NCj4+DQo+PkkgYXNr ZWQgZmV3IHF1ZXN0aW9ucyBpbiBhbiBlbWFpbCB3aGljaCBJIHRoaW5rIHdhcyBkaXJlY3Rl ZCB0byBUZWxlbWFjbw0KPj5hbmQgb3RoZXJzIGJ1dCBuZXZlciBnb3QgYSByZXBseS4gVGhl IGJhc2ljIHBvaW50IGlzIHRoYXQgbm9ib2R5IGhhcw0KPj5hbnN3ZXJlZCBob3cgdGhlIExN QSBrbm93cyBpZiB0aGUgTU4gaXMgc3RpbGwgaW4gYSByZWFzb25hYmxlIFdMQU4NCj4+Y292 ZXJhZ2UsIGhvdyBsb2FkZWQgV0xBTiBpcywgZXRjLiBUaGVyZSBpcyBhIGh1Z2UgZGlmZmVy ZW50IGJldHdlZW4NCj4+Y2VsbHVsYXIgbmV0d29ya3MgYW5kIFdMQU5zOiBpbiBjZWxsdWxh ciBuZXR3b3JrcyB0aGUgaGFuZG92ZXJzIGFyZQ0KPj5jb250cm9sbGVkIGJ5IHRoZSBuZXR3 b3JrIGJlY2F1c2UgdGhlIE1OIGFsd2F5cyBwcm92aWRlcyBtZWFzdXJlbWVudA0KPj5yZXBv cnRzIGFib3V0IHdoYXQgdGhlIE1OIHNlZXMgdG8gdGhlIG5ldHdvcmsuIFRoaXMgaXMgbm90 IGluIHBsYWNlIGZvcg0KPj5pbnRlci10ZWNobm9sb2d5IGhhbmRvdmVycyBiZXR3ZWVuIFdM QU4gYW5kIDNHIGFuZCB0aGlzIGlzIHdoeSB5b3UgY2Fubm90DQo+PnNhZmVseSBhc3N1bWUg dGhlIExNQSB3aWxsIHRha2UgdGhlIGNvcnJlY3QgZGVjaXNpb24uDQo+Pg0KPj5JIGRvbid0 IHRoaW5rIHRoaXMgYXBwcm9hY2ggYikgYnJpbmdzIGFueSB2YWx1ZSBhbmQgSSBhY3R1YWxs eSB0aGluayBpdA0KPj5jcmVhdGVzIGEgbG90IG9mIHByb2JsZW1zLg0KPg0KPg0KPiBSZWdh cmRpbmcgdGhlIHF1ZXN0aW9uIGFib3V0IHdoZXRoZXIgdGhlIExNQSBrbm93cyB0aGUgc3Rh dHVzIG9mIHRoZSBNTnMNCj4gY29ubmVjdGl2aXR5IHRvIGEgTUFHIGFuZCB0aGUgd2lmaSBs aW5rIGNoYXJhY3RlcmlzdGljcyB0aGF0IGl0IGlzIHVzaW5nDQo+IHRvIGF0dGFjaCB0byBh IE1BRzoNCj4gVGhlIExNQSBoYXMgbm8gYXdhcmVuZXNzIG9mIHRoZSBNTnMgY29ubmVjdGl2 aXR5L2xpbmsgc3RhdHVzIHRvIGEgTUFHLiBJdA0KPiBvbmx5IGtub3dzIHRoYXQgdGhlIE1O IGhhcyBhdHRhY2hlZCB2aWEgYSBNQUcuIEFuZCBpZiB0aGUgcG9saWN5IGluZGljYXRlcw0K PiB0aGF0IHRyYWZmaWMgYmUgcm91dGVkIHZpYSB0aGF0IE1BRy9pbnRlcmZhY2UsIGl0IHdp bGwgZG8gc28uDQo+DQo+IEl0IGNvdWxkIHJlc3VsdCBpbiBwYWNrZXRzIGJlaW5nIGRyb3Bw ZWQgaWYgdGhlIE1OIGhhcyBtb3ZlZCBvdXQgb2YgdGhhdA0KPiB3aWZpIGNvdmVyYWdlIG9y IHRoZSBsaW5rIGlzIGNvbmdlc3RlZC4gSW4gdGVybXMgb2YgdGhlIHNjb3BlIG9mIHRoaXMN Cj4gd29yaywgdGhlIGludGVudCBpcyBvbiBzcGVjaWZ5aW5nIGhvdyB0aGUgdHJhZmZpYyBh c3NvY2lhdGVkIHdpdGggYQ0KPiBzZXNzaW9uIGlzIHN3aXRjaGVkIHRvIGFuIGFsdGVybmF0 ZSBNQUcuIFRoZSBwb2ludHMgdGhhdCB5b3UgcmFpc2UgYXJlDQo+IG91dHNpZGUgdGhlIHNj b3BlIG9mIHRoaXMgd29yay4NCg0KSSBhcG9sb2dpemUgaWYgSSBzdGFydCB0byBzb3VuZCBz YXJjYXN0aWMsIGJ1dCB0aGUgb25seSB0aGluZyB0aGF0DQpzZWVtcyBpbiBzY29wZSBvZiB0 aGlzIHdvcmsgaXMgaG93IHRvIHJlYWxpemUgYSBmdW5jdGlvbg0KKExNQS1pbml0aWF0ZWQg IGZsb3cgaGFuZG9mZnMpIHRoYXQgY2Fubm90IGJlIHBvc3NpYmx5IHVzZWQNCm1lYW5pbmdm dWxseSB3aXRob3V0IGEgYnVuY2ggb2Ygb3RoZXIgbWVjaGFuaXNtcyAoTU4tTE1BIHBvbGlj eQ0KY29vcmRpbmF0aW9uLCBNTi1MTUEgcmFkaW8gcXVhbGl0eSByZXBvcnRpbmcsIGV0Yy4g KSB0aGF0IGRvIG5vdCBleGlzdA0KaW4gYW55IGZvcm0gYW5kIGFyZSBhbHNvIG91dCBvZiBz Y29wZSBvZiB0aGlzIHdvcmsuLi4NCg0KQXMgSSBzYWlkLCBhYnNlbnQgdGhlc2UgbWVjaGFu aXNtcywgb3IgYSB1c2VjYXNlIGFuZCBwcm9vZiBvZg0KZmVhc2liaWxpdHksIGRldmVsb3Bp bmcgYW4gTE1BLWluaXRpYXRlZCBmbG93IGhhbmRvZiBmdW5jdGlvbiBtYWtlcyBubw0Kc2Vu c2UgdG8gbWUuDQoNCi0tanVsaWVuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KbmV0ZXh0IG1haWxpbmcgbGlzdA0KbmV0ZXh0QGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGV4dA0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0KVGhpcyB0cmFuc21pc3Npb24gKGluY2x1ZGluZyBhbnkgYXR0YWNobWVu dHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiwgcHJpdmlsZWdlZCBt YXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3RlY3RlZCBieSB0aGUgc29saWNpdG9y LWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZpbGVnZXMpLCBvciBjb25zdGl0dXRl IG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbiBi eSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGlzIHByb2hpYml0 ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBw bGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMg aW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4gVXNlLCBkaXNzZW1pbmF0aW9uLCBkaXN0 cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIHRyYW5zbWlzc2lvbiBieSB1bmlu dGVuZGVkIHJlY2lwaWVudHMgaXMgbm90IGF1dGhvcml6ZWQgYW5kIG1heSBiZSB1bmxhd2Z1 bC4NCg== From hesham@elevatemobile.com Mon Feb 14 16:02:17 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41C233A6DDF for ; Mon, 14 Feb 2011 16:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQ+YCQMofCVS for ; Mon, 14 Feb 2011 16:02:15 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 861253A6C3F for ; Mon, 14 Feb 2011 16:02:14 -0800 (PST) Received: from [122.110.171.194] (helo=[192.168.0.2]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1Pp8NE-0000js-IY; Tue, 15 Feb 2011 11:02:33 +1100 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 15 Feb 2011 11:02:24 +1100 From: Hesham Soliman To: Stefano Faccin Message-ID: Thread-Topic: [netext] On the flow mobility discussion Thread-Index: AcvMng1W8FEWVyaxTSOT1+asY0Y6LwAADCMwAAFYb/Y= In-Reply-To: <680854867F7FD04BB9B06EB8ACA8D5AC0601C1C9@XCH02DFW.rim.net> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Authenticated-User: hesham@elevatemobile.com Cc: netext@ietf.org Subject: Re: [netext] On the flow mobility discussion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 00:02:17 -0000 +1. I can't say I'm surprised we're still talking about this issue in 2011 but I think it's disappointing to see the exact same arguments being made again and again while the proponents of this proposal keep pushing in the same direction, while being totally indifferent to reason. Hesham On 15/02/11 10:25 AM, "Stefano Faccin" wrote: > Julien, > As one can imagine considering my previous comments I fully support your = point > below. As I indicated previously, there is in addition the fact that what= is > being developed will not be able to support current development scenarios= , > which restricts the applicability of the solution. > Cheers, >=20 > Stefano Faccin >=20 > Standards Manager > Research In Motion Corporation > 5000 Riverside Drive > Building 6, Brazos East, Ste. 100 > Irving, Texas 75039 USA > Office: (972) 910 3451=C2=A0 > Internal: 820.63451 > : (510) 230 8422 > www.rim.com; www.blackberry.com >=20 >=20 >=20 > =EF=81=90 Consider the environment before printing. >=20 >=20 > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of > Julien Laganier > Sent: Monday, February 14, 2011 3:18 PM > To: Basavaraj.Patil@nokia.com > Cc: netext@ietf.org > Subject: Re: [netext] On the flow mobility discussion >=20 > Raj, >=20 > On Mon, Feb 14, 2011 at 11:09 AM, wrote: >>=20 >> Gerardo, >>=20 >> On 2/14/11 12:50 PM, "ext Giaretta, Gerardo" wro= te: >>=20 >>>=20 >>>=20 >>> I asked few questions in an email which I think was directed to Telemac= o >>> and others but never got a reply. The basic point is that nobody has >>> answered how the LMA knows if the MN is still in a reasonable WLAN >>> coverage, how loaded WLAN is, etc. There is a huge different between >>> cellular networks and WLANs: in cellular networks the handovers are >>> controlled by the network because the MN always provides measurement >>> reports about what the MN sees to the network. This is not in place for >>> inter-technology handovers between WLAN and 3G and this is why you cann= ot >>> safely assume the LMA will take the correct decision. >>>=20 >>> I don't think this approach b) brings any value and I actually think it >>> creates a lot of problems. >>=20 >>=20 >> Regarding the question about whether the LMA knows the status of the MNs >> connectivity to a MAG and the wifi link characteristics that it is using >> to attach to a MAG: >> The LMA has no awareness of the MNs connectivity/link status to a MAG. I= t >> only knows that the MN has attached via a MAG. And if the policy indicat= es >> that traffic be routed via that MAG/interface, it will do so. >>=20 >> It could result in packets being dropped if the MN has moved out of that >> wifi coverage or the link is congested. In terms of the scope of this >> work, the intent is on specifying how the traffic associated with a >> session is switched to an alternate MAG. The points that you raise are >> outside the scope of this work. >=20 > I apologize if I start to sound sarcastic, but the only thing that > seems in scope of this work is how to realize a function > (LMA-initiated flow handoffs) that cannot be possibly used > meaningfully without a bunch of other mechanisms (MN-LMA policy > coordination, MN-LMA radio quality reporting, etc. ) that do not exist > in any form and are also out of scope of this work... >=20 > As I said, absent these mechanisms, or a usecase and proof of > feasibility, developing an LMA-initiated flow handof function makes no > sense to me. >=20 > --julien > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext >=20 > --------------------------------------------------------------------- This > transmission (including any attachments) may contain confidential informa= tion, > privileged material (including material protected by the solicitor-client= or > other applicable privileges), or constitute non-public information. Any u= se of > this information by anyone other than the intended recipient is prohibite= d. If > you have received this transmission in error, please immediately reply to= the > sender and delete this information from your system. Use, dissemination, > distribution, or reproduction of this transmission by unintended recipien= ts is > not authorized and may be unlawful. > _______________________________________________ netext mailing > list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From Basavaraj.Patil@nokia.com Mon Feb 14 16:10:15 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6C573A6DE0 for ; Mon, 14 Feb 2011 16:10:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.022 X-Spam-Level: X-Spam-Status: No, score=-103.022 tagged_above=-999 required=5 tests=[AWL=0.577, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWyLgl88sBG2 for ; Mon, 14 Feb 2011 16:10:14 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id B37FE3A6DDD for ; Mon, 14 Feb 2011 16:10:14 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1F0AThQ013403; Tue, 15 Feb 2011 02:10:34 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Feb 2011 02:10:23 +0200 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 15 Feb 2011 01:10:23 +0100 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.11]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0270.002; Tue, 15 Feb 2011 01:10:10 +0100 From: To: Thread-Topic: [netext] On the flow mobility discussion Thread-Index: AQHLzC3b2PmyCF1oA0GpKJdDZ+HPZpQBRxwA//+gkICAAKnugP//qhiA Date: Tue, 15 Feb 2011 00:10:07 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [173.64.197.89] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 15 Feb 2011 00:10:23.0888 (UTC) FILETIME=[BDA94100:01CBCCA4] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] On the flow mobility discussion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 00:10:15 -0000 Julien, I understand the issue about the fact that an MN may have moved out of wifi coverage after registering thru MAGy. Or for that matter the wifi network via which the MN is attached (thru MAGy) is congested or the link quality is poor. And this could happen. But on the flip side, the MN may be attached to a wifi network and is able to send/recv packets thru MAGy with no issues, In which case switching the flow at the LMA would work just fine. Does it not make sense to have a solution for this case? The error case when the packets sent to the MN via MAGy into oblivion cannot be ignored. But neither can you say that there is no way this would work at all. -Raj On 2/14/11 5:17 PM, "ext Julien Laganier" wrote: >Raj, > >On Mon, Feb 14, 2011 at 11:09 AM, wrote: >> >> Gerardo, >> >> On 2/14/11 12:50 PM, "ext Giaretta, Gerardo" >>wrote: >> >>> >>> >>>I asked few questions in an email which I think was directed to Telemaco >>>and others but never got a reply. The basic point is that nobody has >>>answered how the LMA knows if the MN is still in a reasonable WLAN >>>coverage, how loaded WLAN is, etc. There is a huge different between >>>cellular networks and WLANs: in cellular networks the handovers are >>>controlled by the network because the MN always provides measurement >>>reports about what the MN sees to the network. This is not in place for >>>inter-technology handovers between WLAN and 3G and this is why you >>>cannot >>>safely assume the LMA will take the correct decision. >>> >>>I don't think this approach b) brings any value and I actually think it >>>creates a lot of problems. >> >> >> Regarding the question about whether the LMA knows the status of the MNs >> connectivity to a MAG and the wifi link characteristics that it is using >> to attach to a MAG: >> The LMA has no awareness of the MNs connectivity/link status to a MAG. >>It >> only knows that the MN has attached via a MAG. And if the policy >>indicates >> that traffic be routed via that MAG/interface, it will do so. >> >> It could result in packets being dropped if the MN has moved out of that >> wifi coverage or the link is congested. In terms of the scope of this >> work, the intent is on specifying how the traffic associated with a >> session is switched to an alternate MAG. The points that you raise are >> outside the scope of this work. > >I apologize if I start to sound sarcastic, but the only thing that >seems in scope of this work is how to realize a function >(LMA-initiated flow handoffs) that cannot be possibly used >meaningfully without a bunch of other mechanisms (MN-LMA policy >coordination, MN-LMA radio quality reporting, etc. ) that do not exist >in any form and are also out of scope of this work... > >As I said, absent these mechanisms, or a usecase and proof of >feasibility, developing an LMA-initiated flow handof function makes no >sense to me. > >--julien From sfaccin@rim.com Mon Feb 14 16:13:00 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 680893A6DDD for ; Mon, 14 Feb 2011 16:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.812 X-Spam-Level: X-Spam-Status: No, score=-5.812 tagged_above=-999 required=5 tests=[AWL=0.787, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aRJ9a0Yf3r3 for ; Mon, 14 Feb 2011 16:12:59 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id F19A23A6DDB for ; Mon, 14 Feb 2011 16:12:57 -0800 (PST) X-AuditID: 0a666446-b7bb4ae00000372f-c5-4d59c520a3e6 Received: from XCH138CNC.rim.net ( [10.65.20.127]) by mhs04ykf.rim.net (RIM Mail) with SMTP id EB.4A.14127.025C95D4; Mon, 14 Feb 2011 19:13:21 -0500 (EST) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH138CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Feb 2011 19:13:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" content-transfer-encoding: base64 Date: Mon, 14 Feb 2011 18:13:18 -0600 Message-ID: <680854867F7FD04BB9B06EB8ACA8D5AC0601C1DD@XCH02DFW.rim.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] On the flow mobility discussion Thread-Index: AQHLzC3b2PmyCF1oA0GpKJdDZ+HPZpQBRxwA//+gkICAAKnugP//qhiAgAB1qRA= References: From: "Stefano Faccin" To: , X-OriginalArrivalTime: 15 Feb 2011 00:13:21.0210 (UTC) FILETIME=[275A71A0:01CBCCA5] X-Brightmail-Tracker: AAAAAwAAAZEXZUAgF2YabQ== Cc: netext@ietf.org Subject: Re: [netext] On the flow mobility discussion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 00:13:00 -0000 UmFqLA0KSSBhcG9sb2dpemUgZm9yIGJlaW5nIHNsb3csIGJ1dCBJIHJlYWxseSBkbyBub3Qg dW5kZXJzdGFuZCB3aGF0IHlvdSBhcmUgc2F5aW5nLiBEbyB3ZSByZWFsbHkgd2FudCB0byBk ZXZlbG9wIGEgc29sdXRpb24gdGhhdCB3b3JrcyBvbmx5IGluIHRoZSBiZXN0IGNhc2Ugc2Nl bmFyaW8gYW5kIHV0dGVybHkgZGlzcmVnYXJkcyByZWFsaXN0aWMgc2NlbmFyaW9zIGxpa2Ug dGhlIG9uZXMgSnVsaWVuIGFuZCBvdGhlcnMgaGF2ZSBtZW50aW9uZWQ/IElzIHRoaXMgZ29v ZCBlbmdpbmVlcmluZyB3b3JrIGJ5IElFVEY/IFdoYXQgeW91IGFyZSBzYXlpbmcgYmVsb3cg aXMgbGl0ZXJhbGx5IHRoYXQgd2UgYXJlIE9LIGlmIHRoZSBzb2x1dGlvbiBkb2VzIG5vdCB3 b3JrIGluIHNjZW5hcmlvIHRoYXQgY2FuIGluZGVlZCBoYXBwZW4gYW5kIHJhdGhlciBvZnRl biBhbHJlYWR5IHRvZGF5LiBJIGNhbm5vdCBiZWxpZXZlIHdlIGFyZSBzZXJpb3VzbHkgd2ls bGluZyB0byBzZXR0bGUgZm9yIHRoYXQuIA0KDQpDaGVlcnMsDQoNClN0ZWZhbm8gRmFjY2lu DQoNClN0YW5kYXJkcyBNYW5hZ2VyDQpSZXNlYXJjaCBJbiBNb3Rpb24gQ29ycG9yYXRpb24g DQo1MDAwIFJpdmVyc2lkZSBEcml2ZSANCkJ1aWxkaW5nIDYsIEJyYXpvcyBFYXN0LCBTdGUu IDEwMA0KSXJ2aW5nLCBUZXhhcyA3NTAzOSBVU0EgDQpPZmZpY2U6ICg5NzIpIDkxMCAzNDUx wqAgDQpJbnRlcm5hbDogODIwLjYzNDUxDQo6ICg1MTApIDIzMCA4NDIyDQp3d3cucmltLmNv bTsgd3d3LmJsYWNrYmVycnkuY29tIA0KDQoNCg0K74GQIENvbnNpZGVyIHRoZSBlbnZpcm9u bWVudCBiZWZvcmUgcHJpbnRpbmcuDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IG5ldGV4dC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bmV0ZXh0LWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCYXNhdmFyYWouUGF0aWxAbm9raWEuY29tDQpTZW50 OiBNb25kYXksIEZlYnJ1YXJ5IDE0LCAyMDExIDQ6MTAgUE0NClRvOiBqdWxpZW4uaWV0ZkBn bWFpbC5jb20NCkNjOiBuZXRleHRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbmV0ZXh0XSBP biB0aGUgZmxvdyBtb2JpbGl0eSBkaXNjdXNzaW9uDQoNCg0KSnVsaWVuLA0KDQpJIHVuZGVy c3RhbmQgdGhlIGlzc3VlIGFib3V0IHRoZSBmYWN0IHRoYXQgYW4gTU4gbWF5IGhhdmUgbW92 ZWQgb3V0IG9mDQp3aWZpIGNvdmVyYWdlIGFmdGVyIHJlZ2lzdGVyaW5nIHRocnUgTUFHeS4N Ck9yIGZvciB0aGF0IG1hdHRlciB0aGUgd2lmaSBuZXR3b3JrIHZpYSB3aGljaCB0aGUgTU4g aXMgYXR0YWNoZWQgKHRocnUNCk1BR3kpIGlzIGNvbmdlc3RlZCBvciB0aGUgbGluayBxdWFs aXR5IGlzIHBvb3IuDQpBbmQgdGhpcyBjb3VsZCBoYXBwZW4uDQoNCkJ1dCBvbiB0aGUgZmxp cCBzaWRlLCB0aGUgTU4gbWF5IGJlIGF0dGFjaGVkIHRvIGEgd2lmaSBuZXR3b3JrIGFuZCBp cyBhYmxlDQp0byBzZW5kL3JlY3YgcGFja2V0cyB0aHJ1IE1BR3kgd2l0aCBubyBpc3N1ZXMs IEluIHdoaWNoIGNhc2Ugc3dpdGNoaW5nIHRoZQ0KZmxvdyBhdCB0aGUgTE1BIHdvdWxkIHdv cmsganVzdCBmaW5lLg0KDQpEb2VzIGl0IG5vdCBtYWtlIHNlbnNlIHRvIGhhdmUgYSBzb2x1 dGlvbiBmb3IgdGhpcyBjYXNlPyBUaGUgZXJyb3IgY2FzZQ0Kd2hlbiB0aGUgcGFja2V0cyBz ZW50IHRvIHRoZSBNTiB2aWEgTUFHeSBpbnRvIG9ibGl2aW9uIGNhbm5vdCBiZSBpZ25vcmVk Lg0KQnV0IG5laXRoZXIgY2FuIHlvdSBzYXkgdGhhdCB0aGVyZSBpcyBubyB3YXkgdGhpcyB3 b3VsZCB3b3JrIGF0IGFsbC4NCg0KLVJhag0KDQpPbiAyLzE0LzExIDU6MTcgUE0sICJleHQg SnVsaWVuIExhZ2FuaWVyIiA8anVsaWVuLmlldGZAZ21haWwuY29tPiB3cm90ZToNCg0KPlJh aiwNCj4NCj5PbiBNb24sIEZlYiAxNCwgMjAxMSBhdCAxMTowOSBBTSwgIDxCYXNhdmFyYWou UGF0aWxAbm9raWEuY29tPiB3cm90ZToNCj4+DQo+PiBHZXJhcmRvLA0KPj4NCj4+IE9uIDIv MTQvMTEgMTI6NTAgUE0sICJleHQgR2lhcmV0dGEsIEdlcmFyZG8iIDxnZXJhcmRvZ0BxdWFs Y29tbS5jb20+DQo+Pndyb3RlOg0KPj4NCj4+Pg0KPj4+DQo+Pj5JIGFza2VkIGZldyBxdWVz dGlvbnMgaW4gYW4gZW1haWwgd2hpY2ggSSB0aGluayB3YXMgZGlyZWN0ZWQgdG8gVGVsZW1h Y28NCj4+PmFuZCBvdGhlcnMgYnV0IG5ldmVyIGdvdCBhIHJlcGx5LiBUaGUgYmFzaWMgcG9p bnQgaXMgdGhhdCBub2JvZHkgaGFzDQo+Pj5hbnN3ZXJlZCBob3cgdGhlIExNQSBrbm93cyBp ZiB0aGUgTU4gaXMgc3RpbGwgaW4gYSByZWFzb25hYmxlIFdMQU4NCj4+PmNvdmVyYWdlLCBo b3cgbG9hZGVkIFdMQU4gaXMsIGV0Yy4gVGhlcmUgaXMgYSBodWdlIGRpZmZlcmVudCBiZXR3 ZWVuDQo+Pj5jZWxsdWxhciBuZXR3b3JrcyBhbmQgV0xBTnM6IGluIGNlbGx1bGFyIG5ldHdv cmtzIHRoZSBoYW5kb3ZlcnMgYXJlDQo+Pj5jb250cm9sbGVkIGJ5IHRoZSBuZXR3b3JrIGJl Y2F1c2UgdGhlIE1OIGFsd2F5cyBwcm92aWRlcyBtZWFzdXJlbWVudA0KPj4+cmVwb3J0cyBh Ym91dCB3aGF0IHRoZSBNTiBzZWVzIHRvIHRoZSBuZXR3b3JrLiBUaGlzIGlzIG5vdCBpbiBw bGFjZSBmb3INCj4+PmludGVyLXRlY2hub2xvZ3kgaGFuZG92ZXJzIGJldHdlZW4gV0xBTiBh bmQgM0cgYW5kIHRoaXMgaXMgd2h5IHlvdQ0KPj4+Y2Fubm90DQo+Pj5zYWZlbHkgYXNzdW1l IHRoZSBMTUEgd2lsbCB0YWtlIHRoZSBjb3JyZWN0IGRlY2lzaW9uLg0KPj4+DQo+Pj5JIGRv bid0IHRoaW5rIHRoaXMgYXBwcm9hY2ggYikgYnJpbmdzIGFueSB2YWx1ZSBhbmQgSSBhY3R1 YWxseSB0aGluayBpdA0KPj4+Y3JlYXRlcyBhIGxvdCBvZiBwcm9ibGVtcy4NCj4+DQo+Pg0K Pj4gUmVnYXJkaW5nIHRoZSBxdWVzdGlvbiBhYm91dCB3aGV0aGVyIHRoZSBMTUEga25vd3Mg dGhlIHN0YXR1cyBvZiB0aGUgTU5zDQo+PiBjb25uZWN0aXZpdHkgdG8gYSBNQUcgYW5kIHRo ZSB3aWZpIGxpbmsgY2hhcmFjdGVyaXN0aWNzIHRoYXQgaXQgaXMgdXNpbmcNCj4+IHRvIGF0 dGFjaCB0byBhIE1BRzoNCj4+IFRoZSBMTUEgaGFzIG5vIGF3YXJlbmVzcyBvZiB0aGUgTU5z IGNvbm5lY3Rpdml0eS9saW5rIHN0YXR1cyB0byBhIE1BRy4NCj4+SXQNCj4+IG9ubHkga25v d3MgdGhhdCB0aGUgTU4gaGFzIGF0dGFjaGVkIHZpYSBhIE1BRy4gQW5kIGlmIHRoZSBwb2xp Y3kNCj4+aW5kaWNhdGVzDQo+PiB0aGF0IHRyYWZmaWMgYmUgcm91dGVkIHZpYSB0aGF0IE1B Ry9pbnRlcmZhY2UsIGl0IHdpbGwgZG8gc28uDQo+Pg0KPj4gSXQgY291bGQgcmVzdWx0IGlu IHBhY2tldHMgYmVpbmcgZHJvcHBlZCBpZiB0aGUgTU4gaGFzIG1vdmVkIG91dCBvZiB0aGF0 DQo+PiB3aWZpIGNvdmVyYWdlIG9yIHRoZSBsaW5rIGlzIGNvbmdlc3RlZC4gSW4gdGVybXMg b2YgdGhlIHNjb3BlIG9mIHRoaXMNCj4+IHdvcmssIHRoZSBpbnRlbnQgaXMgb24gc3BlY2lm eWluZyBob3cgdGhlIHRyYWZmaWMgYXNzb2NpYXRlZCB3aXRoIGENCj4+IHNlc3Npb24gaXMg c3dpdGNoZWQgdG8gYW4gYWx0ZXJuYXRlIE1BRy4gVGhlIHBvaW50cyB0aGF0IHlvdSByYWlz ZSBhcmUNCj4+IG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgd29yay4NCj4NCj5JIGFwb2xv Z2l6ZSBpZiBJIHN0YXJ0IHRvIHNvdW5kIHNhcmNhc3RpYywgYnV0IHRoZSBvbmx5IHRoaW5n IHRoYXQNCj5zZWVtcyBpbiBzY29wZSBvZiB0aGlzIHdvcmsgaXMgaG93IHRvIHJlYWxpemUg YSBmdW5jdGlvbg0KPihMTUEtaW5pdGlhdGVkICBmbG93IGhhbmRvZmZzKSB0aGF0IGNhbm5v dCBiZSBwb3NzaWJseSB1c2VkDQo+bWVhbmluZ2Z1bGx5IHdpdGhvdXQgYSBidW5jaCBvZiBv dGhlciBtZWNoYW5pc21zIChNTi1MTUEgcG9saWN5DQo+Y29vcmRpbmF0aW9uLCBNTi1MTUEg cmFkaW8gcXVhbGl0eSByZXBvcnRpbmcsIGV0Yy4gKSB0aGF0IGRvIG5vdCBleGlzdA0KPmlu IGFueSBmb3JtIGFuZCBhcmUgYWxzbyBvdXQgb2Ygc2NvcGUgb2YgdGhpcyB3b3JrLi4uDQo+ DQo+QXMgSSBzYWlkLCBhYnNlbnQgdGhlc2UgbWVjaGFuaXNtcywgb3IgYSB1c2VjYXNlIGFu ZCBwcm9vZiBvZg0KPmZlYXNpYmlsaXR5LCBkZXZlbG9waW5nIGFuIExNQS1pbml0aWF0ZWQg ZmxvdyBoYW5kb2YgZnVuY3Rpb24gbWFrZXMgbm8NCj5zZW5zZSB0byBtZS4NCj4NCj4tLWp1 bGllbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KbmV0ZXh0IG1haWxpbmcgbGlzdA0KbmV0ZXh0QGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGV4dA0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KVGhp cyB0cmFuc21pc3Npb24gKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWlu IGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVk aW5nIG1hdGVyaWFsIHByb3RlY3RlZCBieSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhl ciBhcHBsaWNhYmxlIHByaXZpbGVnZXMpLCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5m b3JtYXRpb24uIEFueSB1c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbiBieSBhbnlvbmUgb3RoZXIg dGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRl bHkgcmVwbHkgdG8gdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgaW5mb3JtYXRpb24gZnJv bSB5b3VyIHN5c3RlbS4gVXNlLCBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHJl cHJvZHVjdGlvbiBvZiB0aGlzIHRyYW5zbWlzc2lvbiBieSB1bmludGVuZGVkIHJlY2lwaWVu dHMgaXMgbm90IGF1dGhvcml6ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4NCg== From Basavaraj.Patil@nokia.com Mon Feb 14 16:14:28 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0CFB3A6DE5 for ; Mon, 14 Feb 2011 16:14:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.063 X-Spam-Level: X-Spam-Status: No, score=-103.063 tagged_above=-999 required=5 tests=[AWL=0.536, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usgq-zetK1PP for ; Mon, 14 Feb 2011 16:14:27 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id B8A703A6D7D for ; Mon, 14 Feb 2011 16:14:27 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1F0EVEw018090; Tue, 15 Feb 2011 02:14:48 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Feb 2011 02:13:56 +0200 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 15 Feb 2011 01:13:55 +0100 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.11]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0270.002; Tue, 15 Feb 2011 01:13:55 +0100 From: To: , Thread-Topic: [netext] On the flow mobility discussion Thread-Index: AQHLzC3b2PmyCF1oA0GpKJdDZ+HPZpQBRxwA//+gkICAAKnugIAAAkGA//+o4oA= Date: Tue, 15 Feb 2011 00:13:51 +0000 Message-ID: In-Reply-To: <680854867F7FD04BB9B06EB8ACA8D5AC0601C1C9@XCH02DFW.rim.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [173.64.197.89] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 15 Feb 2011 00:13:56.0615 (UTC) FILETIME=[3C74D170:01CBCCA5] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] On the flow mobility discussion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 00:14:28 -0000 DQpIaSBTdGVmYW5vLA0KDQpJIHRoaW5rIGRlcGxveW1lbnQgc2NlbmFyaW9zIGNvdWxkIHZhcnku IExldHMgbm90IGNvbnNpZGVyIHRoYXQgdGhpcw0Kc29sdXRpb24gaXMgYXBwbGljYWJsZSBvbmx5 IGluIHRoZSBjb250ZXh0IG9mIDNHUFAgbmV0d29ya3MgYW5kDQphcmNoaXRlY3R1cmVzLiANCkFz IGFuIGV4YW1wbGUgKEkgYW0gbm90IHNheWluZyB0aGF0IHRoaXMgaXMgc29tZXRoaW5nIG90aGVy IFNET3MgY2FyZQ0KYWJvdXQuIEl0cyBqdXN0IGFuIGV4YW1wbGUpOg0KDQpMZXRzIHRha2UgdGhl IGNhc2Ugb2YgYW4gTU4gd2l0aCBhbiBFVi1ETyBhbmQgV2lNQVggaW50ZXJmYWNlIHRoYXQgaXMN CmF0dGFjaGVkIHRvIGFuIExNQSB2aWEgTUFHeCBhbmQgTUFHeS4NCkNvdWxkIHlvdSBub3QgbWFr ZSBhIGNhc2Ugd2hlcmUgdGhlIGZsb3cgY291bGQgYmUgc3dpdGNoZWQgYmV0d2VlbiBlaXRoZXIN Cm9mIHRoZXNlIGludGVyZmFjZXMgYXQgdGhlIExNQT8NCldoYXQgd291bGQgYmUgdGhlIGlzc3Vl cyBpbiBzdWNoIGEgZGVwbG95bWVudD8NCkxldHMgcHJlc3VtZSB0aGF0IHRoZSBwb2xpY2llcyBy ZWdhcmRpbmcgd2hpY2ggZmxvd3MgYXJlIHJvdXRlZCB2aWEgRVYtRE8NCm9yIFdpTUFYIGFyZSBj b25maWd1cmVkIGF0IHRoZSBMTUEgaXRzZWxmLg0KDQpDaGVlcnMsDQotUmFqDQoNCk9uIDIvMTQv MTEgNToyNSBQTSwgImV4dCBTdGVmYW5vIEZhY2NpbiIgPHNmYWNjaW5AcmltLmNvbT4gd3JvdGU6 DQoNCj5KdWxpZW4sDQo+QXMgb25lIGNhbiBpbWFnaW5lIGNvbnNpZGVyaW5nIG15IHByZXZpb3Vz IGNvbW1lbnRzIEkgZnVsbHkgc3VwcG9ydCB5b3VyDQo+cG9pbnQgYmVsb3cuIEFzIEkgaW5kaWNh dGVkIHByZXZpb3VzbHksIHRoZXJlIGlzIGluIGFkZGl0aW9uIHRoZSBmYWN0DQo+dGhhdCB3aGF0 IGlzIGJlaW5nIGRldmVsb3BlZCB3aWxsIG5vdCBiZSBhYmxlIHRvIHN1cHBvcnQgY3VycmVudA0K PmRldmVsb3BtZW50IHNjZW5hcmlvcywgd2hpY2ggcmVzdHJpY3RzIHRoZSBhcHBsaWNhYmlsaXR5 IG9mIHRoZSBzb2x1dGlvbi4NCj5DaGVlcnMsDQo+DQo+U3RlZmFubyBGYWNjaW4NCj4NCj5TdGFu ZGFyZHMgTWFuYWdlcg0KPlJlc2VhcmNoIEluIE1vdGlvbiBDb3Jwb3JhdGlvbg0KPjUwMDAgUml2 ZXJzaWRlIERyaXZlDQo+QnVpbGRpbmcgNiwgQnJhem9zIEVhc3QsIFN0ZS4gMTAwDQo+SXJ2aW5n LCBUZXhhcyA3NTAzOSBVU0ENCj5PZmZpY2U6ICg5NzIpIDkxMCAzNDUxDQo+SW50ZXJuYWw6IDgy MC42MzQ1MQ0KPjogKDUxMCkgMjMwIDg0MjINCj53d3cucmltLmNvbTsgd3d3LmJsYWNrYmVycnku Y29tDQo+DQo+DQo+DQo+74GQIENvbnNpZGVyIHRoZSBlbnZpcm9ubWVudCBiZWZvcmUgcHJpbnRp bmcuDQo+DQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBuZXRleHQtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5ldGV4dC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYN Cj5PZiBKdWxpZW4gTGFnYW5pZXINCj5TZW50OiBNb25kYXksIEZlYnJ1YXJ5IDE0LCAyMDExIDM6 MTggUE0NCj5UbzogQmFzYXZhcmFqLlBhdGlsQG5va2lhLmNvbQ0KPkNjOiBuZXRleHRAaWV0Zi5v cmcNCj5TdWJqZWN0OiBSZTogW25ldGV4dF0gT24gdGhlIGZsb3cgbW9iaWxpdHkgZGlzY3Vzc2lv bg0KPg0KPlJhaiwNCj4NCj5PbiBNb24sIEZlYiAxNCwgMjAxMSBhdCAxMTowOSBBTSwgIDxCYXNh dmFyYWouUGF0aWxAbm9raWEuY29tPiB3cm90ZToNCj4+DQo+PiBHZXJhcmRvLA0KPj4NCj4+IE9u IDIvMTQvMTEgMTI6NTAgUE0sICJleHQgR2lhcmV0dGEsIEdlcmFyZG8iIDxnZXJhcmRvZ0BxdWFs Y29tbS5jb20+DQo+Pndyb3RlOg0KPj4NCj4+Pg0KPj4+DQo+Pj5JIGFza2VkIGZldyBxdWVzdGlv bnMgaW4gYW4gZW1haWwgd2hpY2ggSSB0aGluayB3YXMgZGlyZWN0ZWQgdG8gVGVsZW1hY28NCj4+ PmFuZCBvdGhlcnMgYnV0IG5ldmVyIGdvdCBhIHJlcGx5LiBUaGUgYmFzaWMgcG9pbnQgaXMgdGhh dCBub2JvZHkgaGFzDQo+Pj5hbnN3ZXJlZCBob3cgdGhlIExNQSBrbm93cyBpZiB0aGUgTU4gaXMg c3RpbGwgaW4gYSByZWFzb25hYmxlIFdMQU4NCj4+PmNvdmVyYWdlLCBob3cgbG9hZGVkIFdMQU4g aXMsIGV0Yy4gVGhlcmUgaXMgYSBodWdlIGRpZmZlcmVudCBiZXR3ZWVuDQo+Pj5jZWxsdWxhciBu ZXR3b3JrcyBhbmQgV0xBTnM6IGluIGNlbGx1bGFyIG5ldHdvcmtzIHRoZSBoYW5kb3ZlcnMgYXJl DQo+Pj5jb250cm9sbGVkIGJ5IHRoZSBuZXR3b3JrIGJlY2F1c2UgdGhlIE1OIGFsd2F5cyBwcm92 aWRlcyBtZWFzdXJlbWVudA0KPj4+cmVwb3J0cyBhYm91dCB3aGF0IHRoZSBNTiBzZWVzIHRvIHRo ZSBuZXR3b3JrLiBUaGlzIGlzIG5vdCBpbiBwbGFjZSBmb3INCj4+PmludGVyLXRlY2hub2xvZ3kg aGFuZG92ZXJzIGJldHdlZW4gV0xBTiBhbmQgM0cgYW5kIHRoaXMgaXMgd2h5IHlvdQ0KPj4+Y2Fu bm90DQo+Pj5zYWZlbHkgYXNzdW1lIHRoZSBMTUEgd2lsbCB0YWtlIHRoZSBjb3JyZWN0IGRlY2lz aW9uLg0KPj4+DQo+Pj5JIGRvbid0IHRoaW5rIHRoaXMgYXBwcm9hY2ggYikgYnJpbmdzIGFueSB2 YWx1ZSBhbmQgSSBhY3R1YWxseSB0aGluayBpdA0KPj4+Y3JlYXRlcyBhIGxvdCBvZiBwcm9ibGVt cy4NCj4+DQo+Pg0KPj4gUmVnYXJkaW5nIHRoZSBxdWVzdGlvbiBhYm91dCB3aGV0aGVyIHRoZSBM TUEga25vd3MgdGhlIHN0YXR1cyBvZiB0aGUgTU5zDQo+PiBjb25uZWN0aXZpdHkgdG8gYSBNQUcg YW5kIHRoZSB3aWZpIGxpbmsgY2hhcmFjdGVyaXN0aWNzIHRoYXQgaXQgaXMgdXNpbmcNCj4+IHRv IGF0dGFjaCB0byBhIE1BRzoNCj4+IFRoZSBMTUEgaGFzIG5vIGF3YXJlbmVzcyBvZiB0aGUgTU5z IGNvbm5lY3Rpdml0eS9saW5rIHN0YXR1cyB0byBhIE1BRy4NCj4+SXQNCj4+IG9ubHkga25vd3Mg dGhhdCB0aGUgTU4gaGFzIGF0dGFjaGVkIHZpYSBhIE1BRy4gQW5kIGlmIHRoZSBwb2xpY3kNCj4+ aW5kaWNhdGVzDQo+PiB0aGF0IHRyYWZmaWMgYmUgcm91dGVkIHZpYSB0aGF0IE1BRy9pbnRlcmZh Y2UsIGl0IHdpbGwgZG8gc28uDQo+Pg0KPj4gSXQgY291bGQgcmVzdWx0IGluIHBhY2tldHMgYmVp bmcgZHJvcHBlZCBpZiB0aGUgTU4gaGFzIG1vdmVkIG91dCBvZiB0aGF0DQo+PiB3aWZpIGNvdmVy YWdlIG9yIHRoZSBsaW5rIGlzIGNvbmdlc3RlZC4gSW4gdGVybXMgb2YgdGhlIHNjb3BlIG9mIHRo aXMNCj4+IHdvcmssIHRoZSBpbnRlbnQgaXMgb24gc3BlY2lmeWluZyBob3cgdGhlIHRyYWZmaWMg YXNzb2NpYXRlZCB3aXRoIGENCj4+IHNlc3Npb24gaXMgc3dpdGNoZWQgdG8gYW4gYWx0ZXJuYXRl IE1BRy4gVGhlIHBvaW50cyB0aGF0IHlvdSByYWlzZSBhcmUNCj4+IG91dHNpZGUgdGhlIHNjb3Bl IG9mIHRoaXMgd29yay4NCj4NCj5JIGFwb2xvZ2l6ZSBpZiBJIHN0YXJ0IHRvIHNvdW5kIHNhcmNh c3RpYywgYnV0IHRoZSBvbmx5IHRoaW5nIHRoYXQNCj5zZWVtcyBpbiBzY29wZSBvZiB0aGlzIHdv cmsgaXMgaG93IHRvIHJlYWxpemUgYSBmdW5jdGlvbg0KPihMTUEtaW5pdGlhdGVkICBmbG93IGhh bmRvZmZzKSB0aGF0IGNhbm5vdCBiZSBwb3NzaWJseSB1c2VkDQo+bWVhbmluZ2Z1bGx5IHdpdGhv dXQgYSBidW5jaCBvZiBvdGhlciBtZWNoYW5pc21zIChNTi1MTUEgcG9saWN5DQo+Y29vcmRpbmF0 aW9uLCBNTi1MTUEgcmFkaW8gcXVhbGl0eSByZXBvcnRpbmcsIGV0Yy4gKSB0aGF0IGRvIG5vdCBl eGlzdA0KPmluIGFueSBmb3JtIGFuZCBhcmUgYWxzbyBvdXQgb2Ygc2NvcGUgb2YgdGhpcyB3b3Jr Li4uDQo+DQo+QXMgSSBzYWlkLCBhYnNlbnQgdGhlc2UgbWVjaGFuaXNtcywgb3IgYSB1c2VjYXNl IGFuZCBwcm9vZiBvZg0KPmZlYXNpYmlsaXR5LCBkZXZlbG9waW5nIGFuIExNQS1pbml0aWF0ZWQg ZmxvdyBoYW5kb2YgZnVuY3Rpb24gbWFrZXMgbm8NCj5zZW5zZSB0byBtZS4NCj4NCj4tLWp1bGll bg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bmV0 ZXh0IG1haWxpbmcgbGlzdA0KPm5ldGV4dEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0ZXh0DQo+DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+VGhpcyB0cmFuc21p c3Npb24gKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlh bA0KPmluZm9ybWF0aW9uLCBwcml2aWxlZ2VkIG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0ZXJpYWwg cHJvdGVjdGVkIGJ5IHRoZQ0KPnNvbGljaXRvci1jbGllbnQgb3Igb3RoZXIgYXBwbGljYWJsZSBw cml2aWxlZ2VzKSwgb3IgY29uc3RpdHV0ZQ0KPm5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1 c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbg0KPnRoZSBpbnRlbmRl ZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcw0KPnRy YW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5k ZXIgYW5kIGRlbGV0ZQ0KPnRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4gVXNlLCBk aXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9yDQo+cmVwcm9kdWN0aW9uIG9mIHRoaXMgdHJh bnNtaXNzaW9uIGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50cyBpcyBub3QNCj5hdXRob3JpemVkIGFu ZCBtYXkgYmUgdW5sYXdmdWwuDQoNCg== From Basavaraj.Patil@nokia.com Mon Feb 14 16:19:27 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEAB03A6D7D for ; Mon, 14 Feb 2011 16:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srBTHWDbCqRk for ; Mon, 14 Feb 2011 16:19:26 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 8456F3A6B6F for ; Mon, 14 Feb 2011 16:19:26 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1F0Jb33025918; Tue, 15 Feb 2011 02:19:48 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Feb 2011 02:18:37 +0200 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 15 Feb 2011 01:18:36 +0100 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.11]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0270.002; Tue, 15 Feb 2011 01:18:36 +0100 From: To: , Thread-Topic: [netext] On the flow mobility discussion Thread-Index: AQHLzC3b2PmyCF1oA0GpKJdDZ+HPZpQBRxwA//+gkICAAKnugP//qhiAgAB1qRD//4y0AA== Date: Tue, 15 Feb 2011 00:18:34 +0000 Message-ID: In-Reply-To: <680854867F7FD04BB9B06EB8ACA8D5AC0601C1DD@XCH02DFW.rim.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [173.64.197.89] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 15 Feb 2011 00:18:37.0008 (UTC) FILETIME=[E3956500:01CBCCA5] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] On the flow mobility discussion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 00:19:27 -0000 DQpIaSBTdGVmYW5vLA0KDQpJIGFtIG5vdCBzYXlpbmcgdGhhdCB3ZSBzb2x2ZSB0aGUgcHJvYmxl bSBvbmx5IGZvciB0aGUgYmVzdCBjYXNlIHNjZW5hcmlvLg0KSSBhbSBob3BpbmcgdGhhdCBzb21l IG9mIHRoZSBmb2xrcyB3aG8gYXJlIGFjdGl2ZWx5IGludm9sdmVkIHdpdGggdGhlDQpzb2x1dGlv biBkZXZlbG9wbWVudCBjYW4gcHJvdmlkZSBhbnN3ZXJzIGFib3V0IGhvdyB0aGUgY29uY2VybnMg cmFpc2VkIGJ5DQpKdWxpZW4gZXQgYWwuIGNhbiBiZSBkZWFsdCB3aXRoLg0KSG93IGRvIHlvdSBo YW5kbGUgdGhlIGNhc2Ugd2hlbiB0aGUgTE1BIHN3aXRjaGVzIGZsb3dzIHRvIGEgTUFHIHRoYXQN CmNhbm5vdCBkZWxpdmVyIHBhY2tldHMgcmVsaWFibHkgdG8gdGhlIE1OPyBHaXZlbiB0aGF0IHRo ZXJlIGlzIG5vIGZlZWRiYWNrDQptZWNoYW5pc20gdG8gdGhlIExNQSwgdGhlcmUgYXJlIG5vIGVh c3kgYW5zd2VycyBvciBtZWNoYW5pc21zLiBCdXQgSSB3YW50DQp0byBtYWtlIHN1cmUgdGhhdCB3 ZSBnZXQgYSBjaGFuY2UgdG8gbGV0IHRoZSBhdXRob3JzIHByb3ZpZGUgYSByZXNwb25zZS4NCg0K LVJhag0KDQpPbiAyLzE0LzExIDY6MTMgUE0sICJleHQgU3RlZmFubyBGYWNjaW4iIDxzZmFjY2lu QHJpbS5jb20+IHdyb3RlOg0KDQo+UmFqLA0KPkkgYXBvbG9naXplIGZvciBiZWluZyBzbG93LCBi dXQgSSByZWFsbHkgZG8gbm90IHVuZGVyc3RhbmQgd2hhdCB5b3UgYXJlDQo+c2F5aW5nLiBEbyB3 ZSByZWFsbHkgd2FudCB0byBkZXZlbG9wIGEgc29sdXRpb24gdGhhdCB3b3JrcyBvbmx5IGluIHRo ZQ0KPmJlc3QgY2FzZSBzY2VuYXJpbyBhbmQgdXR0ZXJseSBkaXNyZWdhcmRzIHJlYWxpc3RpYyBz Y2VuYXJpb3MgbGlrZSB0aGUNCj5vbmVzIEp1bGllbiBhbmQgb3RoZXJzIGhhdmUgbWVudGlvbmVk PyBJcyB0aGlzIGdvb2QgZW5naW5lZXJpbmcgd29yayBieQ0KPklFVEY/IFdoYXQgeW91IGFyZSBz YXlpbmcgYmVsb3cgaXMgbGl0ZXJhbGx5IHRoYXQgd2UgYXJlIE9LIGlmIHRoZQ0KPnNvbHV0aW9u IGRvZXMgbm90IHdvcmsgaW4gc2NlbmFyaW8gdGhhdCBjYW4gaW5kZWVkIGhhcHBlbiBhbmQgcmF0 aGVyDQo+b2Z0ZW4gYWxyZWFkeSB0b2RheS4gSSBjYW5ub3QgYmVsaWV2ZSB3ZSBhcmUgc2VyaW91 c2x5IHdpbGxpbmcgdG8gc2V0dGxlDQo+Zm9yIHRoYXQuIA0KPg0KPkNoZWVycywNCj4NCj5TdGVm YW5vIEZhY2Npbg0KPg0KPlN0YW5kYXJkcyBNYW5hZ2VyDQo+UmVzZWFyY2ggSW4gTW90aW9uIENv cnBvcmF0aW9uDQo+NTAwMCBSaXZlcnNpZGUgRHJpdmUNCj5CdWlsZGluZyA2LCBCcmF6b3MgRWFz dCwgU3RlLiAxMDANCj5JcnZpbmcsIFRleGFzIDc1MDM5IFVTQQ0KPk9mZmljZTogKDk3MikgOTEw IDM0NTENCj5JbnRlcm5hbDogODIwLjYzNDUxDQo+OiAoNTEwKSAyMzAgODQyMg0KPnd3dy5yaW0u Y29tOyB3d3cuYmxhY2tiZXJyeS5jb20NCj4NCj4NCj4NCj7vgZAgQ29uc2lkZXIgdGhlIGVudmly b25tZW50IGJlZm9yZSBwcmludGluZy4NCj4NCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPkZyb206IG5ldGV4dC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bmV0ZXh0LWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZg0KPk9mIEJhc2F2YXJhai5QYXRpbEBub2tpYS5jb20NCj5TZW50 OiBNb25kYXksIEZlYnJ1YXJ5IDE0LCAyMDExIDQ6MTAgUE0NCj5UbzoganVsaWVuLmlldGZAZ21h aWwuY29tDQo+Q2M6IG5ldGV4dEBpZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbbmV0ZXh0XSBPbiB0 aGUgZmxvdyBtb2JpbGl0eSBkaXNjdXNzaW9uDQo+DQo+DQo+SnVsaWVuLA0KPg0KPkkgdW5kZXJz dGFuZCB0aGUgaXNzdWUgYWJvdXQgdGhlIGZhY3QgdGhhdCBhbiBNTiBtYXkgaGF2ZSBtb3ZlZCBv dXQgb2YNCj53aWZpIGNvdmVyYWdlIGFmdGVyIHJlZ2lzdGVyaW5nIHRocnUgTUFHeS4NCj5PciBm b3IgdGhhdCBtYXR0ZXIgdGhlIHdpZmkgbmV0d29yayB2aWEgd2hpY2ggdGhlIE1OIGlzIGF0dGFj aGVkICh0aHJ1DQo+TUFHeSkgaXMgY29uZ2VzdGVkIG9yIHRoZSBsaW5rIHF1YWxpdHkgaXMgcG9v ci4NCj5BbmQgdGhpcyBjb3VsZCBoYXBwZW4uDQo+DQo+QnV0IG9uIHRoZSBmbGlwIHNpZGUsIHRo ZSBNTiBtYXkgYmUgYXR0YWNoZWQgdG8gYSB3aWZpIG5ldHdvcmsgYW5kIGlzIGFibGUNCj50byBz ZW5kL3JlY3YgcGFja2V0cyB0aHJ1IE1BR3kgd2l0aCBubyBpc3N1ZXMsIEluIHdoaWNoIGNhc2Ug c3dpdGNoaW5nIHRoZQ0KPmZsb3cgYXQgdGhlIExNQSB3b3VsZCB3b3JrIGp1c3QgZmluZS4NCj4N Cj5Eb2VzIGl0IG5vdCBtYWtlIHNlbnNlIHRvIGhhdmUgYSBzb2x1dGlvbiBmb3IgdGhpcyBjYXNl PyBUaGUgZXJyb3IgY2FzZQ0KPndoZW4gdGhlIHBhY2tldHMgc2VudCB0byB0aGUgTU4gdmlhIE1B R3kgaW50byBvYmxpdmlvbiBjYW5ub3QgYmUgaWdub3JlZC4NCj5CdXQgbmVpdGhlciBjYW4geW91 IHNheSB0aGF0IHRoZXJlIGlzIG5vIHdheSB0aGlzIHdvdWxkIHdvcmsgYXQgYWxsLg0KPg0KPi1S YWoNCj4NCj5PbiAyLzE0LzExIDU6MTcgUE0sICJleHQgSnVsaWVuIExhZ2FuaWVyIiA8anVsaWVu LmlldGZAZ21haWwuY29tPiB3cm90ZToNCj4NCj4+UmFqLA0KPj4NCj4+T24gTW9uLCBGZWIgMTQs IDIwMTEgYXQgMTE6MDkgQU0sICA8QmFzYXZhcmFqLlBhdGlsQG5va2lhLmNvbT4gd3JvdGU6DQo+ Pj4NCj4+PiBHZXJhcmRvLA0KPj4+DQo+Pj4gT24gMi8xNC8xMSAxMjo1MCBQTSwgImV4dCBHaWFy ZXR0YSwgR2VyYXJkbyIgPGdlcmFyZG9nQHF1YWxjb21tLmNvbT4NCj4+Pndyb3RlOg0KPj4+DQo+ Pj4+DQo+Pj4+DQo+Pj4+SSBhc2tlZCBmZXcgcXVlc3Rpb25zIGluIGFuIGVtYWlsIHdoaWNoIEkg dGhpbmsgd2FzIGRpcmVjdGVkIHRvDQo+Pj4+VGVsZW1hY28NCj4+Pj5hbmQgb3RoZXJzIGJ1dCBu ZXZlciBnb3QgYSByZXBseS4gVGhlIGJhc2ljIHBvaW50IGlzIHRoYXQgbm9ib2R5IGhhcw0KPj4+ PmFuc3dlcmVkIGhvdyB0aGUgTE1BIGtub3dzIGlmIHRoZSBNTiBpcyBzdGlsbCBpbiBhIHJlYXNv bmFibGUgV0xBTg0KPj4+PmNvdmVyYWdlLCBob3cgbG9hZGVkIFdMQU4gaXMsIGV0Yy4gVGhlcmUg aXMgYSBodWdlIGRpZmZlcmVudCBiZXR3ZWVuDQo+Pj4+Y2VsbHVsYXIgbmV0d29ya3MgYW5kIFdM QU5zOiBpbiBjZWxsdWxhciBuZXR3b3JrcyB0aGUgaGFuZG92ZXJzIGFyZQ0KPj4+PmNvbnRyb2xs ZWQgYnkgdGhlIG5ldHdvcmsgYmVjYXVzZSB0aGUgTU4gYWx3YXlzIHByb3ZpZGVzIG1lYXN1cmVt ZW50DQo+Pj4+cmVwb3J0cyBhYm91dCB3aGF0IHRoZSBNTiBzZWVzIHRvIHRoZSBuZXR3b3JrLiBU aGlzIGlzIG5vdCBpbiBwbGFjZSBmb3INCj4+Pj5pbnRlci10ZWNobm9sb2d5IGhhbmRvdmVycyBi ZXR3ZWVuIFdMQU4gYW5kIDNHIGFuZCB0aGlzIGlzIHdoeSB5b3UNCj4+Pj5jYW5ub3QNCj4+Pj5z YWZlbHkgYXNzdW1lIHRoZSBMTUEgd2lsbCB0YWtlIHRoZSBjb3JyZWN0IGRlY2lzaW9uLg0KPj4+ Pg0KPj4+PkkgZG9uJ3QgdGhpbmsgdGhpcyBhcHByb2FjaCBiKSBicmluZ3MgYW55IHZhbHVlIGFu ZCBJIGFjdHVhbGx5IHRoaW5rIGl0DQo+Pj4+Y3JlYXRlcyBhIGxvdCBvZiBwcm9ibGVtcy4NCj4+ Pg0KPj4+DQo+Pj4gUmVnYXJkaW5nIHRoZSBxdWVzdGlvbiBhYm91dCB3aGV0aGVyIHRoZSBMTUEg a25vd3MgdGhlIHN0YXR1cyBvZiB0aGUNCj4+Pk1Ocw0KPj4+IGNvbm5lY3Rpdml0eSB0byBhIE1B RyBhbmQgdGhlIHdpZmkgbGluayBjaGFyYWN0ZXJpc3RpY3MgdGhhdCBpdCBpcw0KPj4+dXNpbmcN Cj4+PiB0byBhdHRhY2ggdG8gYSBNQUc6DQo+Pj4gVGhlIExNQSBoYXMgbm8gYXdhcmVuZXNzIG9m IHRoZSBNTnMgY29ubmVjdGl2aXR5L2xpbmsgc3RhdHVzIHRvIGEgTUFHLg0KPj4+SXQNCj4+PiBv bmx5IGtub3dzIHRoYXQgdGhlIE1OIGhhcyBhdHRhY2hlZCB2aWEgYSBNQUcuIEFuZCBpZiB0aGUg cG9saWN5DQo+Pj5pbmRpY2F0ZXMNCj4+PiB0aGF0IHRyYWZmaWMgYmUgcm91dGVkIHZpYSB0aGF0 IE1BRy9pbnRlcmZhY2UsIGl0IHdpbGwgZG8gc28uDQo+Pj4NCj4+PiBJdCBjb3VsZCByZXN1bHQg aW4gcGFja2V0cyBiZWluZyBkcm9wcGVkIGlmIHRoZSBNTiBoYXMgbW92ZWQgb3V0IG9mDQo+Pj50 aGF0DQo+Pj4gd2lmaSBjb3ZlcmFnZSBvciB0aGUgbGluayBpcyBjb25nZXN0ZWQuIEluIHRlcm1z IG9mIHRoZSBzY29wZSBvZiB0aGlzDQo+Pj4gd29yaywgdGhlIGludGVudCBpcyBvbiBzcGVjaWZ5 aW5nIGhvdyB0aGUgdHJhZmZpYyBhc3NvY2lhdGVkIHdpdGggYQ0KPj4+IHNlc3Npb24gaXMgc3dp dGNoZWQgdG8gYW4gYWx0ZXJuYXRlIE1BRy4gVGhlIHBvaW50cyB0aGF0IHlvdSByYWlzZSBhcmUN Cj4+PiBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIHdvcmsuDQo+Pg0KPj5JIGFwb2xvZ2l6ZSBp ZiBJIHN0YXJ0IHRvIHNvdW5kIHNhcmNhc3RpYywgYnV0IHRoZSBvbmx5IHRoaW5nIHRoYXQNCj4+ c2VlbXMgaW4gc2NvcGUgb2YgdGhpcyB3b3JrIGlzIGhvdyB0byByZWFsaXplIGEgZnVuY3Rpb24N Cj4+KExNQS1pbml0aWF0ZWQgIGZsb3cgaGFuZG9mZnMpIHRoYXQgY2Fubm90IGJlIHBvc3NpYmx5 IHVzZWQNCj4+bWVhbmluZ2Z1bGx5IHdpdGhvdXQgYSBidW5jaCBvZiBvdGhlciBtZWNoYW5pc21z IChNTi1MTUEgcG9saWN5DQo+PmNvb3JkaW5hdGlvbiwgTU4tTE1BIHJhZGlvIHF1YWxpdHkgcmVw b3J0aW5nLCBldGMuICkgdGhhdCBkbyBub3QgZXhpc3QNCj4+aW4gYW55IGZvcm0gYW5kIGFyZSBh bHNvIG91dCBvZiBzY29wZSBvZiB0aGlzIHdvcmsuLi4NCj4+DQo+PkFzIEkgc2FpZCwgYWJzZW50 IHRoZXNlIG1lY2hhbmlzbXMsIG9yIGEgdXNlY2FzZSBhbmQgcHJvb2Ygb2YNCj4+ZmVhc2liaWxp dHksIGRldmVsb3BpbmcgYW4gTE1BLWluaXRpYXRlZCBmbG93IGhhbmRvZiBmdW5jdGlvbiBtYWtl cyBubw0KPj5zZW5zZSB0byBtZS4NCj4+DQo+Pi0tanVsaWVuDQo+DQo+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5uZXRleHQgbWFpbGluZyBsaXN0DQo+ bmV0ZXh0QGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRleHQNCj4NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj5UaGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFu eSBhdHRhY2htZW50cykgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsDQo+aW5mb3JtYXRpb24sIHBy aXZpbGVnZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRlcmlhbCBwcm90ZWN0ZWQgYnkgdGhlDQo+ c29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZpbGVnZXMpLCBvciBjb25z dGl0dXRlDQo+bm9uLXB1YmxpYyBpbmZvcm1hdGlvbi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0 aW9uIGJ5IGFueW9uZSBvdGhlciB0aGFuDQo+dGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9o aWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzDQo+dHJhbnNtaXNzaW9uIGluIGVycm9y LCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciBhbmQgZGVsZXRlDQo+dGhp cyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3Ry aWJ1dGlvbiwgb3INCj5yZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Npb24gYnkgdW5pbnRl bmRlZCByZWNpcGllbnRzIGlzIG5vdA0KPmF1dGhvcml6ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4N Cg0K From sfaccin@rim.com Mon Feb 14 16:20:59 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1573F3A6D7D for ; Mon, 14 Feb 2011 16:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.883 X-Spam-Level: X-Spam-Status: No, score=-5.883 tagged_above=-999 required=5 tests=[AWL=0.716, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcGU9B3PySOv for ; Mon, 14 Feb 2011 16:20:57 -0800 (PST) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id D25AE3A6B6F for ; Mon, 14 Feb 2011 16:20:56 -0800 (PST) X-AuditID: 0a401fcb-b7bffae0000009e5-84-4d59c6ffa0ac Received: from XCH139CNC.rim.net ( [10.65.10.235]) by mhs03ykf.rim.net (RIM Mail) with SMTP id 3E.70.02533.FF6C95D4; Mon, 14 Feb 2011 19:21:20 -0500 (EST) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH139CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Feb 2011 19:21:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" content-transfer-encoding: base64 Date: Mon, 14 Feb 2011 18:21:08 -0600 Message-ID: <680854867F7FD04BB9B06EB8ACA8D5AC0601C1E2@XCH02DFW.rim.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] On the flow mobility discussion Thread-Index: AQHLzC3b2PmyCF1oA0GpKJdDZ+HPZpQBRxwA//+gkICAAKnugP//qhiAgAB1qRD//4y0AAAOu2Gg References: <680854867F7FD04BB9B06EB8ACA8D5AC0601C1DD@XCH02DFW.rim.net> From: "Stefano Faccin" To: , X-OriginalArrivalTime: 15 Feb 2011 00:21:11.0488 (UTC) FILETIME=[3FA92C00:01CBCCA6] X-Brightmail-Tracker: AAAAAwAAAZEXZUAgF2YabQ== Cc: netext@ietf.org Subject: Re: [netext] On the flow mobility discussion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 00:20:59 -0000 UmFqLA0KQXMgSGVzaGFtIGhhcyBpbmRpY2F0ZWQsIHRoZXJlIGFyZSBzZXZlcmFsIHF1ZXN0 aW9ucyB0aGF0IGhhdmUgbm90IGJlZW4gYW5zd2VyZWQsIGFuZCBJIGhhdmUgbm90IHNlZW4g YW55Ym9keSBibG9ja2luZyB0aGUgYXV0aG9ycyBmcm9tIGFuc3dlcmluZyB0aG9zZSAuLi4N Cg0KU3RlZmFubyBGYWNjaW4NCg0KU3RhbmRhcmRzIE1hbmFnZXINClJlc2VhcmNoIEluIE1v dGlvbiBDb3Jwb3JhdGlvbiANCjUwMDAgUml2ZXJzaWRlIERyaXZlIA0KQnVpbGRpbmcgNiwg QnJhem9zIEVhc3QsIFN0ZS4gMTAwDQpJcnZpbmcsIFRleGFzIDc1MDM5IFVTQSANCk9mZmlj ZTogKDk3MikgOTEwIDM0NTHCoCANCkludGVybmFsOiA4MjAuNjM0NTENCjogKDUxMCkgMjMw IDg0MjINCnd3dy5yaW0uY29tOyB3d3cuYmxhY2tiZXJyeS5jb20gDQoNCg0KDQrvgZAgQ29u c2lkZXIgdGhlIGVudmlyb25tZW50IGJlZm9yZSBwcmludGluZy4NCg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQmFzYXZhcmFqLlBhdGlsQG5va2lhLmNvbSBbbWFp bHRvOkJhc2F2YXJhai5QYXRpbEBub2tpYS5jb21dIA0KU2VudDogTW9uZGF5LCBGZWJydWFy eSAxNCwgMjAxMSA0OjE5IFBNDQpUbzogU3RlZmFubyBGYWNjaW47IGp1bGllbi5pZXRmQGdt YWlsLmNvbQ0KQ2M6IG5ldGV4dEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRleHRdIE9u IHRoZSBmbG93IG1vYmlsaXR5IGRpc2N1c3Npb24NCg0KDQpIaSBTdGVmYW5vLA0KDQpJIGFt IG5vdCBzYXlpbmcgdGhhdCB3ZSBzb2x2ZSB0aGUgcHJvYmxlbSBvbmx5IGZvciB0aGUgYmVz dCBjYXNlIHNjZW5hcmlvLg0KSSBhbSBob3BpbmcgdGhhdCBzb21lIG9mIHRoZSBmb2xrcyB3 aG8gYXJlIGFjdGl2ZWx5IGludm9sdmVkIHdpdGggdGhlDQpzb2x1dGlvbiBkZXZlbG9wbWVu dCBjYW4gcHJvdmlkZSBhbnN3ZXJzIGFib3V0IGhvdyB0aGUgY29uY2VybnMgcmFpc2VkIGJ5 DQpKdWxpZW4gZXQgYWwuIGNhbiBiZSBkZWFsdCB3aXRoLg0KSG93IGRvIHlvdSBoYW5kbGUg dGhlIGNhc2Ugd2hlbiB0aGUgTE1BIHN3aXRjaGVzIGZsb3dzIHRvIGEgTUFHIHRoYXQNCmNh bm5vdCBkZWxpdmVyIHBhY2tldHMgcmVsaWFibHkgdG8gdGhlIE1OPyBHaXZlbiB0aGF0IHRo ZXJlIGlzIG5vIGZlZWRiYWNrDQptZWNoYW5pc20gdG8gdGhlIExNQSwgdGhlcmUgYXJlIG5v IGVhc3kgYW5zd2VycyBvciBtZWNoYW5pc21zLiBCdXQgSSB3YW50DQp0byBtYWtlIHN1cmUg dGhhdCB3ZSBnZXQgYSBjaGFuY2UgdG8gbGV0IHRoZSBhdXRob3JzIHByb3ZpZGUgYSByZXNw b25zZS4NCg0KLVJhag0KDQpPbiAyLzE0LzExIDY6MTMgUE0sICJleHQgU3RlZmFubyBGYWNj aW4iIDxzZmFjY2luQHJpbS5jb20+IHdyb3RlOg0KDQo+UmFqLA0KPkkgYXBvbG9naXplIGZv ciBiZWluZyBzbG93LCBidXQgSSByZWFsbHkgZG8gbm90IHVuZGVyc3RhbmQgd2hhdCB5b3Ug YXJlDQo+c2F5aW5nLiBEbyB3ZSByZWFsbHkgd2FudCB0byBkZXZlbG9wIGEgc29sdXRpb24g dGhhdCB3b3JrcyBvbmx5IGluIHRoZQ0KPmJlc3QgY2FzZSBzY2VuYXJpbyBhbmQgdXR0ZXJs eSBkaXNyZWdhcmRzIHJlYWxpc3RpYyBzY2VuYXJpb3MgbGlrZSB0aGUNCj5vbmVzIEp1bGll biBhbmQgb3RoZXJzIGhhdmUgbWVudGlvbmVkPyBJcyB0aGlzIGdvb2QgZW5naW5lZXJpbmcg d29yayBieQ0KPklFVEY/IFdoYXQgeW91IGFyZSBzYXlpbmcgYmVsb3cgaXMgbGl0ZXJhbGx5 IHRoYXQgd2UgYXJlIE9LIGlmIHRoZQ0KPnNvbHV0aW9uIGRvZXMgbm90IHdvcmsgaW4gc2Nl bmFyaW8gdGhhdCBjYW4gaW5kZWVkIGhhcHBlbiBhbmQgcmF0aGVyDQo+b2Z0ZW4gYWxyZWFk eSB0b2RheS4gSSBjYW5ub3QgYmVsaWV2ZSB3ZSBhcmUgc2VyaW91c2x5IHdpbGxpbmcgdG8g c2V0dGxlDQo+Zm9yIHRoYXQuIA0KPg0KPkNoZWVycywNCj4NCj5TdGVmYW5vIEZhY2Npbg0K Pg0KPlN0YW5kYXJkcyBNYW5hZ2VyDQo+UmVzZWFyY2ggSW4gTW90aW9uIENvcnBvcmF0aW9u DQo+NTAwMCBSaXZlcnNpZGUgRHJpdmUNCj5CdWlsZGluZyA2LCBCcmF6b3MgRWFzdCwgU3Rl LiAxMDANCj5JcnZpbmcsIFRleGFzIDc1MDM5IFVTQQ0KPk9mZmljZTogKDk3MikgOTEwIDM0 NTENCj5JbnRlcm5hbDogODIwLjYzNDUxDQo+OiAoNTEwKSAyMzAgODQyMg0KPnd3dy5yaW0u Y29tOyB3d3cuYmxhY2tiZXJyeS5jb20NCj4NCj4NCj4NCj7vgZAgQ29uc2lkZXIgdGhlIGVu dmlyb25tZW50IGJlZm9yZSBwcmludGluZy4NCj4NCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPkZyb206IG5ldGV4dC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bmV0ZXh0 LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPk9mIEJhc2F2YXJhai5QYXRpbEBub2tp YS5jb20NCj5TZW50OiBNb25kYXksIEZlYnJ1YXJ5IDE0LCAyMDExIDQ6MTAgUE0NCj5Ubzog anVsaWVuLmlldGZAZ21haWwuY29tDQo+Q2M6IG5ldGV4dEBpZXRmLm9yZw0KPlN1YmplY3Q6 IFJlOiBbbmV0ZXh0XSBPbiB0aGUgZmxvdyBtb2JpbGl0eSBkaXNjdXNzaW9uDQo+DQo+DQo+ SnVsaWVuLA0KPg0KPkkgdW5kZXJzdGFuZCB0aGUgaXNzdWUgYWJvdXQgdGhlIGZhY3QgdGhh dCBhbiBNTiBtYXkgaGF2ZSBtb3ZlZCBvdXQgb2YNCj53aWZpIGNvdmVyYWdlIGFmdGVyIHJl Z2lzdGVyaW5nIHRocnUgTUFHeS4NCj5PciBmb3IgdGhhdCBtYXR0ZXIgdGhlIHdpZmkgbmV0 d29yayB2aWEgd2hpY2ggdGhlIE1OIGlzIGF0dGFjaGVkICh0aHJ1DQo+TUFHeSkgaXMgY29u Z2VzdGVkIG9yIHRoZSBsaW5rIHF1YWxpdHkgaXMgcG9vci4NCj5BbmQgdGhpcyBjb3VsZCBo YXBwZW4uDQo+DQo+QnV0IG9uIHRoZSBmbGlwIHNpZGUsIHRoZSBNTiBtYXkgYmUgYXR0YWNo ZWQgdG8gYSB3aWZpIG5ldHdvcmsgYW5kIGlzIGFibGUNCj50byBzZW5kL3JlY3YgcGFja2V0 cyB0aHJ1IE1BR3kgd2l0aCBubyBpc3N1ZXMsIEluIHdoaWNoIGNhc2Ugc3dpdGNoaW5nIHRo ZQ0KPmZsb3cgYXQgdGhlIExNQSB3b3VsZCB3b3JrIGp1c3QgZmluZS4NCj4NCj5Eb2VzIGl0 IG5vdCBtYWtlIHNlbnNlIHRvIGhhdmUgYSBzb2x1dGlvbiBmb3IgdGhpcyBjYXNlPyBUaGUg ZXJyb3IgY2FzZQ0KPndoZW4gdGhlIHBhY2tldHMgc2VudCB0byB0aGUgTU4gdmlhIE1BR3kg aW50byBvYmxpdmlvbiBjYW5ub3QgYmUgaWdub3JlZC4NCj5CdXQgbmVpdGhlciBjYW4geW91 IHNheSB0aGF0IHRoZXJlIGlzIG5vIHdheSB0aGlzIHdvdWxkIHdvcmsgYXQgYWxsLg0KPg0K Pi1SYWoNCj4NCj5PbiAyLzE0LzExIDU6MTcgUE0sICJleHQgSnVsaWVuIExhZ2FuaWVyIiA8 anVsaWVuLmlldGZAZ21haWwuY29tPiB3cm90ZToNCj4NCj4+UmFqLA0KPj4NCj4+T24gTW9u LCBGZWIgMTQsIDIwMTEgYXQgMTE6MDkgQU0sICA8QmFzYXZhcmFqLlBhdGlsQG5va2lhLmNv bT4gd3JvdGU6DQo+Pj4NCj4+PiBHZXJhcmRvLA0KPj4+DQo+Pj4gT24gMi8xNC8xMSAxMjo1 MCBQTSwgImV4dCBHaWFyZXR0YSwgR2VyYXJkbyIgPGdlcmFyZG9nQHF1YWxjb21tLmNvbT4N Cj4+Pndyb3RlOg0KPj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+SSBhc2tlZCBmZXcgcXVlc3Rpb25z IGluIGFuIGVtYWlsIHdoaWNoIEkgdGhpbmsgd2FzIGRpcmVjdGVkIHRvDQo+Pj4+VGVsZW1h Y28NCj4+Pj5hbmQgb3RoZXJzIGJ1dCBuZXZlciBnb3QgYSByZXBseS4gVGhlIGJhc2ljIHBv aW50IGlzIHRoYXQgbm9ib2R5IGhhcw0KPj4+PmFuc3dlcmVkIGhvdyB0aGUgTE1BIGtub3dz IGlmIHRoZSBNTiBpcyBzdGlsbCBpbiBhIHJlYXNvbmFibGUgV0xBTg0KPj4+PmNvdmVyYWdl LCBob3cgbG9hZGVkIFdMQU4gaXMsIGV0Yy4gVGhlcmUgaXMgYSBodWdlIGRpZmZlcmVudCBi ZXR3ZWVuDQo+Pj4+Y2VsbHVsYXIgbmV0d29ya3MgYW5kIFdMQU5zOiBpbiBjZWxsdWxhciBu ZXR3b3JrcyB0aGUgaGFuZG92ZXJzIGFyZQ0KPj4+PmNvbnRyb2xsZWQgYnkgdGhlIG5ldHdv cmsgYmVjYXVzZSB0aGUgTU4gYWx3YXlzIHByb3ZpZGVzIG1lYXN1cmVtZW50DQo+Pj4+cmVw b3J0cyBhYm91dCB3aGF0IHRoZSBNTiBzZWVzIHRvIHRoZSBuZXR3b3JrLiBUaGlzIGlzIG5v dCBpbiBwbGFjZSBmb3INCj4+Pj5pbnRlci10ZWNobm9sb2d5IGhhbmRvdmVycyBiZXR3ZWVu IFdMQU4gYW5kIDNHIGFuZCB0aGlzIGlzIHdoeSB5b3UNCj4+Pj5jYW5ub3QNCj4+Pj5zYWZl bHkgYXNzdW1lIHRoZSBMTUEgd2lsbCB0YWtlIHRoZSBjb3JyZWN0IGRlY2lzaW9uLg0KPj4+ Pg0KPj4+PkkgZG9uJ3QgdGhpbmsgdGhpcyBhcHByb2FjaCBiKSBicmluZ3MgYW55IHZhbHVl IGFuZCBJIGFjdHVhbGx5IHRoaW5rIGl0DQo+Pj4+Y3JlYXRlcyBhIGxvdCBvZiBwcm9ibGVt cy4NCj4+Pg0KPj4+DQo+Pj4gUmVnYXJkaW5nIHRoZSBxdWVzdGlvbiBhYm91dCB3aGV0aGVy IHRoZSBMTUEga25vd3MgdGhlIHN0YXR1cyBvZiB0aGUNCj4+Pk1Ocw0KPj4+IGNvbm5lY3Rp dml0eSB0byBhIE1BRyBhbmQgdGhlIHdpZmkgbGluayBjaGFyYWN0ZXJpc3RpY3MgdGhhdCBp dCBpcw0KPj4+dXNpbmcNCj4+PiB0byBhdHRhY2ggdG8gYSBNQUc6DQo+Pj4gVGhlIExNQSBo YXMgbm8gYXdhcmVuZXNzIG9mIHRoZSBNTnMgY29ubmVjdGl2aXR5L2xpbmsgc3RhdHVzIHRv IGEgTUFHLg0KPj4+SXQNCj4+PiBvbmx5IGtub3dzIHRoYXQgdGhlIE1OIGhhcyBhdHRhY2hl ZCB2aWEgYSBNQUcuIEFuZCBpZiB0aGUgcG9saWN5DQo+Pj5pbmRpY2F0ZXMNCj4+PiB0aGF0 IHRyYWZmaWMgYmUgcm91dGVkIHZpYSB0aGF0IE1BRy9pbnRlcmZhY2UsIGl0IHdpbGwgZG8g c28uDQo+Pj4NCj4+PiBJdCBjb3VsZCByZXN1bHQgaW4gcGFja2V0cyBiZWluZyBkcm9wcGVk IGlmIHRoZSBNTiBoYXMgbW92ZWQgb3V0IG9mDQo+Pj50aGF0DQo+Pj4gd2lmaSBjb3ZlcmFn ZSBvciB0aGUgbGluayBpcyBjb25nZXN0ZWQuIEluIHRlcm1zIG9mIHRoZSBzY29wZSBvZiB0 aGlzDQo+Pj4gd29yaywgdGhlIGludGVudCBpcyBvbiBzcGVjaWZ5aW5nIGhvdyB0aGUgdHJh ZmZpYyBhc3NvY2lhdGVkIHdpdGggYQ0KPj4+IHNlc3Npb24gaXMgc3dpdGNoZWQgdG8gYW4g YWx0ZXJuYXRlIE1BRy4gVGhlIHBvaW50cyB0aGF0IHlvdSByYWlzZSBhcmUNCj4+PiBvdXRz aWRlIHRoZSBzY29wZSBvZiB0aGlzIHdvcmsuDQo+Pg0KPj5JIGFwb2xvZ2l6ZSBpZiBJIHN0 YXJ0IHRvIHNvdW5kIHNhcmNhc3RpYywgYnV0IHRoZSBvbmx5IHRoaW5nIHRoYXQNCj4+c2Vl bXMgaW4gc2NvcGUgb2YgdGhpcyB3b3JrIGlzIGhvdyB0byByZWFsaXplIGEgZnVuY3Rpb24N Cj4+KExNQS1pbml0aWF0ZWQgIGZsb3cgaGFuZG9mZnMpIHRoYXQgY2Fubm90IGJlIHBvc3Np Ymx5IHVzZWQNCj4+bWVhbmluZ2Z1bGx5IHdpdGhvdXQgYSBidW5jaCBvZiBvdGhlciBtZWNo YW5pc21zIChNTi1MTUEgcG9saWN5DQo+PmNvb3JkaW5hdGlvbiwgTU4tTE1BIHJhZGlvIHF1 YWxpdHkgcmVwb3J0aW5nLCBldGMuICkgdGhhdCBkbyBub3QgZXhpc3QNCj4+aW4gYW55IGZv cm0gYW5kIGFyZSBhbHNvIG91dCBvZiBzY29wZSBvZiB0aGlzIHdvcmsuLi4NCj4+DQo+PkFz IEkgc2FpZCwgYWJzZW50IHRoZXNlIG1lY2hhbmlzbXMsIG9yIGEgdXNlY2FzZSBhbmQgcHJv b2Ygb2YNCj4+ZmVhc2liaWxpdHksIGRldmVsb3BpbmcgYW4gTE1BLWluaXRpYXRlZCBmbG93 IGhhbmRvZiBmdW5jdGlvbiBtYWtlcyBubw0KPj5zZW5zZSB0byBtZS4NCj4+DQo+Pi0tanVs aWVuDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj5uZXRleHQgbWFpbGluZyBsaXN0DQo+bmV0ZXh0QGlldGYub3JnDQo+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRleHQNCj4NCj4tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj5UaGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5 IGNvbnRhaW4gY29uZmlkZW50aWFsDQo+aW5mb3JtYXRpb24sIHByaXZpbGVnZWQgbWF0ZXJp YWwgKGluY2x1ZGluZyBtYXRlcmlhbCBwcm90ZWN0ZWQgYnkgdGhlDQo+c29saWNpdG9yLWNs aWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZpbGVnZXMpLCBvciBjb25zdGl0dXRlDQo+ bm9uLXB1YmxpYyBpbmZvcm1hdGlvbi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5 IGFueW9uZSBvdGhlciB0aGFuDQo+dGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJp dGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzDQo+dHJhbnNtaXNzaW9uIGluIGVycm9y LCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciBhbmQgZGVsZXRlDQo+ dGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24s IGRpc3RyaWJ1dGlvbiwgb3INCj5yZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Npb24g YnkgdW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdA0KPmF1dGhvcml6ZWQgYW5kIG1heSBi ZSB1bmxhd2Z1bC4NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KVGhpcyB0cmFuc21pc3Npb24gKGlu Y2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZv cm1hdGlvbiwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3Rl Y3RlZCBieSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZp bGVnZXMpLCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ug b2YgdGhpcyBpbmZvcm1hdGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQg cmVjaXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJh bnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNl bmRlciBhbmQgZGVsZXRlIHRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4gVXNl LCBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlz IHRyYW5zbWlzc2lvbiBieSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90IGF1dGhvcml6 ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4NCg== From sfaccin@rim.com Mon Feb 14 16:29:07 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1167A3A6C3C for ; Mon, 14 Feb 2011 16:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.943 X-Spam-Level: X-Spam-Status: No, score=-5.943 tagged_above=-999 required=5 tests=[AWL=0.656, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ww7GSfYPhBHz for ; Mon, 14 Feb 2011 16:29:05 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 8D4153A6B6F for ; Mon, 14 Feb 2011 16:29:04 -0800 (PST) X-AuditID: 0a666446-b7b4aae0000009df-ae-4d59c8e7f19a Received: from XCH138CNC.rim.net ( [10.65.20.127]) by mhs04ykf.rim.net (RIM Mail) with SMTP id DD.50.02527.7E8C95D4; Mon, 14 Feb 2011 19:29:27 -0500 (EST) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH138CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Feb 2011 19:29:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" content-transfer-encoding: base64 Date: Mon, 14 Feb 2011 18:29:25 -0600 Message-ID: <680854867F7FD04BB9B06EB8ACA8D5AC0601C1E6@XCH02DFW.rim.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] On the flow mobility discussion Thread-Index: AQHLzC3b2PmyCF1oA0GpKJdDZ+HPZpQBRxwA//+gkICAAKnugIAAAkGA//+o4oCAAHXTsA== References: <680854867F7FD04BB9B06EB8ACA8D5AC0601C1C9@XCH02DFW.rim.net> From: "Stefano Faccin" To: , X-OriginalArrivalTime: 15 Feb 2011 00:29:27.0982 (UTC) FILETIME=[679824E0:01CBCCA7] X-Brightmail-Tracker: AAAAAgAAAZEXZhpt Cc: netext@ietf.org Subject: Re: [netext] On the flow mobility discussion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 00:29:07 -0000 UmFqLA0KWW91IHJhaXNlIGFuIGludGVyZXN0aW5nIGV4YW1wbGUuIFNpbmNlIHlvdSBtZW50 aW9uIDNHUFAsIHBsZWFzZSBub3RlIHRoYXQgYW55IHNvcnQgb2YgaW50ZXJ3b3JraW5nIGJl dHdlZW4gRVYtRE8gYW5kIFdpTUFYIGlzIGNvbXBsZXRlbHkgb3V0IG9mIHNjb3BlIG9mIDNH UFAsIHRoZXJlZm9yZSAzR1BQIHdvdWxkIG5vdCBiZSBhIGN1c3RvbWVyIGZvciB0aGlzIHBy b3RvY29sIGZvciB0aGUgc2NlbmFyaW8geW91IG1lbnRpb24uIA0KDQpJIGFtIGFsc28gd29u ZGVyaW5nIGlmIGFueWJvZHkgaGFzIGluZGljYXRlZCB0aGUgZGVwbG95bWVudCBzY2VuYXJp byBvZiBwYXJhbGxlbCBFVi1ETyBhbmQgV2lNQVggYXMgb25lIG9mIGludGVyZXN0LiANCg0K QXMgZm9yIG90aGVyIGRlcGxveW1lbnQgc2NlbmFyaW9zLCB5b3UgYXJlIGNvcnJlY3QsIGJ1 dCBJIGJlbGlldmUgdGhhdCB0aGUgaXNzdWVzIHJhaXNlZCBhcHBsaWVkIGFzIHdlbGwgdG8g b3RoZXIgZGVwbG95bWVudHMgc2luY2UgdGhleSBhcmUgY29tcGxldGVseSBpbmRlcGVuZGVu dCBvZiB0aGUgZGVjaXNpb25zIDNHUFAgaGFzIHRha2VuLiBUaGUgaXNzdWVzIGV4aXN0IGFu eXdheS4NCg0KQ2hlZXJzLA0KDQpTdGVmYW5vIEZhY2Npbg0KDQpTdGFuZGFyZHMgTWFuYWdl cg0KUmVzZWFyY2ggSW4gTW90aW9uIENvcnBvcmF0aW9uIA0KNTAwMCBSaXZlcnNpZGUgRHJp dmUgDQpCdWlsZGluZyA2LCBCcmF6b3MgRWFzdCwgU3RlLiAxMDANCklydmluZywgVGV4YXMg NzUwMzkgVVNBIA0KT2ZmaWNlOiAoOTcyKSA5MTAgMzQ1McKgIA0KSW50ZXJuYWw6IDgyMC42 MzQ1MQ0KOiAoNTEwKSAyMzAgODQyMg0Kd3d3LnJpbS5jb207IHd3dy5ibGFja2JlcnJ5LmNv bSANCg0KDQoNCu+BkCBDb25zaWRlciB0aGUgZW52aXJvbm1lbnQgYmVmb3JlIHByaW50aW5n Lg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCYXNhdmFyYWouUGF0 aWxAbm9raWEuY29tIFttYWlsdG86QmFzYXZhcmFqLlBhdGlsQG5va2lhLmNvbV0gDQpTZW50 OiBNb25kYXksIEZlYnJ1YXJ5IDE0LCAyMDExIDQ6MTQgUE0NClRvOiBTdGVmYW5vIEZhY2Np bjsganVsaWVuLmlldGZAZ21haWwuY29tDQpDYzogbmV0ZXh0QGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW25ldGV4dF0gT24gdGhlIGZsb3cgbW9iaWxpdHkgZGlzY3Vzc2lvbg0KDQoNCkhp IFN0ZWZhbm8sDQoNCkkgdGhpbmsgZGVwbG95bWVudCBzY2VuYXJpb3MgY291bGQgdmFyeS4g TGV0cyBub3QgY29uc2lkZXIgdGhhdCB0aGlzDQpzb2x1dGlvbiBpcyBhcHBsaWNhYmxlIG9u bHkgaW4gdGhlIGNvbnRleHQgb2YgM0dQUCBuZXR3b3JrcyBhbmQNCmFyY2hpdGVjdHVyZXMu IA0KQXMgYW4gZXhhbXBsZSAoSSBhbSBub3Qgc2F5aW5nIHRoYXQgdGhpcyBpcyBzb21ldGhp bmcgb3RoZXIgU0RPcyBjYXJlDQphYm91dC4gSXRzIGp1c3QgYW4gZXhhbXBsZSk6DQoNCkxl dHMgdGFrZSB0aGUgY2FzZSBvZiBhbiBNTiB3aXRoIGFuIEVWLURPIGFuZCBXaU1BWCBpbnRl cmZhY2UgdGhhdCBpcw0KYXR0YWNoZWQgdG8gYW4gTE1BIHZpYSBNQUd4IGFuZCBNQUd5Lg0K Q291bGQgeW91IG5vdCBtYWtlIGEgY2FzZSB3aGVyZSB0aGUgZmxvdyBjb3VsZCBiZSBzd2l0 Y2hlZCBiZXR3ZWVuIGVpdGhlcg0Kb2YgdGhlc2UgaW50ZXJmYWNlcyBhdCB0aGUgTE1BPw0K V2hhdCB3b3VsZCBiZSB0aGUgaXNzdWVzIGluIHN1Y2ggYSBkZXBsb3ltZW50Pw0KTGV0cyBw cmVzdW1lIHRoYXQgdGhlIHBvbGljaWVzIHJlZ2FyZGluZyB3aGljaCBmbG93cyBhcmUgcm91 dGVkIHZpYSBFVi1ETw0Kb3IgV2lNQVggYXJlIGNvbmZpZ3VyZWQgYXQgdGhlIExNQSBpdHNl bGYuDQoNCkNoZWVycywNCi1SYWoNCg0KT24gMi8xNC8xMSA1OjI1IFBNLCAiZXh0IFN0ZWZh bm8gRmFjY2luIiA8c2ZhY2NpbkByaW0uY29tPiB3cm90ZToNCg0KPkp1bGllbiwNCj5BcyBv bmUgY2FuIGltYWdpbmUgY29uc2lkZXJpbmcgbXkgcHJldmlvdXMgY29tbWVudHMgSSBmdWxs eSBzdXBwb3J0IHlvdXINCj5wb2ludCBiZWxvdy4gQXMgSSBpbmRpY2F0ZWQgcHJldmlvdXNs eSwgdGhlcmUgaXMgaW4gYWRkaXRpb24gdGhlIGZhY3QNCj50aGF0IHdoYXQgaXMgYmVpbmcg ZGV2ZWxvcGVkIHdpbGwgbm90IGJlIGFibGUgdG8gc3VwcG9ydCBjdXJyZW50DQo+ZGV2ZWxv cG1lbnQgc2NlbmFyaW9zLCB3aGljaCByZXN0cmljdHMgdGhlIGFwcGxpY2FiaWxpdHkgb2Yg dGhlIHNvbHV0aW9uLg0KPkNoZWVycywNCj4NCj5TdGVmYW5vIEZhY2Npbg0KPg0KPlN0YW5k YXJkcyBNYW5hZ2VyDQo+UmVzZWFyY2ggSW4gTW90aW9uIENvcnBvcmF0aW9uDQo+NTAwMCBS aXZlcnNpZGUgRHJpdmUNCj5CdWlsZGluZyA2LCBCcmF6b3MgRWFzdCwgU3RlLiAxMDANCj5J cnZpbmcsIFRleGFzIDc1MDM5IFVTQQ0KPk9mZmljZTogKDk3MikgOTEwIDM0NTENCj5JbnRl cm5hbDogODIwLjYzNDUxDQo+OiAoNTEwKSAyMzAgODQyMg0KPnd3dy5yaW0uY29tOyB3d3cu YmxhY2tiZXJyeS5jb20NCj4NCj4NCj4NCj7vgZAgQ29uc2lkZXIgdGhlIGVudmlyb25tZW50 IGJlZm9yZSBwcmludGluZy4NCj4NCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PkZyb206IG5ldGV4dC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bmV0ZXh0LWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZg0KPk9mIEp1bGllbiBMYWdhbmllcg0KPlNlbnQ6IE1vbmRh eSwgRmVicnVhcnkgMTQsIDIwMTEgMzoxOCBQTQ0KPlRvOiBCYXNhdmFyYWouUGF0aWxAbm9r aWEuY29tDQo+Q2M6IG5ldGV4dEBpZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbbmV0ZXh0XSBP biB0aGUgZmxvdyBtb2JpbGl0eSBkaXNjdXNzaW9uDQo+DQo+UmFqLA0KPg0KPk9uIE1vbiwg RmViIDE0LCAyMDExIGF0IDExOjA5IEFNLCAgPEJhc2F2YXJhai5QYXRpbEBub2tpYS5jb20+ IHdyb3RlOg0KPj4NCj4+IEdlcmFyZG8sDQo+Pg0KPj4gT24gMi8xNC8xMSAxMjo1MCBQTSwg ImV4dCBHaWFyZXR0YSwgR2VyYXJkbyIgPGdlcmFyZG9nQHF1YWxjb21tLmNvbT4NCj4+d3Jv dGU6DQo+Pg0KPj4+DQo+Pj4NCj4+PkkgYXNrZWQgZmV3IHF1ZXN0aW9ucyBpbiBhbiBlbWFp bCB3aGljaCBJIHRoaW5rIHdhcyBkaXJlY3RlZCB0byBUZWxlbWFjbw0KPj4+YW5kIG90aGVy cyBidXQgbmV2ZXIgZ290IGEgcmVwbHkuIFRoZSBiYXNpYyBwb2ludCBpcyB0aGF0IG5vYm9k eSBoYXMNCj4+PmFuc3dlcmVkIGhvdyB0aGUgTE1BIGtub3dzIGlmIHRoZSBNTiBpcyBzdGls bCBpbiBhIHJlYXNvbmFibGUgV0xBTg0KPj4+Y292ZXJhZ2UsIGhvdyBsb2FkZWQgV0xBTiBp cywgZXRjLiBUaGVyZSBpcyBhIGh1Z2UgZGlmZmVyZW50IGJldHdlZW4NCj4+PmNlbGx1bGFy IG5ldHdvcmtzIGFuZCBXTEFOczogaW4gY2VsbHVsYXIgbmV0d29ya3MgdGhlIGhhbmRvdmVy cyBhcmUNCj4+PmNvbnRyb2xsZWQgYnkgdGhlIG5ldHdvcmsgYmVjYXVzZSB0aGUgTU4gYWx3 YXlzIHByb3ZpZGVzIG1lYXN1cmVtZW50DQo+Pj5yZXBvcnRzIGFib3V0IHdoYXQgdGhlIE1O IHNlZXMgdG8gdGhlIG5ldHdvcmsuIFRoaXMgaXMgbm90IGluIHBsYWNlIGZvcg0KPj4+aW50 ZXItdGVjaG5vbG9neSBoYW5kb3ZlcnMgYmV0d2VlbiBXTEFOIGFuZCAzRyBhbmQgdGhpcyBp cyB3aHkgeW91DQo+Pj5jYW5ub3QNCj4+PnNhZmVseSBhc3N1bWUgdGhlIExNQSB3aWxsIHRh a2UgdGhlIGNvcnJlY3QgZGVjaXNpb24uDQo+Pj4NCj4+PkkgZG9uJ3QgdGhpbmsgdGhpcyBh cHByb2FjaCBiKSBicmluZ3MgYW55IHZhbHVlIGFuZCBJIGFjdHVhbGx5IHRoaW5rIGl0DQo+ Pj5jcmVhdGVzIGEgbG90IG9mIHByb2JsZW1zLg0KPj4NCj4+DQo+PiBSZWdhcmRpbmcgdGhl IHF1ZXN0aW9uIGFib3V0IHdoZXRoZXIgdGhlIExNQSBrbm93cyB0aGUgc3RhdHVzIG9mIHRo ZSBNTnMNCj4+IGNvbm5lY3Rpdml0eSB0byBhIE1BRyBhbmQgdGhlIHdpZmkgbGluayBjaGFy YWN0ZXJpc3RpY3MgdGhhdCBpdCBpcyB1c2luZw0KPj4gdG8gYXR0YWNoIHRvIGEgTUFHOg0K Pj4gVGhlIExNQSBoYXMgbm8gYXdhcmVuZXNzIG9mIHRoZSBNTnMgY29ubmVjdGl2aXR5L2xp bmsgc3RhdHVzIHRvIGEgTUFHLg0KPj5JdA0KPj4gb25seSBrbm93cyB0aGF0IHRoZSBNTiBo YXMgYXR0YWNoZWQgdmlhIGEgTUFHLiBBbmQgaWYgdGhlIHBvbGljeQ0KPj5pbmRpY2F0ZXMN Cj4+IHRoYXQgdHJhZmZpYyBiZSByb3V0ZWQgdmlhIHRoYXQgTUFHL2ludGVyZmFjZSwgaXQg d2lsbCBkbyBzby4NCj4+DQo+PiBJdCBjb3VsZCByZXN1bHQgaW4gcGFja2V0cyBiZWluZyBk cm9wcGVkIGlmIHRoZSBNTiBoYXMgbW92ZWQgb3V0IG9mIHRoYXQNCj4+IHdpZmkgY292ZXJh Z2Ugb3IgdGhlIGxpbmsgaXMgY29uZ2VzdGVkLiBJbiB0ZXJtcyBvZiB0aGUgc2NvcGUgb2Yg dGhpcw0KPj4gd29yaywgdGhlIGludGVudCBpcyBvbiBzcGVjaWZ5aW5nIGhvdyB0aGUgdHJh ZmZpYyBhc3NvY2lhdGVkIHdpdGggYQ0KPj4gc2Vzc2lvbiBpcyBzd2l0Y2hlZCB0byBhbiBh bHRlcm5hdGUgTUFHLiBUaGUgcG9pbnRzIHRoYXQgeW91IHJhaXNlIGFyZQ0KPj4gb3V0c2lk ZSB0aGUgc2NvcGUgb2YgdGhpcyB3b3JrLg0KPg0KPkkgYXBvbG9naXplIGlmIEkgc3RhcnQg dG8gc291bmQgc2FyY2FzdGljLCBidXQgdGhlIG9ubHkgdGhpbmcgdGhhdA0KPnNlZW1zIGlu IHNjb3BlIG9mIHRoaXMgd29yayBpcyBob3cgdG8gcmVhbGl6ZSBhIGZ1bmN0aW9uDQo+KExN QS1pbml0aWF0ZWQgIGZsb3cgaGFuZG9mZnMpIHRoYXQgY2Fubm90IGJlIHBvc3NpYmx5IHVz ZWQNCj5tZWFuaW5nZnVsbHkgd2l0aG91dCBhIGJ1bmNoIG9mIG90aGVyIG1lY2hhbmlzbXMg KE1OLUxNQSBwb2xpY3kNCj5jb29yZGluYXRpb24sIE1OLUxNQSByYWRpbyBxdWFsaXR5IHJl cG9ydGluZywgZXRjLiApIHRoYXQgZG8gbm90IGV4aXN0DQo+aW4gYW55IGZvcm0gYW5kIGFy ZSBhbHNvIG91dCBvZiBzY29wZSBvZiB0aGlzIHdvcmsuLi4NCj4NCj5BcyBJIHNhaWQsIGFi c2VudCB0aGVzZSBtZWNoYW5pc21zLCBvciBhIHVzZWNhc2UgYW5kIHByb29mIG9mDQo+ZmVh c2liaWxpdHksIGRldmVsb3BpbmcgYW4gTE1BLWluaXRpYXRlZCBmbG93IGhhbmRvZiBmdW5j dGlvbiBtYWtlcyBubw0KPnNlbnNlIHRvIG1lLg0KPg0KPi0tanVsaWVuDQo+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5uZXRleHQgbWFpbGlu ZyBsaXN0DQo+bmV0ZXh0QGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRleHQNCj4NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj5UaGlzIHRyYW5zbWlz c2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5IGNvbnRhaW4gY29uZmlkZW50 aWFsDQo+aW5mb3JtYXRpb24sIHByaXZpbGVnZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRl cmlhbCBwcm90ZWN0ZWQgYnkgdGhlDQo+c29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBs aWNhYmxlIHByaXZpbGVnZXMpLCBvciBjb25zdGl0dXRlDQo+bm9uLXB1YmxpYyBpbmZvcm1h dGlvbi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5IGFueW9uZSBvdGhlciB0aGFu DQo+dGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzDQo+dHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRl bHkgcmVwbHkgdG8gdGhlIHNlbmRlciBhbmQgZGVsZXRlDQo+dGhpcyBpbmZvcm1hdGlvbiBm cm9tIHlvdXIgc3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IN Cj5yZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Npb24gYnkgdW5pbnRlbmRlZCByZWNp cGllbnRzIGlzIG5vdA0KPmF1dGhvcml6ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4NCg0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0KVGhpcyB0cmFuc21pc3Npb24gKGluY2x1ZGluZyBhbnkgYXR0YWNo bWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiwgcHJpdmlsZWdl ZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3RlY3RlZCBieSB0aGUgc29saWNp dG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZpbGVnZXMpLCBvciBjb25zdGl0 dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ugb2YgdGhpcyBpbmZvcm1hdGlv biBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGlzIHByb2hp Yml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9y LCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRo aXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4gVXNlLCBkaXNzZW1pbmF0aW9uLCBk aXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIHRyYW5zbWlzc2lvbiBieSB1 bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90IGF1dGhvcml6ZWQgYW5kIG1heSBiZSB1bmxh d2Z1bC4NCg== From cjbc@it.uc3m.es Mon Feb 14 16:39:45 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AAD03A6DE8 for ; Mon, 14 Feb 2011 16:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.056 X-Spam-Level: X-Spam-Status: No, score=-4.056 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9RWoqDRGthZ for ; Mon, 14 Feb 2011 16:39:43 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 413093A6B6F for ; Mon, 14 Feb 2011 16:39:41 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.3] (213.37.82.169.static.user.ono.com [213.37.82.169]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 7D40BBF5A47; Tue, 15 Feb 2011 01:39:59 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Julien Laganier In-Reply-To: References: <1297677607.4514.71.camel@acorde.it.uc3m.es> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-2G8KztUL5aFHPmWQ7Qve" Organization: Universidad Carlos III de Madrid Date: Tue, 15 Feb 2011 01:41:03 +0100 Message-ID: <1297730463.3945.22.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17956.003 Cc: netext@ietf.org Subject: Re: [netext] On the flow mobility discussion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 15 Feb 2011 00:39:45 -0000 --=-2G8KztUL5aFHPmWQ7Qve Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Julien Thanks for your reply. Some comments below. On Mon, 2011-02-14 at 11:02 -0800, Julien Laganier wrote: > Hi Carlos, >=20 > I am trying to answer some of your questions inline below, but I am > afraid this comes at the cost of having to re-ask the same questions > again and again: >=20 > 2011/2/14 Carlos Jes=FAs Bernardos Cano : > > Hi all, > > > > First of all, thanks for the active and lively discussion. I think that > > we are slowly making some progress. For the sake of making progress, le= t > > me try to summarize the discussion (well, actually, my view of it), pos= e > > some questions and propose some next steps: > > > > - Trigger for flow mobility. We have heard at least two main opinions o= n > > this: a) triggers can only come from the MAG (based on L2 signaling fro= m > > the MN), and b) triggers can come from the MAG or from the LMA. Strong > > points of a): strictly follows current RFC 5213 and allows to support > > scenarios in which the MN can signal to the MAG events relevant to flow > > mobility via L2-specific signaling. Here it is my first question: to me > > L2 triggers and L2 signaling are not the same thing, RFC5213 requires L= 2 > > triggers to be in place (AFAIK, it can also work based on IPv6 ND, with > > some assumptions on how to get the MNID and set the HI) for example to > > detect when a MN has attached. >=20 > Well, the L2 trigger has a cause, which is most certainly that some L2 > signaling occured, or, did not occured (e.g. L2 timer goes off.) As > such, there is little sense in making distinction between the two in > the context of that discussion. To me an L2 trigger at the MAG that says "an interface has attached" based on L2 messages that are there regardless of whether PMIPv6 is being used or not is actually very different from L2 signalling from the MN conveying the message "I want this interface added to this PMIPv6 mobility session". I must be missign something, cause I see huge differences there. >=20 > > However, L2 signaling between = the MN and > > MAG are a bit different (it implies the existence of a communication > > channel for control purposes between MAG and MN that is able to convey > > information relevant/relative to a L3 protocol). Do we want to restri= ct > > the solution to the scenarios in which this L2 signaling channel is > > present? >=20 > See my point above. When the L2 attaches (through L2 signaling, I > don't know of any wireless network attachment that happens by magic), > the MAG is triggered to attach this L2 interface to a PMIPv6 session. > So I don't know what restrictions we would be making by requiring L2 > signaling / triggers. This is already there in RFC5213. True, that L2 signal triggers to add this interface to a new PMIPv6 session (or to a existing one for the case of handover). Here you are proposing a new hint based on L2 indications for flow mobility purposes, right? >=20 > > To cite one example, one of the approaches that = has been > > proposed in the ML requires the MN to signal via L2 (over an attachment > > through iface X) about events of iface Y. >=20 > The approach I've been proposing requires MN to signal via L2 iface X > that iface X be attached to a session. Nothing more, nothing less, all > of which is already required per 5213. In effect, the only added Well, you are requiring that an interface that is already attached has to generate L2 signaling (that otherwise would not be generated) to support the flow mobility scenario. I see that as posing new requirements to a scenario that not require that. > requirement placed on L2 signaling compared to 5213 is that, in > addition the existing inter-interface handoff indicator (attach iface > X to session in lieu of iface Y), we add a new simutaneous attach > handoff indicator (that is, not really a handoff, attach iface X to > session along any existing ifaces Y, Z etc. that were already > attached.) We'd also need the ability to selectively detach an > interface and keep the other ifaces in the session attached. That > could be done through use of the same HI I just introduced, but in a > deregistration PBU. Sure if we can put all that semantics on the L2 signaling, MAG triggered flow mobility can be supported (as well as with the "flow bindings" based approach that we describe in our draft) . LMA triggered remains to be the issue. >=20 > > Regarding b) Julien (and other folks) have asked about scenarios that > > require that. I think 3G offloading is one of the scenarios that > > requires that to be supported. If an operator has an MN that is attache= d > > to WLAN and 3G simultaneously wants (because of network load conditions= ) > > to offload some flows from 3G to WLAN on demand, I think this should be > > supported, and LMA initiated flow mobility is the way to do it. >=20 > As I've explained in other notes, there is no basis for the LMA to > unilateraly decide where to send flows. This simply doesn't work in a > variety of cases where a wireless L2 might be attached but provide no > meaningful connectivity. Even in your approach, the LMA would be the one deciding where to send flows, right? a mobility session would have different interfaces attached, and the LMA would always be the one deciding through which MAG (i.e. through which MN interface) the traffic will be delivered. >=20 > > = Some > > folks have said that the MN is the only one that knows the quality of > > the signal it receives and this is mostly true (note that there are > > solutions than allows the owner of the WLAN to know of the quality and > > status of the network), but it is also true that in current celular > > networks handovers are controlled by the network (based on signal > > quality reports from the MN). To me PMIPv6 follows the same model: > > network controlled __IP__ mobility. >=20 > You cannot generalize what a cellular network does with a homogeneous > collections of radio access technologies that are all developed in the > same system, and include signaling for the terminal equipment to > report to a control network node what is the signal quality, to an IP > layer mobility management in which the radio techonologies were not > developed to fit together, and you do not have terminal to network > signaling for radio signal quality. To me generalizing that is as generalizing the existence of L2 signaling that does all what is missing to support flow mobility. >=20 > Further, even if you could (but surely you can't), let me point out > that in the network controlled cellular systems that are deployed > and/or specified, the entity that takes the decision is an edge entity > (e.g. SGSN, MME) which is closer to MAG rather than a hierarchical > entity (e.g., GGSN, PGW) similar to LMA. >=20 > Thus your statement that the LMA being in control would make PMIPv6 > following the same model than cellular network seems to be factually > incorrect. >=20 > > - On the RFC5213 model and extensions to it. We can debate (as we are > > doing) on the pros and cons of different technical approaches, that's > > what we can do. However, I disagree with the idea that adding new > > messages between LMA and MAG (if they are necessary) is fundamentally > > changing the protocol and that we need to change the charter, ask the > > ADs, etc. Current charter says on this regard: > > > > "The working group will determine what protocol extensions are > > required between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) > > to support the ability for an interface (at the IP layer) to > > transmit packets over different media, the ability to distribute > > specific traffic flows on different media components of that > > interface, and making this work with the handover hints in the base > > protocol. The relevant protocol extensions will be developed as > > necessary." >=20 > The point I have relentlessly making is that, in order to provide flow > mobility, you do NOT need to change the basics of RFC 5213 session > management, and thus, from out charter item it follows that we have > determined that this needs not to be changed, and thus you need not to > extend it. My point is that we don't change the basics of RFC 5213 session management. Actually we don't introduce any change, but we just put the flow bindings support on top to be able to route flows. >=20 > That, is unless somebody comes up with the killer usecase, which would > have to involve more than: "I want to allocate a different prefix" > because this has nothing to do with flow mobility. Sorry, but I see both approaches equivalent. >=20 > > I think all technical approaches discussed so far are fine with the > > above text. Even one could read that text as preventing from adding new > > handover hints (which has been proposed as one of the solutions), thoug= h > > that's not my reading. >=20 > Truly no. >=20 > Instead of doing charter exegesis, let's have those who favor the > alternative model come up with a valid and motivated usecase.... This only applies to the need of the LMA triggered scenario, not on the technical approach itself. Both yours and the one included in our draft provides the same functionality. > Please.... >=20 > > - On the technical approach itself. If we forget for a second about the > > LMA-triggered event, and we just think of MAG triggered ones, there hav= e > > been two fundamental approaches proposed so far. I think Tran summarize= d > > them very well in a previous e-mail. Let me try it again for the sake o= f > > this discussion: a) extensions to RFC5213 to support dynamically adding > > and removing interfaces to mobility sessions, and b) extensions to > > RFC5213 (based on standardized solutions developed in the MEXT WG) to > > allow dynamic prefix management (and use that as a way to enable flow > > mobility). Option a) does requires to modify conceptual data structures > > defined in RFC5213 as well as state machines (to support the new > > behavior). Option b) does not require modifications to the mobility > > session related data structures, but on the other hand adds new ones > > (related to flow bindings) and also modifies state machines. Option b) > > leverages on existing MEXT work. >=20 > Option b) is dynamic prefix management and is not necessary per se to > do flow mobility so I am starting to really wonder why we are still > discussing it in the first place. Why do you call it prefix management? I call it flow bindings over RFC 5213 mobility sessions. >=20 > Option a) works. Unless it is not sufficient to support a motivated > and real usecase, there is no reason for us to even discuss anything > else. Why? I can say the same for your solution. >=20 > > To me, in order to enable flow mobility in PMIPv6, there are two main > > things needed (on the network side): the ability for the LMA to perform > > flow routing (i.e. not just routing based on IP destination prefix) and > > to allow the MAG to route prefixes that have not been delegated by the > > LMA on the initial interface attachment of the MN (i.e. to support the > > dynamic modification of the prefixes -- associated to a particular MN -= - > > that the MAG is aware of). Of course, we need on the mobile side the > > ability to receive and send packets simultaneously through different > > physical interfaces (regardless of the IPs used). IMO, both technical > > approaches a) and b) above meet the technical requirements without > > posing any issue related to implementation complexity (both follows the > > KISS principle) or charter compliance. >=20 > a) works. b) is unecessary unless proven otherwise, which hasn't happen. >=20 > > > > To sum up this long e-mail, I see two main issues that need to be > > resolved to be able to progress: > > > > - Trigger issue. I see the need for both LMA and MAG initiated. > > Therefore I propose to work on a solution that supports BOTH. Different > > people have expressed their preferences to support both and I don't see > > any major issue on that. The only required change to support both is th= e > > addition of some signaling between LMA and MAG. >=20 > There is a major issue that there is no basis for an LMA to decide > where to send flows, and nobody was able to refute the argument I put > forth why this doesn't work. But this applies to any solution, right? The LMA is always the entity that has to decide to which MAG it should send the traffic. Kind Regards, Carlos >=20 > So I propose we work on a solution that works, that is, MAG initiated. >=20 > > - Technical approach issue (interface adding to mobility sessions vs > > "flow bindings based" approach). I don't see major issues in any of > > them. Current draft follows the second and I prefer to keep using it, > > unless there is a clear advantage (that I don't see at this point) of > > using the first. >=20 > The clear advantage of using the first is that it supports flow > mobility. You don't need to have two ways of doing something in a > standards, unless you have to. >=20 > And you don't have to it seems, or I missed the email describing the > valid and motivated use case to do dynamic prefix management in lieu > of simple flow mobility. >=20 > If we want to move forward, we have to settle for simple single model > I've proposed, or the proponent of doing otherwise have to come up > with answers to the questions I've put forth eventually. I'll let them > choose. >=20 > --julien --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-2G8KztUL5aFHPmWQ7Qve Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1Zy5kACgkQNdy6TdFwT2cRAwCdGLhDtwOYnzmYu7OeB6TMU5OX goIAoJcHk05SCUCJBRZ5wdTiBmkwuYcW =b7IR -----END PGP SIGNATURE----- --=-2G8KztUL5aFHPmWQ7Qve-- From yh21.han@gmail.com Mon Feb 14 17:37:47 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E955F3A6E04 for ; Mon, 14 Feb 2011 17:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFhdHK2faNMW for ; Mon, 14 Feb 2011 17:37:45 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id A73633A6A0C for ; Mon, 14 Feb 2011 17:37:45 -0800 (PST) Received: by pzk5 with SMTP id 5so1153958pzk.31 for ; Mon, 14 Feb 2011 17:38:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=h3x/mPlW1UGNGwNJNyhqtTHIjsesRayBOlRzkgGiUg8=; b=kTJod9UXciNpKuNSyyB3WHWuQ8e/58BFVgrjqXChPY2WxqhmUDb8p6QesJHFEsCaGn uqbGFWc54gWJaqihvs/LevqiwN9xS+xZFN6f5DT5dUJuLSAh2WzceVH6ufAmPztXDzSl AJu8IGaA8U6BYAivvzEVZuMzzCr3qqTGjvm/M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=bVzopId2UkcV6aIqKr4sIRzzwE7prT/1mmKX5nqEbDbgz7gRptA7RY/lINz/pmcpsr pAhqRQkt/P4PJe9tCS7N82EnOFOeIiXEpeRW0zUVU/zYAZOyniVndO13nrAk1KgBwg6K V0lg8iUzum+YgChAUPcSAICjbWdueIdB+51gM= Received: by 10.143.34.4 with SMTP id m4mr3663924wfj.358.1297733889975; Mon, 14 Feb 2011 17:38:09 -0800 (PST) Received: from USERPC ([220.68.82.28]) by mx.google.com with ESMTPS id y42sm4938950wfd.22.2011.02.14.17.38.07 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Feb 2011 17:38:08 -0800 (PST) From: "Youn-Hee Han" To: "'Julien Laganier'" , References: <1297677607.4514.71.camel@acorde.it.uc3m.es> In-Reply-To: Date: Tue, 15 Feb 2011 10:38:04 +0900 Message-ID: <01f001cbccb1$000dc050$002940f0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGpNwhiI/EAb+IhoRNCaiNKkLsOmgJYaEKAlDQifnA= Content-Language: ko Cc: netext@ietf.org Subject: Re: [netext] On the flow mobility discussion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 01:37:47 -0000 Hi Julien and Stefano, > > Regarding b) Julien (and other folks) have asked about scenarios that > > require that. I think 3G offloading is one of the scenarios that > > requires that to be supported. If an operator has an MN that is > > attached to WLAN and 3G simultaneously wants (because of network load > > conditions) to offload some flows from 3G to WLAN on demand, I think > > this should be supported, and LMA initiated flow mobility is the way > to do it. > > As I've explained in other notes, there is no basis for the LMA to > unilateraly decide where to send flows. This simply doesn't work in a > variety of cases where a wireless L2 might be attached but provide no > meaningful connectivity. > > > > > Some folks have said that the MN is the only one that knows the > > quality of the signal it receives and this is mostly true (note that > > there are solutions than allows the owner of the WLAN to know of the > > quality and status of the network), but it is also true that in > > current celular networks handovers are controlled by the network > > (based on signal quality reports from the MN). To me PMIPv6 follows > the same model: > > network controlled __IP__ mobility. > > You cannot generalize what a cellular network does with a homogeneous > collections of radio access technologies that are all developed in the > same system, and include signaling for the terminal equipment to report > to a control network node what is the signal quality, to an IP layer > mobility management in which the radio techonologies were not developed > to fit together, and you do not have terminal to network signaling for > radio signal quality. > > Further, even if you could (but surely you can't), let me point out that > in the network controlled cellular systems that are deployed and/or > specified, the entity that takes the decision is an edge entity (e.g. > SGSN, MME) which is closer to MAG rather than a hierarchical entity > (e.g., GGSN, PGW) similar to LMA. > > Thus your statement that the LMA being in control would make PMIPv6 > following the same model than cellular network seems to be factually > incorrect. The procedural sequence of two initiation ways seems to be as follows: 1) MAG/MN initiation: L2 trigger to MAG -> MAG sends PBU to LMA -> LMA redistribute flows, 2) LMA initiation: L2 trigger to SGSN/MME -> SGSN/MME sends a signaling to LMA -> LMA redistribute flows. Based on such procedural sequence, I am not able to find any technical reason that rejects one way, while accepting the other way. Of course, the signaling between SGSN/MME and LMA is implementation-specific and out of scope. However, if operators install PMIPv6 function in their networks, they know well that LMA is the topological anchor (i.e., all traffic pass through the LMA), and thus they will consent to implement such signaling to support flow mobility. There is another scenario to go well with LMA initiation. It can be setup with a policy provisioning based on a kind of contract formed between a mobile client and operator. We don't need to stand firmly by that a policy will be made only based on L2 triggers. We can expect that a policy will be made based on many reasons, such as spatial, temporal, environmental, or even social events. Should do we restrict such various events to be brought by MN or L2 trigger between MN and MAG? I think that a network-controlled flow mobility should allow them to directly stimulate the LMA to redistribute flows across MAGs/interfaces. Youn-Hee From hesham@elevatemobile.com Mon Feb 14 19:13:56 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8EB63A6DF5 for ; Mon, 14 Feb 2011 19:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMAhR1eW+exg for ; Mon, 14 Feb 2011 19:13:55 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 2C2E33A6C3F for ; Mon, 14 Feb 2011 19:13:54 -0800 (PST) Received: from [122.110.171.194] (helo=[192.168.0.2]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1PpBMb-0002jO-43; Tue, 15 Feb 2011 14:14:06 +1100 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 15 Feb 2011 14:13:52 +1100 From: Hesham Soliman To: , , Message-ID: Thread-Topic: [netext] On the flow mobility discussion Thread-Index: AQHLzC3b2PmyCF1oA0GpKJdDZ+HPZpQBRxwA//+gkICAAKnugP//qhiAgAB1qRD//4y0AAAUymlO In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Authenticated-User: hesham@elevatemobile.com Cc: netext@ietf.org Subject: Re: [netext] On the flow mobility discussion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 03:13:56 -0000 Hi Raj,=20 The questions are not left unanswered due to lack of enthusiasm; if anythin= g there is too much enthusiasm here. They're not being answered because there are no good answers to the issues raised. We've seen this discussion before more than once, there is _nothing_ new being discussed. The basic concept o= f doing flow mobility based only on network entities' knowledge is broken and will not be used in today's networks. But lets continue talking about it.... Hesham On 15/02/11 11:18 AM, "Basavaraj.Patil@nokia.com" wrote: >=20 > Hi Stefano, >=20 > I am not saying that we solve the problem only for the best case scenario= . > I am hoping that some of the folks who are actively involved with the > solution development can provide answers about how the concerns raised by > Julien et al. can be dealt with. > How do you handle the case when the LMA switches flows to a MAG that > cannot deliver packets reliably to the MN? Given that there is no feedbac= k > mechanism to the LMA, there are no easy answers or mechanisms. But I want > to make sure that we get a chance to let the authors provide a response. >=20 > -Raj >=20 > On 2/14/11 6:13 PM, "ext Stefano Faccin" wrote: >=20 >> Raj, >> I apologize for being slow, but I really do not understand what you are >> saying. Do we really want to develop a solution that works only in the >> best case scenario and utterly disregards realistic scenarios like the >> ones Julien and others have mentioned? Is this good engineering work by >> IETF? What you are saying below is literally that we are OK if the >> solution does not work in scenario that can indeed happen and rather >> often already today. I cannot believe we are seriously willing to settle >> for that.=20 >>=20 >> Cheers, >>=20 >> Stefano Faccin >>=20 >> Standards Manager >> Research In Motion Corporation >> 5000 Riverside Drive >> Building 6, Brazos East, Ste. 100 >> Irving, Texas 75039 USA >> Office: (972) 910 3451 >> Internal: 820.63451 >> : (510) 230 8422 >> www.rim.com; www.blackberry.com >>=20 >>=20 >>=20 >> =EF=81=90 Consider the environment before printing. >>=20 >>=20 >> -----Original Message----- >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf >> Of Basavaraj.Patil@nokia.com >> Sent: Monday, February 14, 2011 4:10 PM >> To: julien.ietf@gmail.com >> Cc: netext@ietf.org >> Subject: Re: [netext] On the flow mobility discussion >>=20 >>=20 >> Julien, >>=20 >> I understand the issue about the fact that an MN may have moved out of >> wifi coverage after registering thru MAGy. >> Or for that matter the wifi network via which the MN is attached (thru >> MAGy) is congested or the link quality is poor. >> And this could happen. >>=20 >> But on the flip side, the MN may be attached to a wifi network and is ab= le >> to send/recv packets thru MAGy with no issues, In which case switching t= he >> flow at the LMA would work just fine. >>=20 >> Does it not make sense to have a solution for this case? The error case >> when the packets sent to the MN via MAGy into oblivion cannot be ignored= . >> But neither can you say that there is no way this would work at all. >>=20 >> -Raj >>=20 >> On 2/14/11 5:17 PM, "ext Julien Laganier" wrote: >>=20 >>> Raj, >>>=20 >>> On Mon, Feb 14, 2011 at 11:09 AM, wrote: >>>>=20 >>>> Gerardo, >>>>=20 >>>> On 2/14/11 12:50 PM, "ext Giaretta, Gerardo" >>>> wrote: >>>>=20 >>>>>=20 >>>>>=20 >>>>> I asked few questions in an email which I think was directed to >>>>> Telemaco >>>>> and others but never got a reply. The basic point is that nobody has >>>>> answered how the LMA knows if the MN is still in a reasonable WLAN >>>>> coverage, how loaded WLAN is, etc. There is a huge different between >>>>> cellular networks and WLANs: in cellular networks the handovers are >>>>> controlled by the network because the MN always provides measurement >>>>> reports about what the MN sees to the network. This is not in place f= or >>>>> inter-technology handovers between WLAN and 3G and this is why you >>>>> cannot >>>>> safely assume the LMA will take the correct decision. >>>>>=20 >>>>> I don't think this approach b) brings any value and I actually think = it >>>>> creates a lot of problems. >>>>=20 >>>>=20 >>>> Regarding the question about whether the LMA knows the status of the >>>> MNs >>>> connectivity to a MAG and the wifi link characteristics that it is >>>> using >>>> to attach to a MAG: >>>> The LMA has no awareness of the MNs connectivity/link status to a MAG. >>>> It >>>> only knows that the MN has attached via a MAG. And if the policy >>>> indicates >>>> that traffic be routed via that MAG/interface, it will do so. >>>>=20 >>>> It could result in packets being dropped if the MN has moved out of >>>> that >>>> wifi coverage or the link is congested. In terms of the scope of this >>>> work, the intent is on specifying how the traffic associated with a >>>> session is switched to an alternate MAG. The points that you raise are >>>> outside the scope of this work. >>>=20 >>> I apologize if I start to sound sarcastic, but the only thing that >>> seems in scope of this work is how to realize a function >>> (LMA-initiated flow handoffs) that cannot be possibly used >>> meaningfully without a bunch of other mechanisms (MN-LMA policy >>> coordination, MN-LMA radio quality reporting, etc. ) that do not exist >>> in any form and are also out of scope of this work... >>>=20 >>> As I said, absent these mechanisms, or a usecase and proof of >>> feasibility, developing an LMA-initiated flow handof function makes no >>> sense to me. >>>=20 >>> --julien >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >>=20 >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential >> information, privileged material (including material protected by the >> solicitor-client or other applicable privileges), or constitute >> non-public information. Any use of this information by anyone other than >> the intended recipient is prohibited. If you have received this >> transmission in error, please immediately reply to the sender and delete >> this information from your system. Use, dissemination, distribution, or >> reproduction of this transmission by unintended recipients is not >> authorized and may be unlawful. >=20 > _______________________________________________ netext mailing > list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From hesham@elevatemobile.com Mon Feb 14 19:17:46 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D2333A6E23 for ; Mon, 14 Feb 2011 19:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNJPDgr801ma for ; Mon, 14 Feb 2011 19:17:45 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id EC5E03A6E21 for ; Mon, 14 Feb 2011 19:17:42 -0800 (PST) Received: from [122.110.171.194] (helo=[192.168.0.2]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1PpBQM-0003eA-UP; Tue, 15 Feb 2011 14:18:00 +1100 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 15 Feb 2011 14:17:51 +1100 From: Hesham Soliman To: Stefano Faccin , , Message-ID: Thread-Topic: [netext] On the flow mobility discussion Thread-Index: AQHLzC3b2PmyCF1oA0GpKJdDZ+HPZpQBRxwA//+gkICAAKnugP//qhiAgAB1qRCAADQkag== In-Reply-To: <680854867F7FD04BB9B06EB8ACA8D5AC0601C1DD@XCH02DFW.rim.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: netext@ietf.org Subject: Re: [netext] On the flow mobility discussion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 03:17:46 -0000 > > I understand the issue about the fact that an MN may have moved out of > wifi coverage after registering thru MAGy. > Or for that matter the wifi network via which the MN is attached (thru > MAGy) is congested or the link quality is poor. > And this could happen. > > But on the flip side, the MN may be attached to a wifi network and is able > to send/recv packets thru MAGy with no issues, In which case switching the > flow at the LMA would work just fine. > > Does it not make sense to have a solution for this case? => No it doesn't make sense. Because those cases are not deployment scenarios, they're runtime changes within any deployment. This would be a solution that "may" work. In other words a useless solution. Hesham The error case > when the packets sent to the MN via MAGy into oblivion cannot be ignored. > But neither can you say that there is no way this would work at all. > > -Raj > > On 2/14/11 5:17 PM, "ext Julien Laganier" wrote: > >> Raj, >> >> On Mon, Feb 14, 2011 at 11:09 AM, wrote: >>> >>> Gerardo, >>> >>> On 2/14/11 12:50 PM, "ext Giaretta, Gerardo" >>> wrote: >>> >>>> >>>> >>>> I asked few questions in an email which I think was directed to Telemaco >>>> and others but never got a reply. The basic point is that nobody has >>>> answered how the LMA knows if the MN is still in a reasonable WLAN >>>> coverage, how loaded WLAN is, etc. There is a huge different between >>>> cellular networks and WLANs: in cellular networks the handovers are >>>> controlled by the network because the MN always provides measurement >>>> reports about what the MN sees to the network. This is not in place for >>>> inter-technology handovers between WLAN and 3G and this is why you >>>> cannot >>>> safely assume the LMA will take the correct decision. >>>> >>>> I don't think this approach b) brings any value and I actually think it >>>> creates a lot of problems. >>> >>> >>> Regarding the question about whether the LMA knows the status of the MNs >>> connectivity to a MAG and the wifi link characteristics that it is using >>> to attach to a MAG: >>> The LMA has no awareness of the MNs connectivity/link status to a MAG. >>> It >>> only knows that the MN has attached via a MAG. And if the policy >>> indicates >>> that traffic be routed via that MAG/interface, it will do so. >>> >>> It could result in packets being dropped if the MN has moved out of that >>> wifi coverage or the link is congested. In terms of the scope of this >>> work, the intent is on specifying how the traffic associated with a >>> session is switched to an alternate MAG. The points that you raise are >>> outside the scope of this work. >> >> I apologize if I start to sound sarcastic, but the only thing that >> seems in scope of this work is how to realize a function >> (LMA-initiated flow handoffs) that cannot be possibly used >> meaningfully without a bunch of other mechanisms (MN-LMA policy >> coordination, MN-LMA radio quality reporting, etc. ) that do not exist >> in any form and are also out of scope of this work... >> >> As I said, absent these mechanisms, or a usecase and proof of >> feasibility, developing an LMA-initiated flow handof function makes no >> sense to me. >> >> --julien > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > --------------------------------------------------------------------- This > transmission (including any attachments) may contain confidential information, > privileged material (including material protected by the solicitor-client or > other applicable privileges), or constitute non-public information. Any use of > this information by anyone other than the intended recipient is prohibited. If > you have received this transmission in error, please immediately reply to the > sender and delete this information from your system. Use, dissemination, > distribution, or reproduction of this transmission by unintended recipients is > not authorized and may be unlawful. > _______________________________________________ netext mailing > list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From zhou.xingyue@zte.com.cn Mon Feb 14 23:51:16 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A76A3A6E53; Mon, 14 Feb 2011 23:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.052 X-Spam-Level: X-Spam-Status: No, score=-95.052 tagged_above=-999 required=5 tests=[AWL=-2.262, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ej5jpLJALDu8; Mon, 14 Feb 2011 23:51:15 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 0A6C83A6A5A; Mon, 14 Feb 2011 23:51:13 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 205953502467742; Tue, 15 Feb 2011 15:46:42 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 84746.10283158427; Tue, 15 Feb 2011 15:50:05 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p1F7nxpR014876; Tue, 15 Feb 2011 15:49:59 +0800 (GMT-8) (envelope-from zhou.xingyue@zte.com.cn) In-Reply-To: To: Hesham Soliman MIME-Version: 1.0 X-KeepSent: 8EC9613A:DB5E575C-48257838:0024C409; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.xingyue@zte.com.cn Date: Tue, 15 Feb 2011 15:49:53 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-02-15 15:50:00, Serialize complete at 2011-02-15 15:50:00 Content-Type: multipart/alternative; boundary="=_alternative 002B03C248257838_=" X-MAIL: mse01.zte.com.cn p1F7nxpR014876 Cc: zhou.na@zte.com.cn, netext@ietf.org, zhu.jinguo@zte.com.cn, Basavaraj.Patil@nokia.com, netext-bounces@ietf.org Subject: [netext] =?gb2312?b?tPC4tDogUmU6ICBPbiB0aGUgZmxvdyBtb2JpbGl0eSBk?= =?gb2312?b?aXNjdXNzaW9u?= X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 07:51:16 -0000 This is a multipart message in MIME format. --=_alternative 002B03C248257838_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQpJTUhPLCBpbml0aWF0aW5nIGZsb3cgbW9iaWxpdHkgYnkgZWl0aGVyIHRlcm1pbmFsIHNp ZGUgb3IgbmV0d29yayBzaWRlIA0KaXRzZWxmIGlzIGEga2luZCBvZiBoZWxwbGVzcyBjaG9pY2Uu IFBlb3BsZSBzdXJlbHkgd2FudCBzdGFibGUgZmxvd3Mgb3RoZXIgDQp0aGFuICJmbGV4aWJsZSIg Zmxvd3MuIFNvIGluIG1vc3QgY2FzZXMsIHdlIHVzZSBmbG93IG1vYmlsaXR5IG9ubHkgd2hlbiB3 ZSANCmhhdmUgdG8gZG8uDQpJbiBjYXNlIG9mIGhvc3QtYmFzZWQgZmxvdyBtb2JpbGl0eSwgdGVy bWluYWwgZGVjaWRlcyB0byBtb3ZlIHNwZWNpZmljIA0KZmxvd3MgZHVlIHRvIGUuZy4gb3V0IG9m IHRoZSB3aWZpIGNvdmVyYWdlIGJ5IHNlbmRpbmcgQlUgdG8gbm90aWZ5IHRoZSANCm5ldHdvcmsu IEhvd2V2ZXIsIHRoZSBuZXR3b3JrIHdpbGwgcmVqZWN0IHRoaXMgcmVxdWVzdCBpZiBuZXR3b3Jr IGRvZXMgbm90IA0Kc3VwcG9ydCB0cmFuc3BvcnRpbmcgdGhpcyBmbG93IHRocm91Z2ggb3RoZXIg YWNjZXNzZXMuICBUaGVuLCB0aGUgZmxvdyANCndpbGwgYmUga2lsbGVkLiBJdCBpcyBub3QgYSB0 ZXJyaWJsZSB0aGluZyBpZiBhIGZsb3cgY2FuIG5vdCBzdXJ2aXZlIHRoZSANCnNhbWUgaW4gbmV0 d29yay1iYXNlZCBzY2VuYXJpby4gSSBiZWxpZXZlIGl0IGRvZXMgbWFrZSBzZW5zZSB0byBzdHVk eSBvbiANCkxNQS1pbml0aWF0ZWQgZmxvdyBtb2JpbGl0eSBhbHRob3VnaCB0aGUgZmxvdyBtYXkg YmUgZGVhZCBkdWUgdG8gZS5nLiBNTiANCm91dCBvZiB0aGUgdGFyZ2VyIGFjY2Vzcy4gQW55d2F5 LCBubyBzb2x1dGlvbiBpcyBwZXJmZWN0Lg0KSSBkaXNhZ3JlZSB0aGUgdGhvdWdodHMgYWJvdXQg bm8gYmFzaXMgZXhpc3RpbmcgZm9yIHRoZSBMTUEgdG8gdW5pbGF0ZXJhbHkgDQpkZWNpZGUgd2hl cmUgdG8gc2VuZCBmbG93cy4gTE1BIGlzIHVzdWFsbHkgY29ubmVjdGVkIHdpdGggbmV0d29yayAN Cm1hbmFnZW1lbnQgc3lzdGVtIHN1Y2ggYXMgdHJhZmZpYyBtb25pdG9yaW5nIGRlcGxveWVkIGlu IHRoZSBvcGVyYXRvcidzIA0KaW50ZXJuYWwgbmV0d29yay4gV2hlbiBzZXJpb3VzIGNvbmdlc3Rp b24gb2NjdXJzIGluIHNvbWUgYWNjZXNzIHN5c3RlbSwgDQp0aGUgTE1BIGlzIHJlcG9ydGVkICB0 aGlzIGluZm8gYnkgbW9uaXRvcmluZyBzeXN0ZW0uIFRoZW4sIGl0IGlzIExNQSB0byANCmRlY2lk ZSB3aGljaCBmbG93cyBzaG91bGQgYmUgbW92ZWQgZnJvbSB0aGUgY29uZ2VzdGVkIHN5c3RlbS4g QWZ0ZXIgYWxsIA0KdGhlIExNQSBrbm93cyB0aGF0IHdoaWNoIE1OcyBjb25uZWN0aW5nIG11bHRp cGxlIE1BR3Mgc2ltdWx0YW5lb3VzbHkgYW5kIA0KY2FuIG1ha2UgZmxvdyBwb2xpY2llcyBhY2Nv cmRpbmcgdG8gY3VycmVudCBzaXR1YXRpb24uIElmIHRoZSBwYWNrZXQgDQpiZWxvbmdpbmcgdG8g dGhlIG1vdmVkIGZsb3cgZHJvcHBlZCBieSB0aGUgdGFyZ2V0IE1BRywgd2hhdCB3ZSBjYW4gZG8g aXMgDQpqdXN0IGxldCBpdCBnbyBjYXVzZSB0aGUgbmV0d29yayBoYXMgZG9uZSBpdHMgYmVzdCB0 byBhdm9pZCBiYWQgdXNlciANCmV4cGVyaWVuY2UuIE1vcmV2ZXIsIGJlZm9yZSBkZWNpZGluZyB0 aGUgZmxvdyByb3V0aW5nIHRvIHdoaWNoIE1BRywgYSANCmhlYWx0aCBzdGF0dXMgY2hlY2sgIGJl dHdlZW4gdGVybWluYWwgYW5kIExNQSBjYW4gYmUgcGVyZm9ybWVkIHdoaWNoIGlzIA0KaW1wbGVt ZW50YXRpb24gZGVwZW5kZW50LiBQb2xpY3kgQmFzaXMgZm9yIExNQSBuZWVkcyB0byBiZSBmdXJ0 aGVyIHN0dWRpZWQgDQphbmQgc2hvdWxkICBub3QgYmUgc3BlY2lmaWVkIGluIHRoaXMgZHJhZnQu DQoNClJlZ2FyZHMsDQpKb3kNCg0KDQoNCkhlc2hhbSBTb2xpbWFuIDxoZXNoYW1AZWxldmF0ZW1v YmlsZS5jb20+IA0Kt6K8/sjLOiAgbmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTEtMDItMTUg yc/O5yAxMToxNw0KDQrK1bz+yMsNClN0ZWZhbm8gRmFjY2luIDxzZmFjY2luQHJpbS5jb20+LCA8 QmFzYXZhcmFqLlBhdGlsQG5va2lhLmNvbT4sIA0KPGp1bGllbi5pZXRmQGdtYWlsLmNvbT4NCrOt y80NCm5ldGV4dEBpZXRmLm9yZw0K1vfM4g0KUmU6IFtuZXRleHRdIE9uIHRoZSBmbG93IG1vYmls aXR5IGRpc2N1c3Npb24NCg0KDQoNCg0KDQoNCg0KDQoNCj4gDQo+IEkgdW5kZXJzdGFuZCB0aGUg aXNzdWUgYWJvdXQgdGhlIGZhY3QgdGhhdCBhbiBNTiBtYXkgaGF2ZSBtb3ZlZCBvdXQgb2YNCj4g d2lmaSBjb3ZlcmFnZSBhZnRlciByZWdpc3RlcmluZyB0aHJ1IE1BR3kuDQo+IE9yIGZvciB0aGF0 IG1hdHRlciB0aGUgd2lmaSBuZXR3b3JrIHZpYSB3aGljaCB0aGUgTU4gaXMgYXR0YWNoZWQgKHRo cnUNCj4gTUFHeSkgaXMgY29uZ2VzdGVkIG9yIHRoZSBsaW5rIHF1YWxpdHkgaXMgcG9vci4NCj4g QW5kIHRoaXMgY291bGQgaGFwcGVuLg0KPiANCj4gQnV0IG9uIHRoZSBmbGlwIHNpZGUsIHRoZSBN TiBtYXkgYmUgYXR0YWNoZWQgdG8gYSB3aWZpIG5ldHdvcmsgYW5kIGlzIA0KYWJsZQ0KPiB0byBz ZW5kL3JlY3YgcGFja2V0cyB0aHJ1IE1BR3kgd2l0aCBubyBpc3N1ZXMsIEluIHdoaWNoIGNhc2Ug c3dpdGNoaW5nIA0KdGhlDQo+IGZsb3cgYXQgdGhlIExNQSB3b3VsZCB3b3JrIGp1c3QgZmluZS4N Cj4gDQo+IERvZXMgaXQgbm90IG1ha2Ugc2Vuc2UgdG8gaGF2ZSBhIHNvbHV0aW9uIGZvciB0aGlz IGNhc2U/DQoNCj0+IE5vIGl0IGRvZXNuJ3QgbWFrZSBzZW5zZS4gQmVjYXVzZSB0aG9zZSBjYXNl cyBhcmUgbm90IGRlcGxveW1lbnQNCnNjZW5hcmlvcywgdGhleSdyZSBydW50aW1lIGNoYW5nZXMg d2l0aGluIGFueSBkZXBsb3ltZW50LiBUaGlzIHdvdWxkIGJlIGENCnNvbHV0aW9uIHRoYXQgIm1h eSIgd29yay4gSW4gb3RoZXIgd29yZHMgYSB1c2VsZXNzIHNvbHV0aW9uLg0KDQpIZXNoYW0NCg0K DQpUaGUgZXJyb3IgY2FzZQ0KPiB3aGVuIHRoZSBwYWNrZXRzIHNlbnQgdG8gdGhlIE1OIHZpYSBN QUd5IGludG8gb2JsaXZpb24gY2Fubm90IGJlIA0KaWdub3JlZC4NCj4gQnV0IG5laXRoZXIgY2Fu IHlvdSBzYXkgdGhhdCB0aGVyZSBpcyBubyB3YXkgdGhpcyB3b3VsZCB3b3JrIGF0IGFsbC4NCj4g DQo+IC1SYWoNCj4gDQo+IE9uIDIvMTQvMTEgNToxNyBQTSwgImV4dCBKdWxpZW4gTGFnYW5pZXIi IDxqdWxpZW4uaWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4+IFJhaiwNCj4+IA0KPj4gT24g TW9uLCBGZWIgMTQsIDIwMTEgYXQgMTE6MDkgQU0sICA8QmFzYXZhcmFqLlBhdGlsQG5va2lhLmNv bT4gd3JvdGU6DQo+Pj4gDQo+Pj4gR2VyYXJkbywNCj4+PiANCj4+PiBPbiAyLzE0LzExIDEyOjUw IFBNLCAiZXh0IEdpYXJldHRhLCBHZXJhcmRvIiA8Z2VyYXJkb2dAcXVhbGNvbW0uY29tPg0KPj4+ IHdyb3RlOg0KPj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IEkgYXNrZWQgZmV3IHF1ZXN0aW9ucyBp biBhbiBlbWFpbCB3aGljaCBJIHRoaW5rIHdhcyBkaXJlY3RlZCB0byANClRlbGVtYWNvDQo+Pj4+ IGFuZCBvdGhlcnMgYnV0IG5ldmVyIGdvdCBhIHJlcGx5LiBUaGUgYmFzaWMgcG9pbnQgaXMgdGhh dCBub2JvZHkgaGFzDQo+Pj4+IGFuc3dlcmVkIGhvdyB0aGUgTE1BIGtub3dzIGlmIHRoZSBNTiBp cyBzdGlsbCBpbiBhIHJlYXNvbmFibGUgV0xBTg0KPj4+PiBjb3ZlcmFnZSwgaG93IGxvYWRlZCBX TEFOIGlzLCBldGMuIFRoZXJlIGlzIGEgaHVnZSBkaWZmZXJlbnQgYmV0d2Vlbg0KPj4+PiBjZWxs dWxhciBuZXR3b3JrcyBhbmQgV0xBTnM6IGluIGNlbGx1bGFyIG5ldHdvcmtzIHRoZSBoYW5kb3Zl cnMgYXJlDQo+Pj4+IGNvbnRyb2xsZWQgYnkgdGhlIG5ldHdvcmsgYmVjYXVzZSB0aGUgTU4gYWx3 YXlzIHByb3ZpZGVzIG1lYXN1cmVtZW50DQo+Pj4+IHJlcG9ydHMgYWJvdXQgd2hhdCB0aGUgTU4g c2VlcyB0byB0aGUgbmV0d29yay4gVGhpcyBpcyBub3QgaW4gcGxhY2UgDQpmb3INCj4+Pj4gaW50 ZXItdGVjaG5vbG9neSBoYW5kb3ZlcnMgYmV0d2VlbiBXTEFOIGFuZCAzRyBhbmQgdGhpcyBpcyB3 aHkgeW91DQo+Pj4+IGNhbm5vdA0KPj4+PiBzYWZlbHkgYXNzdW1lIHRoZSBMTUEgd2lsbCB0YWtl IHRoZSBjb3JyZWN0IGRlY2lzaW9uLg0KPj4+PiANCj4+Pj4gSSBkb24ndCB0aGluayB0aGlzIGFw cHJvYWNoIGIpIGJyaW5ncyBhbnkgdmFsdWUgYW5kIEkgYWN0dWFsbHkgdGhpbmsgDQppdA0KPj4+ PiBjcmVhdGVzIGEgbG90IG9mIHByb2JsZW1zLg0KPj4+IA0KPj4+IA0KPj4+IFJlZ2FyZGluZyB0 aGUgcXVlc3Rpb24gYWJvdXQgd2hldGhlciB0aGUgTE1BIGtub3dzIHRoZSBzdGF0dXMgb2YgdGhl IA0KTU5zDQo+Pj4gY29ubmVjdGl2aXR5IHRvIGEgTUFHIGFuZCB0aGUgd2lmaSBsaW5rIGNoYXJh Y3RlcmlzdGljcyB0aGF0IGl0IGlzIA0KdXNpbmcNCj4+PiB0byBhdHRhY2ggdG8gYSBNQUc6DQo+ Pj4gVGhlIExNQSBoYXMgbm8gYXdhcmVuZXNzIG9mIHRoZSBNTnMgY29ubmVjdGl2aXR5L2xpbmsg c3RhdHVzIHRvIGEgTUFHLg0KPj4+IEl0DQo+Pj4gb25seSBrbm93cyB0aGF0IHRoZSBNTiBoYXMg YXR0YWNoZWQgdmlhIGEgTUFHLiBBbmQgaWYgdGhlIHBvbGljeQ0KPj4+IGluZGljYXRlcw0KPj4+ IHRoYXQgdHJhZmZpYyBiZSByb3V0ZWQgdmlhIHRoYXQgTUFHL2ludGVyZmFjZSwgaXQgd2lsbCBk byBzby4NCj4+PiANCj4+PiBJdCBjb3VsZCByZXN1bHQgaW4gcGFja2V0cyBiZWluZyBkcm9wcGVk IGlmIHRoZSBNTiBoYXMgbW92ZWQgb3V0IG9mIA0KdGhhdA0KPj4+IHdpZmkgY292ZXJhZ2Ugb3Ig dGhlIGxpbmsgaXMgY29uZ2VzdGVkLiBJbiB0ZXJtcyBvZiB0aGUgc2NvcGUgb2YgdGhpcw0KPj4+ IHdvcmssIHRoZSBpbnRlbnQgaXMgb24gc3BlY2lmeWluZyBob3cgdGhlIHRyYWZmaWMgYXNzb2Np YXRlZCB3aXRoIGENCj4+PiBzZXNzaW9uIGlzIHN3aXRjaGVkIHRvIGFuIGFsdGVybmF0ZSBNQUcu IFRoZSBwb2ludHMgdGhhdCB5b3UgcmFpc2UgYXJlDQo+Pj4gb3V0c2lkZSB0aGUgc2NvcGUgb2Yg dGhpcyB3b3JrLg0KPj4gDQo+PiBJIGFwb2xvZ2l6ZSBpZiBJIHN0YXJ0IHRvIHNvdW5kIHNhcmNh c3RpYywgYnV0IHRoZSBvbmx5IHRoaW5nIHRoYXQNCj4+IHNlZW1zIGluIHNjb3BlIG9mIHRoaXMg d29yayBpcyBob3cgdG8gcmVhbGl6ZSBhIGZ1bmN0aW9uDQo+PiAoTE1BLWluaXRpYXRlZCAgZmxv dyBoYW5kb2ZmcykgdGhhdCBjYW5ub3QgYmUgcG9zc2libHkgdXNlZA0KPj4gbWVhbmluZ2Z1bGx5 IHdpdGhvdXQgYSBidW5jaCBvZiBvdGhlciBtZWNoYW5pc21zIChNTi1MTUEgcG9saWN5DQo+PiBj b29yZGluYXRpb24sIE1OLUxNQSByYWRpbyBxdWFsaXR5IHJlcG9ydGluZywgZXRjLiApIHRoYXQg ZG8gbm90IGV4aXN0DQo+PiBpbiBhbnkgZm9ybSBhbmQgYXJlIGFsc28gb3V0IG9mIHNjb3BlIG9m IHRoaXMgd29yay4uLg0KPj4gDQo+PiBBcyBJIHNhaWQsIGFic2VudCB0aGVzZSBtZWNoYW5pc21z LCBvciBhIHVzZWNhc2UgYW5kIHByb29mIG9mDQo+PiBmZWFzaWJpbGl0eSwgZGV2ZWxvcGluZyBh biBMTUEtaW5pdGlhdGVkIGZsb3cgaGFuZG9mIGZ1bmN0aW9uIG1ha2VzIG5vDQo+PiBzZW5zZSB0 byBtZS4NCj4+IA0KPj4gLS1qdWxpZW4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IG5ldGV4dCBtYWlsaW5nIGxpc3QNCj4gbmV0ZXh0QGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0DQo+ IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NClRoaXMNCj4gdHJhbnNtaXNzaW9uIChpbmNsdWRpbmcgYW55IGF0 dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgDQppbmZvcm1hdGlvbiwNCj4gcHJp dmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3RlY3RlZCBieSB0aGUgDQpz b2xpY2l0b3ItY2xpZW50IG9yDQo+IG90aGVyIGFwcGxpY2FibGUgcHJpdmlsZWdlcyksIG9yIGNv bnN0aXR1dGUgbm9uLXB1YmxpYyBpbmZvcm1hdGlvbi4gQW55IA0KdXNlIG9mDQo+IHRoaXMgaW5m b3JtYXRpb24gYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyAN CnByb2hpYml0ZWQuIElmDQo+IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGlu IGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgDQp0byB0aGUNCj4gc2VuZGVyIGFuZCBk ZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lzdGVtLiBVc2UsIGRpc3NlbWluYXRp b24sDQo+IGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9u IGJ5IHVuaW50ZW5kZWQgDQpyZWNpcGllbnRzIGlzDQo+IG5vdCBhdXRob3JpemVkIGFuZCBtYXkg YmUgdW5sYXdmdWwuDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpuZXRleHQgbWFpbGluZw0KPiBsaXN0DQpuZXRleHRAaWV0Zi5vcmcNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0DQoNCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0ZXh0IG1haWxpbmcgbGlzdA0K bmV0ZXh0QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dGV4dA0KDQoNCg0K --=_alternative 002B03C248257838_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0ic2Fucy1zZXJpZiI+SGksPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9InNhbnMtc2VyaWYiPklN SE8sIGluaXRpYXRpbmcgZmxvdw0KbW9iaWxpdHkgYnkgZWl0aGVyIHRlcm1pbmFsIHNpZGUgb3Ig bmV0d29yayBzaWRlIGl0c2VsZiBpcyBhIGtpbmQgb2YgaGVscGxlc3MNCmNob2ljZS4gUGVvcGxl IHN1cmVseSB3YW50IHN0YWJsZSBmbG93cyBvdGhlciB0aGFuICZxdW90O2ZsZXhpYmxlJnF1b3Q7 DQpmbG93cy4gU28gaW4gbW9zdCBjYXNlcywgd2UgdXNlIGZsb3cgbW9iaWxpdHkgb25seSB3aGVu IHdlIGhhdmUgdG8gZG8uPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZh Y2U9InNhbnMtc2VyaWYiPkluIGNhc2Ugb2YgaG9zdC1iYXNlZA0KZmxvdyBtb2JpbGl0eSwgdGVy bWluYWwgZGVjaWRlcyB0byBtb3ZlIHNwZWNpZmljIGZsb3dzIGR1ZSB0byBlLmcuIG91dA0Kb2Yg dGhlIHdpZmkgY292ZXJhZ2UgYnkgc2VuZGluZyBCVSB0byBub3RpZnkgdGhlIG5ldHdvcmsuIEhv d2V2ZXIsIHRoZQ0KbmV0d29yayB3aWxsIHJlamVjdCB0aGlzIHJlcXVlc3QgaWYgbmV0d29yayBk b2VzIG5vdCBzdXBwb3J0IHRyYW5zcG9ydGluZw0KdGhpcyBmbG93IHRocm91Z2ggb3RoZXIgYWNj ZXNzZXMuICZuYnNwO1RoZW4sIHRoZSBmbG93IHdpbGwgYmUga2lsbGVkLg0KSXQgaXMgbm90IGEg dGVycmlibGUgdGhpbmcgaWYgYSBmbG93IGNhbiBub3Qgc3Vydml2ZSB0aGUgc2FtZSBpbiBuZXR3 b3JrLWJhc2VkDQpzY2VuYXJpby4gSSBiZWxpZXZlIGl0IGRvZXMgbWFrZSBzZW5zZSB0byBzdHVk eSBvbiBMTUEtaW5pdGlhdGVkIGZsb3cgbW9iaWxpdHkNCmFsdGhvdWdoIHRoZSBmbG93IG1heSBi ZSBkZWFkIGR1ZSB0byBlLmcuIE1OIG91dCBvZiB0aGUgdGFyZ2VyIGFjY2Vzcy4NCkFueXdheSwg bm8gc29sdXRpb24gaXMgcGVyZmVjdC48L2ZvbnQ+DQo8YnI+PHR0Pjxmb250IHNpemU9MiBjb2xv cj0jMDAwMDgwPkkgZGlzYWdyZWUgdGhlIHRob3VnaHRzIGFib3V0IG5vIGJhc2lzDQpleGlzdGlu ZyBmb3IgdGhlIExNQSB0byB1bmlsYXRlcmFseSBkZWNpZGUgd2hlcmUgdG8gc2VuZCBmbG93cy4g TE1BIGlzDQp1c3VhbGx5IGNvbm5lY3RlZCB3aXRoIG5ldHdvcmsgbWFuYWdlbWVudCBzeXN0ZW0g c3VjaCBhcyB0cmFmZmljIG1vbml0b3JpbmcNCmRlcGxveWVkIGluIHRoZSBvcGVyYXRvcidzIGlu dGVybmFsIG5ldHdvcmsuIFdoZW4gc2VyaW91cyBjb25nZXN0aW9uIG9jY3Vycw0KaW4gc29tZSBh Y2Nlc3Mgc3lzdGVtLCB0aGUgTE1BIGlzIHJlcG9ydGVkICZuYnNwO3RoaXMgaW5mbyBieSBtb25p dG9yaW5nDQpzeXN0ZW0uIFRoZW4sIGl0IGlzIExNQSB0byBkZWNpZGUgd2hpY2ggZmxvd3Mgc2hv dWxkIGJlIG1vdmVkIGZyb20gdGhlDQpjb25nZXN0ZWQgc3lzdGVtLiBBZnRlciBhbGwgdGhlIExN QSBrbm93cyB0aGF0IHdoaWNoIE1OcyBjb25uZWN0aW5nIG11bHRpcGxlDQpNQUdzIHNpbXVsdGFu ZW91c2x5IGFuZCBjYW4gbWFrZSBmbG93IHBvbGljaWVzIGFjY29yZGluZyB0byBjdXJyZW50IHNp dHVhdGlvbi4NCklmIHRoZSBwYWNrZXQgYmVsb25naW5nIHRvIHRoZSBtb3ZlZCBmbG93IGRyb3Bw ZWQgYnkgdGhlIHRhcmdldCBNQUcsIHdoYXQNCndlIGNhbiBkbyBpcyBqdXN0IGxldCBpdCBnbyBj YXVzZSB0aGUgbmV0d29yayBoYXMgZG9uZSBpdHMgYmVzdCB0byBhdm9pZA0KYmFkIHVzZXIgZXhw ZXJpZW5jZS4gTW9yZXZlciwgYmVmb3JlIGRlY2lkaW5nIHRoZSBmbG93IHJvdXRpbmcgdG8gd2hp Y2gNCk1BRywgYSBoZWFsdGggc3RhdHVzIGNoZWNrICZuYnNwO2JldHdlZW4gdGVybWluYWwgYW5k IExNQSBjYW4gYmUgcGVyZm9ybWVkDQp3aGljaCBpcyBpbXBsZW1lbnRhdGlvbiBkZXBlbmRlbnQu IFBvbGljeSBCYXNpcyBmb3IgTE1BIG5lZWRzIHRvIGJlIGZ1cnRoZXINCnN0dWRpZWQgYW5kIHNo b3VsZCAmbmJzcDtub3QgYmUgc3BlY2lmaWVkIGluIHRoaXMgZHJhZnQuPC9mb250PjwvdHQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0ic2Fucy1zZXJpZiI+UmVn YXJkcyw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0ic2Fucy1z ZXJpZiI+Sm95PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPjxiPkhlc2hhbSBTb2xpbWFuICZsdDtoZXNoYW1AZWxldmF0ZW1vYmlsZS5jb20mZ3Q7PC9i Pg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZu YnNwO25ldGV4dC1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPjIwMTEtMDItMTUgyc/O5yAxMToxNzwvZm9udD4NCjx0ZCB3aWR0aD02NCU+ DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1y aWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0K PHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5TdGVmYW5vIEZhY2NpbiAmbHQ7c2Zh Y2NpbkByaW0uY29tJmd0OywNCiZsdDtCYXNhdmFyYWouUGF0aWxAbm9raWEuY29tJmd0OywgJmx0 O2p1bGllbi5pZXRmQGdtYWlsLmNvbSZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N CjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2Zv bnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPm5ldGV4dEBpZXRm Lm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtuZXRleHRdIE9uIHRoZSBmbG93IG1vYmlsaXR5 IGRpc2N1c3Npb248L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPjxicj4NCjxicj4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyBJIHVuZGVyc3Rh bmQgdGhlIGlzc3VlIGFib3V0IHRoZSBmYWN0IHRoYXQgYW4gTU4gbWF5IGhhdmUgbW92ZWQgb3V0 DQpvZjxicj4NCiZndDsgd2lmaSBjb3ZlcmFnZSBhZnRlciByZWdpc3RlcmluZyB0aHJ1IE1BR3ku PGJyPg0KJmd0OyBPciBmb3IgdGhhdCBtYXR0ZXIgdGhlIHdpZmkgbmV0d29yayB2aWEgd2hpY2gg dGhlIE1OIGlzIGF0dGFjaGVkICh0aHJ1PGJyPg0KJmd0OyBNQUd5KSBpcyBjb25nZXN0ZWQgb3Ig dGhlIGxpbmsgcXVhbGl0eSBpcyBwb29yLjxicj4NCiZndDsgQW5kIHRoaXMgY291bGQgaGFwcGVu Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBCdXQgb24gdGhlIGZsaXAgc2lkZSwgdGhlIE1OIG1heSBi ZSBhdHRhY2hlZCB0byBhIHdpZmkgbmV0d29yayBhbmQNCmlzIGFibGU8YnI+DQomZ3Q7IHRvIHNl bmQvcmVjdiBwYWNrZXRzIHRocnUgTUFHeSB3aXRoIG5vIGlzc3VlcywgSW4gd2hpY2ggY2FzZSBz d2l0Y2hpbmcNCnRoZTxicj4NCiZndDsgZmxvdyBhdCB0aGUgTE1BIHdvdWxkIHdvcmsganVzdCBm aW5lLjxicj4NCiZndDsgPGJyPg0KJmd0OyBEb2VzIGl0IG5vdCBtYWtlIHNlbnNlIHRvIGhhdmUg YSBzb2x1dGlvbiBmb3IgdGhpcyBjYXNlPzxicj4NCjxicj4NCj0mZ3Q7IE5vIGl0IGRvZXNuJ3Qg bWFrZSBzZW5zZS4gQmVjYXVzZSB0aG9zZSBjYXNlcyBhcmUgbm90IGRlcGxveW1lbnQ8YnI+DQpz Y2VuYXJpb3MsIHRoZXkncmUgcnVudGltZSBjaGFuZ2VzIHdpdGhpbiBhbnkgZGVwbG95bWVudC4g VGhpcyB3b3VsZCBiZQ0KYTxicj4NCnNvbHV0aW9uIHRoYXQgJnF1b3Q7bWF5JnF1b3Q7IHdvcmsu IEluIG90aGVyIHdvcmRzIGEgdXNlbGVzcyBzb2x1dGlvbi48YnI+DQo8YnI+DQpIZXNoYW08YnI+ DQo8YnI+DQo8YnI+DQpUaGUgZXJyb3IgY2FzZTxicj4NCiZndDsgd2hlbiB0aGUgcGFja2V0cyBz ZW50IHRvIHRoZSBNTiB2aWEgTUFHeSBpbnRvIG9ibGl2aW9uIGNhbm5vdCBiZSBpZ25vcmVkLjxi cj4NCiZndDsgQnV0IG5laXRoZXIgY2FuIHlvdSBzYXkgdGhhdCB0aGVyZSBpcyBubyB3YXkgdGhp cyB3b3VsZCB3b3JrIGF0IGFsbC48YnI+DQomZ3Q7IDxicj4NCiZndDsgLVJhajxicj4NCiZndDsg PGJyPg0KJmd0OyBPbiAyLzE0LzExIDU6MTcgUE0sICZxdW90O2V4dCBKdWxpZW4gTGFnYW5pZXIm cXVvdDsgJmx0O2p1bGllbi5pZXRmQGdtYWlsLmNvbSZndDsNCndyb3RlOjxicj4NCiZndDsgPGJy Pg0KJmd0OyZndDsgUmFqLDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IE9uIE1vbiwgRmVi IDE0LCAyMDExIGF0IDExOjA5IEFNLCAmbmJzcDsmbHQ7QmFzYXZhcmFqLlBhdGlsQG5va2lhLmNv bSZndDsNCndyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgR2VyYXJk byw8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IE9uIDIvMTQvMTEgMTI6NTAg UE0sICZxdW90O2V4dCBHaWFyZXR0YSwgR2VyYXJkbyZxdW90OyAmbHQ7Z2VyYXJkb2dAcXVhbGNv bW0uY29tJmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsgPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsgSSBhc2tlZCBmZXcgcXVlc3Rpb25zIGluIGFuIGVtYWlsIHdoaWNoIEkgdGhpbmsg d2FzIGRpcmVjdGVkDQp0byBUZWxlbWFjbzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgYW5kIG90aGVy cyBidXQgbmV2ZXIgZ290IGEgcmVwbHkuIFRoZSBiYXNpYyBwb2ludCBpcyB0aGF0DQpub2JvZHkg aGFzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBhbnN3ZXJlZCBob3cgdGhlIExNQSBrbm93cyBpZiB0 aGUgTU4gaXMgc3RpbGwgaW4gYSByZWFzb25hYmxlDQpXTEFOPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyBjb3ZlcmFnZSwgaG93IGxvYWRlZCBXTEFOIGlzLCBldGMuIFRoZXJlIGlzIGEgaHVnZSBkaWZm ZXJlbnQNCmJldHdlZW48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGNlbGx1bGFyIG5ldHdvcmtzIGFu ZCBXTEFOczogaW4gY2VsbHVsYXIgbmV0d29ya3MgdGhlDQpoYW5kb3ZlcnMgYXJlPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyBjb250cm9sbGVkIGJ5IHRoZSBuZXR3b3JrIGJlY2F1c2UgdGhlIE1OIGFs d2F5cyBwcm92aWRlcw0KbWVhc3VyZW1lbnQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHJlcG9ydHMg YWJvdXQgd2hhdCB0aGUgTU4gc2VlcyB0byB0aGUgbmV0d29yay4gVGhpcyBpcw0Kbm90IGluIHBs YWNlIGZvcjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgaW50ZXItdGVjaG5vbG9neSBoYW5kb3ZlcnMg YmV0d2VlbiBXTEFOIGFuZCAzRyBhbmQgdGhpcw0KaXMgd2h5IHlvdTxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsgY2Fubm90PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBzYWZlbHkgYXNzdW1lIHRoZSBMTUEg d2lsbCB0YWtlIHRoZSBjb3JyZWN0IGRlY2lzaW9uLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyBJIGRvbid0IHRoaW5rIHRoaXMgYXBwcm9hY2ggYikgYnJpbmdz IGFueSB2YWx1ZSBhbmQgSQ0KYWN0dWFsbHkgdGhpbmsgaXQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 IGNyZWF0ZXMgYSBsb3Qgb2YgcHJvYmxlbXMuPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsm Z3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgUmVnYXJkaW5nIHRoZSBxdWVzdGlvbiBhYm91dCB3 aGV0aGVyIHRoZSBMTUEga25vd3MgdGhlIHN0YXR1cw0Kb2YgdGhlIE1Oczxicj4NCiZndDsmZ3Q7 Jmd0OyBjb25uZWN0aXZpdHkgdG8gYSBNQUcgYW5kIHRoZSB3aWZpIGxpbmsgY2hhcmFjdGVyaXN0 aWNzIHRoYXQNCml0IGlzIHVzaW5nPGJyPg0KJmd0OyZndDsmZ3Q7IHRvIGF0dGFjaCB0byBhIE1B Rzo8YnI+DQomZ3Q7Jmd0OyZndDsgVGhlIExNQSBoYXMgbm8gYXdhcmVuZXNzIG9mIHRoZSBNTnMg Y29ubmVjdGl2aXR5L2xpbmsgc3RhdHVzDQp0byBhIE1BRy48YnI+DQomZ3Q7Jmd0OyZndDsgSXQ8 YnI+DQomZ3Q7Jmd0OyZndDsgb25seSBrbm93cyB0aGF0IHRoZSBNTiBoYXMgYXR0YWNoZWQgdmlh IGEgTUFHLiBBbmQgaWYgdGhlDQpwb2xpY3k8YnI+DQomZ3Q7Jmd0OyZndDsgaW5kaWNhdGVzPGJy Pg0KJmd0OyZndDsmZ3Q7IHRoYXQgdHJhZmZpYyBiZSByb3V0ZWQgdmlhIHRoYXQgTUFHL2ludGVy ZmFjZSwgaXQgd2lsbCBkbw0Kc28uPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0 OyBJdCBjb3VsZCByZXN1bHQgaW4gcGFja2V0cyBiZWluZyBkcm9wcGVkIGlmIHRoZSBNTiBoYXMg bW92ZWQNCm91dCBvZiB0aGF0PGJyPg0KJmd0OyZndDsmZ3Q7IHdpZmkgY292ZXJhZ2Ugb3IgdGhl IGxpbmsgaXMgY29uZ2VzdGVkLiBJbiB0ZXJtcyBvZiB0aGUgc2NvcGUNCm9mIHRoaXM8YnI+DQom Z3Q7Jmd0OyZndDsgd29yaywgdGhlIGludGVudCBpcyBvbiBzcGVjaWZ5aW5nIGhvdyB0aGUgdHJh ZmZpYyBhc3NvY2lhdGVkDQp3aXRoIGE8YnI+DQomZ3Q7Jmd0OyZndDsgc2Vzc2lvbiBpcyBzd2l0 Y2hlZCB0byBhbiBhbHRlcm5hdGUgTUFHLiBUaGUgcG9pbnRzIHRoYXQgeW91DQpyYWlzZSBhcmU8 YnI+DQomZ3Q7Jmd0OyZndDsgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyB3b3JrLjxicj4NCiZn dDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IEkgYXBvbG9naXplIGlmIEkgc3RhcnQgdG8gc291bmQgc2Fy Y2FzdGljLCBidXQgdGhlIG9ubHkgdGhpbmcNCnRoYXQ8YnI+DQomZ3Q7Jmd0OyBzZWVtcyBpbiBz Y29wZSBvZiB0aGlzIHdvcmsgaXMgaG93IHRvIHJlYWxpemUgYSBmdW5jdGlvbjxicj4NCiZndDsm Z3Q7IChMTUEtaW5pdGlhdGVkICZuYnNwO2Zsb3cgaGFuZG9mZnMpIHRoYXQgY2Fubm90IGJlIHBv c3NpYmx5IHVzZWQ8YnI+DQomZ3Q7Jmd0OyBtZWFuaW5nZnVsbHkgd2l0aG91dCBhIGJ1bmNoIG9m IG90aGVyIG1lY2hhbmlzbXMgKE1OLUxNQSBwb2xpY3k8YnI+DQomZ3Q7Jmd0OyBjb29yZGluYXRp b24sIE1OLUxNQSByYWRpbyBxdWFsaXR5IHJlcG9ydGluZywgZXRjLiApIHRoYXQgZG8gbm90DQpl eGlzdDxicj4NCiZndDsmZ3Q7IGluIGFueSBmb3JtIGFuZCBhcmUgYWxzbyBvdXQgb2Ygc2NvcGUg b2YgdGhpcyB3b3JrLi4uPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgQXMgSSBzYWlkLCBh YnNlbnQgdGhlc2UgbWVjaGFuaXNtcywgb3IgYSB1c2VjYXNlIGFuZCBwcm9vZiBvZjxicj4NCiZn dDsmZ3Q7IGZlYXNpYmlsaXR5LCBkZXZlbG9waW5nIGFuIExNQS1pbml0aWF0ZWQgZmxvdyBoYW5k b2YgZnVuY3Rpb24NCm1ha2VzIG5vPGJyPg0KJmd0OyZndDsgc2Vuc2UgdG8gbWUuPGJyPg0KJmd0 OyZndDsgPGJyPg0KJmd0OyZndDsgLS1qdWxpZW48YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IG5ldGV4 dCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IG5ldGV4dEBpZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRleHQ8YnI+DQomZ3Q7IDxicj4NCiZn dDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPGJyPg0KVGhpczxicj4NCiZndDsgdHJhbnNtaXNzaW9uIChpbmNsdWRp bmcgYW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRpYWwNCmluZm9ybWF0aW9u LDxicj4NCiZndDsgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3Rl Y3RlZCBieSB0aGUgc29saWNpdG9yLWNsaWVudA0Kb3I8YnI+DQomZ3Q7IG90aGVyIGFwcGxpY2Fi bGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1YmxpYyBpbmZvcm1hdGlvbi4NCkFu eSB1c2Ugb2Y8YnI+DQomZ3Q7IHRoaXMgaW5mb3JtYXRpb24gYnkgYW55b25lIG90aGVyIHRoYW4g dGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLg0KSWY8YnI+DQomZ3Q7IHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRl bHkgcmVwbHkNCnRvIHRoZTxicj4NCiZndDsgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1h dGlvbiBmcm9tIHlvdXIgc3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24sPGJyPg0KJmd0OyBkaXN0 cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIHRyYW5zbWlzc2lvbiBieSB1bmludGVu ZGVkIHJlY2lwaWVudHMNCmlzPGJyPg0KJmd0OyBub3QgYXV0aG9yaXplZCBhbmQgbWF5IGJlIHVu bGF3ZnVsLjxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpuZXRleHQgbWFpbGluZzxicj4NCiZndDsgbGlzdDxicj4NCm5ldGV4dEBp ZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0 PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpuZXRleHQgbWFpbGluZyBsaXN0PGJyPg0KbmV0ZXh0QGlldGYu b3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRleHQ8YnI+ DQo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 002B03C248257838_=-- From pierrick.seite@orange-ftgroup.com Tue Feb 15 00:32:42 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2305A3A6ABB; Tue, 15 Feb 2011 00:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.715 X-Spam-Level: X-Spam-Status: No, score=-1.715 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2W0OkVkmS4Xp; Tue, 15 Feb 2011 00:32:41 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id A84E03A6B6A; Tue, 15 Feb 2011 00:32:40 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2DFD56C8006; Tue, 15 Feb 2011 09:33:35 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 1F2F46C0003; Tue, 15 Feb 2011 09:33:35 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Feb 2011 09:33:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 15 Feb 2011 09:33:03 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C4620180DE92@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?UTF-8?B?W25ldGV4dF3nrZTlpI06IFJlOiBQb2xpY3kgYXNzdW1wdGlv?= =?UTF-8?B?bnMgaW4gZHJhZnQtYmVybmFyZG9zLW5ldGV4dC1wbWk=?= =?UTF-8?B?cHY2LWZsb3dtb2I=?= Thread-Index: AcvMdeGX7nnNC9t3RXK2G9+0OOytCAAdGVqg References: <843DA8228A1BA74CA31FB4E111A5C4620180DB4A@ftrdmel0.rd.francetelecom.fr> From: To: X-OriginalArrivalTime: 15 Feb 2011 08:33:04.0663 (UTC) FILETIME=[F6E24A70:01CBCCEA] Cc: netext-bounces@ietf.org, netext@ietf.org Subject: Re: [netext] =?utf-8?b?562U5aSNOiBSZTogUG9saWN5IGFzc3VtcHRpb25zIGlu?= =?utf-8?q?_draft-bernardos-netext-pmipv6-flowmob?= X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 08:32:42 -0000 DQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEp1bGllbiBMYWdhbmll ciBbbWFpbHRvOmp1bGllbi5pZXRmQGdtYWlsLmNvbV0NCj4gRW52b3nDqcKgOiBsdW5kaSAxNCBm w6l2cmllciAyMDExIDE5OjM1DQo+IMOAwqA6IFNFSVRFIFBpZXJyaWNrIFJELVJFU0EtUkVODQo+ IENjwqA6IHpob3UueGluZ3l1ZUB6dGUuY29tLmNuOyBuZXRleHRAaWV0Zi5vcmc7IG5ldGV4dC1i b3VuY2VzQGlldGYub3JnDQo+IE9iamV0wqA6IFJlOiBbbmV0ZXh0XeetlOWkjTogUmU6IFBvbGlj eSBhc3N1bXB0aW9ucyBpbiBkcmFmdC1iZXJuYXJkb3MtDQo+IG5ldGV4dC1wbWlwdjYtZmxvd21v Yg0KPiANCj4gSGkgUGllcnJpY2sgLQ0KPiANCj4gT24gTW9uLCBGZWIgMTQsIDIwMTEgYXQgMToy MyBBTSwgIDxwaWVycmljay5zZWl0ZUBvcmFuZ2UtZnRncm91cC5jb20+DQo+IHdyb3RlOg0KPiA+ DQo+ID4gSGksDQo+ID4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+PiBEZcKgOiBu ZXRleHQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5ldGV4dC1ib3VuY2VzQGlldGYub3JnXSBE ZSBsYQ0KPiBwYXJ0DQo+ID4+IGRlIEp1bGllbiBMYWdhbmllcg0KPiA+PiBFbnZvecOpwqA6IHZl bmRyZWRpIDExIGbDqXZyaWVyIDIwMTEgMTk6MTANCj4gPj4gw4DCoDogemhvdS54aW5neXVlQHp0 ZS5jb20uY24NCj4gPj4gQ2PCoDogbmV0ZXh0QGlldGYub3JnOyBuZXRleHQtYm91bmNlc0BpZXRm Lm9yZw0KPiA+PiBPYmpldMKgOiBSZTogW25ldGV4dF3nrZTlpI06IFJlOiBQb2xpY3kgYXNzdW1w dGlvbnMgaW4gZHJhZnQtYmVybmFyZG9zLQ0KPiA+PiBuZXRleHQtcG1pcHY2LWZsb3dtb2INCj4g Pj4NCj4gPj4gSGVsbG8gLQ0KPiA+Pg0KPiA+PiAyMDExLzIvMTAgwqA8emhvdS54aW5neXVlQHp0 ZS5jb20uY24+Og0KPiA+PiA+DQo+ID4+ID4gSGVsbG8sDQo+ID4+ID4NCj4gPj4gPiBuZXRleHQt Ym91bmNlc0BpZXRmLm9yZyDlhpnkuo4gMjAxMS0wMi0xMCDkuIrljYggMDY6Mjc6MDA6DQo+ID4+ ID4NCj4gPj4gPj4gSGVsbG8sDQo+ID4+ID4+DQo+ID4+ID4+ID4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPj4gPj4gPiBGcm9tOiBUcmFuIE1pbmggVHJ1bmcgW21haWx0bzp0cnVuZ3Rt MjkwOUBnbWFpbC5jb21dDQo+ID4+ID4+ID4gU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwOSwg MjAxMSAxMjozMSBBTQ0KPiA+PiA+PiA+IFRvOiBHaWFyZXR0YSwgR2VyYXJkbw0KPiA+PiA+PiA+ IENjOiBuZXRleHRAaWV0Zi5vcmcNCj4gPj4gPj4gPiBTdWJqZWN0OiBSZTogW25ldGV4dF0gUG9s aWN5IGFzc3VtcHRpb25zIGluIGRyYWZ0LWJlcm5hcmRvcy0NCj4gbmV0ZXh0LQ0KPiA+PiA+PiA+ IHBtaXB2Ni1mbG93bW9iDQo+ID4+ID4+ID4NCj4gPj4gPj4gPiBPbiBXZWQsIEZlYiA5LCAyMDEx IGF0IDM6MzYgUE0sIEdpYXJldHRhLCBHZXJhcmRvDQo+ID4+ID4+ID4gPGdlcmFyZG9nQHF1YWxj b21tLmNvbT4gd3JvdGU6DQo+ID4+ID4+ID4gPiBJIHdhbnQgdG8gZ28gYmFjayB0byB0aGUgcG9p bnQgcmFpc2VkIGJ5IFN0ZWZhbm8gd2hpY2ggd2FzDQo+IHNvbWVob3cNCj4gPj4gPj4gPiBsb3N0 IGluIHRoZSBsb25nIHRocmVhZC4NCj4gPj4gPj4gPiA+DQo+ID4+ID4+ID4gPiBJIG5lZWQgc29t ZSBjbGFyaWZpY2F0aW9ucyBvbiB3aGljaCBpcyB0aGUgYXNzdW1wdGlvbiBpbiB0ZXJtcw0KPiBv Zg0KPiA+PiA+PiA+IHBvbGljaWVzIGluIHRoZSBkcmFmdC4gSW4gcGFydGljdWxhcjoNCj4gPj4g Pj4gPiA+DQo+ID4+ID4+ID4gPiAtIElzIGl0IGNvcnJlY3QgdGhhdCB0aGVyZSBpcyBhbiBhc3N1 bXB0aW9uIHRoYXQgTU4gYW5kIExNQSBoYXZlDQo+ID4+IHRoZQ0KPiA+PiA+PiA+IHNhbWUgcG9s aWNpZXMgYW5kIGJlaGF2ZSBhY2NvcmRpbmdseT8NCj4gPj4gPj4gPiA+DQo+ID4+ID4+ID4NCj4g Pj4gPj4gPiBZZXMsIHRoZXkgc2hvdWxkIGhhdmUgdGhlIHNhbWUgcG9saWNpZXMuDQo+ID4+ID4+ ID4NCj4gPj4gPj4NCj4gPj4gPj4gVGhlbiwgdGhlIHNjZW5hcmlvIG9mIGNoYW5nZSBvZiBwb2xp Y3kgaW4gdGhlIExNQSBpcyBjb25mbGljdGluZw0KPiA+PiA+PiB3aXRoIHRoaXMgYXNzdW1wdGlv biB1bmxlc3MgcG9saWNpZXMgY2hhbmdlZCBhbHNvIG9uIE1OLg0KPiA+PiA+Pg0KPiA+PiA+IEFz IG1lbnRpb25lZCBieSBQaWVycmljaywgYSBwcmFnbWF0aWMgYW5kIGJhc2ljIHdheSBvbiBwb2xp Y3kgY2FuIGJlDQo+ID4+ID4gYXBwcGxpZWQgb24gTU4gaW4gZmlyc3Qgcm91bmQuIEZvciBjdXJy ZW50IGZsb3csIHRoZSBNTiBzaG91bGQgZm9sbG93DQo+ID4+IHRoZQ0KPiA+PiA+IExNQSdzIGNo YW5nZSBvZiB0cmFmZmljIHJvdXRpbmcuIEFuZCB0aGUgTU4gaW5pdGF0ZXMgYW55IGZsb3cNCj4g YWNjb3JkaW5nDQo+ID4+IHRvDQo+ID4+ID4gdGhlIGRlZmF1bHQgcG9saWN5IGNvbmZpZ3VyYXRp b24uIE5vIGR5bmFtaWMgcG9saWN5IG1haW50ZW5hbmNlIGlzDQo+ID4+IG5lZWRlZCBvbg0KPiA+ PiA+IE1OLg0KPiA+Pg0KPiA+PiBUaGlzIGlzIG5laXRoZXIgcHJhZ21hdGljIG5vciBwcmFjdGlj YWwuDQo+ID4+DQo+ID4+IEFuIExNQSBoYXMgbm8gYmFzaXMgdG8gdW5pbGF0ZXJhbGx5IGluc3Ry dWN0IGEgTU4gdG8gcm91dGUgdHJhZmZpYyBvbg0KPiA+PiBhIGRpZmZlcmVudCBpbnRlcmZhY2Us IGFzIHRoZSBNTiBpcyB0aGUgb25seSBuZXR3b3JrIG5vZGUgdGhhdCByZWFsbHkNCj4gPj4ga25v d3MgaG93IGdvb2Qgb3IgYmFkIHRoYXQgaW50ZXJmYWNlIGlzLiBJZiBteSBNTiBpcyBhdHRhY2hl ZCB0byBhIGJhZA0KPiA+PiBXaUZpIChzYXkgb3ZlcmxvYWRlZCBJRVRGIG1lZXRpbmcgaG90ZWwg V2lGaSkgYW5kIGEgcmVhc29uYWJsZSAzRw0KPiA+PiBuZXR3b3JrLCBJIGRvbid0IHdhbnQgdGhl IExNQSB0byBmb3JjZSBtZSB0byB1c2UgdGhlIG92ZXJsb2FkZWQgV2lGaS4NCj4gPj4NCj4gPj4g V2hhdCdzIHByYWdtYXRpYyBhbmQgcHJhY3RpY2FsIGlzIHRoYXQgdGhlIE1OIGlzIHByb3Zpc2lv bmVkIHdpdGgNCj4gPj4gcG9saWNpZXMgKGUuZy4sIEFORFNGIGluIDNHUFApIHRoYXQgaW5kaWNh dGVzIGUuZy4gdGhhdCBXaUZJIHNob3VsZCBiZQ0KPiA+PiBwcmVmZXJyZWQgb3ZlciAzRywgYW5k IGJhc2VkIG9uIHRoaXMgcG9saWN5IGFuZCB0aGUgb3BlcmF0aW5nDQo+ID4+IGVudmlyb25tZW50 LCBpZiBXaUZpIGlzIGNvbnNpZGVyZWQgYXMgd29ya2luZyBieSB0aGUgTU4gKG5vdA0KPiA+PiBv dmVybG9hZGVkIHRvIGEgcG9pbnQgd2hlcmUgb25lIGNhbiBiYXJlbHkgcnVuIFRDUCksIHRoZW4g dGhlIE1ODQo+ID4+IGRlY2lkZXMgdG8gdXNlIFdpRmkgb3ZlciAzRy4gQmFzZWQgb24gdGhpcywg dGhlIExNQSBzaG91bGQgbWlycm9yIHRoZQ0KPiA+PiBNTidzIGZsb3cgcm91dGluZyBkZWNpc2lv bi4NCj4gPj4NCj4gPg0KPiA+IEluIHRoYXQgY2FzZSwgdGhlcmUgaXMgZmV3IGFkZGVkIHZhbHVl IHRvIFBNSVA7IHdpdGggc3VjaCBhIHRlcm1pbmFsDQo+IGNlbnRyaWMgZGVjaXNpb24sIE1JUCBz aG91bGQgYmUgcHJlZmVycmVkLg0KPiANCj4gSU1ITywgd2hpbGUgZGVzaWduaW5nIGEgUE1JUC1i YXNlZCBzeXN0ZW0sIGhhdmluZyBhIHdvcmtpbmcgc3lzdGVtDQo+IHNob3VsZCBwcmltZSBvdmVy IFBNSVAgaGF2aW5nIGFkZGVkIHZhbHVlIHJlbGF0aXZlIHRvIE1JUC4NCj4gDQo+IEluIG90aGVy IHdvcmRzLCBjb3JyZWN0bmVzcyB0cnVtcHMgZmVhdHVyZXMuDQo+IA0KPiA+IElmIExNQSBjb250 cm9sbGVkIGRlY2lzaW9uIGhhcyBsaW1pdGF0aW9uLCBhIHRlcm1pbmFsIGNlbnRyaWMgZGVjaXNp b24NCj4gbW9kZWwgaGFzIGFsc28gZHJhd2JhY2tzLiBBY3R1YWxseSwgYSBnb29kIHRyYWRlLW9m ZiBpcyBhIG1vZGVsIHdoZXJlIHRoZQ0KPiBuZXR3b3JrIGNhbiBhc3Npc3QgdGhlIE1OIGluIGl0 cyBkZWNpc2lvbiAodGhlIE1OIG1ha2VzIHRoZSBmaW5hbCBkZWNpc2lvbiwNCj4gYnV0IGdldHMg aW5mbyBmcm9tIHRoZSBuZXR3b3JrIHRvIG1ha2UgdGhhdCBkZWNpc2lvbiksIHNvIGF2b2lkaW5n IHRoZSBNTg0KPiB0byBhdHRhY2ggYW4gYWNjZXNzIHdpdGggYmFkIGNvbmRpdGlvbi4gQnV0IHN1 Y2ggYSBtb2RlbCBicmluZyBjb3VwbGUgb2YNCj4gaXNzdWVzIGluIFBNSVAgY29udGV4dDsgdGhl c2UgaXNzdWVzIGhhcyBiZWVuIHJhaXNlZCB1cCBpbiB0aGUgTUwNCj4gTU4vbmV0d29yayBpbnRl cmFjdGlvbiwgcG9saWN5IHN5bmNocm9uaXphdGlvbi4uLiBGb3Igc3VyZSB3ZSBzaG91bGQNCj4g YWRkcmVzcyB0aGVzZSBpc3N1ZXMsIGJ1dCBpbiB0aGUgbWVhbnRpbWUgYW5kIGluIHRoZSBzY29w ZSBvZiBjdXJyZW50IG5leHQNCj4gZHJhdGZzLCBhIGRlY2lzaW9uIG1vZGVsIHdoZXJlIHRoZSBM TUEgZW5mb3JjZXMgaXRzIGRlY2lzaW9uIHRvIHRoZSBNTiBjYW4NCj4gYmUgY29uc2lkZXJlZCwg a25vd2luZyB0aGF0IExNQSBkZWNpc2lvbiBlbmZvcmNlbWVudCBjYW5ub3QgYmUgdGhlIG9ubHkN Cj4gYW5zd2VyLg0KPiANCj4gV2hhdCB3b3VsZCBiZSB0aGUgYmFzaXMgZm9yIGFuIExNQSB0byBl bmZvcmNlIHRoYXQgZmxvd3MgYXJlIHJvdXRlZCBvbg0KPiBhIGdpdmVuIGludGVyZmFjZSBpZiB0 aGUgTE1BIGhhcyBubyBhdmFpbGFiaWxpdHkgb24gdGhlIE1OJ3MNCj4gaW50ZXJmYWNlcyBhdmFp bGFiaWxpdHk/DQo+IA0KPiBBYnNlbnQgdGhhdCwgaXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgTE1B IHdpbGwgbmV2ZXIgYmUgaW4gYSBwb3NpdGlvbg0KPiB0byBlbmZvcmNlIGFueXRoaW5nLi4uIEkg YW0gbWlzc2luZyBzb21ldGhpbmc/DQo+IA0KDQpFeGFjdGx5LCBQTUlQLCBvciBNSVAsIG9yIHdo YXRldmVyIHRoZSBoYW5kb3ZlciBleGVjdXRpb24gaXMsIG11c3QgaW50ZXJhY3Qgd2l0aCBkZWNp c2lvbiBmcmFtZXdvcmsuIE1vYmlsaXR5IG1hbmFnZW1lbnQgaXMgbWFkZSBvZiBkaWZmZXJlbnQg ZnVuY3Rpb25zLCBQTUlQIGRlYWxzIG9ubHkgd2l0aCBleGVjdXRpb24uDQogDQo+IC0tanVsaWVu DQo= From julien.ietf@gmail.com Tue Feb 15 11:00:56 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F9CC3A6D4E for ; Tue, 15 Feb 2011 11:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=-0.617, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ka25prwugA0H for ; Tue, 15 Feb 2011 11:00:55 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 3D36B3A6D4B for ; Tue, 15 Feb 2011 11:00:55 -0800 (PST) Received: by fxm9 with SMTP id 9so607846fxm.31 for ; Tue, 15 Feb 2011 11:01:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8rOq58ISmtsHtCdmcN1C3G6nCW0zXumtgmExucpbPEI=; b=lkQQxG8cF+l7Zaaal4284G2Pput8OIeYqQWtN0zQxioVYsmlPWajkcEjlmVICQ9s7W NgeIoa9LVM03+TwPm5Bo4V+BYpBQ2kz7sPhzveyzxyOIZGZXRuLP5v5TAH4HF/0FQJld R0D3bEVrJBXNGa5aGAQRrqXPf+1FWRQpyZdZg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RiBnkuQTpNnLuS8CV7J0HgaFILoy56LUHGv7Uk796dZg7D/JTgGAXnKENVpH6VOLr4 36PApRtfo9YO4s+VGiZxXgDnNPdAFK7+4Dp4z8T0N9iI26lzwUFyBJ4HsTYVEgakvkWL YaB9EbuxaFw24UipR8cOxpKGHVyb6xfsCAGTA= MIME-Version: 1.0 Received: by 10.223.69.141 with SMTP id z13mr1474132fai.9.1297796461724; Tue, 15 Feb 2011 11:01:01 -0800 (PST) Received: by 10.223.74.142 with HTTP; Tue, 15 Feb 2011 11:01:01 -0800 (PST) In-Reply-To: References: Date: Tue, 15 Feb 2011 11:01:01 -0800 Message-ID: From: Julien Laganier To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org Subject: Re: [netext] On the flow mobility discussion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 19:00:56 -0000 Raj, On Mon, Feb 14, 2011 at 4:10 PM, wrote: > > Julien, > > I understand the issue about the fact that an MN may have moved out of > wifi coverage after registering thru MAGy. > Or for that matter the wifi network via which the MN is attached (thru > MAGy) is congested or the link quality is poor. > And this could happen. > > But on the flip side, the MN may be attached to a wifi network and is able > to send/recv packets thru MAGy with no issues, In which case switching the > flow at the LMA would work just fine. > > Does it not make sense to have a solution for this case? The error case > when the packets sent to the MN via MAGy into oblivion cannot be ignored. > But neither can you say that there is no way this would work at all. The IETF designs protocol that have to be robust in the Internet, which is in line with your statement that the error case cannot be ignored. Thus unless someone comes up with appropriate handling to recover from the error case, we do not have a robust protocol / the protocol doesn't work (robustly) in the Internet. --julien From julien.ietf@gmail.com Tue Feb 15 11:05:46 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1BC13A6CA2 for ; Tue, 15 Feb 2011 11:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=-0.607, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTiP6VAnUUg1 for ; Tue, 15 Feb 2011 11:05:45 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id B5E7D3A6AB3 for ; Tue, 15 Feb 2011 11:05:44 -0800 (PST) Received: by fxm9 with SMTP id 9so613808fxm.31 for ; Tue, 15 Feb 2011 11:06:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4Yh8bjaPr1OgMCcSVYck06HiizjMma82c/clGKCmnnk=; b=GL5G8bd25P88TfFMnJnRodnsFYtSaD1XWyVxP+0n5K/hW/jF5N4aQToMkZgdBTRlbL jUJO2QluX/qSXvUDfaVdQKqwZZ5ZgcduRxJ/Hvm9urFvBkKoCPwagGTXVrMLdwUzkT1M EJGM3YMlE7z0XlUz/uP1BWRPZE0oPFYvzevT0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=J/KS0T3cZ+RfG2eZo1D4K7kEwmU4N96qRzITrFO/yZJA2HjbQ1Xu02Rw8RWz2pIG30 iLRMNkZQLdKVARlZfI4qRkmSgyYK8R34zN2yYDuCzfO8sjL3eOZGeauiJBCNCMtVcy9a nWGPSX3JfmVV2me8+VjtG3XVAzfppxymFNSB8= MIME-Version: 1.0 Received: by 10.223.103.8 with SMTP id i8mr679758fao.47.1297796769969; Tue, 15 Feb 2011 11:06:09 -0800 (PST) Received: by 10.223.74.142 with HTTP; Tue, 15 Feb 2011 11:06:09 -0800 (PST) In-Reply-To: References: <680854867F7FD04BB9B06EB8ACA8D5AC0601C1C9@XCH02DFW.rim.net> Date: Tue, 15 Feb 2011 11:06:09 -0800 Message-ID: From: Julien Laganier To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] On the flow mobility discussion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 19:05:46 -0000 Hi Raj, I do not see how the specific case of EV-DO/WiMAX flow mobility changes anything to the fact that unless the LMA has knowledge on both these radio links quality and a way to compare them (which it has not), the LMA has no basis to decide to move flows based solely on the terminal being attached to both these technologies. I have certainly be attached to cellular packet radio network that gave me abysmal data rates. I am glad there were no LMA to force me to use those. --julien On Mon, Feb 14, 2011 at 4:13 PM, wrote: > > Hi Stefano, > > I think deployment scenarios could vary. Lets not consider that this > solution is applicable only in the context of 3GPP networks and > architectures. > As an example (I am not saying that this is something other SDOs care > about. Its just an example): > > Lets take the case of an MN with an EV-DO and WiMAX interface that is > attached to an LMA via MAGx and MAGy. > Could you not make a case where the flow could be switched between either > of these interfaces at the LMA? > What would be the issues in such a deployment? > Lets presume that the policies regarding which flows are routed via EV-DO > or WiMAX are configured at the LMA itself. > > Cheers, > -Raj > > On 2/14/11 5:25 PM, "ext Stefano Faccin" wrote: > >>Julien, >>As one can imagine considering my previous comments I fully support your >>point below. As I indicated previously, there is in addition the fact >>that what is being developed will not be able to support current >>development scenarios, which restricts the applicability of the solution. >>Cheers, >> >>Stefano Faccin >> >>Standards Manager >>Research In Motion Corporation >>5000 Riverside Drive >>Building 6, Brazos East, Ste. 100 >>Irving, Texas 75039 USA >>Office: (972) 910 3451 >>Internal: 820.63451 >>: (510) 230 8422 >>www.rim.com; www.blackberry.com >> >> >> >>=EF=81=90 Consider the environment before printing. >> >> >>-----Original Message----- >>From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf >>Of Julien Laganier >>Sent: Monday, February 14, 2011 3:18 PM >>To: Basavaraj.Patil@nokia.com >>Cc: netext@ietf.org >>Subject: Re: [netext] On the flow mobility discussion >> >>Raj, >> >>On Mon, Feb 14, 2011 at 11:09 AM, =C2=A0 wrote= : >>> >>> Gerardo, >>> >>> On 2/14/11 12:50 PM, "ext Giaretta, Gerardo" >>>wrote: >>> >>>> >>>> >>>>I asked few questions in an email which I think was directed to Telemac= o >>>>and others but never got a reply. The basic point is that nobody has >>>>answered how the LMA knows if the MN is still in a reasonable WLAN >>>>coverage, how loaded WLAN is, etc. There is a huge different between >>>>cellular networks and WLANs: in cellular networks the handovers are >>>>controlled by the network because the MN always provides measurement >>>>reports about what the MN sees to the network. This is not in place for >>>>inter-technology handovers between WLAN and 3G and this is why you >>>>cannot >>>>safely assume the LMA will take the correct decision. >>>> >>>>I don't think this approach b) brings any value and I actually think it >>>>creates a lot of problems. >>> >>> >>> Regarding the question about whether the LMA knows the status of the MN= s >>> connectivity to a MAG and the wifi link characteristics that it is usin= g >>> to attach to a MAG: >>> The LMA has no awareness of the MNs connectivity/link status to a MAG. >>>It >>> only knows that the MN has attached via a MAG. And if the policy >>>indicates >>> that traffic be routed via that MAG/interface, it will do so. >>> >>> It could result in packets being dropped if the MN has moved out of tha= t >>> wifi coverage or the link is congested. In terms of the scope of this >>> work, the intent is on specifying how the traffic associated with a >>> session is switched to an alternate MAG. The points that you raise are >>> outside the scope of this work. >> >>I apologize if I start to sound sarcastic, but the only thing that >>seems in scope of this work is how to realize a function >>(LMA-initiated =C2=A0flow handoffs) that cannot be possibly used >>meaningfully without a bunch of other mechanisms (MN-LMA policy >>coordination, MN-LMA radio quality reporting, etc. ) that do not exist >>in any form and are also out of scope of this work... >> >>As I said, absent these mechanisms, or a usecase and proof of >>feasibility, developing an LMA-initiated flow handof function makes no >>sense to me. >> >>--julien >>_______________________________________________ >>netext mailing list >>netext@ietf.org >>https://www.ietf.org/mailman/listinfo/netext >> >>--------------------------------------------------------------------- >>This transmission (including any attachments) may contain confidential >>information, privileged material (including material protected by the >>solicitor-client or other applicable privileges), or constitute >>non-public information. Any use of this information by anyone other than >>the intended recipient is prohibited. If you have received this >>transmission in error, please immediately reply to the sender and delete >>this information from your system. Use, dissemination, distribution, or >>reproduction of this transmission by unintended recipients is not >>authorized and may be unlawful. > > From julien.ietf@gmail.com Tue Feb 15 11:29:13 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 506F13A6D37 for ; Tue, 15 Feb 2011 11:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[AWL=-0.897, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlwG4rxKqMqr for ; Tue, 15 Feb 2011 11:29:11 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 2D20E3A6A6C for ; Tue, 15 Feb 2011 11:29:10 -0800 (PST) Received: by fxm9 with SMTP id 9so636590fxm.31 for ; Tue, 15 Feb 2011 11:29:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GWjNzdFgj7qdNfTwCU+H/IeommWPQqZz3OjRxScJq3U=; b=jG1DiQkf7ynMS60bgwPJA7/tftwysacg0hohXmQoaB8Ef9xoZR43XC1IRTczPurP61 U0GlRLFEAiHvC9sp54dMFyCJNx6XnzjAOnqY/gh7ehaZi8aF6+jq83My+ICRrbNleLpC ZOwxD9EEf9vMcLXv0ANNqe/1LNPLyM9NAAB58= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=e443R9TLjJC4Jp2TXNxsar8HaORpJ1luWI2mzxdo4Kt7P4//VE7wgFaCl8QocCfq79 TrCuIU1XRZKj5Gs3hvuBMpFHkL8UCqvB5qYFcpXBI8cnqIZBKr8+GGxhedhc38TPlLmR fj28e98lG7kkiSOIAY37eh9EOhpytP9C2fwO8= MIME-Version: 1.0 Received: by 10.223.71.200 with SMTP id i8mr5604113faj.142.1297798175755; Tue, 15 Feb 2011 11:29:35 -0800 (PST) Received: by 10.223.74.142 with HTTP; Tue, 15 Feb 2011 11:29:35 -0800 (PST) In-Reply-To: <1297730463.3945.22.camel@acorde.it.uc3m.es> References: <1297677607.4514.71.camel@acorde.it.uc3m.es> <1297730463.3945.22.camel@acorde.it.uc3m.es> Date: Tue, 15 Feb 2011 11:29:35 -0800 Message-ID: From: Julien Laganier To: cjbc@it.uc3m.es Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] On the flow mobility discussion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 19:29:13 -0000 Hi Carlos, Please see follow-up below: 2011/2/14 Carlos Jes=FAs Bernardos Cano : > Hi Julien > > Thanks for your reply. Some comments below. > > On Mon, 2011-02-14 at 11:02 -0800, Julien Laganier wrote: >> Hi Carlos, >> >> I am trying to answer some of your questions inline below, but I am >> afraid this comes at the cost of having to re-ask the same questions >> again and again: >> >> 2011/2/14 Carlos Jes=FAs Bernardos Cano : >> > Hi all, >> > >> > First of all, thanks for the active and lively discussion. I think tha= t >> > we are slowly making some progress. For the sake of making progress, l= et >> > me try to summarize the discussion (well, actually, my view of it), po= se >> > some questions and propose some next steps: >> > >> > - Trigger for flow mobility. We have heard at least two main opinions = on >> > this: a) triggers can only come from the MAG (based on L2 signaling fr= om >> > the MN), and b) triggers can come from the MAG or from the LMA. Strong >> > points of a): strictly follows current RFC 5213 and allows to support >> > scenarios in which the MN can signal to the MAG events relevant to flo= w >> > mobility via L2-specific signaling. Here it is my first question: to m= e >> > L2 triggers and L2 signaling are not the same thing, RFC5213 requires = L2 >> > triggers to be in place (AFAIK, it can also work based on IPv6 ND, wit= h >> > some assumptions on how to get the MNID and set the HI) for example to >> > detect when a MN has attached. >> >> Well, the L2 trigger has a cause, which is most certainly that some L2 >> signaling occured, or, did not occured (e.g. L2 timer goes off.) As >> such, there is little sense in making distinction between the two in >> the context of that discussion. > > To me an L2 trigger at the MAG that says "an interface has attached" > based on L2 messages that are there regardless of whether PMIPv6 is > being used or not is actually very different from L2 signalling from the > MN conveying the message "I want this interface added to this PMIPv6 > mobility session". I must be missign something, cause I see huge > differences there. If you actually look at the system level specification that uses PMIPv6 to do inter-technology handovers, this is exactly what they have, a L2 signaling from the MN that conveys the message "I want this interface to replace the old one in this PMIPv6 mobility session", which triggers the MAG to set the Handoff Indicator to "Handoff Between Interfaces" in the PBU it sends. If the L2 signaling is a simple attach and doesn't embed the MN intent to handoff between interfaces, i.e., the MN is legacy IP host, then the MAG does set the handoff indicator to this value and this result to a default of creating a new PMIPv6 session for that interface. Thus in terms of flow mobility, what we need to do is rely on an extended L2 signaling from the MN that conveys the information that the MN does support flow mobility across interfaces, as you put it: "I want this interface added to this PMIPv6 mobility session". This is pretty much inline with what's been already. Yes, it does mean that in order to do inter-tech handoffs and/or flow mobility, you do need extensions to the L2 signaling. Nothing new here... >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0However, L2 signaling between the MN and >> > MAG are a bit different (it implies the existence of a communication >> > channel for control purposes between MAG and MN that is able to convey >> > information relevant/relative to a L3 protocol). =A0 Do we want to res= trict >> > the solution to the scenarios in which this L2 signaling channel is >> > present? >> >> See my point above. When the L2 attaches (through L2 signaling, I >> don't know of any wireless network attachment that happens by magic), >> the MAG is triggered to attach this L2 interface to a PMIPv6 session. >> So I don't know what restrictions we would be making by requiring L2 >> signaling / triggers. This is already there in RFC5213. > > True, that L2 signal triggers to add this interface to a new PMIPv6 > session (or to a existing one for the case of handover). Here you are > proposing a new hint based on L2 indications for flow mobility purposes, > right? I am proposing that we rely on what has to be done anyway for this to work (and has been done already for inter-tech handoffs), i.e., extensions of the L2 signalings to convey the MN intent (inter-tech handoff, or simultaneous attach for flow mobility.) >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0To cite one example, on= e of the approaches that has been >> > proposed in the ML requires the MN to signal via L2 (over an attachmen= t >> > through iface X) about events of iface Y. >> >> The approach I've been proposing requires MN to signal via L2 iface X >> that iface X be attached to a session. Nothing more, nothing less, all >> of which is already required per 5213. In effect, the only added > > Well, you are requiring that an interface that is already attached has > to generate L2 signaling (that otherwise would not be generated) to > support the flow mobility scenario. I see that as posing new > requirements to a scenario that not require that. See my earlier points - this already has to be generated for inter-tech handoffs. It is required already. You cannot build a working system without these L2 signals from a MN with unmodified IP layer. >> requirement placed on L2 signaling compared to 5213 is that, in >> addition the existing inter-interface handoff indicator (attach iface >> X to session in lieu of iface Y), we add a new simutaneous attach >> handoff indicator (that is, not really a handoff, attach iface X to >> session along any existing ifaces Y, Z etc. that were already >> attached.) We'd also need the ability to selectively detach an >> interface and keep the other ifaces in the session attached. That >> could be done through use of the same HI I just introduced, but in a >> deregistration PBU. > > Sure if we can put all that semantics on the L2 signaling, MAG triggered > flow mobility can be supported (as well as with the "flow bindings" > based approach that we describe in our draft) . LMA triggered remains to > be the issue. As I'm explaining in couple of other notes, LMA triggered makes no sense without mechanisms in place for the LMA to know the quality of the various radio links the MN has. These mechanisms do not exist and it is dubious that they will ever (because mobile networks are not architect'ed in such a way.) >> > Regarding b) Julien (and other folks) have asked about scenarios that >> > require that. I think 3G offloading is one of the scenarios that >> > requires that to be supported. If an operator has an MN that is attach= ed >> > to WLAN and 3G simultaneously wants (because of network load condition= s) >> > to offload some flows from 3G to WLAN on demand, I think this should b= e >> > supported, and LMA initiated flow mobility is the way to do it. >> >> As I've explained in other notes, there is no basis for the LMA to >> unilateraly decide where to send flows. This simply doesn't work in a >> variety of cases where a wireless L2 might be attached but provide no >> meaningful connectivity. > > Even in your approach, the LMA would be the one deciding where to send > flows, right? a mobility session would have different interfaces > attached, and the LMA would always be the one deciding through which MAG > (i.e. through which MN interface) the traffic will be delivered. I don't think the LMA is in a position to decide where to send flow, hence my statement that LMA-triggered isn't useful. I've given arguments that substantiate this claims, none of which has been rebutted so far. >> > folks have said that the MN is the only one that knows the quality of >> > the signal it receives and this is mostly true (note that there are >> > solutions than allows the owner of the WLAN to know of the quality and >> > status of the network), but it is also true that in current celular >> > networks handovers are controlled by the network (based on signal >> > quality reports from the MN). To me PMIPv6 follows the same model: >> > network controlled __IP__ mobility. >> >> You cannot generalize what a cellular network does with a homogeneous >> collections of radio access technologies that are all developed in the >> same system, and include signaling for the terminal equipment to >> report to a control network node what is the signal quality, to an IP >> layer mobility management in which the radio techonologies were not >> developed to fit together, and you do not have terminal to network >> signaling =A0for radio signal quality. > > To me generalizing that is as generalizing the existence of L2 signaling > that does all what is missing to support flow mobility. Except that you have no other choice than to suppose that the L2 signaling for adding/removing interfaces to session is in place. Otherwise an unmodified IP layer on the MN will not work. The signaling has to occur somewhere, if not at L3, then it has to be L2. (I take if for granted that nobody on this list wants to have that signaling at L4-7 ;-) >> Further, even if you could (but surely you can't), let me point out >> that in the network controlled cellular systems that are deployed >> and/or specified, the entity that takes the decision is an edge entity >> (e.g. SGSN, MME) which is closer to MAG rather than a hierarchical >> entity (e.g., GGSN, PGW) similar to LMA. >> >> Thus your statement that the LMA being in control would make PMIPv6 >> following the same model than cellular network seems to be factually >> incorrect. >> >> > - On the RFC5213 model and extensions to it. We can debate (as we are >> > doing) on the pros and cons of different technical approaches, that's >> > what we can do. However, I disagree with the idea that adding new >> > messages between LMA and MAG (if they are necessary) is fundamentally >> > changing the protocol and that we need to change the charter, ask the >> > ADs, etc. Current charter says on this regard: >> > >> > "The working group will determine what protocol extensions are >> > required between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) >> > to support the ability for an interface (at the IP layer) to >> > transmit packets over different media, the ability to distribute >> > specific traffic flows on different media components of that >> > interface, and making this work with the handover hints in the base >> > protocol. The relevant protocol extensions will be developed as >> > necessary." >> >> The point I have relentlessly making is that, in order to provide flow >> mobility, you do NOT need to change the basics of RFC 5213 session >> management, and thus, from out charter item it follows that we have >> determined that this needs not to be changed, and thus you need not to >> extend it. > > My point is that we don't change the basics of RFC 5213 session > management. Actually we don't introduce any change, but we just put the > flow bindings support on top to be able to route flows. You change it with the ability for LMA to add/remove interfaces and prefixes to sessions, which isn't in 5213. 5213 is entirely MAG driven, except for purposes of revocation but that is an entirely different matter. >> That, is unless somebody comes up with the killer usecase, which would >> have to involve more than: "I want to allocate a different prefix" >> because this has nothing to do with flow mobility. > > Sorry, but I see both approaches equivalent. They are not. The approach you're defending requires changes to the 5213 model to support a useless LMA-tirggered flow mobility usecase. My approach retains the original MAG-driven by L2 triggers approach documented in 5213, and specified in various systems (e.g. 3GPP), and supports the practical usecases. >> > I think all technical approaches discussed so far are fine with the >> > above text. Even one could read that text as preventing from adding ne= w >> > handover hints (which has been proposed as one of the solutions), thou= gh >> > that's not my reading. >> >> Truly no. >> >> Instead of doing charter exegesis, let's have those who favor the >> alternative model come up with a valid and motivated usecase.... > > This only applies to the need of the LMA triggered scenario, not on the > technical approach itself. Both yours and the one included in our draft > provides the same functionality. So once again: 1) LMA triggered scenario has no real world applicability 2) my approach supports real world usecases. The one is the draft is only required to support the imaginary LMA usecase. >> Please.... >> >> > - On the technical approach itself. If we forget for a second about th= e >> > LMA-triggered event, and we just think of MAG triggered ones, there ha= ve >> > been two fundamental approaches proposed so far. I think Tran summariz= ed >> > them very well in a previous e-mail. Let me try it again for the sake = of >> > this discussion: a) extensions to RFC5213 to support dynamically addin= g >> > and removing interfaces to mobility sessions, and b) extensions to >> > RFC5213 (based on standardized solutions developed in the MEXT WG) to >> > allow dynamic prefix management (and use that as a way to enable flow >> > mobility). Option a) does requires to modify conceptual data structure= s >> > defined in RFC5213 as well as state machines (to support the new >> > behavior). Option b) does not require modifications to the mobility >> > session related data structures, but on the other hand adds new ones >> > (related to flow bindings) and also modifies state machines. Option b) >> > leverages on existing MEXT work. >> >> Option b) is dynamic prefix management and is not necessary per se to >> do flow mobility so I am starting to really wonder why we are still >> discussing it in the first place. > > Why do you call it prefix management? I call it flow bindings over RFC > 5213 mobility sessions. You can call it what you want. The fact is that, if we can agree that there's no need to support LMA triggered flow movements, the only incremental feature option b) has compared to option a) is that you can add and remove prefixes to sessions, which seems to be exactly dynamic prefix management... But I don't care much about terminology. I care about meaningful functions that supports real world usecases. Protocols are complex enough without packing features that are unusable in practice. >> Option a) works. Unless it is not sufficient to support a motivated >> and real usecase, there is no reason for us to even discuss anything >> else. > > Why? I can say the same for your solution. My solution has the minimum feature set required to support flow mobility in real-world usecases, i.e. MAG driven based on L2 triggers. Your solution has more feature (dynamic prefix management, LMA-triggered flow movement) that applies to imaginary usecases (e.g., one in which a LMA in a core network somewhere knows how good or bad a radio link is...) >> > To me, in order to enable flow mobility in PMIPv6, there are two main >> > things needed (on the network side): the ability for the LMA to perfor= m >> > flow routing (i.e. not just routing based on IP destination prefix) an= d >> > to allow the MAG to route prefixes that have not been delegated by the >> > LMA on the initial interface attachment of the MN (i.e. to support the >> > dynamic modification of the prefixes -- associated to a particular MN = -- >> > that the MAG is aware of). Of course, we need on the mobile side the >> > ability to receive and send packets simultaneously through different >> > physical interfaces (regardless of the IPs used). IMO, both technical >> > approaches a) and b) above meet the technical requirements without >> > posing any issue related to implementation complexity (both follows th= e >> > KISS principle) or charter compliance. >> >> a) works. b) is unecessary unless proven otherwise, which hasn't happen. >> >> > >> > To sum up this long e-mail, I see two main issues that need to be >> > resolved to be able to progress: >> > >> > - Trigger issue. I see the need for both LMA and MAG initiated. >> > Therefore I propose to work on a solution that supports BOTH. Differen= t >> > people have expressed their preferences to support both and I don't se= e >> > any major issue on that. The only required change to support both is t= he >> > addition of some signaling between LMA and MAG. >> >> There is a major issue that there is no basis for an LMA to decide >> where to send flows, and nobody was able to refute the argument I put >> forth why this doesn't work. > > But this applies to any solution, right? The LMA is always the entity > that has to decide to which MAG it should send the traffic. My solution doesn't have added complexity to support a usecase that does not happen in practice, i.e., the LMA knowing where to sends flows. --julien From julien.ietf@gmail.com Tue Feb 15 11:39:19 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 344523A6A9E for ; Tue, 15 Feb 2011 11:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=-0.583, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4fsdE+oezDu for ; Tue, 15 Feb 2011 11:39:18 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id DBE633A6A6C for ; Tue, 15 Feb 2011 11:39:17 -0800 (PST) Received: by fxm9 with SMTP id 9so647370fxm.31 for ; Tue, 15 Feb 2011 11:39:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dptwKJxjiFmG5QLf0SH8ys1pSuE2K73J+soD9y1a7pk=; b=pEAKIsxAGJQ010S1OBrHDHhuMUzbUiZ82w3Qc9HSbXFwtpsdPnIM9NHPBSoBzdkM/X 6fu1aQp0aB62cgrpqp0/ONnyRegq7UMHjP1i/7bn6oKy8DI+U8+IaCdwp5m6IO9LhZAw 5iPN07lU2Q/VEVjk70PaHIzf5S3hq8SJ6UlVE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=x3/nPCrkciUuzQCrlBVVUcsjqiXzRlyaHl0ysL+huY+6R5dF3ZrV7iuI+7k04pY5JR nkEsE+8nkhq/5XyN/88Q/p9DjbWhhUqmWX+f9+/RST82MQN71MAX0R7jcWurqGGpIxaR cNswuEEoxvroERJiRd8V3GLaB9x4oaNP5+7hM= MIME-Version: 1.0 Received: by 10.223.74.206 with SMTP id v14mr6639882faj.66.1297798783533; Tue, 15 Feb 2011 11:39:43 -0800 (PST) Received: by 10.223.74.142 with HTTP; Tue, 15 Feb 2011 11:39:43 -0800 (PST) In-Reply-To: <01f001cbccb1$000dc050$002940f0$@gmail.com> References: <1297677607.4514.71.camel@acorde.it.uc3m.es> <01f001cbccb1$000dc050$002940f0$@gmail.com> Date: Tue, 15 Feb 2011 11:39:43 -0800 Message-ID: From: Julien Laganier To: Youn-Hee Han Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] On the flow mobility discussion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 19:39:19 -0000 Youn-Hee, On Mon, Feb 14, 2011 at 5:38 PM, Youn-Hee Han wrote: > Hi Julien and Stefano, > >> > Regarding b) Julien (and other folks) have asked about scenarios that >> > require that. I think 3G offloading is one of the scenarios that >> > requires that to be supported. If an operator has an MN that is >> > attached to WLAN and 3G simultaneously wants (because of network load >> > conditions) to offload some flows from 3G to WLAN on demand, I think >> > this should be supported, and LMA initiated flow mobility is the way >> to do it. >> >> As I've explained in other notes, there is no basis for the LMA to >> unilateraly decide where to send flows. This simply doesn't work in a >> variety of cases where a wireless L2 might be attached but provide no >> meaningful connectivity. >> >> > >> > Some folks have said that the MN is the only one that knows the >> > quality of the signal it receives and this is mostly true (note that >> > there are solutions than allows the owner of the WLAN to know of the >> > quality and status of the network), but it is also true that in >> > current celular networks handovers are controlled by the network >> > (based on signal quality reports from the MN). To me PMIPv6 follows >> the same model: >> > network controlled __IP__ mobility. >> >> You cannot generalize what a cellular network does with a homogeneous >> collections of radio access technologies that are all developed in the >> same system, and include signaling for the terminal equipment to report >> to a control network node what is the signal quality, to an IP layer >> mobility management in which the radio techonologies were not developed >> to fit together, and you do not have terminal to network signaling =A0fo= r >> radio signal quality. >> >> Further, even if you could (but surely you can't), let me point out that >> in the network controlled cellular systems that are deployed and/or >> specified, the entity that takes the decision is an edge entity (e.g. >> SGSN, MME) which is closer to MAG rather than a hierarchical entity >> (e.g., GGSN, PGW) similar to LMA. >> >> Thus your statement that the LMA being in control would make PMIPv6 >> following the same model than cellular network seems to be factually >> incorrect. > > The procedural sequence of two initiation ways seems to be as follows: 1) > MAG/MN initiation: L2 trigger to MAG -> MAG sends PBU to LMA -> LMA > redistribute flows, 2) LMA initiation: L2 trigger to SGSN/MME -> SGSN/MME > sends a signaling to LMA -> LMA redistribute flows. I don't see how your #2 above is possibly a case of LMA initiation as it starts with a L2 trigger... Surely the LMA isn't terminating the L2 where this trigger occur.... > = Based on such procedural > sequence, I am not able to find any technical reason that rejects one way= , > while accepting the other way. Of course, the signaling between SGSN/MME = and > LMA is implementation-specific and out of scope. I think I'm reaching the point where an indigestion of out-of-scope-ness prevents meaningful technical discussions. Are you saying that the LMA will have interfaces through which it can learn of the link condition of each MN's radio access? > = However, if operators > install PMIPv6 function in their networks, they know well that LMA is the > topological anchor (i.e., all traffic pass through the LMA), and thus the= y > will consent to implement such signaling to support flow mobility. I'd rather have operator express their consent than making prediction on what they will consent if ... > There is another scenario to go well with LMA initiation. It can be setup > with a policy provisioning based on a kind of contract formed between a > mobile client and operator. We don't need to stand firmly by that a polic= y > will be made only based on L2 triggers. We can expect that a policy will = be > made based on many reasons, such as spatial, temporal, environmental, or > even social events. Should do we restrict such various events to be broug= ht > by MN or L2 trigger between MN and MAG? I think that a network-controlled > flow mobility should allow them to directly stimulate the LMA to > redistribute flows across MAGs/interfaces. See my point above. I do not think it is realistic that the LMA is aware of radio conditions for each interface of each MN it serving. Corollary: there is a reason the radio access network is separate from the core network in real systems... --julien From julien.ietf@gmail.com Tue Feb 15 11:41:27 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 673703A6D56 for ; Tue, 15 Feb 2011 11:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=-0.574, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPWSLL3mHl6w for ; Tue, 15 Feb 2011 11:41:26 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 6D95D3A6D10 for ; Tue, 15 Feb 2011 11:41:26 -0800 (PST) Received: by fxm9 with SMTP id 9so649467fxm.31 for ; Tue, 15 Feb 2011 11:41:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=g4G0a8CBt41nf1RFP8ROrsVjIU2s+fZpAi+yLkRKilA=; b=KwAJeDtTBHzWIUT/urBV9KyPI9AMr/G8hr3NztA2flIZb/iSal7p/3YfXCHs9YlA21 9Y1MSWiiWeK5jU7Oa0oivf2vvM6Jqi1wS0dkpecFteKyOEVA487aeMniorRLbiXi/Pnu 2ULauMeDP2iKDum7mMpVEKwcVq5E4YNH7I1aA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NlycFoYFEUQb1Y1RGnHwMDz0Vb6IusjknXYpUgV3SKpcF2x9JCoszcIvTpYpck+pv8 gc8Uk4FxOmwC5xbA75Xv6mfYWhOycAInMG+TuLuuIEbkEgRfW5tWnj4K6sTGpOBOKSEJ xGMof2kgvaF0BMD1PYY7daSzYSswIWW76Su78= MIME-Version: 1.0 Received: by 10.223.100.16 with SMTP id w16mr6654870fan.85.1297798909974; Tue, 15 Feb 2011 11:41:49 -0800 (PST) Received: by 10.223.74.142 with HTTP; Tue, 15 Feb 2011 11:41:49 -0800 (PST) In-Reply-To: References: <680854867F7FD04BB9B06EB8ACA8D5AC0601C1DD@XCH02DFW.rim.net> Date: Tue, 15 Feb 2011 11:41:49 -0800 Message-ID: From: Julien Laganier To: Hesham Soliman Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] On the flow mobility discussion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 19:41:27 -0000 On Mon, Feb 14, 2011 at 7:17 PM, Hesham Soliman wrote: > >> I understand the issue about the fact that an MN may have moved out of >> wifi coverage after registering thru MAGy. >> Or for that matter the wifi network via which the MN is attached (thru >> MAGy) is congested or the link quality is poor. >> And this could happen. >> >> But on the flip side, the MN may be attached to a wifi network and is able >> to send/recv packets thru MAGy with no issues, In which case switching the >> flow at the LMA would work just fine. >> >> Does it not make sense to have a solution for this case? > > => No it doesn't make sense. Because those cases are not deployment > scenarios, they're runtime changes within any deployment. This would be a > solution that "may" work. In other words a useless solution. With the full force of rhetoric: +1 --julien From yh21.han@gmail.com Tue Feb 15 17:28:26 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 367693A6D2D for ; Tue, 15 Feb 2011 17:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTlYqyEPzue2 for ; Tue, 15 Feb 2011 17:28:23 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 4CF2B3A6C7E for ; Tue, 15 Feb 2011 17:28:22 -0800 (PST) Received: by iym1 with SMTP id 1so723154iym.31 for ; Tue, 15 Feb 2011 17:28:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=P/NP71b0Jc+O5mVldzgObwcHIVsMUVI+0O73rQGlzls=; b=QSZ2q6DT4azpoPUTcOx2BhnQ9fLMNcFkO6h5e9jla2bHgeJBjCDUgKf3zbCjQvatYw /YQe+rh7T7K8bZkfvowljnjkdJgzZ5Cm4lUKry/DdLe5BIMBi0gW3z66m246acU3DYft Xe3sJBeROPkKD/VB5iFWzoaaJYmKOG1nAHMGA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=aHemrU28/cLC6g/S00k4B2K9M12fsyegP7Sx22bK2Mz0+6ca1LIQszHQ8uD3mTYQIb zDB505XNAWQ7xoDi+/BngGglGyEz9eaeR8T8AxxbdnDbxnpsyQWaQy6bg9pwQnTAs1Mq HkxPPZDJ+BvYCOsmXjk336WG1oCL0nTtPk3UQ= Received: by 10.231.31.67 with SMTP id x3mr74272ibc.11.1297819729545; Tue, 15 Feb 2011 17:28:49 -0800 (PST) Received: from USERPC ([220.68.82.28]) by mx.google.com with ESMTPS id u9sm57445ibe.8.2011.02.15.17.28.46 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Feb 2011 17:28:47 -0800 (PST) From: "Youn-Hee Han" To: "'Julien Laganier'" References: <1297677607.4514.71.camel@acorde.it.uc3m.es> <01f001cbccb1$000dc050$002940f0$@gmail.com> In-Reply-To: Date: Wed, 16 Feb 2011 10:28:34 +0900 Message-ID: <003b01cbcd78$db74b6e0$925e24a0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGpNwhiI/EAb+IhoRNCaiNKkLsOmgJYaEKAAmMmWB8CAq97vZQShL0Q Content-Language: ko Cc: netext@ietf.org Subject: Re: [netext] On the flow mobility discussion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 01:28:26 -0000 Julien, Before seeing in-lined texts, please consider my point. Basically, I = don't think that the flow redistribution can start only based on L2 status = (e.g., radio condition) change. Yes, the L2 status change is the most major = source to initiate flow redistribution, and thus, MAG/MN initiation way is definitely needed. However, I don't agree that it is the only source. I believe the followings can be the source: user's geographical location, temporal events, financial (accounting) reason, etc. That is, we can = build many scenarios where flows can move across 3G and WLAN, even though both interfaces (3G and WLAN) of a phone are connected in very stable manner = and their radio strength are enough good. Network can collect information = about such various sources, and decide where should a flow be delivered.=20 > On Mon, Feb 14, 2011 at 5:38 PM, Youn-Hee Han = wrote: > > Hi Julien and Stefano, > > > >> > Regarding b) Julien (and other folks) have asked about scenarios > >> > that require that. I think 3G offloading is one of the scenarios > >> > that requires that to be supported. If an operator has an MN that > >> > is attached to WLAN and 3G simultaneously wants (because of = network > >> > load > >> > conditions) to offload some flows from 3G to WLAN on demand, I > >> > think this should be supported, and LMA initiated flow mobility = is > >> > the way > >> to do it. > >> > >> As I've explained in other notes, there is no basis for the LMA to > >> unilateraly decide where to send flows. This simply doesn't work in = a > >> variety of cases where a wireless L2 might be attached but provide = no > >> meaningful connectivity. > >> > >> > > >> > Some folks have said that the MN is the only one that knows the > >> > quality of the signal it receives and this is mostly true (note > >> > that there are solutions than allows the owner of the WLAN to = know > >> > of the quality and status of the network), but it is also true = that > >> > in current celular networks handovers are controlled by the = network > >> > (based on signal quality reports from the MN). To me PMIPv6 = follows > >> the same model: > >> > network controlled __IP__ mobility. > >> > >> You cannot generalize what a cellular network does with a = homogeneous > >> collections of radio access technologies that are all developed in > >> the same system, and include signaling for the terminal equipment = to > >> report to a control network node what is the signal quality, to an = IP > >> layer mobility management in which the radio techonologies were not > >> developed to fit together, and you do not have terminal to network > >> signaling =A0for radio signal quality. > >> > >> Further, even if you could (but surely you can't), let me point out > >> that in the network controlled cellular systems that are deployed > >> and/or specified, the entity that takes the decision is an edge > entity (e.g. > >> SGSN, MME) which is closer to MAG rather than a hierarchical entity > >> (e.g., GGSN, PGW) similar to LMA. > >> > >> Thus your statement that the LMA being in control would make PMIPv6 > >> following the same model than cellular network seems to be = factually > >> incorrect. > > > > The procedural sequence of two initiation ways seems to be as = follows: > > 1) MAG/MN initiation: L2 trigger to MAG -> MAG sends PBU to LMA -> = LMA > > redistribute flows, 2) LMA initiation: L2 trigger to SGSN/MME -> > > SGSN/MME sends a signaling to LMA -> LMA redistribute flows. >=20 > I don't see how your #2 above is possibly a case of LMA initiation as = it > starts with a L2 trigger... Surely the LMA isn't terminating the L2 > where this trigger occur.... >=20 > > > > Based on such procedural sequence, I am not able to find any = technical > > reason that rejects one way, while accepting the other way. Of = course, > > the signaling between SGSN/MME and LMA is implementation-specific = and > out of scope. >=20 > I think I'm reaching the point where an indigestion of = out-of-scope-ness > prevents meaningful technical discussions. Are you saying that the LMA > will have interfaces through which it can learn of the link condition = of > each MN's radio access? >=20 It is implementation-specific. That's all.=20 Many technical discussion has been done based on reasonable assumption. = As you know well, RFC5213 was also made by a reasonable assumption that MAG = can know the status of MN handover and insert a proper HI value to PBU = message. How to get such handover status is also out-of-scope.=20 > > > > However, if operators install PMIPv6 function in their networks, = they > > know well that LMA is the topological anchor (i.e., all traffic pass > > through the LMA), and thus they will consent to implement such > signaling to support flow mobility. >=20 > I'd rather have operator express their consent than making prediction = on > what they will consent if ... >=20 > > There is another scenario to go well with LMA initiation. It can be > > setup with a policy provisioning based on a kind of contract formed > > between a mobile client and operator. We don't need to stand firmly = by > > that a policy will be made only based on L2 triggers. We can expect > > that a policy will be made based on many reasons, such as spatial, > > temporal, environmental, or even social events. Should do we = restrict > > such various events to be brought by MN or L2 trigger between MN and > > MAG? I think that a network-controlled flow mobility should allow = them > > to directly stimulate the LMA to redistribute flows across > MAGs/interfaces. >=20 > See my point above. I do not think it is realistic that the LMA is = aware > of radio conditions for each interface of each MN it serving. > Corollary: there is a reason the radio access network is separate from > the core network in real systems... The radio condition was not what I mentioned. Except radio condition, = many sources can stimulate flow redistribution, and network-side is better to track such sources. Youn-Hee=20 From julien.ietf@gmail.com Tue Feb 15 18:04:22 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 658F23A6C24 for ; Tue, 15 Feb 2011 18:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.175 X-Spam-Level: X-Spam-Status: No, score=-3.175 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKvia7Q8-ERa for ; Tue, 15 Feb 2011 18:04:21 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id C3C963A6B6F for ; Tue, 15 Feb 2011 18:04:20 -0800 (PST) Received: by fxm9 with SMTP id 9so993828fxm.31 for ; Tue, 15 Feb 2011 18:04:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XY3w2LVEC9a/TczKtsyJpok4cmChcHnihG/EBZD1ixg=; b=DtA7cUDPoG2q08n4IKvCW4J2OahY7Lb5vKB7uVCYKExACwubo8K7BQS8yHuDk6nNe7 EbgOrkVYMITtlQjAkaPtHIyHcBvyhEVNlKV+RnU6lfHZCI5EaNQSvVcB5RuTidAt+2XN 5NOodwX2yTvwLVGzMogWPawarioHgh7geybkI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=o5/sxJTDP7ISisUyCLTk1q76Y0z7ryLXXlJfjCQktX4ae5CbEwZ8E94BLBOW5sFQyK uBR/CEYqOWuiiCzThrh1Tp3pfICt9yzx9nDm4gI/AG4yPJYMNCmbDOICPLyicvllmg7D XAZRJ0UtdXCs8zVcCgTys3lhzFpd9l6DLt/Rg= MIME-Version: 1.0 Received: by 10.223.103.8 with SMTP id i8mr140245fao.47.1297821885516; Tue, 15 Feb 2011 18:04:45 -0800 (PST) Received: by 10.223.74.142 with HTTP; Tue, 15 Feb 2011 18:04:45 -0800 (PST) In-Reply-To: <003b01cbcd78$db74b6e0$925e24a0$@gmail.com> References: <1297677607.4514.71.camel@acorde.it.uc3m.es> <01f001cbccb1$000dc050$002940f0$@gmail.com> <003b01cbcd78$db74b6e0$925e24a0$@gmail.com> Date: Tue, 15 Feb 2011 18:04:45 -0800 Message-ID: From: Julien Laganier To: Youn-Hee Han Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] On the flow mobility discussion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 02:04:22 -0000 Youn-Hee, On Tue, Feb 15, 2011 at 5:28 PM, Youn-Hee Han wrote: > Julien, > > Before seeing in-lined texts, please consider my point. Basically, I don'= t > think that the flow redistribution can start only based on L2 status (e.g= ., > radio condition) change. Yes, the L2 status change is the most major sour= ce > to initiate flow redistribution, and thus, MAG/MN initiation way is > definitely needed. However, I don't agree that it is the only source. I > believe the followings can be the source: user's geographical location, > temporal events, financial (accounting) reason, etc. That is, we can buil= d > many scenarios where flows can move across 3G and WLAN, even though both > interfaces (3G and WLAN) of a phone are connected in very stable manner a= nd > their radio strength are enough good. Network can collect information abo= ut > such various sources, and decide where should a flow be delivered. IMHO this is theoretical and does no fly in practice. See below - >> On Mon, Feb 14, 2011 at 5:38 PM, Youn-Hee Han wrote= : >> > Hi Julien and Stefano, >> > >> >> > Regarding b) Julien (and other folks) have asked about scenarios >> >> > that require that. I think 3G offloading is one of the scenarios >> >> > that requires that to be supported. If an operator has an MN that >> >> > is attached to WLAN and 3G simultaneously wants (because of network >> >> > load >> >> > conditions) to offload some flows from 3G to WLAN on demand, I >> >> > think this should be supported, and LMA initiated flow mobility is >> >> > the way >> >> to do it. >> >> >> >> As I've explained in other notes, there is no basis for the LMA to >> >> unilateraly decide where to send flows. This simply doesn't work in a >> >> variety of cases where a wireless L2 might be attached but provide no >> >> meaningful connectivity. >> >> >> >> > >> >> > Some folks have said that the MN is the only one that knows the >> >> > quality of the signal it receives and this is mostly true (note >> >> > that there are solutions than allows the owner of the WLAN to know >> >> > of the quality and status of the network), but it is also true that >> >> > in current celular networks handovers are controlled by the network >> >> > (based on signal quality reports from the MN). To me PMIPv6 follows >> >> the same model: >> >> > network controlled __IP__ mobility. >> >> >> >> You cannot generalize what a cellular network does with a homogeneous >> >> collections of radio access technologies that are all developed in >> >> the same system, and include signaling for the terminal equipment to >> >> report to a control network node what is the signal quality, to an IP >> >> layer mobility management in which the radio techonologies were not >> >> developed to fit together, and you do not have terminal to network >> >> signaling =A0for radio signal quality. >> >> >> >> Further, even if you could (but surely you can't), let me point out >> >> that in the network controlled cellular systems that are deployed >> >> and/or specified, the entity that takes the decision is an edge >> entity (e.g. >> >> SGSN, MME) which is closer to MAG rather than a hierarchical entity >> >> (e.g., GGSN, PGW) similar to LMA. >> >> >> >> Thus your statement that the LMA being in control would make PMIPv6 >> >> following the same model than cellular network seems to be factually >> >> incorrect. >> > >> > The procedural sequence of two initiation ways seems to be as follows: >> > 1) MAG/MN initiation: L2 trigger to MAG -> MAG sends PBU to LMA -> LMA >> > redistribute flows, 2) LMA initiation: L2 trigger to SGSN/MME -> >> > SGSN/MME sends a signaling to LMA -> LMA redistribute flows. >> >> I don't see how your #2 above is possibly a case of LMA initiation as it >> starts with a L2 trigger... Surely the LMA isn't terminating the L2 >> where this trigger occur.... >> >> > >> > Based on such procedural sequence, I am not able to find any technical >> > reason that rejects one way, while accepting the other way. Of course, >> > the signaling between SGSN/MME and LMA is implementation-specific and >> out of scope. >> >> I think I'm reaching the point where an indigestion of out-of-scope-ness >> prevents meaningful technical discussions. Are you saying that the LMA >> will have interfaces through which it can learn of the link condition of >> each MN's radio access? >> > > It is implementation-specific. That's all. > > Many technical discussion has been done based on reasonable assumption. A= s > you know well, RFC5213 was also made by a reasonable assumption that MAG = can > know the status of MN handover and insert a proper HI value to PBU messag= e. > How to get such handover status is also out-of-scope. Functionally speaking, the LMA being aware of radio conditions at the MN is neither practical neither a reasonable assumption. It is also not implementation specific as this is an external interface between network nodes (LMA and MN), for which we have no existing protocols. Finally, note that there are no interfaces between an MME and a LMA in real systems. The MME is interfaced to the MAG. The MAG is interfaced to the LMA. >> > However, if operators install PMIPv6 function in their networks, they >> > know well that LMA is the topological anchor (i.e., all traffic pass >> > through the LMA), and thus they will consent to implement such >> signaling to support flow mobility. >> >> I'd rather have operator express their consent than making prediction on >> what they will consent if ... >> >> > There is another scenario to go well with LMA initiation. It can be >> > setup with a policy provisioning based on a kind of contract formed >> > between a mobile client and operator. We don't need to stand firmly by >> > that a policy will be made only based on L2 triggers. We can expect >> > that a policy will be made based on many reasons, such as spatial, >> > temporal, environmental, or even social events. Should do we restrict >> > such various events to be brought by MN or L2 trigger between MN and >> > MAG? I think that a network-controlled flow mobility should allow them >> > to directly stimulate the LMA to redistribute flows across >> MAGs/interfaces. >> >> See my point above. I do not think it is realistic that the LMA is aware >> of radio conditions for each interface of each MN it serving. >> Corollary: there is a reason the radio access network is separate from >> the core network in real systems... > > The radio condition was not what I mentioned. Except radio condition, man= y > sources can stimulate flow redistribution, and network-side is better to > track such sources. Can we agree that, flow mobility or not, client-based or network based, what ultimately primes is that the MN has actual connectivity? If yes, given that connectivity is contingent of good radio conditions, the entity that triggers flow mobility has to be aware of connectivity and thus of radio conditions. That is the case for the MN, and that is not the case for the LMA unless the LMA is made aware of how good or bad radio links are which I do not believe is a reasonable assumption. --julien From trungtm2909@gmail.com Wed Feb 16 16:46:27 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9A413A6C3E for ; Wed, 16 Feb 2011 16:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.193 X-Spam-Level: X-Spam-Status: No, score=-3.193 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwDtKTvHvTPu for ; Wed, 16 Feb 2011 16:46:26 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 9CCDA3A6A0C for ; Wed, 16 Feb 2011 16:46:26 -0800 (PST) Received: by iwc10 with SMTP id 10so2052586iwc.31 for ; Wed, 16 Feb 2011 16:46:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Tim1GVPNszzVrFvYYvs26UsUFZS3hGrNhoz7CNLD7pY=; b=pn4EfcAIMr2ACrgoQhjUJxs7OLI753+j+kz/sUvAse/6+kQkipVA0QRDOE2x0gFyww 78sVp/IE2SL5qBAV2FsYEIOkdGSFErU/oelSlqZsNTiSmZl2BeGg5jFYgtjapCjY2EsI Eiv8/kFW0pgrWssoJua8UOpY6PN5jZVq7rz64= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nn/TJm+hKar+8RJBAM9A25cE/YPKDAKScTHUVE6LsxGwUSrCwXdcHB3Y13keuy62uP qkg/rzwsfTyw687ZxJaVULZzLHsPrYQyrdoQpvvn96M+hd1EG+g4+DH5TGJF+owgYSwj +sCevcTgOoyK0oc/U25SNuuSwo8e0wXYMculU= MIME-Version: 1.0 Received: by 10.42.175.6 with SMTP id ay6mr1767627icb.470.1297903615759; Wed, 16 Feb 2011 16:46:55 -0800 (PST) Received: by 10.42.72.199 with HTTP; Wed, 16 Feb 2011 16:46:55 -0800 (PST) In-Reply-To: References: <1297677607.4514.71.camel@acorde.it.uc3m.es> <01f001cbccb1$000dc050$002940f0$@gmail.com> <003b01cbcd78$db74b6e0$925e24a0$@gmail.com> Date: Thu, 17 Feb 2011 09:46:55 +0900 Message-ID: From: Tran Minh Trung To: Julien Laganier Content-Type: multipart/alternative; boundary=90e6ba6e8f46f8574d049c6fbb17 Cc: netext@ietf.org Subject: Re: [netext] On the flow mobility discussion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 00:46:27 -0000 --90e6ba6e8f46f8574d049c6fbb17 Content-Type: text/plain; charset=ISO-8859-1 Hi Julien and all, Actually the argument that "the LMA is not aware of MN's radio links then it can send data to the black-hole" dose not work with me :-). Is MAG aware of the MN's radio links status and inform it to the LMA?. The only question here is how fast the MAG can update MN's link status to the LMA. It is two sizes of a coin!. We also can argue that the MN is not aware of the network status (or network policy in some cases) so it can send data to a congested road of forbidden road (kind of black-holes ^^) as well. And also one question here is how fast the MN can keep update with Network Status (or policy - can be a rarely case)?. For me the only reason that we do not need signaling message from the LMA to the MAG is that we can setup the environment for flow mobility in advance, relying on the L2 attachment/detachment event of the interfaces. There are three cases can be occurred when the MN attach an interface to the network as following: MN attaches an interface IF-N to MAG-N: Case 1: L2 informs MAG-N that it is a New attachment -> Create new Session (RFC5312) Case 2: L2 informs MAG-N that it is a Hand-Off Attachment -> replace IF in the existing session by IF-N. (RFC5213) Case 3: L2 informs MAG-N that it is a Simultaneous attachment (that can support flow mobility)-> Add interface to existing sessions of the interfaces in the same set. (Extension for flow mobility) The case 3 can always help us to setup the environment for flow mobility in advance. After that the LMA can decide to move flow at anytime without any extra signaling message. That's all, we may not need more complicated protocol. I understand the arguments from Rajeev, Carlos, Telemaco, and Youn that we need to support different user cases as well as allowing LMA to send FMI to MAG. However, up to now I did not see any reasonable reason during this discussion. If we can not show out real cases and convince people that they are necessary then I would suggest to skip these parts from baseline document. I am on checking carefully some real cases that may require signaling message from LMA to MAG. Two of them can be listed here is (1) Multiple PDP Contexts in UTMS system (2) Creating a new VPN connection. It needs more time to have final answer exactly. Regards, TrungTM --90e6ba6e8f46f8574d049c6fbb17 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Julien and all,

Actually the argument that "the LMA is = not aware of MN's=A0radio links then it can send data to the=A0black-ho= le"=A0dose not work with me :-).
Is MAG aware of the MN'= s radio links status and inform it to the LMA?. The only question here is h= ow fast the MAG can update MN's link status to the LMA.

It is two sizes of a coin!. We also can argue that the = MN is not aware of the network status (or network policy in some cases) so = it can send data to a congested road of=A0forbidden=A0road (kind of black-h= oles ^^) as well. And also one question here is how fast the MN can keep up= date with Network Status (or policy - can be a rarely case)?.

For me the only reason that =A0we do not need signaling= message from the LMA to the MAG is that we can setup the environment for f= low mobility in advance, relying on the L2 attachment/detachment event of t= he interfaces.

There are three cases can be=A0occurred=A0when the MN a= ttach an interface to the network as following:=A0

MN attaches an interface IF-N to MAG-N:
Case 1: L2 informs = MAG-N that it is a New attachment -> Create new Session =A0(RFC5312)
Case 2: L2 informs MAG-N that it is a Hand-Off Attachment -> replac= e IF in the existing session by IF-N. =A0(RFC5213)
Case 3: L2 inf= orms MAG-N that it is a Simultaneous attachment (that can support flow mobi= lity)-> Add interface to existing sessions of the interfaces in the same= set. =A0(Extension for flow mobility)

The case 3 can always help us to setup the enviro= nment for flow mobility in advance. After that the LMA can decide to move f= low at anytime without any extra signaling message.

That's all, we may not need more complicated protocol.
<= br>
I understand the arguments from Rajeev, Carlos, Telemaco, and= Youn that we need to support different user cases as well as allowing LMA = to send FMI to MAG. However, up to now I did not see any=A0reasonable=A0rea= son during this discussion.=A0If we can=A0not show out real cases and convi= nce people that they are necessary then I would suggest to skip these parts= from baseline document.=A0

I am on checking carefully some real=A0cases that may r= equire signaling message from LMA to MAG.
Two of them can be list= ed here is (1) Multiple PDP Contexts in UTMS system (2) Creating a new VPN = connection.
It needs more time to have final answer exactly.

<= div>Regards,
TrungTM

--90e6ba6e8f46f8574d049c6fbb17-- From Internet-Drafts@ietf.org Thu Feb 17 04:00:03 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0B313A6DCF; Thu, 17 Feb 2011 04:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NctbATDwlel2; Thu, 17 Feb 2011 04:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 572983A6D3C; Thu, 17 Feb 2011 04:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110217120002.10796.6101.idtracker@localhost> Date: Thu, 17 Feb 2011 04:00:02 -0800 Cc: netext@ietf.org Subject: [netext] I-D Action:draft-ietf-netext-redirect-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 12:00:03 -0000 --NextPart 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 : Runtime LMA Assignment Support for Proxy Mobile IPv6 Author(s) : J. Korhonen, et al. Filename : draft-ietf-netext-redirect-05.txt Pages : 19 Date : 2011-02-17 This document describes a runtime Local Mobility Anchor assignment functionality and corresponding mobility options for Proxy Mobile IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-redirect-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netext-redirect-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-17034923.I-D@ietf.org> --NextPart-- From pierrick.seite@orange-ftgroup.com Thu Feb 17 07:33:04 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4884C3A6DD9 for ; Thu, 17 Feb 2011 07:33:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.845 X-Spam-Level: X-Spam-Status: No, score=-2.845 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRop+iwVKIOc for ; Thu, 17 Feb 2011 07:33:02 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 77A3F3A6E49 for ; Thu, 17 Feb 2011 07:33:02 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C23CC8C0A32; Thu, 17 Feb 2011 13:56:02 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 2E11D9B1628; Wed, 16 Feb 2011 11:35:09 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Feb 2011 11:34:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Feb 2011 11:34:43 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C4620180E319@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] On the flow mobility discussion Thread-Index: AcvNfeZXKOtT/JelS/+8xBuXEn8GBAAO7kMQ References: <1297677607.4514.71.camel@acorde.it.uc3m.es><01f001cbccb1$000dc050$002940f0$@gmail.com><003b01cbcd78$db74b6e0$925e24a0$@gmail.com> From: To: , X-OriginalArrivalTime: 16 Feb 2011 10:34:44.0332 (UTC) FILETIME=[203D22C0:01CBCDC5] Cc: netext@ietf.org Subject: Re: [netext] On the flow mobility discussion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 15:33:04 -0000 Hi, Just a question for clarification... Could we say that if the MN = attaches a new physical interface (i.e. the MN makes decision to use = it), the LMA can consider this interface as valid candidate for IP flow = mobility . In other words, can we consider that adding/removing = interface to the session is a way to make the LMA aware about MN = decision? The LMA is still the entity making the final decision (it = should not be the only use-case, but can be the first...) but the LMA = trusts MN's decision and is not required to compute MN's measurement. BTW, I agree the LMA should not be provisioned with MN's radio = measurements, or other local information; in the same way the MN should = not be provisioned with information on accesses network load. It is = generally preferable to share decision between entities rather than = exchanging info. But it's another debate and application to PMIP = architecture is not so obvious... Pierrick > -----Message d'origine----- > De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la = part > de Julien Laganier > Envoy=E9=A0: mercredi 16 f=E9vrier 2011 03:05 > =C0=A0: Youn-Hee Han > Cc=A0: netext@ietf.org > Objet=A0: Re: [netext] On the flow mobility discussion >=20 > Youn-Hee, >=20 > On Tue, Feb 15, 2011 at 5:28 PM, Youn-Hee Han = wrote: > > Julien, > > > > Before seeing in-lined texts, please consider my point. Basically, I > don't > > think that the flow redistribution can start only based on L2 status > (e.g., > > radio condition) change. Yes, the L2 status change is the most major > source > > to initiate flow redistribution, and thus, MAG/MN initiation way is > > definitely needed. However, I don't agree that it is the only = source. I > > believe the followings can be the source: user's geographical = location, > > temporal events, financial (accounting) reason, etc. That is, we can > build > > many scenarios where flows can move across 3G and WLAN, even though = both > > interfaces (3G and WLAN) of a phone are connected in very stable = manner > and > > their radio strength are enough good. Network can collect = information > about > > such various sources, and decide where should a flow be delivered. >=20 > IMHO this is theoretical and does no fly in practice. See below - >=20 > >> On Mon, Feb 14, 2011 at 5:38 PM, Youn-Hee Han > wrote: > >> > Hi Julien and Stefano, > >> > > >> >> > Regarding b) Julien (and other folks) have asked about = scenarios > >> >> > that require that. I think 3G offloading is one of the = scenarios > >> >> > that requires that to be supported. If an operator has an MN = that > >> >> > is attached to WLAN and 3G simultaneously wants (because of > network > >> >> > load > >> >> > conditions) to offload some flows from 3G to WLAN on demand, I > >> >> > think this should be supported, and LMA initiated flow = mobility is > >> >> > the way > >> >> to do it. > >> >> > >> >> As I've explained in other notes, there is no basis for the LMA = to > >> >> unilateraly decide where to send flows. This simply doesn't work = in > a > >> >> variety of cases where a wireless L2 might be attached but = provide > no > >> >> meaningful connectivity. > >> >> > >> >> > > >> >> > Some folks have said that the MN is the only one that knows = the > >> >> > quality of the signal it receives and this is mostly true = (note > >> >> > that there are solutions than allows the owner of the WLAN to = know > >> >> > of the quality and status of the network), but it is also true > that > >> >> > in current celular networks handovers are controlled by the > network > >> >> > (based on signal quality reports from the MN). To me PMIPv6 > follows > >> >> the same model: > >> >> > network controlled __IP__ mobility. > >> >> > >> >> You cannot generalize what a cellular network does with a > homogeneous > >> >> collections of radio access technologies that are all developed = in > >> >> the same system, and include signaling for the terminal = equipment to > >> >> report to a control network node what is the signal quality, to = an > IP > >> >> layer mobility management in which the radio techonologies were = not > >> >> developed to fit together, and you do not have terminal to = network > >> >> signaling =A0for radio signal quality. > >> >> > >> >> Further, even if you could (but surely you can't), let me point = out > >> >> that in the network controlled cellular systems that are = deployed > >> >> and/or specified, the entity that takes the decision is an edge > >> entity (e.g. > >> >> SGSN, MME) which is closer to MAG rather than a hierarchical = entity > >> >> (e.g., GGSN, PGW) similar to LMA. > >> >> > >> >> Thus your statement that the LMA being in control would make = PMIPv6 > >> >> following the same model than cellular network seems to be = factually > >> >> incorrect. > >> > > >> > The procedural sequence of two initiation ways seems to be as > follows: > >> > 1) MAG/MN initiation: L2 trigger to MAG -> MAG sends PBU to LMA = -> > LMA > >> > redistribute flows, 2) LMA initiation: L2 trigger to SGSN/MME -> > >> > SGSN/MME sends a signaling to LMA -> LMA redistribute flows. > >> > >> I don't see how your #2 above is possibly a case of LMA initiation = as > it > >> starts with a L2 trigger... Surely the LMA isn't terminating the L2 > >> where this trigger occur.... > >> > >> > > >> > Based on such procedural sequence, I am not able to find any > technical > >> > reason that rejects one way, while accepting the other way. Of = course, > >> > the signaling between SGSN/MME and LMA is implementation-specific = and > >> out of scope. > >> > >> I think I'm reaching the point where an indigestion of = out-of-scope- > ness > >> prevents meaningful technical discussions. Are you saying that the = LMA > >> will have interfaces through which it can learn of the link = condition > of > >> each MN's radio access? > >> > > > > It is implementation-specific. That's all. > > > > Many technical discussion has been done based on reasonable = assumption. > As > > you know well, RFC5213 was also made by a reasonable assumption that = MAG > can > > know the status of MN handover and insert a proper HI value to PBU > message. > > How to get such handover status is also out-of-scope. >=20 > Functionally speaking, the LMA being aware of radio conditions at the > MN is neither practical neither a reasonable assumption. >=20 > It is also not implementation specific as this is an external > interface between network nodes (LMA and MN), for which we have no > existing protocols. >=20 > Finally, note that there are no interfaces between an MME and a LMA in > real systems. The MME is interfaced to the MAG. The MAG is interfaced > to the LMA. >=20 > >> > However, if operators install PMIPv6 function in their networks, = they > >> > know well that LMA is the topological anchor (i.e., all traffic = pass > >> > through the LMA), and thus they will consent to implement such > >> signaling to support flow mobility. > >> > >> I'd rather have operator express their consent than making = prediction > on > >> what they will consent if ... > >> > >> > There is another scenario to go well with LMA initiation. It can = be > >> > setup with a policy provisioning based on a kind of contract = formed > >> > between a mobile client and operator. We don't need to stand = firmly > by > >> > that a policy will be made only based on L2 triggers. We can = expect > >> > that a policy will be made based on many reasons, such as = spatial, > >> > temporal, environmental, or even social events. Should do we = restrict > >> > such various events to be brought by MN or L2 trigger between MN = and > >> > MAG? I think that a network-controlled flow mobility should allow > them > >> > to directly stimulate the LMA to redistribute flows across > >> MAGs/interfaces. > >> > >> See my point above. I do not think it is realistic that the LMA is > aware > >> of radio conditions for each interface of each MN it serving. > >> Corollary: there is a reason the radio access network is separate = from > >> the core network in real systems... > > > > The radio condition was not what I mentioned. Except radio = condition, > many > > sources can stimulate flow redistribution, and network-side is = better to > > track such sources. >=20 > Can we agree that, flow mobility or not, client-based or network > based, what ultimately primes is that the MN has actual connectivity? >=20 > If yes, given that connectivity is contingent of good radio > conditions, the entity that triggers flow mobility has to be aware of > connectivity and thus of radio conditions. >=20 > That is the case for the MN, and that is not the case for the LMA > unless the LMA is made aware of how good or bad radio links are which > I do not believe is a reasonable assumption. >=20 > --julien > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From julien.ietf@gmail.com Thu Feb 17 10:41:43 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E56E43A6D60 for ; Thu, 17 Feb 2011 10:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2NKNpNY2QnG for ; Thu, 17 Feb 2011 10:41:43 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id D9DF73A6D39 for ; Thu, 17 Feb 2011 10:41:42 -0800 (PST) Received: by eyd10 with SMTP id 10so1700920eyd.31 for ; Thu, 17 Feb 2011 10:42:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=aLTrSdEEn4OlhFfR13UJJlVFhH6tfoImmkQHsC9vY0Q=; b=bYr5Jnrxixw/gv/Ue6Mgi3S7fZtBYQEpmDmJ9uzlh8EJ88nDEUEebEtegGeS8u9dnB a0f0fFVCRrARNG0+QxnVtkiIaxposuTiN9eCkjZtWO/rCWniiK8/TS8KGJj7ZbfeLqQj d9QBa9sOze9664ZdfFyXHoyWxIu7aysWuFSMA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NcUJ/HpQOpri6dhpb5C92V3FKJ8o3xHfvZWCAcIKErWBx7b1jcTQ7h7rUY4t63sgns Ov1DvII7/jgWC0cWEphFiq2gLkLduuJz02O8aDCA10UPfx1i7M73e4wqKuyfdot8K+Xt 4ZJj2AyaWiBAtVl8jV48v58NH4eo9UAFiflB8= MIME-Version: 1.0 Received: by 10.223.69.141 with SMTP id z13mr2813776fai.9.1297968103787; Thu, 17 Feb 2011 10:41:43 -0800 (PST) Received: by 10.223.74.142 with HTTP; Thu, 17 Feb 2011 10:41:43 -0800 (PST) In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C4620180E319@ftrdmel0.rd.francetelecom.fr> References: <1297677607.4514.71.camel@acorde.it.uc3m.es> <01f001cbccb1$000dc050$002940f0$@gmail.com> <003b01cbcd78$db74b6e0$925e24a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C4620180E319@ftrdmel0.rd.francetelecom.fr> Date: Thu, 17 Feb 2011 10:41:43 -0800 Message-ID: From: Julien Laganier To: pierrick.seite@orange-ftgroup.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] On the flow mobility discussion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 18:41:44 -0000 Hi Pierrick, On Wed, Feb 16, 2011 at 2:34 AM, wrote= : > > Hi, > > Just a question for clarification... Could we say that if the MN attaches= a new physical interface (i.e. the MN makes decision to use it), the LMA c= an consider this interface as valid candidate for IP flow mobility . In oth= er words, can we consider that adding/removing interface to the session is = a way to make the LMA aware about MN decision? The LMA is still the entity = making the final decision (it should not be the only use-case, but can be t= he first...) but the LMA trusts MN's decision and is not required to comput= e MN's measurement. I don't think that would fly: if I follow your line of thought it could be that the interface doesn't provide meaningful connectivity to the Internet but the MN doesn't know yet because it's not attached, MN attaches it, then the LMA decides to route flows there but they're not making it to the MN... Given the time constant with which radio conditions varies, I think the MN should be the one making the final decision. > BTW, I agree the LMA should not be provisioned with MN's radio measuremen= ts, or other local information; in the same way the MN should not be provis= ioned with information on accesses network load. It is generally preferable= to share decision between entities rather than exchanging info. But it's a= nother debate and application to PMIP architecture is not so obvious... I am confused by this statement. If no information is ever exchanged and decision is shared, wouldn't that lead to contradictory decisions being taken by MN and NW side? --julien From sfaccin@rim.com Thu Feb 17 11:17:48 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96F343A6DE3 for ; Thu, 17 Feb 2011 11:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.993 X-Spam-Level: X-Spam-Status: No, score=-5.993 tagged_above=-999 required=5 tests=[AWL=0.606, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IhejEqNbBdB for ; Thu, 17 Feb 2011 11:17:47 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 35D823A6E52 for ; Thu, 17 Feb 2011 11:17:45 -0800 (PST) X-AuditID: 0a666446-b7b84ae000000ae2-5e-4d5d7478322d Received: from XCH139CNC.rim.net ( [10.65.10.235]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 07.ED.02786.8747D5D4; Thu, 17 Feb 2011 14:18:16 -0500 (EST) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH139CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Feb 2011 14:18:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" content-transfer-encoding: base64 Date: Thu, 17 Feb 2011 13:18:14 -0600 Message-ID: <680854867F7FD04BB9B06EB8ACA8D5AC0611EAF4@XCH02DFW.rim.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] On the flow mobility discussion Thread-Index: AcvO0nMubQAi8qFIRu2a3ZmY8t2QAgABJq8w References: <1297677607.4514.71.camel@acorde.it.uc3m.es><01f001cbccb1$000dc050$002940f0$@gmail.com><003b01cbcd78$db74b6e0$925e24a0$@gmail.com><843DA8228A1BA74CA31FB4E111A5C4620180E319@ftrdmel0.rd.francetelecom.fr> From: "Stefano Faccin" To: "Julien Laganier" , X-OriginalArrivalTime: 17 Feb 2011 19:18:17.0378 (UTC) FILETIME=[6E495020:01CBCED7] X-Brightmail-Tracker: AAAAAwAAAZEXcZZxF3JSIg== Cc: netext@ietf.org Subject: Re: [netext] On the flow mobility discussion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 19:17:48 -0000 SnVsaWVuLCBQaWVycmljaywNCkkgaGF2ZSB0byBhZ3JlZSB3aXRoIEp1bGllbiBvbiB0aGUg TU4gc3RpbGwgYW5kIGFsd2F5cyBiZWluZyB0aGUgYmVzdCBlbnRpdHkgY2FwYWJsZSBvZiBt YWtpbmcgc3VjaCBkZWNpc2lvbi4gQmFzZWQgb24gZGV2aWNlIGV4cGVyaWVuY2UsIGluIG1v c3QgY2FzZXMgdGhlIE1OIGlzIHRoZSBzb2xlIGVudGl0eSB0aGF0IGNhbiBtYWtlIGFuIGVk dWNhdGVkIGRlY2lzaW9uIGFuZCBhdm9pZCBjb25mbGljdHMgd2l0aCB0aGUgbmV0d29yay4g VGhhdCdzIHRoZSBtYWluIHJlYXNvbiB3aHksIGluIDNHUFAsIGZvciB0aGUgaW50ZXJ3b3Jr aW5nIGJldHdlZW4gY2VsbHVsYXIgbGlua3MgYW5kIG90aGVyIG5vbi1jZWxsdWxhciB0ZWNo bm9sb2dpZXMsIGl0IGhhcyBiZWVuIGxlZnQgdG8gdGhlIE1OIHRvIGRldmljZSB3aGljaCBh Y2Nlc3MgdG8gY29ubmVjdCB0byBhbmQgd2hlbiAodGhvdWdoIG9wZXJhdG9ycyBjYW4gY29u dHJvbCB0aGF0IHRocm91Z2ggcG9saWN5IHByb3Zpc2lvbmluZykuDQoNCkNoZWVycywNClN0 ZWZhbm8gRmFjY2luDQoNClN0YW5kYXJkcyBNYW5hZ2VyDQpSZXNlYXJjaCBJbiBNb3Rpb24g Q29ycG9yYXRpb24gDQo1MDAwIFJpdmVyc2lkZSBEcml2ZSANCkJ1aWxkaW5nIDYsIEJyYXpv cyBFYXN0LCBTdGUuIDEwMA0KSXJ2aW5nLCBUZXhhcyA3NTAzOSBVU0EgDQpPZmZpY2U6ICg5 NzIpIDkxMCAzNDUxwqAgDQpJbnRlcm5hbDogODIwLjYzNDUxDQo6ICg1MTApIDIzMCA4NDIy DQp3d3cucmltLmNvbTsgd3d3LmJsYWNrYmVycnkuY29tIA0KDQoNCg0K74GQIENvbnNpZGVy IHRoZSBlbnZpcm9ubWVudCBiZWZvcmUgcHJpbnRpbmcuDQoNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IG5ldGV4dC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bmV0 ZXh0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdWxpZW4gTGFnYW5pZXINClNl bnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxNywgMjAxMSAxMDo0MiBBTQ0KVG86IHBpZXJyaWNr LnNlaXRlQG9yYW5nZS1mdGdyb3VwLmNvbQ0KQ2M6IG5ldGV4dEBpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtuZXRleHRdIE9uIHRoZSBmbG93IG1vYmlsaXR5IGRpc2N1c3Npb24NCg0KSGkg UGllcnJpY2ssDQoNCk9uIFdlZCwgRmViIDE2LCAyMDExIGF0IDI6MzQgQU0sICA8cGllcnJp Y2suc2VpdGVAb3JhbmdlLWZ0Z3JvdXAuY29tPiB3cm90ZToNCj4NCj4gSGksDQo+DQo+IEp1 c3QgYSBxdWVzdGlvbiBmb3IgY2xhcmlmaWNhdGlvbi4uLiBDb3VsZCB3ZSBzYXkgdGhhdCBp ZiB0aGUgTU4gYXR0YWNoZXMgYSBuZXcgcGh5c2ljYWwgaW50ZXJmYWNlIChpLmUuIHRoZSBN TiBtYWtlcyBkZWNpc2lvbiB0byB1c2UgaXQpLCB0aGUgTE1BIGNhbiBjb25zaWRlciB0aGlz IGludGVyZmFjZSBhcyB2YWxpZCBjYW5kaWRhdGUgZm9yIElQIGZsb3cgbW9iaWxpdHkgLiBJ biBvdGhlciB3b3JkcywgY2FuIHdlIGNvbnNpZGVyIHRoYXQgYWRkaW5nL3JlbW92aW5nIGlu dGVyZmFjZSB0byB0aGUgc2Vzc2lvbiBpcyBhIHdheSB0byBtYWtlIHRoZSBMTUEgYXdhcmUg YWJvdXQgTU4gZGVjaXNpb24/IFRoZSBMTUEgaXMgc3RpbGwgdGhlIGVudGl0eSBtYWtpbmcg dGhlIGZpbmFsIGRlY2lzaW9uIChpdCBzaG91bGQgbm90IGJlIHRoZSBvbmx5IHVzZS1jYXNl LCBidXQgY2FuIGJlIHRoZSBmaXJzdC4uLikgYnV0IHRoZSBMTUEgdHJ1c3RzIE1OJ3MgZGVj aXNpb24gYW5kIGlzIG5vdCByZXF1aXJlZCB0byBjb21wdXRlIE1OJ3MgbWVhc3VyZW1lbnQu DQoNCkkgZG9uJ3QgdGhpbmsgdGhhdCB3b3VsZCBmbHk6IGlmIEkgZm9sbG93IHlvdXIgbGlu ZSBvZiB0aG91Z2h0IGl0DQpjb3VsZCBiZSB0aGF0IHRoZSBpbnRlcmZhY2UgZG9lc24ndCBw cm92aWRlIG1lYW5pbmdmdWwgY29ubmVjdGl2aXR5IHRvDQp0aGUgSW50ZXJuZXQgYnV0IHRo ZSBNTiBkb2Vzbid0IGtub3cgeWV0IGJlY2F1c2UgaXQncyBub3QgYXR0YWNoZWQsIE1ODQph dHRhY2hlcyBpdCwgdGhlbiB0aGUgTE1BIGRlY2lkZXMgdG8gcm91dGUgZmxvd3MgdGhlcmUg YnV0IHRoZXkncmUgbm90DQptYWtpbmcgaXQgdG8gdGhlIE1OLi4uDQoNCkdpdmVuIHRoZSB0 aW1lIGNvbnN0YW50IHdpdGggd2hpY2ggcmFkaW8gY29uZGl0aW9ucyB2YXJpZXMsIEkgdGhp bmsNCnRoZSBNTiBzaG91bGQgYmUgdGhlIG9uZSBtYWtpbmcgdGhlIGZpbmFsIGRlY2lzaW9u Lg0KDQo+IEJUVywgSSBhZ3JlZSB0aGUgTE1BIHNob3VsZCBub3QgYmUgcHJvdmlzaW9uZWQg d2l0aCBNTidzIHJhZGlvIG1lYXN1cmVtZW50cywgb3Igb3RoZXIgbG9jYWwgaW5mb3JtYXRp b247IGluIHRoZSBzYW1lIHdheSB0aGUgTU4gc2hvdWxkIG5vdCBiZSBwcm92aXNpb25lZCB3 aXRoIGluZm9ybWF0aW9uIG9uIGFjY2Vzc2VzIG5ldHdvcmsgbG9hZC4gSXQgaXMgZ2VuZXJh bGx5IHByZWZlcmFibGUgdG8gc2hhcmUgZGVjaXNpb24gYmV0d2VlbiBlbnRpdGllcyByYXRo ZXIgdGhhbiBleGNoYW5naW5nIGluZm8uIEJ1dCBpdCdzIGFub3RoZXIgZGViYXRlIGFuZCBh cHBsaWNhdGlvbiB0byBQTUlQIGFyY2hpdGVjdHVyZSBpcyBub3Qgc28gb2J2aW91cy4uLg0K DQpJIGFtIGNvbmZ1c2VkIGJ5IHRoaXMgc3RhdGVtZW50LiBJZiBubyBpbmZvcm1hdGlvbiBp cyBldmVyIGV4Y2hhbmdlZA0KYW5kIGRlY2lzaW9uIGlzIHNoYXJlZCwgd291bGRuJ3QgdGhh dCBsZWFkIHRvIGNvbnRyYWRpY3RvcnkgZGVjaXNpb25zDQpiZWluZyB0YWtlbiBieSBNTiBh bmQgTlcgc2lkZT8NCg0KLS1qdWxpZW4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpuZXRleHQgbWFpbGluZyBsaXN0DQpuZXRleHRAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0DQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQpUaGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2ht ZW50cykgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLCBwcml2aWxlZ2Vk IG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0ZXJpYWwgcHJvdGVjdGVkIGJ5IHRoZSBzb2xpY2l0 b3ItY2xpZW50IG9yIG90aGVyIGFwcGxpY2FibGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1 dGUgbm9uLXB1YmxpYyBpbmZvcm1hdGlvbi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9u IGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGli aXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3Is IHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhp cyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRp c3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9uIGJ5IHVu aW50ZW5kZWQgcmVjaXBpZW50cyBpcyBub3QgYXV0aG9yaXplZCBhbmQgbWF5IGJlIHVubGF3 ZnVsLg0K From trungtm2909@gmail.com Fri Feb 18 01:27:31 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEAD33A6EAC for ; Fri, 18 Feb 2011 01:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.212 X-Spam-Level: X-Spam-Status: No, score=-3.212 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0qayLTOs-Df for ; Fri, 18 Feb 2011 01:27:30 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 7CE263A6E81 for ; Fri, 18 Feb 2011 01:27:27 -0800 (PST) Received: by iwl42 with SMTP id 42so143994iwl.31 for ; Fri, 18 Feb 2011 01:28:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fiT3p2TpD4T+fps5CbbS7Ifw+fgKQdRM+nrSgZm6dcU=; b=sYb8Fv7EBjbbwagiWIgVfml6befoyxU3JYKOvU8JtAZ2TmCTamd4GXhBHyb9WXD+5H 2DebSVfBWvlrsvpNnVPLqXayIDla+/VSOV3uDTU+l37prD2uUYes88AyBDK+HVO2t8JA 7jyx5oQTKof0tXOhul06R8jEP8zSBuONLpJz0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DK7FEEA1bwoQQsfzuYaSD4n9pRWoQRkGVdk8kKyB77bOhyiJHOtB09mV2ogIyPP0BK /fpXKuhs1a/AsXJ2ITyuP+GDJinD8zqEJtrnNWCpNtP8FmlvhWOkskuwR8IvD1iYLppa IlBnvjepX9p62sLdwS9XbRpoA4AaGP99JrQWI= MIME-Version: 1.0 Received: by 10.42.218.136 with SMTP id hq8mr605347icb.379.1298021280476; Fri, 18 Feb 2011 01:28:00 -0800 (PST) Received: by 10.42.72.199 with HTTP; Fri, 18 Feb 2011 01:28:00 -0800 (PST) In-Reply-To: References: <1297677607.4514.71.camel@acorde.it.uc3m.es> <01f001cbccb1$000dc050$002940f0$@gmail.com> <003b01cbcd78$db74b6e0$925e24a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C4620180E319@ftrdmel0.rd.francetelecom.fr> Date: Fri, 18 Feb 2011 18:28:00 +0900 Message-ID: From: Tran Minh Trung To: Julien Laganier Content-Type: multipart/alternative; boundary=20cf3043475c557074049c8b2153 Cc: netext@ietf.org Subject: Re: [netext] On the flow mobility discussion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 09:27:31 -0000 --20cf3043475c557074049c8b2153 Content-Type: text/plain; charset=ISO-8859-1 Hi Julien and Pierrick, On Fri, Feb 18, 2011 at 3:41 AM, Julien Laganier wrote: > Hi Pierrick, > > On Wed, Feb 16, 2011 at 2:34 AM, > wrote: > > > > Hi, > > > > Just a question for clarification... Could we say that if the MN attaches > a new physical interface (i.e. the MN makes decision to use it), the LMA can > consider this interface as valid candidate for IP flow mobility . In other > words, can we consider that adding/removing interface to the session is a > way to make the LMA aware about MN decision? The LMA is still the entity > making the final decision (it should not be the only use-case, but can be > the first...) but the LMA trusts MN's decision and is not required to > compute MN's measurement. > > I don't think that would fly: if I follow your line of thought it > could be that the interface doesn't provide meaningful connectivity to > the Internet but the MN doesn't know yet because it's not attached, MN > attaches it, then the LMA decides to route flows there but they're not > making it to the MN... > > Given the time constant with which radio conditions varies, I think > the MN should be the one making the final decision. > Dou you mean that the flow mobility decision? If yes, then I disagree. The MN just decides which interface can be used to attach to the network basing on the availablity of access points (MAGs). L2 trigger just helps the network to setup session to support flow mobility (eg. add interface in the set to the same session). L2 trigger can not be used to trigger the network to move flow. Since we are proposing network-based flow mobility, the network (LMA) is the one who decides to move a flow basing on the *network policy* and the *available attahcments* of the MN. The MN just follows the network's policy to send uplink traffic. Regards, TrungTM > > > BTW, I agree the LMA should not be provisioned with MN's radio > measurements, or other local information; in the same way the MN should not > be provisioned with information on accesses network load. It is generally > preferable to share decision between entities rather than exchanging info. > But it's another debate and application to PMIP architecture is not so > obvious... > > I am confused by this statement. If no information is ever exchanged > and decision is shared, wouldn't that lead to contradictory decisions > being taken by MN and NW side? > > --julien > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > -- Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132, Fax : +82-42-861-5404 --20cf3043475c557074049c8b2153 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Julien and Pierrick,

On Fri, Feb 18, 2011 at 3:41 AM, Julien Laganier= <julien.ietf= @gmail.com> wrote:
Hi Pierrick,

On Wed, Feb 16, 2011 at 2:34 AM, =A0<pierrick.seite@orange-ftgroup.com> wrote:
>
> Hi,
>
> Just a question for clari= fication... Could we say that if the MN attaches a new physical interface (= i.e. the MN makes decision to use it), the LMA can consider this interface = as valid candidate for IP flow mobility . In other words, can we consider t= hat adding/removing interface to the session is a way to make the LMA aware= about MN decision? The LMA is still the entity making the final decision (= it should not be the only use-case, but can be the first...) but the LMA tr= usts MN's decision and is not required to compute MN's measurement.=

I don't think that would fly: if I follow your line of though= t it
could be that the interface doesn't provide meaningful connecti= vity to
the Internet but the MN doesn't know yet because it's no= t attached, MN
attaches it, then the LMA decides to route flows there but they're not<= br>making it to the MN...

Given the time constant with which radio c= onditions varies, I think
the MN should be the one making the final deci= sion.
=A0
Dou you mean that the flow mobility decision?
If yes, then I disagree.
=A0
The MN just decides which interface can be used to attach to the netwo= rk basing on the availablity of access points (MAGs).
L2 trigger just helps the network to=A0setup session to support flow m= obility (eg. add interface in the set to the same session).
L2 trigger can not be used to trigger the network to move flow.
=A0
Since we are proposing network-based flow mobility, the network (LMA) = is the one who decides to move a flow basing on the network policy<= /strong> and the available attahcments of the MN. The MN j= ust follows the network's policy to send uplink traffic.
=A0
Regards,
TrungTM
=A0
=A0

> BTW, I agree the LMA should not be provisioned w= ith MN's radio measurements, or other local information; in the same wa= y the MN should not be provisioned with information on accesses network loa= d. It is generally preferable to share decision between entities rather tha= n exchanging info. But it's another debate and application to PMIP arch= itecture is not so obvious...

I am confused by this statement. If no information is ever exchan= ged
and decision is shared, wouldn't that lead to contradictory deci= sions
being taken by MN and NW side?



--
Ph.D., Seni= or Member
Electronics and Telecommunications Research Institute
Stan= dards Research Center
161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KO= REA
Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404
--20cf3043475c557074049c8b2153-- From pierrick.seite@orange-ftgroup.com Fri Feb 18 01:33:56 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 760243A6C78 for ; Fri, 18 Feb 2011 01:33:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEEvsORDHMzO for ; Fri, 18 Feb 2011 01:33:55 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 3D5A03A6D48 for ; Fri, 18 Feb 2011 01:33:55 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D56A1FC400E; Fri, 18 Feb 2011 10:34:32 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id C8E9CFC4003; Fri, 18 Feb 2011 10:34:32 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Feb 2011 10:34:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Feb 2011 10:34:26 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C4620180E962@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] On the flow mobility discussion Thread-Index: AcvO0mWBg8tnBo0pQLGgdQr0Hg/dJAAdD/Gw References: <1297677607.4514.71.camel@acorde.it.uc3m.es><01f001cbccb1$000dc050$002940f0$@gmail.com><003b01cbcd78$db74b6e0$925e24a0$@gmail.com><843DA8228A1BA74CA31FB4E111A5C4620180E319@ftrdmel0.rd.francetelecom.fr> From: To: X-OriginalArrivalTime: 18 Feb 2011 09:34:27.0288 (UTC) FILETIME=[09238580:01CBCF4F] Cc: netext@ietf.org Subject: Re: [netext] On the flow mobility discussion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 09:33:56 -0000 Hi, Just some thoughts inline.... > -----Message d'origine----- > De=A0: Julien Laganier [mailto:julien.ietf@gmail.com] > Envoy=E9=A0: jeudi 17 f=E9vrier 2011 19:42 > =C0=A0: SEITE Pierrick RD-RESA-REN > Cc=A0: yh21.han@gmail.com; netext@ietf.org > Objet=A0: Re: [netext] On the flow mobility discussion >=20 > Hi Pierrick, >=20 > On Wed, Feb 16, 2011 at 2:34 AM, > wrote: > > > > Hi, > > > > Just a question for clarification... Could we say that if the MN > attaches a new physical interface (i.e. the MN makes decision to use = it), > the LMA can consider this interface as valid candidate for IP flow > mobility . In other words, can we consider that adding/removing = interface > to the session is a way to make the LMA aware about MN decision? The = LMA > is still the entity making the final decision (it should not be the = only > use-case, but can be the first...) but the LMA trusts MN's decision = and is > not required to compute MN's measurement. >=20 > I don't think that would fly: if I follow your line of thought it > could be that the interface doesn't provide meaningful connectivity to > the Internet but the MN doesn't know yet because it's not attached, MN > attaches it, then the LMA decides to route flows there but they're not > making it to the MN... >=20 Ok, I see. But, we could assume that the MN implements a connection = manager (it seems a reasonable for a multiple interfaces). One of the = function of the connection manager could be the "IP connectivity check". = The idea is that this connection manager function could guarantee that = the MN attaches to an interface with good radio condition. The only = thing that the connection manager cannot take into account is accesses = network load, but it's typically the role of the network to monitor = accesses load and trigger mobility via the LMA. > Given the time constant with which radio conditions varies, I think > the MN should be the one making the final decision. >=20 > > BTW, I agree the LMA should not be provisioned with MN's radio > measurements, or other local information; in the same way the MN = should > not be provisioned with information on accesses network load. It is > generally preferable to share decision between entities rather than > exchanging info. But it's another debate and application to PMIP > architecture is not so obvious... >=20 > I am confused by this statement. If no information is ever exchanged > and decision is shared, wouldn't that lead to contradictory decisions > being taken by MN and NW side? >=20 Actually, I meant that we avoid exchanging brute measurement between = entities. But, of course, decision entities exchange information. This = information can be partial decision (e.g. we have a decision = architecture where different decision makers calculate, upon their local = information, a score per access; then these scores are exchanged and = compute by the entity making the final decision) or updated policies. = Then the question is "where to put the final decision?". As Stefano = pointed out, the MN used to make the final decision, and it's = reasonable. Actually, the only real added-value for network assisted = decision (I'm not saying network enforced :-)) is on access overloaded = condition. Network assistance avoids that the MN attach to an access = network that cannot provide "good" connectivity. Now, I don't know if, = in the PMIP context, we should require to stick to this model and close = the door to other decision model.=20 Sorry for digressing on the decision model in the netext ML, but I think = it was worth to be clarified.=20 > --julien From trungtm2909@gmail.com Fri Feb 18 01:39:22 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D7AD3A6B5F for ; Fri, 18 Feb 2011 01:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.23 X-Spam-Level: X-Spam-Status: No, score=-3.23 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9v+8J4cvtudn for ; Fri, 18 Feb 2011 01:39:20 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 031753A6A5A for ; Fri, 18 Feb 2011 01:39:19 -0800 (PST) Received: by iwl42 with SMTP id 42so154185iwl.31 for ; Fri, 18 Feb 2011 01:39:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QgeTRT55z93AbR75dIBnwgEb0qSWYE79DrUvUX2BaE0=; b=xi4doapTLImcfixSAziuMHlPZKvg5NvKhYV1kMTCkXCvP/T9dxCDR3RCyB4tVCfpuo IXYNp+JHepYR1p1A4P63Asml1PDPCdudOvRminpeq/WFAwEyoBdANA6+C5+//Mu8J8pM PEhHKjSWDXrqDN6ruiH0D/1rByZ+D6+YlMUfs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wbEuC+CkTrvlW4DeCi3lit/t+jD+lmJR5BCY2JkfsFuWvvzF+9pssQxGO/GCJK5MMZ CbsSZqAtjXF+va7bPJ71Hz5Lo7nvcUUj/+2DYo1bniDbOyoc4xeAXsQJNayvDCiBimIP 5lajyIKSTrtjBaxrqt65hEOopJnfyxgQjTH0I= MIME-Version: 1.0 Received: by 10.42.218.136 with SMTP id hq8mr618110icb.379.1298021991083; Fri, 18 Feb 2011 01:39:51 -0800 (PST) Received: by 10.42.72.199 with HTTP; Fri, 18 Feb 2011 01:39:51 -0800 (PST) In-Reply-To: <680854867F7FD04BB9B06EB8ACA8D5AC0611EAF4@XCH02DFW.rim.net> References: <1297677607.4514.71.camel@acorde.it.uc3m.es> <01f001cbccb1$000dc050$002940f0$@gmail.com> <003b01cbcd78$db74b6e0$925e24a0$@gmail.com> <843DA8228A1BA74CA31FB4E111A5C4620180E319@ftrdmel0.rd.francetelecom.fr> <680854867F7FD04BB9B06EB8ACA8D5AC0611EAF4@XCH02DFW.rim.net> Date: Fri, 18 Feb 2011 18:39:51 +0900 Message-ID: From: Tran Minh Trung To: Stefano Faccin Content-Type: multipart/alternative; boundary=20cf3043475cb06f6c049c8b4b6d Cc: netext@ietf.org Subject: Re: [netext] On the flow mobility discussion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 09:39:22 -0000 --20cf3043475cb06f6c049c8b4b6d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Stefano, On Fri, Feb 18, 2011 at 4:18 AM, Stefano Faccin wrote: > Julien, Pierrick, > I have to agree with Julien on the MN still and always being the best > entity capable of making such decision. Based on device experience, in mo= st > cases the MN is the sole entity that can make an educated decision and av= oid > conflicts with the network. That's the main reason why, in 3GPP, for the > interworking between cellular links and other non-cellular technologies, = it > has been left to the MN to device which access to connect to and when > (though operators can control that through policy provisioning). > Ofcouse the MN has its right to decide which interface can be used to attac= h to the network. But the MN dose not have full right (or information) to send a flow via an attachment. For example in the pass, AT&T did not allow VoIP over 3G then MN can not make VoIP call over 3G attachment. Is that right? In addition, to send downlink traffic, the LMA should check the available o= f the MN's attachments first, then check the network policy to decide which attachment that downlink traffic will be sent to. The LMA sending downlink traffic to blackhole or not is totaly depend on the information that is updated from MAG. If the MAG can not update exatcly the attachment status of the MN then we have no way to help the LMA not to send data to blackhole! Could you show out another way? Regards, TrungTM > > Cheers, > Stefano Faccin > > Standards Manager > Research In Motion Corporation > 5000 Riverside Drive > Building 6, Brazos East, Ste. 100 > Irving, Texas 75039 USA > Office: (972) 910 3451 > Internal: 820.63451 > : (510) 230 8422 > www.rim.com; www.blackberry.com > > > > =EF=81=90 Consider the environment before printing. > > > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf > Of Julien Laganier > Sent: Thursday, February 17, 2011 10:42 AM > To: pierrick.seite@orange-ftgroup.com > Cc: netext@ietf.org > Subject: Re: [netext] On the flow mobility discussion > > Hi Pierrick, > > On Wed, Feb 16, 2011 at 2:34 AM, > wrote: > > > > Hi, > > > > Just a question for clarification... Could we say that if the MN attach= es > a new physical interface (i.e. the MN makes decision to use it), the LMA = can > consider this interface as valid candidate for IP flow mobility . In othe= r > words, can we consider that adding/removing interface to the session is a > way to make the LMA aware about MN decision? The LMA is still the entity > making the final decision (it should not be the only use-case, but can be > the first...) but the LMA trusts MN's decision and is not required to > compute MN's measurement. > > I don't think that would fly: if I follow your line of thought it > could be that the interface doesn't provide meaningful connectivity to > the Internet but the MN doesn't know yet because it's not attached, MN > attaches it, then the LMA decides to route flows there but they're not > making it to the MN... > > Given the time constant with which radio conditions varies, I think > the MN should be the one making the final decision. > > > BTW, I agree the LMA should not be provisioned with MN's radio > measurements, or other local information; in the same way the MN should n= ot > be provisioned with information on accesses network load. It is generally > preferable to share decision between entities rather than exchanging info= . > But it's another debate and application to PMIP architecture is not so > obvious... > > I am confused by this statement. If no information is ever exchanged > and decision is shared, wouldn't that lead to contradictory decisions > being taken by MN and NW side? > > --julien > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-publi= c > information. Any use of this information by anyone other than the intende= d > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from y= our > system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawf= ul. > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132, Fax : +82-42-861-5404 --20cf3043475cb06f6c049c8b4b6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Stefano,

On Fri, Feb 18, 2011 at 4:18 AM, Stefano Faccin = <sfaccin@rim.com> wrote:
Julien, Pierrick,
I have to a= gree with Julien on the MN still and always being the best entity capable o= f making such decision. Based on device experience, in most cases the MN is= the sole entity that can make an educated decision and avoid conflicts wit= h the network. That's the main reason why, in 3GPP, for the interworkin= g between cellular links and other non-cellular technologies, it has been l= eft to the MN to device which access to connect to and when (though operato= rs can control that through policy provisioning).
=C2=A0
Ofcouse the MN has its right to decide which interface can be used to = attach to the network.
But the MN dose not have full right (or information) to send a flow vi= a an attachment.
=C2=A0
For example in the pass, AT&T=C2=A0did not allow VoIP over 3G then= MN can not make VoIP call over 3G attachment.
Is that right?
=C2=A0
In addition, to send downlink traffic, the LMA should check the=C2=A0a= vailable of the MN's attachments first, then check the network policy t= o=C2=A0decide which attachment that downlink traffic will be sent to.
=C2=A0
The LMA sending downlink traffic to blackhole or=C2=A0not is=C2=A0tota= ly depend on the=C2=A0information that is updated from MAG.
If the MAG can not update exatcly the attachment status of the MN then= we have no way to help the LMA not to send data to blackhole!
=C2=A0
Could you show out another way?
=C2=A0
Regards,
TrungTM
=C2=A0=C2=A0

Cheers,
Stefano Faccin

Standards ManagerResearch In Motion Corporation
5000 Riverside Drive
Building 6, Braz= os East, Ste. 100
Irving, Texas 75039 USA
Office: (972) 910 3451=C2= =A0
Internal: 820.63451
: (510) 230 8422
www.rim.com; www.blackberry.com



=EF=81=90 Consider t= he environment before printing.


-----Original Message-----
From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Julien Laganier
Sent: Thursday, February 17, 2011 10:42 AM
To: pierrick.seite@orange-ftgroup= .com
Cc: netext@ietf.org
<= /div>
Subject: Re: [netext] On the flow mobility discussion
=
Hi Pierrick,

On Wed, Feb 16, 2011 at 2:34 AM, =C2=A0<pierrick.seite@orange-ftgroup= .com> wrote:
>
> Hi,
>
> Just a question for clarification... Could= we say that if the MN attaches a new physical interface (i.e. the MN makes= decision to use it), the LMA can consider this interface as valid candidat= e for IP flow mobility . In other words, can we consider that adding/removi= ng interface to the session is a way to make the LMA aware about MN decisio= n? The LMA is still the entity making the final decision (it should not be = the only use-case, but can be the first...) but the LMA trusts MN's dec= ision and is not required to compute MN's measurement.

I don't think that would fly: if I follow your line of thought itcould be that the interface doesn't provide meaningful connectivity t= o
the Internet but the MN doesn't know yet because it's not atta= ched, MN
attaches it, then the LMA decides to route flows there but they're not<= br>making it to the MN...

Given the time constant with which radio c= onditions varies, I think
the MN should be the one making the final deci= sion.

> BTW, I agree the LMA should not be provisioned with MN's radio= measurements, or other local information; in the same way the MN should no= t be provisioned with information on accesses network load. It is generally= preferable to share decision between entities rather than exchanging info.= But it's another debate and application to PMIP architecture is not so= obvious...

I am confused by this statement. If no information is ever exchangedand decision is shared, wouldn't that lead to contradictory decisions<= br>being taken by MN and NW side?

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

---------------------------------------------------------= ------------
This transmission (including any attachments) may contain c= onfidential information, privileged material (including material protected = by the solicitor-client or other applicable privileges), or constitute non-= public information. Any use of this information by anyone other than the in= tended recipient is prohibited. If you have received this transmission in e= rror, please immediately reply to the sender and delete this information fr= om your system. Use, dissemination, distribution, or reproduction of this t= ransmission by unintended recipients is not authorized and may be unlawful.=
_______________________________________________



--
Ph.D., Senior Mem= ber
Electronics and Telecommunications Research Institute
Standards = Research Center
161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132,=C2=A0=C2=A0 Fax : +82-42-861-5404
--20cf3043475cb06f6c049c8b4b6d-- From Internet-Drafts@ietf.org Tue Feb 22 09:15:02 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DABB3A6961; Tue, 22 Feb 2011 09:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vHBz+jGnCuL; Tue, 22 Feb 2011 09:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 998EB3A693F; Tue, 22 Feb 2011 09:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110222171501.5063.24068.idtracker@localhost> Date: Tue, 22 Feb 2011 09:15:01 -0800 Cc: netext@ietf.org Subject: [netext] I-D Action:draft-ietf-netext-pmip6-lr-ps-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 17:15:02 -0000 --NextPart 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 : PMIPv6 Localized Routing Problem Statement Author(s) : M. Liebsch, et al. Filename : draft-ietf-netext-pmip6-lr-ps-05.txt Pages : 19 Date : 2011-02-22 Proxy Mobile IPv6 is the IETF standard for network-based mobility management. In Proxy Mobile IPv6, mobile nodes are topologically anchored at a Local Mobility Anchor, which forwards all data for registered mobile nodes. The setup and maintenance of localized routing, which allows forwarding of data packets between mobile nodes and correspondent nodes directly without involvement of the Local Mobility Anchor in forwarding, is not considered. This document describes the problem space of localized routing in Proxy Mobile IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-pmip6-lr-ps-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netext-pmip6-lr-ps-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-22090250.I-D@ietf.org> --NextPart-- From Basavaraj.Patil@nokia.com Tue Feb 22 14:28:31 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D07403A697A; Tue, 22 Feb 2011 14:28:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMakM4MVqJBW; Tue, 22 Feb 2011 14:28:28 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 6FB5C3A6934; Tue, 22 Feb 2011 14:28:28 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1MMTB2A013161; Wed, 23 Feb 2011 00:29:12 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Feb 2011 00:29:01 +0200 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 22 Feb 2011 23:29:00 +0100 Received: from 008-AM1MPN1-005.mgdnok.nokia.com ([169.254.4.2]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0270.002; Tue, 22 Feb 2011 23:29:00 +0100 From: To: , Thread-Topic: Request to progress Netext WG I-D: draft-ietf-netext-pmip6-lr-ps-05.txt Thread-Index: AQHL0t/ms6y4eVDDAUG4DRjKd/ye0A== Date: Tue, 22 Feb 2011 22:29:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [172.19.59.20] Content-Type: text/plain; charset="us-ascii" Content-ID: <2FFF62294A0FC449AE7B3E397C072703@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 Feb 2011 22:29:01.0304 (UTC) FILETIME=[E7769780:01CBD2DF] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: [netext] Request to progress Netext WG I-D: draft-ietf-netext-pmip6-lr-ps-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 22:28:31 -0000 Hello, The Netext WG I-D mentioned below is ready to be progressed to the IESG for review and approval. Attached is the document shepherd writeup for this I-D. I-D: PMIPv6 Localized Routing Problem Statement -Raj (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Document shepherd: Basavaraj Patil Yes, I have reviewed this version of the document and believe it is ready for IESG review and publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has had adequate reviews by key WG members. I do not have any concerns regarding the depth or breadth of the reviews received. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No concerns regarding the reviews so far and do not believe additional reviews are needed. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. I do not have any specific concerns at this time regarding this document. The problem statement has been presented and discussed at length in previous WG meetings and on the mailing list. I am not aware of any IPR disclosures related to this I-D. =20 (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is solid WG consensus behind this document. I believe the majority of WG members understand and agree with the document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No threats of appeal or extreme discontent have been expressed regarding this I-D. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. I have run the I-D through the ID nits tool and found no issues. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References are split into normative and informative sections. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? This document does not require any IANA action. It is a problem state description.=20 (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Not applicable. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Proxy Mobile IPv6 is the IETF standard for network-based mobility management. In Proxy Mobile IPv6, mobile nodes are topologically anchored at a Local Mobility Anchor, which forwards all data for registered mobile nodes. The setup and maintenance of localized routing, which allows forwarding of data packets between mobile nodes and correspondent nodes directly without involvement of the Local Mobility Anchor in forwarding, is not considered. This document describes the problem space of localized routing in Proxy Mobile IPv6.=20 There is strong WG consensus regarding the problem statement and the need for a solution to deal with localized routing. The document describes the localized routing problem in Proxy Mobile IPv6 deployments and hence not relevant from an implementation perspective.=20 From Xiangsong.Cui@huawei.com Tue Feb 22 17:44:37 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5581B3A6784; Tue, 22 Feb 2011 17:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXZ-ZNah2D0R; Tue, 22 Feb 2011 17:44:36 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id A02D03A63EC; Tue, 22 Feb 2011 17:44:35 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LH1003IKRJATC@szxga04-in.huawei.com>; Wed, 23 Feb 2011 09:45:10 +0800 (CST) Received: from c00111037 ([10.111.16.128]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LH1005ZRRJAP4@szxga04-in.huawei.com>; Wed, 23 Feb 2011 09:45:10 +0800 (CST) Date: Wed, 23 Feb 2011 09:45:10 +0800 From: Xiangsong Cui In-reply-to: To: Basavaraj.Patil@nokia.com, iesg-secretary@ietf.org, jari.arkko@piuha.net Message-id: <004001cbd2fb$4e9b3590$ebd1a0b0$%cui@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AQHL0t/ms6y4eVDDAUG4DRjKd/ye0JQOTjaw References: Cc: netext@ietf.org Subject: Re: [netext] Request to progress Netext WG I-D: draft-ietf-netext-pmip6-lr-ps-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 01:44:37 -0000 Hi Raj, I'm not sure I have understood this well, because in my mind, there are some comments not completely addressed, I mean http://www.ietf.org/mail-archive/web/netext/current/msg01483.html. Would you please check them, or make sure those comments are negligible? If I was wrong, please let me know my mistake. Thanks, Xiangsong > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of > Basavaraj.Patil@nokia.com > Sent: Wednesday, February 23, 2011 6:29 AM > To: iesg-secretary@ietf.org; jari.arkko@piuha.net > Cc: netext@ietf.org > Subject: [netext] Request to progress Netext WG I-D: > draft-ietf-netext-pmip6-lr-ps-05.txt > > > Hello, > > The Netext WG I-D mentioned below is ready to be progressed to the > IESG for review and approval. Attached is the document shepherd > writeup for this I-D. > > I-D: PMIPv6 Localized Routing Problem Statement > > > -Raj > > > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? > > Document shepherd: Basavaraj Patil > Yes, I have reviewed this version of the document and believe it is > ready for IESG review and publication. > > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? > > The document has had adequate reviews by key WG members. > I do not have any concerns regarding the depth or breadth of the > reviews received. > > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? > > No concerns regarding the reviews so far and do not believe additional > reviews are needed. > > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. > > I do not have any specific concerns at this time regarding this > document. The problem statement has been presented and discussed at > length in previous WG meetings and on the mailing list. I am not aware > of any IPR disclosures related to this I-D. > > > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? > > There is solid WG consensus behind this document. I believe the > majority of WG members understand and agree with the document. > > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) > > No threats of appeal or extreme discontent have been expressed > regarding this I-D. > > > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See the Internet-Drafts Checklist > and http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? > > Yes. I have run the I-D through the ID nits tool and found no issues. > > > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. > > References are split into normative and informative sections. > > > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC5226]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? > > This document does not require any IANA action. It is a problem state > description. > > > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? > > Not applicable. > > > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up? Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: > > Proxy Mobile IPv6 is the IETF standard for network-based mobility > management. In Proxy Mobile IPv6, mobile nodes are topologically > anchored at a Local Mobility Anchor, which forwards all data > for registered mobile nodes. The setup and maintenance of localized > routing, which allows forwarding of data packets between mobile nodes > and correspondent nodes directly without involvement of the Local > Mobility Anchor in forwarding, is not considered. This document > describes the problem space of localized routing in Proxy Mobile > IPv6. > > There is strong WG consensus regarding the problem statement and the > need for a solution to deal with localized routing. > The document describes the localized routing problem in Proxy Mobile > IPv6 deployments and hence not relevant from an implementation > perspective. > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From rkoodli@cisco.com Tue Feb 22 22:04:52 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AAA93A681E for ; Tue, 22 Feb 2011 22:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.83 X-Spam-Level: X-Spam-Status: No, score=-108.83 tagged_above=-999 required=5 tests=[AWL=-0.828, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_28=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m88eSt4J9Wuv for ; Tue, 22 Feb 2011 22:04:50 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5A2633A67C3 for ; Tue, 22 Feb 2011 22:04:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rkoodli@cisco.com; l=5023; q=dns/txt; s=iport; t=1298441133; x=1299650733; h=date:subject:from:to:message-id:mime-version; bh=/8mumjOveRll7ArAcNiLPGuPdvx1ZtSPbdDFHsxAGZ8=; b=HxigmWHY1ENiZtI/zoCwEPBitcDLpgFPz8ZbBR7SSpgQxbAAVa4SzcjF gvbKX60g+NZvA3oQZs754oX42dhtZHH4xcn6uRxTK4/mYOm87Fr1Rj1Gd MKhQpZEOgku5g87EHoyNGOF2RdOc5YOr5es/+r6IuRTiZpYumbZ7mQIp8 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkHAOQxZE2tJXG9/2dsb2JhbACCSpVPjThVc6E6m2KFXgSFDYcHg0E X-IronPort-AV: E=Sophos;i="4.62,210,1297036800"; d="scan'208,217";a="218861851" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rtp-iport-2.cisco.com with ESMTP; 23 Feb 2011 06:05:30 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p1N65UbO007985 for ; Wed, 23 Feb 2011 06:05:30 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Feb 2011 00:05:30 -0600 Received: from 10.21.86.112 ([10.21.86.112]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Wed, 23 Feb 2011 06:05:29 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 22 Feb 2011 22:05:50 -0800 From: Rajeev Koodli To: Message-ID: Thread-Topic: Flow Mobility discussion - way forward? Thread-Index: AcvTH7hRFKVN0Kr67UiTaBIlg8gywg== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3381257150_3065243" X-OriginalArrivalTime: 23 Feb 2011 06:05:30.0235 (UTC) FILETIME=[AC89CCB0:01CBD31F] Subject: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 06:04:52 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3381257150_3065243 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hello folks, I guess we all could agree that we have had plenty of discussion. There are pros and cons of both L2 signaling and IP-based signaling approaches. I would like to propose a way forward. 1) L2 signaling-based: 1. MN attaches to a (new) MAGy 2. MN indicates using (extended) L2 signaling that the attachment is for flow mobility with a new HI=FM value 3. MAGy sends the PBU, and the LMA updates an existing session with the new interface and MAGy 4. The old and new prefixes are shared for the session 5. There is new L2 signaling between the MN and the (old) MAGx to trigger the PBU from MAGx. 6. This covers the case where we assume that L2 signaling and the associated extensions are feasible. Keeps the existing RFC 5213 model 2) IP-based: 1. *If* the PBU from the new MAGy does not carry the new HI=FM value, the LMA creates a new session (modulo handover^) per RFC 5213. 2. In this case, the LMA adds the prefix to the session(s) if the policy requires/allows the MN for flow mobility 3. The LMA signals the relevant MAGs to provide the prefix(es) when flow mobility is required 4. This covers the case where L2 signaling extensions for flow mobility are not feasible or are not in place, or for any generic L2 technology 5. 2) will not come into play if 1) above is in place. Comments? -Rajeev ^ HI=Handover will be similar to 1) above except that the forwarding state for Proxy-CoA-MAGx is removed (and hence no flow mobility). --B_3381257150_3065243 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Flow Mobility discussion - way forward?
Hello folks,

I guess we all could agree that we have had plenty of discussion.
There are pros and cons of both L2 signaling and IP-based signaling approac= hes. I would like to propose a way forward.

1) L2 signaling-based:
  1. MN attaches to a (new) MAGy=20
  2. MN indicates using (extended) L2 signaling that the atta= chment is for flow mobility with a new HI=3DFM value=20
  3. MAGy sends the PBU, and the LMA updates an existing sess= ion with the new interface and MAGy=20
  4. The old and new prefixes are shared for the session=20
  5. There is new L2 signaling between the MN and the (old) M= AGx to trigger the PBU from MAGx.=20
  6. This covers the case where we assume that L2 signaling a= nd the associated extensions are feasible. Keeps the existing RFC 5213 model=

2) IP-based:
  1. *If* the PBU from the new MAGy does not carry the ne= w HI=3DFM value, the LMA creates a new session (modulo handover^) per RFC 5213= .=20
  2. In this case, the LMA adds the prefix to the session(s) = if the policy requires/allows the MN for flow mobility=20
  3. The LMA signals the relevant MAGs to provide the prefix(= es) when flow mobility is required=20
  4. This covers the case where L2 signaling extensions for f= low mobility are not feasible or are not in place, or for any generic L2 tec= hnology=20
  5. 2) will not come into play if 1) above is in place.

Comments?

-Rajeev

^ HI=3DHandover will be similar to 1) above except that the forwarding state = for Proxy-CoA-MAGx is removed (and hence no flow mobility).
 --B_3381257150_3065243-- From jouni.nospam@gmail.com Tue Feb 22 22:58:42 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A435F3A67DB for ; Tue, 22 Feb 2011 22:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.379 X-Spam-Level: X-Spam-Status: No, score=-3.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMMFyumJfeUZ for ; Tue, 22 Feb 2011 22:58:40 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 2F4BB3A683A for ; Tue, 22 Feb 2011 22:58:39 -0800 (PST) Received: by ewy9 with SMTP id 9so902721ewy.31 for ; Tue, 22 Feb 2011 22:59:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=k1aEwRWMbnUM+hQutJq2JOY//P+usOrZRqS6LQ3LuuE=; b=X0pee6wpMxYLyM1GL/f9sj22AUTnIyrxPQcA9ID1VtQ4gR9WzyV4t3yLqPNvIkRPmW dY7ClXXk+w4v3Hqcd2TFQW1wWh7sI/VriSAIvuczzqldRFqb6afITcVznrQezeT7oxXy wZ+KCLH26/39Eqt02t1RnenKV6qEvlf0JznOQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=rONfYHrupzIC3HXHsdfOTosgkxRJ27jMlG7A4wBIV+2YXHudhpObk4Lr2Z5waTLzWS frjgRlqqQW7Cl7Oe2H/eJl49v1QeApSzqmMr4bfplDidE5WSrZjuPkuexe9wMHwzcWzq aB8nne1YiphS4IvAzMjaRiTxfoNV3jj0SJ/yU= Received: by 10.213.114.144 with SMTP id e16mr216753ebq.57.1298444364277; Tue, 22 Feb 2011 22:59:24 -0800 (PST) Received: from a88-114-170-183.elisa-laajakaista.fi (a88-114-170-183.elisa-laajakaista.fi [88.114.170.183]) by mx.google.com with ESMTPS id u1sm189314eeh.10.2011.02.22.22.59.22 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Feb 2011 22:59:23 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Wed, 23 Feb 2011 08:59:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <84631D62-D918-4E19-A292-178B2492AE92@gmail.com> References: To: Rajeev Koodli X-Mailer: Apple Mail (2.1078) Cc: netext@ietf.org Subject: Re: [netext] LMA Redirect ID X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 06:58:42 -0000 Rajeev, We have updated the draft based on these comments (see the recently = submitted -05) and the authors also think the draft is ready to move = forward. - Jouni On Dec 9, 2010, at 7:40 AM, Rajeev Koodli wrote: >=20 > Hi Jouni, All,=20 >=20 > Attached is the document with my review of the ID. > Please have a look. >=20 > Regards, >=20 > -Rajeev > = ___________________________________________= ____ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From trungtm2909@gmail.com Wed Feb 23 00:51:45 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA1433A680E for ; Wed, 23 Feb 2011 00:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=-0.747, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_28=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnbVJeCpeQhV for ; Wed, 23 Feb 2011 00:51:44 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id B16BD3A6809 for ; Wed, 23 Feb 2011 00:51:44 -0800 (PST) Received: by vxa40 with SMTP id 40so2102523vxa.31 for ; Wed, 23 Feb 2011 00:52:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wt2Ow1QEJMqsZwdKn7rVCIF2WduArZzCtKLO+dXLeVU=; b=q5ZTm+QVQk2qY4r3OM5ywJyJ2CnSB8K4KFEUjthaprqY06V08qYxGTaY0PQasCJRWu pOZMEryX/sIy+HUXAPuxiatocbpxhCdYikd6NMRZxo9Q19JQgSOQ2o0ixmRLAMBTFHNb 3JJ5vVgp0qvOGnOqqX6wH1hF80HZ9P7viyuZs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=S82Ju4vN2iSCbr+KJKDpiGLuxn9QqFvclR5rBzC/KzeVyI2qZp/COuPTiwdOoazI9k 1mevdEge6DutF+HjkJC7N8coJnwewbB0neNeRfSBhffC6L7Bc0yOA38Ijky26vsokWv/ dtveqgVEOD0GdiYINo2+6sUXGlna+UAmqbg6o= MIME-Version: 1.0 Received: by 10.52.157.7 with SMTP id wi7mr3739896vdb.59.1298451150769; Wed, 23 Feb 2011 00:52:30 -0800 (PST) Received: by 10.52.162.1 with HTTP; Wed, 23 Feb 2011 00:52:30 -0800 (PST) In-Reply-To: References: Date: Wed, 23 Feb 2011 17:52:30 +0900 Message-ID: From: Tran Minh Trung To: Rajeev Koodli Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 08:51:45 -0000 Hi Rajeev, Please see my inline comments. On Wed, Feb 23, 2011 at 3:05 PM, Rajeev Koodli wrote: > > Hello folks, > > I guess we all could agree that we have had plenty of discussion. > There are pros and cons of both L2 signaling and IP-based signaling > approaches. I would like to propose a way forward. > > 1) L2 signaling-based: > > MN attaches to a (new) MAGy > MN indicates using (extended) L2 signaling that the attachment is for flo= w > mobility with a new HI=3DFM value > MAGy sends the PBU, and the LMA updates an existing session with the new > interface and MAGy > The old and new prefixes are shared for the session If HI=3DFM then the LMA just adds the new interface to the existing session. No new prefixes are assigned. > There is new L2 signaling between the MN and the (old) MAGx to trigger th= e > PBU from MAGx. Since no new prefixes are assigned, we do not need a new L2 signaling here. > This covers the case where we assume that L2 signaling and the associated > extensions are feasible. Keeps the existing RFC 5213 model > > 2) IP-based: > > *If* the PBU from the new MAGy does not carry the new HI=3DFM value, the = LMA > creates a new session (modulo handover^) per RFC 5213. > In this case, the LMA adds the prefix to the session(s) if the policy > requires/allows the MN for flow mobility > The LMA signals the relevant MAGs to provide the prefix(es) when flow > mobility is required > This covers the case where L2 signaling extensions for flow mobility are = not > feasible or are not in place, or for any generic L2 technology > 2) will not come into play if 1) above is in place. As my comments in 1), we do not need new L2 signaling. The only thing we need is new value of HI to indicate that the new attach can support flow mobility. It is the same as hand-off indicator used in RFC5213. So I think that the basic L2 signaling, as used in RFC5213, is enough for the scenario that you described above. The IP-Based may be needed when a new virtual interface is activated on the fly (create new VPN connection or add new primary PDP contexts in UMTS). Let's consider the following scenario: (1) MN attached interface 1 (IF1) and Interface 2 (IF2) to the MAG1 and MAG2 respectively. - Session_A:[Prefixes_A | IF1,MAG1 | IF2,MAG2 ] was created to manage both IF1 and IF2. (2) A new virtual interface (eg. ppp) is created for a new VPN connection via the physical interface IF1. - A new IPv4 address/IPv6 prefix is assigned to the VPN interface ppp. - Session_N{Prefix_N | PPP,MAG1 } is created to manage the virtual interfac= e ppp To allow VPN flows can be moved across physical interfaces, we need to add IF1, IF2 to Session_N. Is that right? In this scenario I would rather follow IP-Based approach than rely on a new L2 signaling message. I hope that my description is clear enough. Regards, TrungTM > > Comments? > > -Rajeev > > ^ HI=3DHandover will be similar to 1) above except that the forwarding st= ate > for Proxy-CoA-MAGx is removed (and hence no flow mobility). > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 From Marco.Liebsch@neclab.eu Wed Feb 23 01:50:52 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 999A03A67E7; Wed, 23 Feb 2011 01:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66VZ92G8pKuP; Wed, 23 Feb 2011 01:50:50 -0800 (PST) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id EB67F3A69C4; Wed, 23 Feb 2011 01:50:49 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 82B1F2800018B; Wed, 23 Feb 2011 10:52:52 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5kyQUtQFTLh; Wed, 23 Feb 2011 10:52:52 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 634282800018A; Wed, 23 Feb 2011 10:52:27 +0100 (CET) Received: from [10.1.6.32] (10.1.6.32) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 23 Feb 2011 10:51:11 +0100 Message-ID: <4D64D88E.6090202@neclab.eu> Date: Wed, 23 Feb 2011 10:51:10 +0100 From: Marco Liebsch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Xiangsong Cui References: <004001cbd2fb$4e9b3590$ebd1a0b0$%cui@huawei.com> In-Reply-To: <004001cbd2fb$4e9b3590$ebd1a0b0$%cui@huawei.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.6.32] Cc: netext@ietf.org, iesg-secretary@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Request to progress Netext WG I-D: draft-ietf-netext-pmip6-lr-ps-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 09:50:52 -0000 Hi Xiangsong, all your comments have been addressed in version 4 and 5. W.r.t. the remaining two paragraphs you refer to in msg-1483, let me clarify again by copying your last reply: Xiangsong wrote: >The first sentence of section 5, >Figure 2 shows PMIPv6 roaming cases where PMIPv6 components (e.g., LMAs, >MAGs) tied by MN and CN may be distributed between different provider >domains (i.e., domain A, B, C) and MN and/or CN moves from one provider >domain to another one. >Let me try to simplify this sentence, it is describing the roaming case >which is showed in Figure 2, >The front half of the subordinate clause says, "PMIPv6 components (e.g., >LMAs, MAGs) tied by MN and CN may be distributed between different provider >domains" does this mean MAGs may be in different provider domain? >The end half of the subordinate clause says, "MN and/or CN moves from one >provider domain to another one". Does the *or* means that the nodes may roam >one by one? So even MAGs are in same provider domain, it would be changed >when one node is roaming (to a new MAG in another provider domain). Marco: The first sentence you refer to in section 5 is related to general roaming use cases. So, both is possible, MN and/or CN move. This has nothing to do yet with localized routing. Only in the second sentence we indicate that NetExt covers only use cases for localized routing where both MAGs (MN's and CN's) share the same provider domain. This is also independent of their LMA's location Xiangsong wrote: >Do you mean MN and CN are roaming exactly simultaneously? From MAG1/MAG2 >pair to MAG1'/MAG2' pair? >In my impression, when MN (or CN) moves to a new provider domain, it would >lie in a different provider domain with CN (or MN), so the localized routing >should be released, right? >If you say they are exactly simultaneously roaming, supposed they are >registered in the same LMA, the LMA would receive PBU from MAG1' and MAG2' >respectively, I think here should be a single thread program, so it is >impossible for the LMA to receive exactly simultaneous message, do you mean >the LMA should hold one PBU for some time (not destroy localized routing >immediately although "different provider domain") and wait for the other PBU >(to continue the localized routing on new MAG pair)? This is of course >purely implementation issue, here my point is just to check the case. Marco: This is not about maintenance of localized routing when MN/CN step from a non-roaming into a roaming situation. It only mandates (according to NetExt scope and requirements) that both MAGs share the same provider domain in a steady state situation, which means localized routing is set up when MN and CN start a communication and both MAGs are within the same provider domain. Further, this section indicates that MN's as well as CN's LMA may be located in the same provider domain as the MN's/CN's MAG or in a different one (roaming). I hope that clarifies your concerns and we can proceed with version 5. Marco Am 23.02.2011 02:45, schrieb Xiangsong Cui: > Hi Raj, > > I'm not sure I have understood this well, because in my mind, there are some > comments not completely addressed, I mean > http://www.ietf.org/mail-archive/web/netext/current/msg01483.html. > Would you please check them, or make sure those comments are negligible? > If I was wrong, please let me know my mistake. > > Thanks, > Xiangsong > >> -----Original Message----- >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf > Of >> Basavaraj.Patil@nokia.com >> Sent: Wednesday, February 23, 2011 6:29 AM >> To: iesg-secretary@ietf.org; jari.arkko@piuha.net >> Cc: netext@ietf.org >> Subject: [netext] Request to progress Netext WG I-D: >> draft-ietf-netext-pmip6-lr-ps-05.txt >> >> >> Hello, >> >> The Netext WG I-D mentioned below is ready to be progressed to the >> IESG for review and approval. Attached is the document shepherd >> writeup for this I-D. >> >> I-D: PMIPv6 Localized Routing Problem Statement >> >> >> -Raj >> >> >> (1.a) Who is the Document Shepherd for this document? Has the >> Document Shepherd personally reviewed this version of the >> document and, in particular, does he or she believe this >> version is ready for forwarding to the IESG for publication? >> >> Document shepherd: Basavaraj Patil >> Yes, I have reviewed this version of the document and believe it is >> ready for IESG review and publication. >> >> (1.b) Has the document had adequate review both from key WG members >> and from key non-WG members? Does the Document Shepherd have >> any concerns about the depth or breadth of the reviews that >> have been performed? >> >> The document has had adequate reviews by key WG members. >> I do not have any concerns regarding the depth or breadth of the >> reviews received. >> >> (1.c) Does the Document Shepherd have concerns that the document >> needs more review from a particular or broader perspective, >> e.g., security, operational complexity, someone familiar with >> AAA, internationalization or XML? >> >> No concerns regarding the reviews so far and do not believe additional >> reviews are needed. >> >> (1.d) Does the Document Shepherd have any specific concerns or >> issues with this document that the Responsible Area Director >> and/or the IESG should be aware of? For example, perhaps he >> or she is uncomfortable with certain parts of the document, or >> has concerns whether there really is a need for it. In any >> event, if the WG has discussed those issues and has indicated >> that it still wishes to advance the document, detail those >> concerns here. Has an IPR disclosure related to this document >> been filed? If so, please include a reference to the >> disclosure and summarize the WG discussion and conclusion on >> this issue. >> >> I do not have any specific concerns at this time regarding this >> document. The problem statement has been presented and discussed at >> length in previous WG meetings and on the mailing list. I am not aware >> of any IPR disclosures related to this I-D. >> >> >> (1.e) How solid is the WG consensus behind this document? Does it >> represent the strong concurrence of a few individuals, with >> others being silent, or does the WG as a whole understand and >> agree with it? >> >> There is solid WG consensus behind this document. I believe the >> majority of WG members understand and agree with the document. >> >> (1.f) Has anyone threatened an appeal or otherwise indicated extreme >> discontent? If so, please summarise the areas of conflict in >> separate email messages to the Responsible Area Director. (It >> should be in a separate email because this questionnaire is >> entered into the ID Tracker.) >> >> No threats of appeal or extreme discontent have been expressed >> regarding this I-D. >> >> >> (1.g) Has the Document Shepherd personally verified that the >> document satisfies all ID nits? (See the Internet-Drafts Checklist >> and http://tools.ietf.org/tools/idnits/). Boilerplate checks are >> not enough; this check needs to be thorough. Has the document >> met all formal review criteria it needs to, such as the MIB >> Doctor, media type and URI type reviews? >> >> Yes. I have run the I-D through the ID nits tool and found no issues. >> >> >> (1.h) Has the document split its references into normative and >> informative? Are there normative references to documents that >> are not ready for advancement or are otherwise in an unclear >> state? If such normative references exist, what is the >> strategy for their completion? Are there normative references >> that are downward references, as described in [RFC3967]? If >> so, list these downward references to support the Area >> Director in the Last Call procedure for them [RFC3967]. >> >> References are split into normative and informative sections. >> >> >> (1.i) Has the Document Shepherd verified that the document IANA >> consideration section exists and is consistent with the body >> of the document? If the document specifies protocol >> extensions, are reservations requested in appropriate IANA >> registries? Are the IANA registries clearly identified? If >> the document creates a new registry, does it define the >> proposed initial contents of the registry and an allocation >> procedure for future registrations? Does it suggest a >> reasonable name for the new registry? See [RFC5226]. If the >> document describes an Expert Review process has Shepherd >> conferred with the Responsible Area Director so that the IESG >> can appoint the needed Expert during the IESG Evaluation? >> >> This document does not require any IANA action. It is a problem state >> description. >> >> >> (1.j) Has the Document Shepherd verified that sections of the >> document that are written in a formal language, such as XML >> code, BNF rules, MIB definitions, etc., validate correctly in >> an automated checker? >> >> Not applicable. >> >> >> (1.k) The IESG approval announcement includes a Document >> Announcement Write-Up. Please provide such a Document >> Announcement Write-Up? Recent examples can be found in the >> "Action" announcements for approved documents. The approval >> announcement contains the following sections: >> >> Proxy Mobile IPv6 is the IETF standard for network-based mobility >> management. In Proxy Mobile IPv6, mobile nodes are topologically >> anchored at a Local Mobility Anchor, which forwards all data >> for registered mobile nodes. The setup and maintenance of localized >> routing, which allows forwarding of data packets between mobile nodes >> and correspondent nodes directly without involvement of the Local >> Mobility Anchor in forwarding, is not considered. This document >> describes the problem space of localized routing in Proxy Mobile >> IPv6. >> >> There is strong WG consensus regarding the problem statement and the >> need for a solution to deal with localized routing. >> The document describes the localized routing problem in Proxy Mobile >> IPv6 deployments and hence not relevant from an implementation >> perspective. >> >> _______________________________________________ >> 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 Basavaraj.Patil@nokia.com Wed Feb 23 07:44:55 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D88A13A689A for ; Wed, 23 Feb 2011 07:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.124 X-Spam-Level: X-Spam-Status: No, score=-103.124 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMn4tz2cODOt for ; Wed, 23 Feb 2011 07:44:54 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 5EAE93A6845 for ; Wed, 23 Feb 2011 07:44:54 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1NFiTK5011324; Wed, 23 Feb 2011 17:45:37 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Feb 2011 17:45:14 +0200 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 23 Feb 2011 16:45:13 +0100 Received: from 008-AM1MPN1-005.mgdnok.nokia.com ([169.254.4.2]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0270.002; Wed, 23 Feb 2011 16:45:13 +0100 From: To: Thread-Topic: [netext] Request to progress Netext WG I-D: draft-ietf-netext-pmip6-lr-ps-05.txt Thread-Index: AQHL0t/ms6y4eVDDAUG4DRjKd/ye0JQOTjawgAB4AIA= Date: Wed, 23 Feb 2011 15:45:13 +0000 Message-ID: In-Reply-To: <004001cbd2fb$4e9b3590$ebd1a0b0$%cui@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [172.19.59.21] Content-Type: text/plain; charset="us-ascii" Content-ID: <9250AD9A9A4EBB42871476ECDB1BD702@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Feb 2011 15:45:14.0528 (UTC) FILETIME=[A997B200:01CBD370] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] Request to progress Netext WG I-D: draft-ietf-netext-pmip6-lr-ps-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 15:44:55 -0000 Hi Xiansong, IMO your comments have been addressed in this revision of the I-D. Marco has provided the details in another email. It should be noted that the scope of the problem statement includes aspects which will not be considered in the solution space itself. It is simply considering all aspects of localized routing. -Raj On 2/22/11 7:45 PM, "ext Xiangsong Cui" wrote: >Hi Raj, > >I'm not sure I have understood this well, because in my mind, there are >some >comments not completely addressed, I mean >http://www.ietf.org/mail-archive/web/netext/current/msg01483.html. >Would you please check them, or make sure those comments are negligible? >If I was wrong, please let me know my mistake. > >Thanks, >Xiangsong > >> -----Original Message----- >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf >Of >> Basavaraj.Patil@nokia.com >> Sent: Wednesday, February 23, 2011 6:29 AM >> To: iesg-secretary@ietf.org; jari.arkko@piuha.net >> Cc: netext@ietf.org >> Subject: [netext] Request to progress Netext WG I-D: >> draft-ietf-netext-pmip6-lr-ps-05.txt >>=20 >>=20 >> Hello, >>=20 >> The Netext WG I-D mentioned below is ready to be progressed to the >> IESG for review and approval. Attached is the document shepherd >> writeup for this I-D. >>=20 >> I-D: PMIPv6 Localized Routing Problem Statement >> >>=20 >> -Raj >>=20 >>=20 >> (1.a) Who is the Document Shepherd for this document? Has the >> Document Shepherd personally reviewed this version of the >> document and, in particular, does he or she believe this >> version is ready for forwarding to the IESG for publication? >>=20 >> Document shepherd: Basavaraj Patil >> Yes, I have reviewed this version of the document and believe it is >> ready for IESG review and publication. >>=20 >> (1.b) Has the document had adequate review both from key WG members >> and from key non-WG members? Does the Document Shepherd have >> any concerns about the depth or breadth of the reviews that >> have been performed? >>=20 >> The document has had adequate reviews by key WG members. >> I do not have any concerns regarding the depth or breadth of the >> reviews received. >>=20 >> (1.c) Does the Document Shepherd have concerns that the document >> needs more review from a particular or broader perspective, >> e.g., security, operational complexity, someone familiar with >> AAA, internationalization or XML? >>=20 >> No concerns regarding the reviews so far and do not believe additional >> reviews are needed. >>=20 >> (1.d) Does the Document Shepherd have any specific concerns or >> issues with this document that the Responsible Area Director >> and/or the IESG should be aware of? For example, perhaps he >> or she is uncomfortable with certain parts of the document, or >> has concerns whether there really is a need for it. In any >> event, if the WG has discussed those issues and has indicated >> that it still wishes to advance the document, detail those >> concerns here. Has an IPR disclosure related to this document >> been filed? If so, please include a reference to the >> disclosure and summarize the WG discussion and conclusion on >> this issue. >>=20 >> I do not have any specific concerns at this time regarding this >> document. The problem statement has been presented and discussed at >> length in previous WG meetings and on the mailing list. I am not aware >> of any IPR disclosures related to this I-D. >>=20 >>=20 >> (1.e) How solid is the WG consensus behind this document? Does it >> represent the strong concurrence of a few individuals, with >> others being silent, or does the WG as a whole understand and >> agree with it? >>=20 >> There is solid WG consensus behind this document. I believe the >> majority of WG members understand and agree with the document. >>=20 >> (1.f) Has anyone threatened an appeal or otherwise indicated extreme >> discontent? If so, please summarise the areas of conflict in >> separate email messages to the Responsible Area Director. (It >> should be in a separate email because this questionnaire is >> entered into the ID Tracker.) >>=20 >> No threats of appeal or extreme discontent have been expressed >> regarding this I-D. >>=20 >>=20 >> (1.g) Has the Document Shepherd personally verified that the >> document satisfies all ID nits? (See the Internet-Drafts >>Checklist >> and http://tools.ietf.org/tools/idnits/). Boilerplate checks are >> not enough; this check needs to be thorough. Has the document >> met all formal review criteria it needs to, such as the MIB >> Doctor, media type and URI type reviews? >>=20 >> Yes. I have run the I-D through the ID nits tool and found no issues. >>=20 >>=20 >> (1.h) Has the document split its references into normative and >> informative? Are there normative references to documents that >> are not ready for advancement or are otherwise in an unclear >> state? If such normative references exist, what is the >> strategy for their completion? Are there normative references >> that are downward references, as described in [RFC3967]? If >> so, list these downward references to support the Area >> Director in the Last Call procedure for them [RFC3967]. >>=20 >> References are split into normative and informative sections. >>=20 >>=20 >> (1.i) Has the Document Shepherd verified that the document IANA >> consideration section exists and is consistent with the body >> of the document? If the document specifies protocol >> extensions, are reservations requested in appropriate IANA >> registries? Are the IANA registries clearly identified? If >> the document creates a new registry, does it define the >> proposed initial contents of the registry and an allocation >> procedure for future registrations? Does it suggest a >> reasonable name for the new registry? See [RFC5226]. If the >> document describes an Expert Review process has Shepherd >> conferred with the Responsible Area Director so that the IESG >> can appoint the needed Expert during the IESG Evaluation? >>=20 >> This document does not require any IANA action. It is a problem state >> description. >>=20 >>=20 >> (1.j) Has the Document Shepherd verified that sections of the >> document that are written in a formal language, such as XML >> code, BNF rules, MIB definitions, etc., validate correctly in >> an automated checker? >>=20 >> Not applicable. >>=20 >>=20 >> (1.k) The IESG approval announcement includes a Document >> Announcement Write-Up. Please provide such a Document >> Announcement Write-Up? Recent examples can be found in the >> "Action" announcements for approved documents. The approval >> announcement contains the following sections: >>=20 >> Proxy Mobile IPv6 is the IETF standard for network-based mobility >> management. In Proxy Mobile IPv6, mobile nodes are topologically >> anchored at a Local Mobility Anchor, which forwards all data >> for registered mobile nodes. The setup and maintenance of localized >> routing, which allows forwarding of data packets between mobile nodes >> and correspondent nodes directly without involvement of the Local >> Mobility Anchor in forwarding, is not considered. This document >> describes the problem space of localized routing in Proxy Mobile >> IPv6. >>=20 >> There is strong WG consensus regarding the problem statement and the >> need for a solution to deal with localized routing. >> The document describes the localized routing problem in Proxy Mobile >> IPv6 deployments and hence not relevant from an implementation >> perspective. >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > From telemaco.melia@alcatel-lucent.com Wed Feb 23 13:13:37 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B69E53A68E7 for ; Wed, 23 Feb 2011 13:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.118 X-Spam-Level: X-Spam-Status: No, score=-5.118 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_28=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8++0dY0GknM for ; Wed, 23 Feb 2011 13:13:36 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 5FE2C3A68F6 for ; Wed, 23 Feb 2011 13:13:35 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p1NLDxwo010463 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 23 Feb 2011 22:13:59 +0100 Received: from FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com ([135.120.45.54]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 23 Feb 2011 22:13:59 +0100 From: "MELIA, TELEMACO (TELEMACO)" To: Rajeev Koodli , "netext@ietf.org" Date: Wed, 23 Feb 2011 22:13:57 +0100 Thread-Topic: Flow Mobility discussion - way forward? Thread-Index: AcvTH7hRFKVN0Kr67UiTaBIlg8gywgAfpgWw Message-ID: <3D6C64F2D792B540BAAEBCEF6509363B0EE6DD1072@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3D6C64F2D792B540BAAEBCEF6509363B0EE6DD1072FRMRSSXCHMBSE_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 21:13:37 -0000 --_000_3D6C64F2D792B540BAAEBCEF6509363B0EE6DD1072FRMRSSXCHMBSE_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It captures very well the discussions so far. Agree and support. telemaco ________________________________ De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part de= Rajeev Koodli Envoy=E9 : mercredi 23 f=E9vrier 2011 07:06 =C0 : netext@ietf.org Objet : [netext] Flow Mobility discussion - way forward? Hello folks, I guess we all could agree that we have had plenty of discussion. There are pros and cons of both L2 signaling and IP-based signaling approac= hes. I would like to propose a way forward. 1) L2 signaling-based: 1. MN attaches to a (new) MAGy 2. MN indicates using (extended) L2 signaling that the attachment is for = flow mobility with a new HI=3DFM value 3. MAGy sends the PBU, and the LMA updates an existing session with the n= ew interface and MAGy 4. The old and new prefixes are shared for the session 5. There is new L2 signaling between the MN and the (old) MAGx to trigger= the PBU from MAGx. 6. This covers the case where we assume that L2 signaling and the associa= ted extensions are feasible. Keeps the existing RFC 5213 model 2) IP-based: 1. *If* the PBU from the new MAGy does not carry the new HI=3DFM value, t= he LMA creates a new session (modulo handover^) per RFC 5213. 2. In this case, the LMA adds the prefix to the session(s) if the policy = requires/allows the MN for flow mobility 3. The LMA signals the relevant MAGs to provide the prefix(es) when flow = mobility is required 4. This covers the case where L2 signaling extensions for flow mobility a= re not feasible or are not in place, or for any generic L2 technology 5. 2) will not come into play if 1) above is in place. Comments? -Rajeev ^ HI=3DHandover will be similar to 1) above except that the forwarding stat= e for Proxy-CoA-MAGx is removed (and hence no flow mobility). --_000_3D6C64F2D792B540BAAEBCEF6509363B0EE6DD1072FRMRSSXCHMBSE_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Flow Mobility discussion - way forward?

It captures= very well the discussions so far. Agree and support.

 =

telemaco

 =

De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part de Rajeev Koodli
Envoyé : mercred= i 23 février 2011 07:06
À : netext@ietf.= org
Objet : [netext] Flow Mobility discussion - way forward?

 


Hello folks,

I guess we all could agree that we have had plenty of discussion.
There are pros and cons of both L2 signaling and IP-based signaling approac= hes. I would like to propose a way forward.

1) L2 signaling-based:

  1. MN attaches to a (new) MAGy =
  2. MN indicates using (extended) L2 signaling that the attachment is for flow mobility with a new HI=3DFM value
  3. MAGy sends the PBU, and the LMA updates an existing session with the new interface and MAGy
  4. The old and new prefixes are shared for th= e session
  5. There is new L2 signaling between the MN a= nd the (old) MAGx to trigger the PBU from MAGx. =
  6. This covers the case where we assume that = L2 signaling and the associated extensions are feasible. Keeps the existi= ng RFC 5213 model


2) IP-based:

  1. *If* the PBU from the new MAGy does not ca= rry the new HI=3DFM value, the LMA creates a new session (modulo handover^= ) per RFC 5213.
  2. In this case, the LMA adds the prefix to t= he session(s) if the policy requires/allows the MN for flow mobility
  3. The LMA signals the relevant MAGs to provi= de the prefix(es) when flow mobility is required
  4. This covers the case where L2 signaling extensions for flow mobility are not feasible or are not in place, or = for any generic L2 technology
  5. 2) will not come into play if 1) above is = in place.


Comments?

-Rajeev

^ HI=3DHandover will be similar to 1) above except that the forwarding stat= e for Proxy-CoA-MAGx is removed (and hence no flow mobility).<= /o:p>

--_000_3D6C64F2D792B540BAAEBCEF6509363B0EE6DD1072FRMRSSXCHMBSE_-- From julien.ietf@gmail.com Wed Feb 23 13:44:29 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 029D53A67F1 for ; Wed, 23 Feb 2011 13:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.214 X-Spam-Level: X-Spam-Status: No, score=-3.214 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMkF8Y2KBw09 for ; Wed, 23 Feb 2011 13:44:28 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 104693A697F for ; Wed, 23 Feb 2011 13:44:26 -0800 (PST) Received: by fxm15 with SMTP id 15so5392730fxm.31 for ; Wed, 23 Feb 2011 13:45:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vCTgLFb4XK0q4xLM/5goxNGbcdyynhj6UIHSf33qr0k=; b=Y69ARxeDLnMcOtQq4kD0wP5JVChANVVJkkE2nZXFGIuCSD/DrrnsN/AOLehqDvFW+O VQ8HzpBk94rGzrp+yDynVMpUp7vUAAQV1eTjxL6cokYWU6CUP1WRA8HY0sprPO4Cg+Hv hFGDkTikzJQtahJOY6UIHTRpK3aVvSsCXEriM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Z0apmIa5nBBOtFhP9tyt8iOshPJWW3DlA9AAc2iEIkpaKizNPVs30vQJBBu3ybC4Uj L6LnEuHxhSrpL44P077SOxzvf/kHAsyJF12qhURXHfF5prI5YefXB4RbEksMFtSwcZvO 9KyELiQWSZeIgstCRYhWaxBdLuyy3u6/v3b4o= MIME-Version: 1.0 Received: by 10.223.100.16 with SMTP id w16mr17694fan.85.1298497411073; Wed, 23 Feb 2011 13:43:31 -0800 (PST) Received: by 10.223.74.142 with HTTP; Wed, 23 Feb 2011 13:43:31 -0800 (PST) In-Reply-To: References: Date: Wed, 23 Feb 2011 14:43:31 -0700 Message-ID: From: Julien Laganier To: Rajeev Koodli Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 21:44:29 -0000 Forgot to mention one thing below: On Tue, Feb 22, 2011 at 11:05 PM, Rajeev Koodli wrote: > > Hello folks, > > I guess we all could agree that we have had plenty of discussion. and I hope we can agree we' ve had a lot of valid questions in alternative 2) that went unanswered. > There are pros and cons of both L2 signaling and IP-based signaling > approaches. I would like to propose a way forward. A way forward would be for the questions that were left unanswered to be answered... Thanks, --julien From julien.ietf@gmail.com Wed Feb 23 13:45:27 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5F403A67F1 for ; Wed, 23 Feb 2011 13:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.919 X-Spam-Level: X-Spam-Status: No, score=-2.919 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JA29fgow25dC for ; Wed, 23 Feb 2011 13:45:26 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 7D4153A6912 for ; Wed, 23 Feb 2011 13:45:26 -0800 (PST) Received: by fxm15 with SMTP id 15so5393642fxm.31 for ; Wed, 23 Feb 2011 13:46:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mNrlVYgZsBxIVRxaJg/23/wraygLb6KVYAMF87MDMl8=; b=UkYni3RoS7RHmPyjhBNpGgsbJrAVVfd4ejZna2bvf+IPK20HD+k7Iz+y6VCzbQ9RYg KDhx2/T3pz5EjkxUo7ZvKUTsm0+g1J9DlgTH2WyDVVGUYEE1qDga1ac6lz0UDUAcwGGS sTkQSGLU9gQ7o3Zl7y2ruVgylRooyhqZcHTE4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ePHVDrjJ5HQQ5v32aqKMCBV6hPjtrvZI4nz+x+NLPHswx2NIOE8LCeJu953D+DArvy EDy+tOIukf9mqmdjlWAhdgbWm8sIp6eqZBqsz2xy/yvTq/0ffvSVbIsFED48JhQ2HaEu +s85Q03db3dcWQvrElAlQiktDcN/8U8cjv0a0= MIME-Version: 1.0 Received: by 10.223.62.12 with SMTP id v12mr39224fah.9.1298497245472; Wed, 23 Feb 2011 13:40:45 -0800 (PST) Received: by 10.223.74.142 with HTTP; Wed, 23 Feb 2011 13:40:45 -0800 (PST) In-Reply-To: References: Date: Wed, 23 Feb 2011 14:40:45 -0700 Message-ID: From: Julien Laganier To: Rajeev Koodli Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 21:45:27 -0000 Hi Rajeev - On Tue, Feb 22, 2011 at 11:05 PM, Rajeev Koodli wrote: > > Hello folks, > > I guess we all could agree that we have had plenty of discussion. > There are pros and cons of both L2 signaling and IP-based signaling > approaches. I would like to propose a way forward. > > 1) L2 signaling-based: > > MN attaches to a (new) MAGy > MN indicates using (extended) L2 signaling that the attachment is for flow > mobility with a new HI=FM value > MAGy sends the PBU, and the LMA updates an existing session with the new > interface and MAGy > The old and new prefixes are shared for the session There are no such thing as old and new prefixes in what I've been advocating. We stick to 5213 model where the prefix _set_ is allocated to a session when that session is first created. > There is new L2 signaling between the MN and the (old) MAGx to trigger the > PBU from MAGx. This is not needed. MAGx doesn't need to send a PBU since MAGx was already registered for that session. > This covers the case where we assume that L2 signaling and the associated > extensions are feasible. Keeps the existing RFC 5213 model The L2 signaling is a prerequisite to use PMIPv6 as per 5213 anyway. There are no systems that can use PMIPv6 ala 5213 w/o the appropriate L2 signal to trigger sending a PBU at initial attach and handoff. > 2) IP-based: > > *If* the PBU from the new MAGy does not carry the new HI=FM value, the LMA > creates a new session (modulo handover^) per RFC 5213. If the PBY doesn't carry the new HI=FM value, it's because the network does not know whether or not the MN supports the flow mobility, in which case a new session is to be created as per RFC 5213, to avoid breaking a legacy host. > In this case, the LMA adds the prefix to the session(s) if the policy > requires/allows the MN for flow mobility In this case we are in pure 5213 model and the LMA shouldn't be doing anything special because it risks breaking a legacy host. This is similar to what happens in 5213 and the same host attaching via two different interfaces but the HI being set to unknown: two separate sessions are maintained for each interface, to avoid breaking legacy host. We cannot depart from this. > The LMA signals the relevant MAGs to provide the prefix(es) when flow > mobility is required No as this would break a legacy host. > This covers the case where L2 signaling extensions for flow mobility are not > feasible or are not in place, or for any generic L2 technology There are no such cases since 5213 requires L2 signaling already. > 2) will not come into play if 1) above is in place. True, thus 2) never comes into play since 5213 requires 1) already. > Comments? As above. Thanks, --julien From rkoodli@cisco.com Wed Feb 23 14:14:51 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 963063A67FC for ; Wed, 23 Feb 2011 14:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.932 X-Spam-Level: X-Spam-Status: No, score=-107.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4aKXiFeTqs1 for ; Wed, 23 Feb 2011 14:14:50 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2ED163A695C for ; Wed, 23 Feb 2011 14:14:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rkoodli@cisco.com; l=3220; q=dns/txt; s=iport; t=1298499338; x=1299708938; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=rnCwMxiVEDmgAEmBzdA/27Z8wdwoC2khwHwEYshzVsc=; b=JeFthmvWn1ZsThsT/HifWRRwy0o6L041DYSKlqJatI5zRU5iMXsD+JXs XsK1P/doDpXueuJmqpHQ9HOBI39mmLdCiTvKZ+D9OucLvNND4flsIcfK0 eebwu80rnopfD/b0E1oywB5tZQfMv6lycjd6svucky8QGqzjIjQmZErfm g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0FAHcVZU2tJV2b/2dsb2JhbACmHQJzoGObbYVeBIUNhwmDQYMKghs X-IronPort-AV: E=Sophos;i="4.62,214,1297036800"; d="scan'208";a="218838266" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-1.cisco.com with ESMTP; 23 Feb 2011 22:15:34 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p1NMFYbO024767; Wed, 23 Feb 2011 22:15:34 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Feb 2011 16:15:34 -0600 Received: from 171.70.249.7 ([171.70.249.7]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Wed, 23 Feb 2011 22:15:33 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Wed, 23 Feb 2011 14:15:56 -0800 From: Rajeev Koodli To: Tran Minh Trung Message-ID: Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvTpz3MPrHhliptPUqXtPoxnKbMIw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 23 Feb 2011 22:15:34.0528 (UTC) FILETIME=[31001800:01CBD3A7] Cc: netext@ietf.org Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 22:14:51 -0000 Hi Trung, On 2/23/11 12:52 AM, "Tran Minh Trung" wrote: > > If HI=FM then the LMA just adds the new interface to the existing > session. No new prefixes are assigned. > We have two cases here, right? A) the new attachment gets the exact same prefix(es) as the previous one, and B) the new attachment gets one or more new prefix(es) - per RFC 5213, any attachment can get multiple prefixes which may or may not be the same as previously assigned ones. So, agree with you on A). We need to also include B). >> There is new L2 signaling between the MN and the (old) MAGx to trigger the >> PBU from MAGx. > > Since no new prefixes are assigned, we do not need a new L2 signaling here. > I think you do, for B) above. Regards, -Rajeev >> This covers the case where we assume that L2 signaling and the associated >> extensions are feasible. Keeps the existing RFC 5213 model >> >> 2) IP-based: >> >> *If* the PBU from the new MAGy does not carry the new HI=FM value, the LMA >> creates a new session (modulo handover^) per RFC 5213. >> In this case, the LMA adds the prefix to the session(s) if the policy >> requires/allows the MN for flow mobility >> The LMA signals the relevant MAGs to provide the prefix(es) when flow >> mobility is required >> This covers the case where L2 signaling extensions for flow mobility are not >> feasible or are not in place, or for any generic L2 technology >> 2) will not come into play if 1) above is in place. > > As my comments in 1), we do not need new L2 signaling. > The only thing we need is new value of HI to indicate that the new > attach can support flow mobility. > It is the same as hand-off indicator used in RFC5213. > So I think that the basic L2 signaling, as used in RFC5213, is enough > for the scenario that you described above. > > The IP-Based may be needed when a new virtual interface is activated > on the fly (create new VPN connection or add new primary PDP contexts > in UMTS). > > Let's consider the following scenario: > > (1) MN attached interface 1 (IF1) and Interface 2 (IF2) to the MAG1 > and MAG2 respectively. > - Session_A:[Prefixes_A | IF1,MAG1 | IF2,MAG2 ] was created to manage > both IF1 and IF2. > (2) A new virtual interface (eg. ppp) is created for a new VPN > connection via the physical interface IF1. > - A new IPv4 address/IPv6 prefix is assigned to the VPN interface ppp. > - Session_N{Prefix_N | PPP,MAG1 } is created to manage the virtual interface > ppp > > To allow VPN flows can be moved across physical interfaces, we need to > add IF1, IF2 to Session_N. > Is that right? > > In this scenario I would rather follow IP-Based approach than rely on > a new L2 signaling message. > > I hope that my description is clear enough. > > Regards, > TrungTM > >> >> Comments? >> >> -Rajeev >> >> ^ HI=Handover will be similar to 1) above except that the forwarding state >> for Proxy-CoA-MAGx is removed (and hence no flow mobility). >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> >> > > From rkoodli@cisco.com Wed Feb 23 14:35:04 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4DAA3A68FD for ; Wed, 23 Feb 2011 14:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.632 X-Spam-Level: X-Spam-Status: No, score=-107.632 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qs6G-C08Y3qT for ; Wed, 23 Feb 2011 14:35:02 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 3DE053A68EE for ; Wed, 23 Feb 2011 14:35:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rkoodli@cisco.com; l=4336; q=dns/txt; s=iport; t=1298500550; x=1299710150; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=CuTX/HlqeO1+zuZQz4sYWw3Qy4su55nNEx5PYr0Bn24=; b=iX3hZRnHUsdeslJwofA/R3MuXJf+DGfoHbLQdRPRONh1hiP9XOE8u3A4 N2fjjpSknJ/KBahAyCp/Xv1/FMgS8cdPrTVUGMS5IrPSbYmaD7B2TrFvT G0R2xeiCUjjUzy35zCKHSapi7LDbDxVeV0EBwUsAdKMd2gFSAZjBrOE5e M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0FACcaZU2tJV2a/2dsb2JhbACmHQJzoF2baYVeBIUNhwmDQYMKghs X-IronPort-AV: E=Sophos;i="4.62,214,1297036800"; d="scan'208";a="218844287" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 23 Feb 2011 22:35:49 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p1NMZnMO005679; Wed, 23 Feb 2011 22:35:49 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Feb 2011 16:35:49 -0600 Received: from 171.70.249.7 ([171.70.249.7]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Wed, 23 Feb 2011 22:35:49 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Wed, 23 Feb 2011 14:36:11 -0800 From: Rajeev Koodli To: Julien Laganier Message-ID: Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvTqhH+hrB1IuqrM0aeLDOtiLCR6Q== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 23 Feb 2011 22:35:49.0635 (UTC) FILETIME=[0542B530:01CBD3AA] Cc: netext@ietf.org Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 22:35:05 -0000 Hi Julien, I am catching up after a travel break. So, pardon me if I have missed something. On 2/23/11 1:40 PM, "Julien Laganier" wrote: >> 1) L2 signaling-based: >> >> MN attaches to a (new) MAGy >> MN indicates using (extended) L2 signaling that the attachment is for flow >> mobility with a new HI=FM value >> MAGy sends the PBU, and the LMA updates an existing session with the new >> interface and MAGy >> The old and new prefixes are shared for the session > > There are no such thing as old and new prefixes in what I've been > advocating. We stick to 5213 model where the prefix _set_ is allocated > to a session when that session is first created. > I understand your model, I think. You pre-assign a set and stick with it. No new prefixes are ever-assigned on an attach. This IMO is a bit restrictive. I don't think 5213 prohibits you from assigning a new prefix on attach which is not (yet) assigned to a session. My point is that you could do what you are suggesting (i.e., pre-assign all the forseable prefixes beforehand) *and* do what I am suggesting (i.e., freely assign a prefix of my choice on attach). >> There is new L2 signaling between the MN and the (old) MAGx to trigger the >> PBU from MAGx. > > This is not needed. MAGx doesn't need to send a PBU since MAGx was > already registered for that session. > If the LMA assigned a prefix which was not assigned before, you need it, right? >> This covers the case where we assume that L2 signaling and the associated >> extensions are feasible. Keeps the existing RFC 5213 model > > The L2 signaling is a prerequisite to use PMIPv6 as per 5213 anyway. > There are no systems that can use PMIPv6 ala 5213 w/o the appropriate > L2 signal to trigger sending a PBU at initial attach and handoff. > For what it is today, yes. That does not mean that we necessarily want to continue to rely on L2 extensions. If it's available, fine. But, we should also be able to support, e.g., IP which is within the jurisdiction of this WG and not dependent on other SDOs. >> 2) IP-based: >> >> *If* the PBU from the new MAGy does not carry the new HI=FM value, the LMA >> creates a new session (modulo handover^) per RFC 5213. > > If the PBY doesn't carry the new HI=FM value, it's because the network > does not know whether or not the MN supports the flow mobility, in > which case a new session is to be created as per RFC 5213, to avoid > breaking a legacy host. > I assume by network you mean the MAG. The LMA can know whether the MN supports flow mobility by other means, e.g., through AAA. See for instance: http://tools.ietf.org/html/draft-koodli-netext-multiaccess-indicator-01 >> In this case, the LMA adds the prefix to the session(s) if the policy >> requires/allows the MN for flow mobility > > In this case we are in pure 5213 model and the LMA shouldn't be doing > anything special because it risks breaking a legacy host. This is > similar to what happens in 5213 and the same host attaching via two > different interfaces but the HI being set to unknown: two separate > sessions are maintained for each interface, to avoid breaking legacy > host. We cannot depart from this. > See above regarding how the LMA might know whether the MN supports Logical Interface. >> The LMA signals the relevant MAGs to provide the prefix(es) when flow >> mobility is required > > No as this would break a legacy host. > Not if the LMA knows otherwise. >> This covers the case where L2 signaling extensions for flow mobility are not >> feasible or are not in place, or for any generic L2 technology > > There are no such cases since 5213 requires L2 signaling already. > Requiring L2 signaling to do what is expected today is not the same as continued reliance on it for anything else. I would like to be able to use IP. >> 2) will not come into play if 1) above is in place. > > True, thus 2) never comes into play since 5213 requires 1) already. > On a MN attach where HI=unknown, it does. It addresses this case without relying on all L2's to provide the necessary extensions for flow mobility signaling. >> Comments? > > As above. Thanks, -Rajeev > > Thanks, > > --julien From julien.ietf@gmail.com Wed Feb 23 15:29:22 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F18E3A6975 for ; Wed, 23 Feb 2011 15:29:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+u9G8IU-A4p for ; Wed, 23 Feb 2011 15:29:21 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id C3A563A695F for ; Wed, 23 Feb 2011 15:29:20 -0800 (PST) Received: by fxm15 with SMTP id 15so5490303fxm.31 for ; Wed, 23 Feb 2011 15:30:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tMkP8up4WMHWfsAU3pOZ0SKargoRbhA5ipbLn/iQIDI=; b=o0rPQheSwCAVZkK0//jlZf/bl3JHEo3VDXUlKJo1E0a6iR2/UQFj8jO5ZBbp7NHh/4 v4ODxPw3/WnbM7j14KBEXD0F6Zo32Aaf09Yr3B4PzpZ/RJjqn9uR4OG2NOAlCYJbDQcC iPuEG4FF8WzI/OQbqIZk/vnrjxoFZIuaeyvPs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=w/1fSXact7i8E0CHIAXHz52o5+ZoEThK56u2AZwZljCMVQ5P+HDE1Dj3rzMrZ3TsOs LxE7ol8c+rsCvSBwdvSC3PuAIaI7WSxLJg6MT2AQ00XGkVC0sgrqQgzh5l2/6rSppGvF kWv1rtyiUC0y1sK/KxveWSo0aFwswFSXd+VQ0= MIME-Version: 1.0 Received: by 10.223.62.12 with SMTP id v12mr137334fah.9.1298503426448; Wed, 23 Feb 2011 15:23:46 -0800 (PST) Received: by 10.223.74.142 with HTTP; Wed, 23 Feb 2011 15:23:46 -0800 (PST) In-Reply-To: References: Date: Wed, 23 Feb 2011 16:23:46 -0700 Message-ID: From: Julien Laganier To: Rajeev Koodli Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 23:29:22 -0000 Hi Rajeev, On Wed, Feb 23, 2011 at 3:36 PM, Rajeev Koodli wrote: > > Hi Julien, > > I am catching up after a travel break. So, pardon me if I have missed > something. > > > On 2/23/11 1:40 PM, "Julien Laganier" wrote: > >>> 1) L2 signaling-based: >>> >>> MN attaches to a (new) MAGy >>> MN indicates using (extended) L2 signaling that the attachment is for flow >>> mobility with a new HI=FM value >>> MAGy sends the PBU, and the LMA updates an existing session with the new >>> interface and MAGy >>> The old and new prefixes are shared for the session >> >> There are no such thing as old and new prefixes in what I've been >> advocating. We stick to 5213 model where the prefix _set_ is allocated >> to a session when that session is first created. >> > > I understand your model, I think. You pre-assign a set and stick with it. No > new prefixes are ever-assigned on an attach. This IMO is a bit restrictive. > I don't think 5213 prohibits you from assigning a new prefix on attach which > is not (yet) assigned to a session. In 5213 the prefix set is allocated once at session creation (i.e., first attach of an interface for that session) and remains unmodified throughout that session duration. I haven't seen anything that justifies departing from that model in the context of providing flow mobility. > My point is that you could do what you are suggesting (i.e., pre-assign all > the forseable prefixes beforehand) *and* do what I am suggesting (i.e., > freely assign a prefix of my choice on attach). It's not what I'm suggesting, it's what 5213 does, and flow mobility in itself ain't a reason to change that. >>> There is new L2 signaling between the MN and the (old) MAGx to trigger the >>> PBU from MAGx. >> >> This is not needed. MAGx doesn't need to send a PBU since MAGx was >> already registered for that session. >> > > If the LMA assigned a prefix which was not assigned before, you need it, > right? An LMA doesn't need to assign a prefix which wasn't assigned before to do flow mobility. So we don't need it. >>> This covers the case where we assume that L2 signaling and the associated >>> extensions are feasible. Keeps the existing RFC 5213 model >> >> The L2 signaling is a prerequisite to use PMIPv6 as per 5213 anyway. >> There are no systems that can use PMIPv6 ala 5213 w/o the appropriate >> L2 signal to trigger sending a PBU at initial attach and handoff. >> > > For what it is today, yes. That does not mean that we necessarily want to > continue to rely on L2 extensions. If it's available, fine. But, we should > also be able to support, e.g., IP which is within the jurisdiction of this > WG and not dependent on other SDOs. So right now PMIPv6 presuppose that MN-to-nework L2 signaling is there for the PMIPv6 protocol to work. Specifying a MN-to-network IP layer signaling has been put explicitely out of the jursiduction of this WG when it was rechartered thus I am surprised by your statement above. >>> 2) IP-based: >>> >>> *If* the PBU from the new MAGy does not carry the new HI=FM value, the LMA >>> creates a new session (modulo handover^) per RFC 5213. >> >> If the PBY doesn't carry the new HI=FM value, it's because the network >> does not know whether or not the MN supports the flow mobility, in >> which case a new session is to be created as per RFC 5213, to avoid >> breaking a legacy host. > > I assume by network you mean the MAG. The LMA can know whether the MN > supports flow mobility by other means, e.g., through AAA. See for instance: > > http://tools.ietf.org/html/draft-koodli-netext-multiaccess-indicator-01 I think whether or not AAA can really knows what are the capabilities of a network stack on a device is questionable, but let's skip on that for now: In 3GPP, the MAG in the ePDG has interfaces to AAA, so the MAG would know from AAA that that MN supports flow mobility, and MAG sets HI=FM. Goto 1) above. On the other hand in 3GPP the LMA has no interfaces with AAA, so what you describe in your draft isn't applicable there. >>> In this case, the LMA adds the prefix to the session(s) if the policy >>> requires/allows the MN for flow mobility >> >> In this case we are in pure 5213 model and the LMA shouldn't be doing >> anything special because it risks breaking a legacy host. This is >> similar to what happens in 5213 and the same host attaching via two >> different interfaces but the HI being set to unknown: two separate >> sessions are maintained for each interface, to avoid breaking legacy >> host. We cannot depart from this. > > See above regarding how the LMA might know whether the MN supports Logical > Interface. I saw. The LMA would know because it is told by the MAG who's told by AAA, and MAG would set HI=FM in PBU. Goto 1) :) >>> The LMA signals the relevant MAGs to provide the prefix(es) when flow >>> mobility is required >> >> No as this would break a legacy host. > > Not if the LMA knows otherwise. See above. >>> This covers the case where L2 signaling extensions for flow mobility are not >>> feasible or are not in place, or for any generic L2 technology >> >> There are no such cases since 5213 requires L2 signaling already. >> > > Requiring L2 signaling to do what is expected today is not the same as > continued reliance on it for anything else. I would like to be able to use > IP. Relying on L2 signaling that is required anyway makes entire sense. Doing something else brings no benefits in terms of that reliance on L2. >>> 2) will not come into play if 1) above is in place. >> >> True, thus 2) never comes into play since 5213 requires 1) already. > > On a MN attach where HI=unknown, it does. It addresses this case without > relying on all L2's to provide the necessary extensions for flow mobility > signaling. HI != unknown since AAA can tell MAG that HI = FM in your AAA-scenario. --julien From julien.ietf@gmail.com Wed Feb 23 15:37:54 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AE5F3A697D for ; Wed, 23 Feb 2011 15:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.917 X-Spam-Level: X-Spam-Status: No, score=-2.917 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8HhfFcFCXcf for ; Wed, 23 Feb 2011 15:37:53 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 6CE613A694E for ; Wed, 23 Feb 2011 15:37:53 -0800 (PST) Received: by fxm15 with SMTP id 15so5497886fxm.31 for ; Wed, 23 Feb 2011 15:38:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GC7zIngV085HEDKOOD3U9iQn9cfJNA5X3iBPgY2NH5M=; b=GBURE2MdU9w6hQY/f6JdkDWFdfdHK//RSYFkqA3xM0uEgr8ZWnRMeUqudD3+R+nwmu RXpP3sepwAeN1LVMfgFO3tEYCx+xJeiPnpR2V3XDrQwFdt4RoAi1UF7opHc6CL7D6Kwi 3f4gvzu/zOFCfXez8PzTJmpm/zIMwDBFTWRao= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=oU8nFhyS6XTLk691QIJQDfMb4rljvPT216tTkiuB1hSp9vCWP1N/2MbieNqTerwzC+ KfARbWYzH/5CHBExroSUXyEahKjbzhq4UZS6r/FCCP8sOrGdA2HALc7jVbiMLAvbq6Q+ pa1wZ9eiODI2RqN5++lQaOUonSAH+ozgDJgs4= MIME-Version: 1.0 Received: by 10.223.74.15 with SMTP id s15mr163189faj.28.1298504251973; Wed, 23 Feb 2011 15:37:31 -0800 (PST) Received: by 10.223.74.142 with HTTP; Wed, 23 Feb 2011 15:37:31 -0800 (PST) In-Reply-To: References: Date: Wed, 23 Feb 2011 16:37:31 -0700 Message-ID: From: Julien Laganier To: Rajeev Koodli Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 23:37:54 -0000 Hi Rajeev, I have a correction to make below on my earlier statement: On Wed, Feb 23, 2011 at 4:23 PM, Julien Laganier wrote: > > On Wed, Feb 23, 2011 at 3:36 PM, Rajeev Koodli wrote: >> >> >> On 2/23/11 1:40 PM, "Julien Laganier" wrote: >> >>>> >>>> 2) IP-based: >>>> >>>> *If* the PBU from the new MAGy does not carry the new HI=FM value, the LMA >>>> creates a new session (modulo handover^) per RFC 5213. >>> >>> If the PBY doesn't carry the new HI=FM value, it's because the network >>> does not know whether or not the MN supports the flow mobility, in >>> which case a new session is to be created as per RFC 5213, to avoid >>> breaking a legacy host. >> >> I assume by network you mean the MAG. The LMA can know whether the MN >> supports flow mobility by other means, e.g., through AAA. See for instance: >> >> http://tools.ietf.org/html/draft-koodli-netext-multiaccess-indicator-01 > > I think whether or not AAA can really knows what are the capabilities > of a network stack on a device is questionable, but let's skip on that > for now: > > In 3GPP, the MAG in the ePDG has interfaces to AAA, so the MAG would > know from AAA that that MN supports flow mobility, and MAG sets HI=FM. > Goto 1) above. On the other hand in 3GPP the LMA has no interfaces > with AAA, so what you describe in your draft isn't applicable there. Regarding 3GPP I made a wrong statement, sorry about that: The LMA indeed has an interface to AAA, but so has the MAG. So anything that the LMA can know thru AAA, the LMA can know as well. That being said, if we only assume 5213 and aren't specific to 3GPP, if a PMIPv6 deployment relies on AAA, the entity that would be required to be interfaced to a AAA system is the MAG, because it needs to authenticate the MNID and pull the policy profile. So in this AAA scenario it still holds that the MAG can know the MN's capability from AAA and set the HI = FM. Hope that clarifies my earlier statement. --julien From Xiangsong.Cui@huawei.com Wed Feb 23 18:40:19 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98ACA3A68C5; Wed, 23 Feb 2011 18:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dx+cJBci72b1; Wed, 23 Feb 2011 18:40:17 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id CACA43A67C2; Wed, 23 Feb 2011 18:40:16 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LH300IZIOS6J5@szxga03-in.huawei.com>; Thu, 24 Feb 2011 10:40:54 +0800 (CST) Received: from c00111037 ([10.111.16.128]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LH300B5DOS5NR@szxga03-in.huawei.com>; Thu, 24 Feb 2011 10:40:54 +0800 (CST) Date: Thu, 24 Feb 2011 10:40:54 +0800 From: Xiangsong Cui In-reply-to: <4D64D88E.6090202@neclab.eu> To: 'Marco Liebsch' Message-id: <006701cbd3cc$4251fe50$c6f5faf0$%cui@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcvTP2O+M2RwQl1oRi6Jpl+hf6PggwAi74VA References: <004001cbd2fb$4e9b3590$ebd1a0b0$%cui@huawei.com> <4D64D88E.6090202@neclab.eu> Cc: netext@ietf.org, iesg-secretary@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Request to progress Netext WG I-D: draft-ietf-netext-pmip6-lr-ps-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 02:40:19 -0000 Hi Marco, Please see my comments below. > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of > Marco Liebsch > Sent: Wednesday, February 23, 2011 5:51 PM > To: Xiangsong Cui > Cc: netext@ietf.org; iesg-secretary@ietf.org; Basavaraj.Patil@nokia.com > Subject: Re: [netext] Request to progress Netext WG I-D: > draft-ietf-netext-pmip6-lr-ps-05.txt > > Hi Xiangsong, > all your comments have been addressed in version 4 and 5. > W.r.t. the remaining two paragraphs you refer to in msg-1483, > let me clarify again by copying your last reply: > > > Xiangsong wrote: > > >The first sentence of section 5, > >Figure 2 shows PMIPv6 roaming cases where PMIPv6 components (e.g., > LMAs, > >MAGs) tied by MN and CN may be distributed between different provider > >domains (i.e., domain A, B, C) and MN and/or CN moves from one > provider > >domain to another one. > >Let me try to simplify this sentence, it is describing the roaming case > >which is showed in Figure 2, > >The front half of the subordinate clause says, "PMIPv6 components (e.g., > >LMAs, MAGs) tied by MN and CN may be distributed between different > provider > >domains" does this mean MAGs may be in different provider domain? > >The end half of the subordinate clause says, "MN and/or CN moves from one > >provider domain to another one". Does the *or* means that the nodes may > roam > >one by one? So even MAGs are in same provider domain, it would be changed > >when one node is roaming (to a new MAG in another provider domain). > > > Marco: The first sentence you refer to in section 5 is related to > general roaming use cases. > So, both is possible, MN and/or CN move. This has nothing to do yet with > localized routing. > Only in the second sentence we indicate that NetExt covers only use > cases for localized > routing where both MAGs (MN's and CN's) share the same provider domain. > This is also > independent of their LMA's location I see, thanks for your kind explanation. > > Xiangsong wrote: > > >Do you mean MN and CN are roaming exactly simultaneously? From > MAG1/MAG2 > >pair to MAG1'/MAG2' pair? > >In my impression, when MN (or CN) moves to a new provider domain, it would > >lie in a different provider domain with CN (or MN), so the localized routing > >should be released, right? > >If you say they are exactly simultaneously roaming, supposed they are > >registered in the same LMA, the LMA would receive PBU from MAG1' and > MAG2' > >respectively, I think here should be a single thread program, so it is > >impossible for the LMA to receive exactly simultaneous message, do you > mean > >the LMA should hold one PBU for some time (not destroy localized routing > >immediately although "different provider domain") and wait for the other PBU > >(to continue the localized routing on new MAG pair)? This is of course > >purely implementation issue, here my point is just to check the case. > > > Marco: This is not about maintenance of localized routing when MN/CN > step from a > non-roaming into a roaming situation. It only mandates (according to > NetExt scope > and requirements) that both MAGs share the same provider domain in a > steady state > situation, which means localized routing is set up when MN and CN start > a communication > and both MAGs are within the same provider domain. Further, this section > indicates that > MN's as well as CN's LMA may be located in the same provider domain as > the MN's/CN's > MAG or in a different one (roaming). Do you mean this section is about the situations before and after "roaming", but not about the procedure of "roaming"? Xiangsong > > I hope that clarifies your concerns and we can proceed with version 5. > > Marco > > > > Am 23.02.2011 02:45, schrieb Xiangsong Cui: > > Hi Raj, > > > > I'm not sure I have understood this well, because in my mind, there are some > > comments not completely addressed, I mean > > http://www.ietf.org/mail-archive/web/netext/current/msg01483.html. > > Would you please check them, or make sure those comments are negligible? > > If I was wrong, please let me know my mistake. > > > > Thanks, > > Xiangsong > > > >> -----Original Message----- > >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf > > Of > >> Basavaraj.Patil@nokia.com > >> Sent: Wednesday, February 23, 2011 6:29 AM > >> To: iesg-secretary@ietf.org; jari.arkko@piuha.net > >> Cc: netext@ietf.org > >> Subject: [netext] Request to progress Netext WG I-D: > >> draft-ietf-netext-pmip6-lr-ps-05.txt > >> > >> > >> Hello, > >> > >> The Netext WG I-D mentioned below is ready to be progressed to the > >> IESG for review and approval. Attached is the document shepherd > >> writeup for this I-D. > >> > >> I-D: PMIPv6 Localized Routing Problem Statement > >> > >> > >> -Raj > >> > >> > >> (1.a) Who is the Document Shepherd for this document? Has the > >> Document Shepherd personally reviewed this version of the > >> document and, in particular, does he or she believe this > >> version is ready for forwarding to the IESG for publication? > >> > >> Document shepherd: Basavaraj Patil > >> Yes, I have reviewed this version of the document and believe it is > >> ready for IESG review and publication. > >> > >> (1.b) Has the document had adequate review both from key WG > members > >> and from key non-WG members? Does the Document Shepherd > have > >> any concerns about the depth or breadth of the reviews that > >> have been performed? > >> > >> The document has had adequate reviews by key WG members. > >> I do not have any concerns regarding the depth or breadth of the > >> reviews received. > >> > >> (1.c) Does the Document Shepherd have concerns that the document > >> needs more review from a particular or broader perspective, > >> e.g., security, operational complexity, someone familiar with > >> AAA, internationalization or XML? > >> > >> No concerns regarding the reviews so far and do not believe additional > >> reviews are needed. > >> > >> (1.d) Does the Document Shepherd have any specific concerns or > >> issues with this document that the Responsible Area Director > >> and/or the IESG should be aware of? For example, perhaps he > >> or she is uncomfortable with certain parts of the document, or > >> has concerns whether there really is a need for it. In any > >> event, if the WG has discussed those issues and has indicated > >> that it still wishes to advance the document, detail those > >> concerns here. Has an IPR disclosure related to this document > >> been filed? If so, please include a reference to the > >> disclosure and summarize the WG discussion and conclusion on > >> this issue. > >> > >> I do not have any specific concerns at this time regarding this > >> document. The problem statement has been presented and discussed at > >> length in previous WG meetings and on the mailing list. I am not aware > >> of any IPR disclosures related to this I-D. > >> > >> > >> (1.e) How solid is the WG consensus behind this document? Does it > >> represent the strong concurrence of a few individuals, with > >> others being silent, or does the WG as a whole understand and > >> agree with it? > >> > >> There is solid WG consensus behind this document. I believe the > >> majority of WG members understand and agree with the document. > >> > >> (1.f) Has anyone threatened an appeal or otherwise indicated extreme > >> discontent? If so, please summarise the areas of conflict in > >> separate email messages to the Responsible Area Director. (It > >> should be in a separate email because this questionnaire is > >> entered into the ID Tracker.) > >> > >> No threats of appeal or extreme discontent have been expressed > >> regarding this I-D. > >> > >> > >> (1.g) Has the Document Shepherd personally verified that the > >> document satisfies all ID nits? (See the Internet-Drafts Checklist > >> and http://tools.ietf.org/tools/idnits/). Boilerplate checks are > >> not enough; this check needs to be thorough. Has the document > >> met all formal review criteria it needs to, such as the MIB > >> Doctor, media type and URI type reviews? > >> > >> Yes. I have run the I-D through the ID nits tool and found no issues. > >> > >> > >> (1.h) Has the document split its references into normative and > >> informative? Are there normative references to documents that > >> are not ready for advancement or are otherwise in an unclear > >> state? If such normative references exist, what is the > >> strategy for their completion? Are there normative references > >> that are downward references, as described in [RFC3967]? If > >> so, list these downward references to support the Area > >> Director in the Last Call procedure for them [RFC3967]. > >> > >> References are split into normative and informative sections. > >> > >> > >> (1.i) Has the Document Shepherd verified that the document IANA > >> consideration section exists and is consistent with the body > >> of the document? If the document specifies protocol > >> extensions, are reservations requested in appropriate IANA > >> registries? Are the IANA registries clearly identified? If > >> the document creates a new registry, does it define the > >> proposed initial contents of the registry and an allocation > >> procedure for future registrations? Does it suggest a > >> reasonable name for the new registry? See [RFC5226]. If the > >> document describes an Expert Review process has Shepherd > >> conferred with the Responsible Area Director so that the IESG > >> can appoint the needed Expert during the IESG Evaluation? > >> > >> This document does not require any IANA action. It is a problem state > >> description. > >> > >> > >> (1.j) Has the Document Shepherd verified that sections of the > >> document that are written in a formal language, such as XML > >> code, BNF rules, MIB definitions, etc., validate correctly in > >> an automated checker? > >> > >> Not applicable. > >> > >> > >> (1.k) The IESG approval announcement includes a Document > >> Announcement Write-Up. Please provide such a Document > >> Announcement Write-Up? Recent examples can be found in the > >> "Action" announcements for approved documents. The approval > >> announcement contains the following sections: > >> > >> Proxy Mobile IPv6 is the IETF standard for network-based mobility > >> management. In Proxy Mobile IPv6, mobile nodes are topologically > >> anchored at a Local Mobility Anchor, which forwards all data > >> for registered mobile nodes. The setup and maintenance of localized > >> routing, which allows forwarding of data packets between mobile nodes > >> and correspondent nodes directly without involvement of the Local > >> Mobility Anchor in forwarding, is not considered. This document > >> describes the problem space of localized routing in Proxy Mobile > >> IPv6. > >> > >> There is strong WG consensus regarding the problem statement and the > >> need for a solution to deal with localized routing. > >> The document describes the localized routing problem in Proxy Mobile > >> IPv6 deployments and hence not relevant from an implementation > >> perspective. > >> > >> _______________________________________________ > >> netext mailing list > >> netext@ietf.org > >> https://www.ietf.org/mailman/listinfo/netext > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From hesham@elevatemobile.com Wed Feb 23 22:52:01 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ADF13A6A2D for ; Wed, 23 Feb 2011 22:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITtJZnLmn4bc for ; Wed, 23 Feb 2011 22:52:00 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 70C3A3A6820 for ; Wed, 23 Feb 2011 22:51:59 -0800 (PST) Received: from [203.219.211.243] (helo=[192.168.0.4]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1PsV46-0003bd-8F; Thu, 24 Feb 2011 17:52:42 +1100 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 24 Feb 2011 17:52:36 +1100 From: Hesham Soliman To: Julien Laganier , Rajeev Koodli Message-ID: Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvT72s9mJZmjOc83UidEq4aiuLcMQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: netext@ietf.org Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 06:52:01 -0000 Julien, all, >>> I assume by network you mean the MAG. The LMA can know whether the MN >>> supports flow mobility by other means, e.g., through AAA. See for instance: >>> >>> http://tools.ietf.org/html/draft-koodli-netext-multiaccess-indicator-01 >> >> I think whether or not AAA can really knows what are the capabilities >> of a network stack on a device is questionable, but let's skip on that >> for now: >> >> In 3GPP, the MAG in the ePDG has interfaces to AAA, so the MAG would >> know from AAA that that MN supports flow mobility, and MAG sets HI=FM. >> Goto 1) above. On the other hand in 3GPP the LMA has no interfaces >> with AAA, so what you describe in your draft isn't applicable there. > > Regarding 3GPP I made a wrong statement, sorry about that: The LMA > indeed has an interface to AAA, but so has the MAG. So anything that > the LMA can know thru AAA, the LMA can know as well. => I think we need to be careful about using AAA as a potential silver bullet for things we don't know how to do in our protocol. More specifically, the property discussed above is a device attribute. AAA is usually a user profile not a device profile unless you assume a 1:1 mapping of device:user, which might be the case in some systems in the US but is certainly not the case in the rest of the world. So assuming the device properties will be stored in AAA and attributed to the user is not a good way to go. Furthermore, users use devices that have not be "initialised" in AAA all the time. A user doesn't ask for an operator's permission before they stick their SIM in a device. So device properties are not known in advance. Hesham > > That being said, if we only assume 5213 and aren't specific to 3GPP, > if a PMIPv6 deployment relies on AAA, the entity that would be > required to be interfaced to a AAA system is the MAG, because it needs > to authenticate the MNID and pull the policy profile. > > So in this AAA scenario it still holds that the MAG can know the MN's > capability from AAA and set the HI = FM. > > Hope that clarifies my earlier statement. > > --julien > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Marco.Liebsch@neclab.eu Thu Feb 24 02:00:10 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53EC23A6843 for ; Thu, 24 Feb 2011 02:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5IlwYS7rI9i for ; Thu, 24 Feb 2011 02:00:07 -0800 (PST) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id 58F303A6A34 for ; Thu, 24 Feb 2011 02:00:07 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id A03532800018A; Thu, 24 Feb 2011 11:02:12 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i06xdxPNPjxN; Thu, 24 Feb 2011 11:02:12 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 7E0122800017B; Thu, 24 Feb 2011 11:01:57 +0100 (CET) Received: from [10.1.6.62] (10.1.6.62) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 24 Feb 2011 11:00:41 +0100 Message-ID: <4D662C48.8070506@neclab.eu> Date: Thu, 24 Feb 2011 11:00:40 +0100 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Xiangsong Cui References: <004001cbd2fb$4e9b3590$ebd1a0b0$%cui@huawei.com> <4D64D88E.6090202@neclab.eu> <006701cbd3cc$4251fe50$c6f5faf0$%cui@huawei.com> In-Reply-To: <006701cbd3cc$4251fe50$c6f5faf0$%cui@huawei.com> Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.6.62] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Request to progress Netext WG I-D: draft-ietf-netext-pmip6-lr-ps-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 10:00:10 -0000 Hi Xiangsong, please find my reply inline. Xiangsong Cui wrote: > Hi Marco, > > Please see my comments below. > > >> -----Original Message----- >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf >> > Of > >> Marco Liebsch >> Sent: Wednesday, February 23, 2011 5:51 PM >> To: Xiangsong Cui >> Cc: netext@ietf.org; iesg-secretary@ietf.org; Basavaraj.Patil@nokia.com >> Subject: Re: [netext] Request to progress Netext WG I-D: >> draft-ietf-netext-pmip6-lr-ps-05.txt >> >> Hi Xiangsong, >> all your comments have been addressed in version 4 and 5. >> W.r.t. the remaining two paragraphs you refer to in msg-1483, >> let me clarify again by copying your last reply: >> >> >> Xiangsong wrote: >> >> >>> The first sentence of section 5, >>> Figure 2 shows PMIPv6 roaming cases where PMIPv6 components (e.g., >>> >> LMAs, >> >>> MAGs) tied by MN and CN may be distributed between different provider >>> domains (i.e., domain A, B, C) and MN and/or CN moves from one >>> >> provider >> >>> domain to another one. >>> Let me try to simplify this sentence, it is describing the roaming case >>> which is showed in Figure 2, >>> The front half of the subordinate clause says, "PMIPv6 components (e.g., >>> LMAs, MAGs) tied by MN and CN may be distributed between different >>> >> provider >> >>> domains" does this mean MAGs may be in different provider domain? >>> The end half of the subordinate clause says, "MN and/or CN moves from one >>> provider domain to another one". Does the *or* means that the nodes may >>> >> roam >> >>> one by one? So even MAGs are in same provider domain, it would be changed >>> when one node is roaming (to a new MAG in another provider domain). >>> >> Marco: The first sentence you refer to in section 5 is related to >> general roaming use cases. >> So, both is possible, MN and/or CN move. This has nothing to do yet with >> localized routing. >> Only in the second sentence we indicate that NetExt covers only use >> cases for localized >> routing where both MAGs (MN's and CN's) share the same provider domain. >> This is also >> independent of their LMA's location >> > > I see, thanks for your kind explanation. > > >> Xiangsong wrote: >> >> >>> Do you mean MN and CN are roaming exactly simultaneously? From >>> >> MAG1/MAG2 >> >>> pair to MAG1'/MAG2' pair? >>> In my impression, when MN (or CN) moves to a new provider domain, it >>> > would > >>> lie in a different provider domain with CN (or MN), so the localized >>> > routing > >>> should be released, right? >>> If you say they are exactly simultaneously roaming, supposed they are >>> registered in the same LMA, the LMA would receive PBU from MAG1' and >>> >> MAG2' >> >>> respectively, I think here should be a single thread program, so it is >>> impossible for the LMA to receive exactly simultaneous message, do you >>> >> mean >> >>> the LMA should hold one PBU for some time (not destroy localized routing >>> immediately although "different provider domain") and wait for the other >>> > PBU > >>> (to continue the localized routing on new MAG pair)? This is of course >>> purely implementation issue, here my point is just to check the case. >>> >> Marco: This is not about maintenance of localized routing when MN/CN >> step from a >> non-roaming into a roaming situation. It only mandates (according to >> NetExt scope >> and requirements) that both MAGs share the same provider domain in a >> steady state >> situation, which means localized routing is set up when MN and CN start >> a communication >> and both MAGs are within the same provider domain. Further, this section >> indicates that >> MN's as well as CN's LMA may be located in the same provider domain as >> the MN's/CN's >> MAG or in a different one (roaming). >> > > Do you mean this section is about the situations before and after "roaming", > but not about the procedure of "roaming"? > yes. marco > Xiangsong > > >> I hope that clarifies your concerns and we can proceed with version 5. >> >> Marco >> >> >> >> Am 23.02.2011 02:45, schrieb Xiangsong Cui: >> >>> Hi Raj, >>> >>> I'm not sure I have understood this well, because in my mind, there are >>> > some > >>> comments not completely addressed, I mean >>> http://www.ietf.org/mail-archive/web/netext/current/msg01483.html. >>> Would you please check them, or make sure those comments are negligible? >>> If I was wrong, please let me know my mistake. >>> >>> Thanks, >>> Xiangsong >>> >>> >>>> -----Original Message----- >>>> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On >>>> > Behalf > >>> Of >>> >>>> Basavaraj.Patil@nokia.com >>>> Sent: Wednesday, February 23, 2011 6:29 AM >>>> To: iesg-secretary@ietf.org; jari.arkko@piuha.net >>>> Cc: netext@ietf.org >>>> Subject: [netext] Request to progress Netext WG I-D: >>>> draft-ietf-netext-pmip6-lr-ps-05.txt >>>> >>>> >>>> Hello, >>>> >>>> The Netext WG I-D mentioned below is ready to be progressed to the >>>> IESG for review and approval. Attached is the document shepherd >>>> writeup for this I-D. >>>> >>>> I-D: PMIPv6 Localized Routing Problem Statement >>>> >>>> >>>> -Raj >>>> >>>> >>>> (1.a) Who is the Document Shepherd for this document? Has the >>>> Document Shepherd personally reviewed this version of the >>>> document and, in particular, does he or she believe this >>>> version is ready for forwarding to the IESG for publication? >>>> >>>> Document shepherd: Basavaraj Patil >>>> Yes, I have reviewed this version of the document and believe it is >>>> ready for IESG review and publication. >>>> >>>> (1.b) Has the document had adequate review both from key WG >>>> >> members >> >>>> and from key non-WG members? Does the Document Shepherd >>>> >> have >> >>>> any concerns about the depth or breadth of the reviews that >>>> have been performed? >>>> >>>> The document has had adequate reviews by key WG members. >>>> I do not have any concerns regarding the depth or breadth of the >>>> reviews received. >>>> >>>> (1.c) Does the Document Shepherd have concerns that the document >>>> needs more review from a particular or broader perspective, >>>> e.g., security, operational complexity, someone familiar with >>>> AAA, internationalization or XML? >>>> >>>> No concerns regarding the reviews so far and do not believe additional >>>> reviews are needed. >>>> >>>> (1.d) Does the Document Shepherd have any specific concerns or >>>> issues with this document that the Responsible Area Director >>>> and/or the IESG should be aware of? For example, perhaps he >>>> or she is uncomfortable with certain parts of the document, or >>>> has concerns whether there really is a need for it. In any >>>> event, if the WG has discussed those issues and has indicated >>>> that it still wishes to advance the document, detail those >>>> concerns here. Has an IPR disclosure related to this document >>>> been filed? If so, please include a reference to the >>>> disclosure and summarize the WG discussion and conclusion on >>>> this issue. >>>> >>>> I do not have any specific concerns at this time regarding this >>>> document. The problem statement has been presented and discussed at >>>> length in previous WG meetings and on the mailing list. I am not aware >>>> of any IPR disclosures related to this I-D. >>>> >>>> >>>> (1.e) How solid is the WG consensus behind this document? Does it >>>> represent the strong concurrence of a few individuals, with >>>> others being silent, or does the WG as a whole understand and >>>> agree with it? >>>> >>>> There is solid WG consensus behind this document. I believe the >>>> majority of WG members understand and agree with the document. >>>> >>>> (1.f) Has anyone threatened an appeal or otherwise indicated extreme >>>> discontent? If so, please summarise the areas of conflict in >>>> separate email messages to the Responsible Area Director. (It >>>> should be in a separate email because this questionnaire is >>>> entered into the ID Tracker.) >>>> >>>> No threats of appeal or extreme discontent have been expressed >>>> regarding this I-D. >>>> >>>> >>>> (1.g) Has the Document Shepherd personally verified that the >>>> document satisfies all ID nits? (See the Internet-Drafts >>>> > Checklist > >>>> and http://tools.ietf.org/tools/idnits/). Boilerplate checks >>>> > are > >>>> not enough; this check needs to be thorough. Has the document >>>> met all formal review criteria it needs to, such as the MIB >>>> Doctor, media type and URI type reviews? >>>> >>>> Yes. I have run the I-D through the ID nits tool and found no issues. >>>> >>>> >>>> (1.h) Has the document split its references into normative and >>>> informative? Are there normative references to documents that >>>> are not ready for advancement or are otherwise in an unclear >>>> state? If such normative references exist, what is the >>>> strategy for their completion? Are there normative references >>>> that are downward references, as described in [RFC3967]? If >>>> so, list these downward references to support the Area >>>> Director in the Last Call procedure for them [RFC3967]. >>>> >>>> References are split into normative and informative sections. >>>> >>>> >>>> (1.i) Has the Document Shepherd verified that the document IANA >>>> consideration section exists and is consistent with the body >>>> of the document? If the document specifies protocol >>>> extensions, are reservations requested in appropriate IANA >>>> registries? Are the IANA registries clearly identified? If >>>> the document creates a new registry, does it define the >>>> proposed initial contents of the registry and an allocation >>>> procedure for future registrations? Does it suggest a >>>> reasonable name for the new registry? See [RFC5226]. If the >>>> document describes an Expert Review process has Shepherd >>>> conferred with the Responsible Area Director so that the IESG >>>> can appoint the needed Expert during the IESG Evaluation? >>>> >>>> This document does not require any IANA action. It is a problem state >>>> description. >>>> >>>> >>>> (1.j) Has the Document Shepherd verified that sections of the >>>> document that are written in a formal language, such as XML >>>> code, BNF rules, MIB definitions, etc., validate correctly in >>>> an automated checker? >>>> >>>> Not applicable. >>>> >>>> >>>> (1.k) The IESG approval announcement includes a Document >>>> Announcement Write-Up. Please provide such a Document >>>> Announcement Write-Up? Recent examples can be found in the >>>> "Action" announcements for approved documents. The approval >>>> announcement contains the following sections: >>>> >>>> Proxy Mobile IPv6 is the IETF standard for network-based mobility >>>> management. In Proxy Mobile IPv6, mobile nodes are topologically >>>> anchored at a Local Mobility Anchor, which forwards all data >>>> for registered mobile nodes. The setup and maintenance of localized >>>> routing, which allows forwarding of data packets between mobile nodes >>>> and correspondent nodes directly without involvement of the Local >>>> Mobility Anchor in forwarding, is not considered. This document >>>> describes the problem space of localized routing in Proxy Mobile >>>> IPv6. >>>> >>>> There is strong WG consensus regarding the problem statement and the >>>> need for a solution to deal with localized routing. >>>> The document describes the localized routing problem in Proxy Mobile >>>> IPv6 deployments and hence not relevant from an implementation >>>> perspective. >>>> >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> > > > Received: from smtp0.neclab.eu (192.168.23.16) by METHONE.office.hd > (192.168.24.54) with Microsoft SMTP Server id 14.1.270.1; Thu, 24 Feb 2011 > 03:41:07 +0100 > Received: by smtp0.neclab.eu (Postfix) id 7F6052C000205; Thu, 24 Feb 2011 > 03:41:55 +0100 (CET) > Delivered-To: marco.liebsch@neclab.eu > Received: from localhost (localhost.localdomain [127.0.0.1]) by > smtp0.neclab.eu (Postfix) with ESMTP id 7450C2C0001DE for > ; Thu, 24 Feb 2011 03:41:55 +0100 (CET) > X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) > Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd > [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qH1ppQF8hxGR for > ; Thu, 24 Feb 2011 03:41:55 +0100 (CET) > Received: by smtp0.neclab.eu (Postfix, from userid 1001) id 4D5F52C000203; > Thu, 24 Feb 2011 03:41:55 +0100 (CET) > X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on atlas2.office.hd > X-Spam-Level: > X-Spam-Status: No, score=-106.6 required=4.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, > USER_IN_WHITELIST autolearn=ham version=3.2.5 > Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) > by smtp0.neclab.eu (Postfix) with ESMTP id 4BA8F2C0001DE for > ; Thu, 24 Feb 2011 03:41:47 +0100 (CET) > Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com > (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id > <0LH300IZJOS6J5@szxga03-in.huawei.com> for marco.liebsch@neclab.eu; Thu, 24 > Feb 2011 10:40:54 +0800 (CST) > Received: from c00111037 ([10.111.16.128]) by szxga03-in.huawei.com (iPlanet > Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id > <0LH300B5DOS5NR@szxga03-in.huawei.com> for marco.liebsch@neclab.eu; Thu, 24 > Feb 2011 10:40:54 +0800 (CST) > Date: Thu, 24 Feb 2011 10:40:54 +0800 > From: Xiangsong Cui > Subject: RE: [netext] Request to progress Netext WG I-D: > draft-ietf-netext-pmip6-lr-ps-05.txt > In-Reply-To: <4D64D88E.6090202@neclab.eu> > To: 'Marco Liebsch' > CC: , , > Message-ID: <006701cbd3cc$4251fe50$c6f5faf0$%cui@huawei.com> > X-Mailer: Microsoft Office Outlook 12.0 > Content-Type: text/plain; charset="us-ascii" > Content-Language: zh-cn > Content-Transfer-Encoding: 7BIT > Thread-index: AcvTP2O+M2RwQl1oRi6Jpl+hf6PggwAi74VA > References: > <004001cbd2fb$4e9b3590$ebd1a0b0$%cui@huawei.com> <4D64D88E.6090202@neclab.eu> > Return-Path: Xiangsong.Cui@huawei.com > X-MS-Exchange-Organization-AuthSource: METHONE.office.hd > X-MS-Exchange-Organization-AuthAs: Anonymous > MIME-Version: 1.0 > > Hi Marco, > > Please see my comments below. > > >> -----Original Message----- >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf >> > Of > >> Marco Liebsch >> Sent: Wednesday, February 23, 2011 5:51 PM >> To: Xiangsong Cui >> Cc: netext@ietf.org; iesg-secretary@ietf.org; Basavaraj.Patil@nokia.com >> Subject: Re: [netext] Request to progress Netext WG I-D: >> draft-ietf-netext-pmip6-lr-ps-05.txt >> >> Hi Xiangsong, >> all your comments have been addressed in version 4 and 5. >> W.r.t. the remaining two paragraphs you refer to in msg-1483, >> let me clarify again by copying your last reply: >> >> >> Xiangsong wrote: >> >> >>> The first sentence of section 5, >>> Figure 2 shows PMIPv6 roaming cases where PMIPv6 components (e.g., >>> >> LMAs, >> >>> MAGs) tied by MN and CN may be distributed between different provider >>> domains (i.e., domain A, B, C) and MN and/or CN moves from one >>> >> provider >> >>> domain to another one. >>> Let me try to simplify this sentence, it is describing the roaming case >>> which is showed in Figure 2, >>> The front half of the subordinate clause says, "PMIPv6 components (e.g., >>> LMAs, MAGs) tied by MN and CN may be distributed between different >>> >> provider >> >>> domains" does this mean MAGs may be in different provider domain? >>> The end half of the subordinate clause says, "MN and/or CN moves from one >>> provider domain to another one". Does the *or* means that the nodes may >>> >> roam >> >>> one by one? So even MAGs are in same provider domain, it would be changed >>> when one node is roaming (to a new MAG in another provider domain). >>> >> Marco: The first sentence you refer to in section 5 is related to >> general roaming use cases. >> So, both is possible, MN and/or CN move. This has nothing to do yet with >> localized routing. >> Only in the second sentence we indicate that NetExt covers only use >> cases for localized >> routing where both MAGs (MN's and CN's) share the same provider domain. >> This is also >> independent of their LMA's location >> > > I see, thanks for your kind explanation. > > >> Xiangsong wrote: >> >> >>> Do you mean MN and CN are roaming exactly simultaneously? From >>> >> MAG1/MAG2 >> >>> pair to MAG1'/MAG2' pair? >>> In my impression, when MN (or CN) moves to a new provider domain, it >>> > would > >>> lie in a different provider domain with CN (or MN), so the localized >>> > routing > >>> should be released, right? >>> If you say they are exactly simultaneously roaming, supposed they are >>> registered in the same LMA, the LMA would receive PBU from MAG1' and >>> >> MAG2' >> >>> respectively, I think here should be a single thread program, so it is >>> impossible for the LMA to receive exactly simultaneous message, do you >>> >> mean >> >>> the LMA should hold one PBU for some time (not destroy localized routing >>> immediately although "different provider domain") and wait for the other >>> > PBU > >>> (to continue the localized routing on new MAG pair)? This is of course >>> purely implementation issue, here my point is just to check the case. >>> >> Marco: This is not about maintenance of localized routing when MN/CN >> step from a >> non-roaming into a roaming situation. It only mandates (according to >> NetExt scope >> and requirements) that both MAGs share the same provider domain in a >> steady state >> situation, which means localized routing is set up when MN and CN start >> a communication >> and both MAGs are within the same provider domain. Further, this section >> indicates that >> MN's as well as CN's LMA may be located in the same provider domain as >> the MN's/CN's >> MAG or in a different one (roaming). >> > > Do you mean this section is about the situations before and after "roaming", > but not about the procedure of "roaming"? > > Xiangsong > > >> I hope that clarifies your concerns and we can proceed with version 5. >> >> Marco >> >> >> >> Am 23.02.2011 02:45, schrieb Xiangsong Cui: >> >>> Hi Raj, >>> >>> I'm not sure I have understood this well, because in my mind, there are >>> > some > >>> comments not completely addressed, I mean >>> http://www.ietf.org/mail-archive/web/netext/current/msg01483.html. >>> Would you please check them, or make sure those comments are negligible? >>> If I was wrong, please let me know my mistake. >>> >>> Thanks, >>> Xiangsong >>> >>> >>>> -----Original Message----- >>>> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On >>>> > Behalf > >>> Of >>> >>>> Basavaraj.Patil@nokia.com >>>> Sent: Wednesday, February 23, 2011 6:29 AM >>>> To: iesg-secretary@ietf.org; jari.arkko@piuha.net >>>> Cc: netext@ietf.org >>>> Subject: [netext] Request to progress Netext WG I-D: >>>> draft-ietf-netext-pmip6-lr-ps-05.txt >>>> >>>> >>>> Hello, >>>> >>>> The Netext WG I-D mentioned below is ready to be progressed to the >>>> IESG for review and approval. Attached is the document shepherd >>>> writeup for this I-D. >>>> >>>> I-D: PMIPv6 Localized Routing Problem Statement >>>> >>>> >>>> -Raj >>>> >>>> >>>> (1.a) Who is the Document Shepherd for this document? Has the >>>> Document Shepherd personally reviewed this version of the >>>> document and, in particular, does he or she believe this >>>> version is ready for forwarding to the IESG for publication? >>>> >>>> Document shepherd: Basavaraj Patil >>>> Yes, I have reviewed this version of the document and believe it is >>>> ready for IESG review and publication. >>>> >>>> (1.b) Has the document had adequate review both from key WG >>>> >> members >> >>>> and from key non-WG members? Does the Document Shepherd >>>> >> have >> >>>> any concerns about the depth or breadth of the reviews that >>>> have been performed? >>>> >>>> The document has had adequate reviews by key WG members. >>>> I do not have any concerns regarding the depth or breadth of the >>>> reviews received. >>>> >>>> (1.c) Does the Document Shepherd have concerns that the document >>>> needs more review from a particular or broader perspective, >>>> e.g., security, operational complexity, someone familiar with >>>> AAA, internationalization or XML? >>>> >>>> No concerns regarding the reviews so far and do not believe additional >>>> reviews are needed. >>>> >>>> (1.d) Does the Document Shepherd have any specific concerns or >>>> issues with this document that the Responsible Area Director >>>> and/or the IESG should be aware of? For example, perhaps he >>>> or she is uncomfortable with certain parts of the document, or >>>> has concerns whether there really is a need for it. In any >>>> event, if the WG has discussed those issues and has indicated >>>> that it still wishes to advance the document, detail those >>>> concerns here. Has an IPR disclosure related to this document >>>> been filed? If so, please include a reference to the >>>> disclosure and summarize the WG discussion and conclusion on >>>> this issue. >>>> >>>> I do not have any specific concerns at this time regarding this >>>> document. The problem statement has been presented and discussed at >>>> length in previous WG meetings and on the mailing list. I am not aware >>>> of any IPR disclosures related to this I-D. >>>> >>>> >>>> (1.e) How solid is the WG consensus behind this document? Does it >>>> represent the strong concurrence of a few individuals, with >>>> others being silent, or does the WG as a whole understand and >>>> agree with it? >>>> >>>> There is solid WG consensus behind this document. I believe the >>>> majority of WG members understand and agree with the document. >>>> >>>> (1.f) Has anyone threatened an appeal or otherwise indicated extreme >>>> discontent? If so, please summarise the areas of conflict in >>>> separate email messages to the Responsible Area Director. (It >>>> should be in a separate email because this questionnaire is >>>> entered into the ID Tracker.) >>>> >>>> No threats of appeal or extreme discontent have been expressed >>>> regarding this I-D. >>>> >>>> >>>> (1.g) Has the Document Shepherd personally verified that the >>>> document satisfies all ID nits? (See the Internet-Drafts >>>> > Checklist > >>>> and http://tools.ietf.org/tools/idnits/). Boilerplate checks >>>> > are > >>>> not enough; this check needs to be thorough. Has the document >>>> met all formal review criteria it needs to, such as the MIB >>>> Doctor, media type and URI type reviews? >>>> >>>> Yes. I have run the I-D through the ID nits tool and found no issues. >>>> >>>> >>>> (1.h) Has the document split its references into normative and >>>> informative? Are there normative references to documents that >>>> are not ready for advancement or are otherwise in an unclear >>>> state? If such normative references exist, what is the >>>> strategy for their completion? Are there normative references >>>> that are downward references, as described in [RFC3967]? If >>>> so, list these downward references to support the Area >>>> Director in the Last Call procedure for them [RFC3967]. >>>> >>>> References are split into normative and informative sections. >>>> >>>> >>>> (1.i) Has the Document Shepherd verified that the document IANA >>>> consideration section exists and is consistent with the body >>>> of the document? If the document specifies protocol >>>> extensions, are reservations requested in appropriate IANA >>>> registries? Are the IANA registries clearly identified? If >>>> the document creates a new registry, does it define the >>>> proposed initial contents of the registry and an allocation >>>> procedure for future registrations? Does it suggest a >>>> reasonable name for the new registry? See [RFC5226]. If the >>>> document describes an Expert Review process has Shepherd >>>> conferred with the Responsible Area Director so that the IESG >>>> can appoint the needed Expert during the IESG Evaluation? >>>> >>>> This document does not require any IANA action. It is a problem state >>>> description. >>>> >>>> >>>> (1.j) Has the Document Shepherd verified that sections of the >>>> document that are written in a formal language, such as XML >>>> code, BNF rules, MIB definitions, etc., validate correctly in >>>> an automated checker? >>>> >>>> Not applicable. >>>> >>>> >>>> (1.k) The IESG approval announcement includes a Document >>>> Announcement Write-Up. Please provide such a Document >>>> Announcement Write-Up? Recent examples can be found in the >>>> "Action" announcements for approved documents. The approval >>>> announcement contains the following sections: >>>> >>>> Proxy Mobile IPv6 is the IETF standard for network-based mobility >>>> management. In Proxy Mobile IPv6, mobile nodes are topologically >>>> anchored at a Local Mobility Anchor, which forwards all data >>>> for registered mobile nodes. The setup and maintenance of localized >>>> routing, which allows forwarding of data packets between mobile nodes >>>> and correspondent nodes directly without involvement of the Local >>>> Mobility Anchor in forwarding, is not considered. This document >>>> describes the problem space of localized routing in Proxy Mobile >>>> IPv6. >>>> >>>> There is strong WG consensus regarding the problem statement and the >>>> need for a solution to deal with localized routing. >>>> The document describes the localized routing problem in Proxy Mobile >>>> IPv6 deployments and hence not relevant from an implementation >>>> perspective. >>>> >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> > > From julien.ietf@gmail.com Thu Feb 24 08:06:53 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD1933A66B4 for ; Thu, 24 Feb 2011 08:06:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BD1Sw7r3M+MO for ; Thu, 24 Feb 2011 08:06:52 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 868103A63CB for ; Thu, 24 Feb 2011 08:06:52 -0800 (PST) Received: by fxm15 with SMTP id 15so696605fxm.31 for ; Thu, 24 Feb 2011 08:07:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fyXX+62YRuFEYzdBuusHcm4o6qxiCOJnfZYyF3p8u+0=; b=U+dmFymTuyMsdiMdbAmpCoo0yAy1N86fVcOW328y8Ef787hPjnRfv2TBKDQRoUNz2p b4s/yI+oDiqUSXR4h3yHEtZC+2OVqRUUXQPvmexCVAcsWA4TwFc1VM/VsKPk0kj3fu6S XgsXHEpijsOrgUZGGJiBaMQjlNt/MolKEljUY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=H0fg2Nn8T/Cc6XXCjlCORPbFWjw7RoVacCLqjTIL12MoY0TUdoy4HSwJISNb61KIpa j3e/UWJWnqp8ZpCQk1DLLzGTauxdDUHK6X055CJS1hwKDqvfV2kUDDZEvN2FImKUpTK5 LwCdkILyzV6hyYznADx7kD/YUOtvoac6VqvF4= MIME-Version: 1.0 Received: by 10.223.74.206 with SMTP id v14mr1279713faj.66.1298563559376; Thu, 24 Feb 2011 08:05:59 -0800 (PST) Received: by 10.223.74.142 with HTTP; Thu, 24 Feb 2011 08:05:58 -0800 (PST) In-Reply-To: References: Date: Thu, 24 Feb 2011 09:05:58 -0700 Message-ID: From: Julien Laganier To: Hesham Soliman Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 16:06:53 -0000 Hesham, On Wed, Feb 23, 2011 at 11:52 PM, Hesham Soliman wrote: > Julien, all, > > >>>> I assume by network you mean the MAG. The LMA can know whether the MN >>>> supports flow mobility by other means, e.g., through AAA. See for instance: >>>> >>>> http://tools.ietf.org/html/draft-koodli-netext-multiaccess-indicator-01 >>> >>> I think whether or not AAA can really knows what are the capabilities >>> of a network stack on a device is questionable, but let's skip on that >>> for now: >>> >>> In 3GPP, the MAG in the ePDG has interfaces to AAA, so the MAG would >>> know from AAA that that MN supports flow mobility, and MAG sets HI=FM. >>> Goto 1) above. On the other hand in 3GPP the LMA has no interfaces >>> with AAA, so what you describe in your draft isn't applicable there. >> >> Regarding 3GPP I made a wrong statement, sorry about that: The LMA >> indeed has an interface to AAA, but so has the MAG. So anything that >> the LMA can know thru AAA, the LMA can know as well. > > => I think we need to be careful about using AAA as a potential silver > bullet for things we don't know how to do in our protocol. More > specifically, the property discussed above is a device attribute. AAA is > usually a user profile not a device profile unless you assume a 1:1 mapping > of device:user, which might be the case in some systems in the US but is > certainly not the case in the rest of the world. So assuming the device > properties will be stored in AAA and attributed to the user is not a good > way to go. > Furthermore, users use devices that have not be "initialised" in AAA all the > time. A user doesn't ask for an operator's permission before they stick > their SIM in a device. So device properties are not known in advance. I agree with this entirely, which is why I said: >>> I think whether or not AAA can really knows what are the capabilities >>> of a network stack on a device is questionable, but let's skip on that >>> for now: but still I wanted to make the point that if to support scenario 2) in Rajeev's mail one needs to assume LMA is told by AAA the device capabilities, then the MAG can be told that as well by AAA (e.g., at same time it gets to know the MNID) and set HI = FM appropriately as per case 1) thus there's no point in supporting case 2) as per my earlier writings on the topic. --julien From rkoodli@cisco.com Thu Feb 24 09:41:06 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 220383A6832 for ; Thu, 24 Feb 2011 09:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.465 X-Spam-Level: X-Spam-Status: No, score=-109.465 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, J_CHICKENPOX_28=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzkDWXAw-1qu for ; Thu, 24 Feb 2011 09:41:04 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id AA62A3A6826 for ; Thu, 24 Feb 2011 09:41:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rkoodli@cisco.com; l=2966; q=dns/txt; s=iport; t=1298569315; x=1299778915; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=THAR3+Ks3CT41P/p6hodWtFBZEVu1LTxR5PywOQO0X0=; b=dHysqtDUZzQyScoQr/fG7Zsqy+po+5ZcB0L6XITB05Lt9uOkK9R1SsMW zW5ZC3CzOa1QrG5rrjORHwpaSojsRTXTSLkD+pZJRQAYRu6X61t0PeUG2 eR0PvWkbFPYCyK8sE5LNAQC1X0OIepKtFLS9sP77ui7/zmV8ItEwt6QpQ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAK8nZk2tJXHA/2dsb2JhbACmLXOiI5t8hWAEhRCHDINDgww X-IronPort-AV: E=Sophos;i="4.62,219,1297036800"; d="scan'208";a="219701948" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rtp-iport-2.cisco.com with ESMTP; 24 Feb 2011 17:41:40 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p1OHfeRF007498; Thu, 24 Feb 2011 17:41:40 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Feb 2011 11:41:40 -0600 Received: from 10.21.75.48 ([10.21.75.48]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Thu, 24 Feb 2011 17:41:39 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 24 Feb 2011 09:42:05 -0800 From: Rajeev Koodli To: Julien Laganier , Hesham Soliman Message-ID: Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvUSiaSZ0vidh9CikWqPAAw+0TSrQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 24 Feb 2011 17:41:40.0093 (UTC) FILETIME=[17BA12D0:01CBD44A] Cc: netext@ietf.org Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 17:41:06 -0000 Julien, Please treat this as a combined response to your other e-mail as well. On 2/24/11 8:05 AM, "Julien Laganier" wrote: >> >> => I think we need to be careful about using AAA as a potential silver >> bullet for things we don't know how to do in our protocol. More >> specifically, the property discussed above is a device attribute. AAA is >> usually a user profile not a device profile unless you assume a 1:1 mapping >> of device:user, which might be the case in some systems in the US but is >> certainly not the case in the rest of the world. So assuming the device >> properties will be stored in AAA and attributed to the user is not a good >> way to go. >> Furthermore, users use devices that have not be "initialised" in AAA all the >> time. A user doesn't ask for an operator's permission before they stick >> their SIM in a device. So device properties are not known in advance. > > I agree with this entirely, which is why I said: > Good points. The purpose of the multi-access indicator ID is twofold: to enable the MN to indicate its capability and willingness for flow mobility (through the AT_MA_IND attribute). Second, to enable AAA to authorize the user for flow mobility. So, it's the MN which is indicating the device capability, and the AAA providing the authorization for the flow mobility service. >>>> I think whether or not AAA can really knows what are the capabilities >>>> of a network stack on a device is questionable, but let's skip on that >>>> for now: > > but still I wanted to make the point that if to support scenario 2) in > Rajeev's mail one needs to assume LMA is told by AAA the device > capabilities, then the MAG can be told that as well by AAA (e.g., at > same time it gets to know the MNID) and set HI = FM appropriately as > per case 1) thus there's no point in supporting case 2) as per my > earlier writings on the topic. > There are two parts to consider here. First, the issue of LMA knowing that the MN is capable and willing to have flow mobility (I think you brought up the issue of legacy host). Whether or not MAG is informed by the AAA, there is LMA - AAA interaction. In other words, LMA will go to AAA anyway. So, the AAA providing the attribute to the MAG is redundant exchange which we thought unnecessary for the multi-access ID. And, whether the LMA will actually accept the indicator provided by MAG is moot, since the authorization should come from elsewhere (AAA). Second, the issue of assigning prefixes at the LMA. The LMA should be able to assign any prefix freely upon any attach. With HI=Handover, it returns the previously assigned prefix, but there is no prohibition to also return a hitherto unassigned prefix, AFAICT. Similarly, even with HI = FM, the LMA can assign a new prefix which is not in the current set. This is not a new feature which we need to support. -Rajeev > --julien From julien.ietf@gmail.com Thu Feb 24 11:20:14 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34ED93A680D for ; Thu, 24 Feb 2011 11:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.616 X-Spam-Level: X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, J_CHICKENPOX_28=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyhOfJeo6Lvq for ; Thu, 24 Feb 2011 11:20:13 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id BC1D43A6802 for ; Thu, 24 Feb 2011 11:20:12 -0800 (PST) Received: by fxm15 with SMTP id 15so896596fxm.31 for ; Thu, 24 Feb 2011 11:21:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nYSPmKXuSdSsFgHQSILvbS5+iZQpnzA8wLuSbFjlDKs=; b=IvK0EvXVrH6J24jtjJqY41ZY8Ijh69pWV+39I1G/9Zulj6+jVggp18JhwuYeuqs7as Hcz0z0+8Nx+lXhHuyGRT2kK0yaAsR2jqE0RKh0xoAGYL5rmVmShQoiMax0KJe4ghAmge kVc2Vl2lP2FUx3NM4jnR10AKMxLSMFpR8GAi4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VTFiUGXwFOTj6W320f4u2XHxaK1RsNRZv5SVm9YP6Sequi7PMA4yP5+vbRPk9HidLa JilKSKlZqySxgFwsdCVrAZHvb2w3Mi0eheumuiUdS49f55ZwCclMxUQg2dEyupiTR2+/ lZlvXtxmuzUWvnFZXdG6gqK6B/U+y/9SthDiI= MIME-Version: 1.0 Received: by 10.223.119.68 with SMTP id y4mr1494850faq.104.1298575025796; Thu, 24 Feb 2011 11:17:05 -0800 (PST) Received: by 10.223.74.142 with HTTP; Thu, 24 Feb 2011 11:17:05 -0800 (PST) In-Reply-To: References: Date: Thu, 24 Feb 2011 12:17:05 -0700 Message-ID: From: Julien Laganier To: Rajeev Koodli Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 19:20:14 -0000 Rajeev, Please see inline. On Thu, Feb 24, 2011 at 10:42 AM, Rajeev Koodli wrote: > > Julien, > > Please treat this as a combined response to your other e-mail as well. > > On 2/24/11 8:05 AM, "Julien Laganier" wrote: > >>> >>> =3D> I think we need to be careful about using AAA as a potential silve= r >>> bullet for things we don't know how to do in our protocol. More >>> specifically, the property discussed above is a device attribute. AAA i= s >>> usually a user profile not a device profile unless you assume a 1:1 map= ping >>> of device:user, which might be the case in some systems in the US but i= s >>> certainly not the case in the rest of the world. So assuming the device >>> properties will be stored in AAA and attributed to the user is not a go= od >>> way to go. >>> Furthermore, users use devices that have not be "initialised" in AAA al= l the >>> time. A user doesn't ask for an operator's permission before they stick >>> their SIM in a device. So device properties are not known in advance. >> >> I agree with this entirely, which is why I said: >> > > Good points. > The purpose of the multi-access indicator ID is twofold: to enable the MN= to > indicate its capability and willingness for flow mobility (through the > AT_MA_IND attribute). Second, to enable AAA to authorize the user for flo= w > mobility. So, it's the MN which is indicating the device capability, and = the > AAA providing the authorization for the flow mobility service. > > >>>>> I think whether or not AAA can really knows what are the capabilities >>>>> of a network stack on a device is questionable, but let's skip on tha= t >>>>> for now: >> >> but still I wanted to make the point that if to support scenario 2) in >> Rajeev's mail one needs to assume LMA is told by AAA the device >> capabilities, then the =A0MAG can be told that as well by AAA (e.g., at >> same time it gets to know the MNID) and set HI =3D FM appropriately as >> per case 1) thus there's no point in supporting case 2) as per my >> earlier writings on the topic. >> > > There are two parts to consider here. First, the issue of LMA knowing tha= t > the MN is capable and willing to have flow mobility (I think you brought = up > the issue of legacy host). Whether or not MAG is informed by the AAA, the= re > is LMA - AAA interaction. MAG has to be informed of an authenticated MNID for PMIPv6 to work. When authentication of the MNID is based on AAA, the MAG already receives information from AAA. So in a basic 5213 deployment that uses AAA for authentication, there is MAG-AAA interaction. On the other hand LMA - AAA interaction isn't required per se in the 5213 m= odel. > In other words, LMA will go to AAA anywa= y. So, the > AAA providing the attribute to the MAG is redundant exchange which we > thought unnecessary for the multi-access ID. This backward: As above, if AAA is used the MAG will go to AAA, so the AAA providing the attribute to the LMA is the redundant exchange which is unnecessary for multi-access ID. > And, whe= ther the LMA will > actually accept the indicator provided by MAG is moot, since the > authorization should come from elsewhere (AAA). PMIPv6 assumes that the MAG is trusted by the LMA, thus the LMA can accept the indicator provided by the MAG. > Second, the issue of assigning prefixes at the LMA. The LMA should be abl= e > to assign any prefix freely upon any attach. As I said earlier many times, the 5213 model is that of a prefix set allocated at session creation and there has been no reason to depart from that model for purposes of flow mobility, i.e., I can provide flow mobility under that same model thus there's no basis to change that model under this work item. > W= ith HI=3DHandover, it returns > the previously assigned prefix, but there is no prohibition to also retur= n a > hitherto unassigned prefix, AFAICT. As above, the 5213 model factually does not change the prefix set that was allocated at session creation after a handover or at any other point in the session lifetime. As above, there's no basis to change that for the purpose of flow mobility since it is not required / necessary. > Similarly, ev= en with HI =3D FM, the LMA > can assign a new prefix which is not in the current set. Disagree. This is an unwarranted modification of the 5213 model. > This is not a new feature which we need to support. Compared to the 5213 model it is indeed a new feature that a prefix set for a PMIPv6 session can be modified after that session creation, as I've kept explaining again and again. And that new feature is not required to complete the flow mobility work item thus there's no basis to alter the 5213 model in that context. I am surprised we are still discussing this. --julien From julien.ietf@gmail.com Thu Feb 24 11:22:54 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C28F33A680D for ; Thu, 24 Feb 2011 11:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_28=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DECOsLouVV2 for ; Thu, 24 Feb 2011 11:22:54 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id BCD1A3A6802 for ; Thu, 24 Feb 2011 11:22:53 -0800 (PST) Received: by fxm15 with SMTP id 15so899456fxm.31 for ; Thu, 24 Feb 2011 11:23:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OYDJS3/xcBndBR7FfubkNyduHf0V2UL/0hQSHt7FuDg=; b=N/yPNV4jbwPstobrd2T/xkCxmlNh4QR8SexqgGOxfBasuD4LD5L7rVpQ4tbKkk7QlT iMkefc/aN2pCDMh679szEzyXZgaqe6codh224ZCajpDT8tE3QDZUS6W9suKn9BuCZ4uf TJhqNnfUcGlL0xi0MHsm88HLmq+iWhusxaW/Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LLMp2zLQRBcCQxJyjlOIXA/JBQBZr+js7ooAACLsT9/nShIOjoxbPiHlmZ1Q29Lzza hXOjdSV8K8vCyDiKF1t7S/Wt+ao6142rU9y8RjOLQf8AfuKkAguM4/U9pFm2PfYJ9TPw uIi7EU1hndlP2d2hGQLtWRjKfU8DOrGS/sY7E= MIME-Version: 1.0 Received: by 10.223.100.16 with SMTP id w16mr1513506fan.85.1298575314157; Thu, 24 Feb 2011 11:21:54 -0800 (PST) Received: by 10.223.74.142 with HTTP; Thu, 24 Feb 2011 11:21:54 -0800 (PST) In-Reply-To: <3D6C64F2D792B540BAAEBCEF6509363B0EE6DD1072@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> References: <3D6C64F2D792B540BAAEBCEF6509363B0EE6DD1072@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> Date: Thu, 24 Feb 2011 12:21:54 -0700 Message-ID: From: Julien Laganier To: "MELIA, TELEMACO (TELEMACO)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "netext@ietf.org" Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 19:22:54 -0000 Telemaco, I am afraid I do not find your statement below helpful in moving forward. During the discussion many questions have been asked and left unanswered, thus it is both the case that 1) it is premature to summarize the discussion since it hasn't concluded by questions being answered, and 2) the summary that was provided is inappropriate as it does not capture the questions that were left unanswered during the discussion. --julien On Wed, Feb 23, 2011 at 2:13 PM, MELIA, TELEMACO (TELEMACO) wrote: > It captures very well the discussions so far. Agree and support. > > > > telemaco > > > > ________________________________ > > De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la par= t de > Rajeev Koodli > Envoy=E9=A0: mercredi 23 f=E9vrier 2011 07:06 > =C0=A0: netext@ietf.org > Objet=A0: [netext] Flow Mobility discussion - way forward? > > > > Hello folks, > > I guess we all could agree that we have had plenty of discussion. > There are pros and cons of both L2 signaling and IP-based signaling > approaches. I would like to propose a way forward. > > 1) L2 signaling-based: > > MN attaches to a (new) MAGy > MN indicates using (extended) L2 signaling that the attachment is for flo= w > mobility with a new HI=3DFM value > MAGy sends the PBU, and the LMA updates an existing session with the new > interface and MAGy > The old and new prefixes are shared for the session > There is new L2 signaling between the MN and the (old) MAGx to trigger th= e > PBU from MAGx. > This covers the case where we assume that L2 signaling and the associated > extensions are feasible. Keeps the existing RFC 5213 model > > 2) IP-based: > > *If* the PBU from the new MAGy does not carry the new HI=3DFM value, the = LMA > creates a new session (modulo handover^) per RFC 5213. > In this case, the LMA adds the prefix to the session(s) if the policy > requires/allows the MN for flow mobility > The LMA signals the relevant MAGs to provide the prefix(es) when flow > mobility is required > This covers the case where L2 signaling extensions for flow mobility are = not > feasible or are not in place, or for any generic L2 technology > 2) will not come into play if 1) above is in place. > > Comments? > > -Rajeev > > ^ HI=3DHandover will be similar to 1) above except that the forwarding st= ate > for Proxy-CoA-MAGx is removed (and hence no flow mobility). > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > From rkoodli@cisco.com Thu Feb 24 11:37:34 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81B293A680B for ; Thu, 24 Feb 2011 11:37:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.762 X-Spam-Level: X-Spam-Status: No, score=-108.762 tagged_above=-999 required=5 tests=[AWL=-0.759, BAYES_00=-2.599, J_CHICKENPOX_28=0.6, J_CHICKENPOX_64=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlSMtB8W6DQ6 for ; Thu, 24 Feb 2011 11:37:33 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id DA6A33A6807 for ; Thu, 24 Feb 2011 11:37:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rkoodli@cisco.com; l=6294; q=dns/txt; s=iport; t=1298576303; x=1299785903; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=AJxoT9fg/dLli++1tGo01Los5+l/1XoKUxJvHURq4Ho=; b=JS+DrNiw7LpCOfV9J3WJnkxnhHwWgJTnN9lolmB9tZqiI6lLf8IOUbTK vgyQcAM9aKoTkvpj6zfCpz6QqhVSmbAjYVjQf/oj8VB4++Fm33Nis82Qx W/pSeFzxn381vaygehIiS5u/BivC4UY0NLiQoeWISkr2WTHcH5joQUxDR M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKJCZk2tJXG+/2dsb2JhbAClVFxzoiecAoVgBIUQhwyDQ4MM X-IronPort-AV: E=Sophos;i="4.62,219,1297036800"; d="scan'208";a="219798847" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rtp-iport-2.cisco.com with ESMTP; 24 Feb 2011 19:38:22 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p1OJcMvg013575; Thu, 24 Feb 2011 19:38:22 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Feb 2011 13:38:22 -0600 Received: from 10.21.75.48 ([10.21.75.48]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Thu, 24 Feb 2011 19:38:21 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 24 Feb 2011 11:38:47 -0800 From: Rajeev Koodli To: Julien Laganier Message-ID: Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvUWnQWo6lpHKPtOESPqXOQF0Y0Pg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 24 Feb 2011 19:38:22.0624 (UTC) FILETIME=[658F8200:01CBD45A] Cc: netext@ietf.org Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 19:37:34 -0000 Julien, The presumed MAG-AAA interaction in 5213 is for authentication purposes. The LMA-AAA interaction is for authorization purposes. The intent in the multi-access ID is to enable AAA to authorize the LMA for flow mobility purposes. It's kind of interesting that you refer to 3GPP model sometimes, but reticent about it for the LMA - AAA interaction in 3GPP (e.g., your statement below "LMA - AAA interaction is not required per se").. You don't believe that there is a need to add a new prefix to the session. However, you didn't show me that 5213 prohibits adding a new prefix to an existing session. I believe that LMA should be allowed to provide any prefi= x it chooses to, including the previously assigned ones and the new ones. So, let's agree to disagree :-) -Rajeev =20 On 2/24/11 11:17 AM, "Julien Laganier" wrote: > Rajeev, >=20 > Please see inline. >=20 > On Thu, Feb 24, 2011 at 10:42 AM, Rajeev Koodli wrote= : >>=20 >> Julien, >>=20 >> Please treat this as a combined response to your other e-mail as well. >>=20 >> On 2/24/11 8:05 AM, "Julien Laganier" wrote: >>=20 >>>>=20 >>>> =3D> I think we need to be careful about using AAA as a potential silver >>>> bullet for things we don't know how to do in our protocol. More >>>> specifically, the property discussed above is a device attribute. AAA = is >>>> usually a user profile not a device profile unless you assume a 1:1 ma= pping >>>> of device:user, which might be the case in some systems in the US but = is >>>> certainly not the case in the rest of the world. So assuming the devic= e >>>> properties will be stored in AAA and attributed to the user is not a g= ood >>>> way to go. >>>> Furthermore, users use devices that have not be "initialised" in AAA a= ll >>>> the >>>> time. A user doesn't ask for an operator's permission before they stic= k >>>> their SIM in a device. So device properties are not known in advance. >>>=20 >>> I agree with this entirely, which is why I said: >>>=20 >>=20 >> Good points. >> The purpose of the multi-access indicator ID is twofold: to enable the M= N to >> indicate its capability and willingness for flow mobility (through the >> AT_MA_IND attribute). Second, to enable AAA to authorize the user for fl= ow >> mobility. So, it's the MN which is indicating the device capability, and= the >> AAA providing the authorization for the flow mobility service. >>=20 >>=20 >>>>>> I think whether or not AAA can really knows what are the capabilitie= s >>>>>> of a network stack on a device is questionable, but let's skip on th= at >>>>>> for now: >>>=20 >>> but still I wanted to make the point that if to support scenario 2) in >>> Rajeev's mail one needs to assume LMA is told by AAA the device >>> capabilities, then the =A0MAG can be told that as well by AAA (e.g., at >>> same time it gets to know the MNID) and set HI =3D FM appropriately as >>> per case 1) thus there's no point in supporting case 2) as per my >>> earlier writings on the topic. >>>=20 >>=20 >> There are two parts to consider here. First, the issue of LMA knowing th= at >> the MN is capable and willing to have flow mobility (I think you brought= up >> the issue of legacy host). Whether or not MAG is informed by the AAA, th= ere >> is LMA - AAA interaction. >=20 > MAG has to be informed of an authenticated MNID for PMIPv6 to work. > When authentication of the MNID is based on AAA, the MAG already > receives information from AAA. So in a basic 5213 deployment that uses > AAA for authentication, there is MAG-AAA interaction. >=20 > On the other hand LMA - AAA interaction isn't required per se in the 5213 > model. >=20 >> In other words, LMA will go to AAA anyw= ay. >> So, the >> AAA providing the attribute to the MAG is redundant exchange which we >> thought unnecessary for the multi-access ID. >=20 > This backward: As above, if AAA is used the MAG will go to AAA, so the > AAA providing the attribute to the LMA is the redundant exchange which > is unnecessary for multi-access ID. >=20 >> And, wh= ether >> the LMA will >> actually accept the indicator provided by MAG is moot, since the >> authorization should come from elsewhere (AAA). >=20 > PMIPv6 assumes that the MAG is trusted by the LMA, thus the LMA can > accept the indicator provided by the MAG. >=20 >> Second, the issue of assigning prefixes at the LMA. The LMA should be ab= le >> to assign any prefix freely upon any attach. >=20 > As I said earlier many times, the 5213 model is that of a prefix set > allocated at session creation and there has been no reason to depart > from that model for purposes of flow mobility, i.e., I can provide > flow mobility under that same model thus there's no basis to change > that model under this work item. >=20 >> = With >> HI=3DHandover, it returns >> the previously assigned prefix, but there is no prohibition to also retu= rn a >> hitherto unassigned prefix, AFAICT. >=20 > As above, the 5213 model factually does not change the prefix set that > was allocated at session creation after a handover or at any other > point in the session lifetime. As above, there's no basis to change > that for the purpose of flow mobility since it is not required / > necessary. >=20 >> Similarly, e= ven >> with HI =3D FM, the LMA >> can assign a new prefix which is not in the current set. >=20 > Disagree. This is an unwarranted modification of the 5213 model. >=20 >> This is not a new feature which we need to support. >=20 > Compared to the 5213 model it is indeed a new feature that a prefix > set for a PMIPv6 session can be modified after that session creation, > as I've kept explaining again and again. And that new feature is not > required to complete the flow mobility work item thus there's no basis > to alter the 5213 model in that context. >=20 > I am surprised we are still discussing this. >=20 > --julien From julien.ietf@gmail.com Thu Feb 24 13:21:52 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE1783A6807 for ; Thu, 24 Feb 2011 13:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, J_CHICKENPOX_28=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZxt1N0KPCYY for ; Thu, 24 Feb 2011 13:21:51 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id B96B53A6832 for ; Thu, 24 Feb 2011 13:21:50 -0800 (PST) Received: by fxm15 with SMTP id 15so1025093fxm.31 for ; Thu, 24 Feb 2011 13:22:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GuUDQCemDkNturO5sJW+qzyZfRxioGvhi/qEdAHWt6A=; b=Lrf+mKzByNZQ5xAKhbdzH5VyeVVmD6JMP33Xr+FOu+8p9VfZ+SemcPVCBAQ7eouLTd bGRAhvIC2RgwhAAxW+2kQGBXw1bb24pzrB3VOdp5waFE23vHc6n8gGSpk0OHcnvvspcu fNfXwVCF8ETphSanopm3MV5LIzIBncirNjsyE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WYoGLNPoNiWZGDi5jQwGgPVyk4xsNAnjmrLC4HYUx/0fiozSzNj+AIhXg7ogKVMe1k lFrecLuSqmvATWbeZZFDPE4EF3UqZwGl8gyNN/o6Y00IDAy6779fGFyNiTLxThwm+OKx 2mj+E1PvnzWF/iRE+twG0yV47F/qCPvgNqGOo= MIME-Version: 1.0 Received: by 10.223.74.206 with SMTP id v14mr1697535faj.66.1298582439409; Thu, 24 Feb 2011 13:20:39 -0800 (PST) Received: by 10.223.74.142 with HTTP; Thu, 24 Feb 2011 13:20:39 -0800 (PST) In-Reply-To: References: Date: Thu, 24 Feb 2011 14:20:39 -0700 Message-ID: From: Julien Laganier To: Rajeev Koodli Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 21:21:52 -0000 On Thu, Feb 24, 2011 at 12:38 PM, Rajeev Koodli wrote: > > Julien, > > The presumed MAG-AAA interaction in 5213 is for authentication purposes. > The LMA-AAA interaction is for authorization purposes. The intent in the > multi-access ID is to enable AAA to authorize the LMA for flow mobility > purposes. It's kind of interesting that you refer to 3GPP model sometimes= , > but reticent about it for the LMA - AAA interaction in 3GPP (e.g., your > statement below "LMA - AAA interaction is not required per se").. As I said earlier, if AAA is required to be in place to authenticate the MN towards the MAG, that can be used for authorization too. I do not see what is the security requirement that authorization happens in LMA rather than in MAG. That being said, I don't care much about the specifics of the AAA interactions with PMIPv6. My point was, and is, that if you assume that the LMA can know from AAA about the ability for a MN network stack to support flow mobility (as opposed to a legacy node), so can the the MAG. Thus the MAG can set the HI =3D FM to provide flow mobility. As a result the inability of a MAG to know about the MN level of support for flow mobility can't be used as an argument in favor of your model 2) where the LMA knows about MN flow mobility but the MAG doesn't. > You don't believe that there is a need to add a new prefix to the session= . > However, you didn't show me that 5213 prohibits adding a new prefix to an > existing session. I believe that LMA should be allowed to provide any pre= fix > it chooses to, including the previously assigned ones and the new ones. I don't believe there's a need to add a new prefix to an existing session to provide flow mobility. Can you point to a usecase that _requires_ adding a new prefix to an existing session for purposes of providing flow mobility? My reading of 5213 is that it documents a protocol in which the prefix set is allocated at session creation and remains unmodified throughout that session lifetime. 5213 doesn't provide a mean to change the prefix set after session creation. Can you point to a provision of 5213 that allows changing the prefix set of a session after its creation? > So, let's agree to disagree :-) I can certainly agree to disagree on your reading of 5213 on the ability to add prefixes to an existing session, and on the requirement to add new prefix to provide mobility. I do not see any documented or reasoned evidence about these. --julien > On 2/24/11 11:17 AM, "Julien Laganier" wrote: > >> Rajeev, >> >> Please see inline. >> >> On Thu, Feb 24, 2011 at 10:42 AM, Rajeev Koodli wrot= e: >>> >>> Julien, >>> >>> Please treat this as a combined response to your other e-mail as well. >>> >>> On 2/24/11 8:05 AM, "Julien Laganier" wrote: >>> >>>>> >>>>> =3D> I think we need to be careful about using AAA as a potential sil= ver >>>>> bullet for things we don't know how to do in our protocol. More >>>>> specifically, the property discussed above is a device attribute. AAA= is >>>>> usually a user profile not a device profile unless you assume a 1:1 m= apping >>>>> of device:user, which might be the case in some systems in the US but= is >>>>> certainly not the case in the rest of the world. So assuming the devi= ce >>>>> properties will be stored in AAA and attributed to the user is not a = good >>>>> way to go. >>>>> Furthermore, users use devices that have not be "initialised" in AAA = all >>>>> the >>>>> time. A user doesn't ask for an operator's permission before they sti= ck >>>>> their SIM in a device. So device properties are not known in advance. >>>> >>>> I agree with this entirely, which is why I said: >>>> >>> >>> Good points. >>> The purpose of the multi-access indicator ID is twofold: to enable the = MN to >>> indicate its capability and willingness for flow mobility (through the >>> AT_MA_IND attribute). Second, to enable AAA to authorize the user for f= low >>> mobility. So, it's the MN which is indicating the device capability, an= d the >>> AAA providing the authorization for the flow mobility service. >>> >>> >>>>>>> I think whether or not AAA can really knows what are the capabiliti= es >>>>>>> of a network stack on a device is questionable, but let's skip on t= hat >>>>>>> for now: >>>> >>>> but still I wanted to make the point that if to support scenario 2) in >>>> Rajeev's mail one needs to assume LMA is told by AAA the device >>>> capabilities, then the =A0MAG can be told that as well by AAA (e.g., a= t >>>> same time it gets to know the MNID) and set HI =3D FM appropriately as >>>> per case 1) thus there's no point in supporting case 2) as per my >>>> earlier writings on the topic. >>>> >>> >>> There are two parts to consider here. First, the issue of LMA knowing t= hat >>> the MN is capable and willing to have flow mobility (I think you brough= t up >>> the issue of legacy host). Whether or not MAG is informed by the AAA, t= here >>> is LMA - AAA interaction. >> >> MAG has to be informed of an authenticated MNID for PMIPv6 to work. >> When authentication of the MNID is based on AAA, the MAG already >> receives information from AAA. So in a basic 5213 deployment that uses >> AAA for authentication, there is MAG-AAA interaction. >> >> On the other hand LMA - AAA interaction isn't required per se in the 521= 3 >> model. >> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0In o= ther words, LMA will go to AAA anyway. >>> So, the >>> AAA providing the attribute to the MAG is redundant exchange which we >>> thought unnecessary for the multi-access ID. >> >> This backward: As above, if AAA is used the MAG will go to AAA, so the >> AAA providing the attribute to the LMA is the redundant exchange which >> is unnecessary for multi-access ID. >> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0And, whether >>> the LMA will >>> actually accept the indicator provided by MAG is moot, since the >>> authorization should come from elsewhere (AAA). >> >> PMIPv6 assumes that the MAG is trusted by the LMA, thus the LMA can >> accept the indicator provided by the MAG. >> >>> Second, the issue of assigning prefixes at the LMA. The LMA should be a= ble >>> to assign any prefix freely upon any attach. >> >> As I said earlier many times, the 5213 model is that of a prefix set >> allocated at session creation and there has been no reason to depart >> from that model for purposes of flow mobility, i.e., I can provide >> flow mobility under that same model thus there's no basis to change >> that model under this work item. >> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Wi= th >>> HI=3DHandover, it returns >>> the previously assigned prefix, but there is no prohibition to also ret= urn a >>> hitherto unassigned prefix, AFAICT. >> >> As above, the 5213 model factually does not change the prefix set that >> was allocated at session creation after a handover or at any other >> point in the session lifetime. As above, there's no basis to change >> that for the purpose of flow mobility since it is not required / >> necessary. >> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Similarly, even >>> with HI =3D FM, the LMA >>> can assign a new prefix which is not in the current set. >> >> Disagree. This is an unwarranted modification of the 5213 model. >> >>> This is not a new feature which we need to support. >> >> Compared to the 5213 model it is indeed a new feature that a prefix >> set for a PMIPv6 session can be modified after that session creation, >> as I've kept explaining again and again. And that new feature is not >> required to complete the flow mobility work item thus there's no basis >> to alter the 5213 model in that context. >> >> I am surprised we are still discussing this. >> >> --julien > > From hesham@elevatemobile.com Thu Feb 24 16:42:25 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 503ED3A68C9 for ; Thu, 24 Feb 2011 16:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFjMuf-dwN9K for ; Thu, 24 Feb 2011 16:42:24 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 298563A6860 for ; Thu, 24 Feb 2011 16:42:22 -0800 (PST) Received: from [121.219.52.146] (helo=[10.0.0.15]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1Pslm1-0006m1-I5; Fri, 25 Feb 2011 11:43:09 +1100 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Fri, 25 Feb 2011 11:43:03 +1100 From: Hesham Soliman To: Julien Laganier Message-ID: Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvUhPWDavnugQ5Yp0+sDwduaSCVNw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: netext@ietf.org Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 00:42:25 -0000 >> >> => I think we need to be careful about using AAA as a potential silver >> bullet for things we don't know how to do in our protocol. More >> specifically, the property discussed above is a device attribute. AAA is >> usually a user profile not a device profile unless you assume a 1:1 mapping >> of device:user, which might be the case in some systems in the US but is >> certainly not the case in the rest of the world. So assuming the device >> properties will be stored in AAA and attributed to the user is not a good >> way to go. >> Furthermore, users use devices that have not be "initialised" in AAA all the >> time. A user doesn't ask for an operator's permission before they stick >> their SIM in a device. So device properties are not known in advance. > > I agree with this entirely, which is why I said: > >>>> I think whether or not AAA can really knows what are the capabilities >>>> of a network stack on a device is questionable, but let's skip on that >>>> for now: => ok I missed that part, then we're in agreement. > > but still I wanted to make the point that if to support scenario 2) in > Rajeev's mail one needs to assume LMA is told by AAA the device > capabilities, then the MAG can be told that as well by AAA (e.g., at > same time it gets to know the MNID) and set HI = FM appropriately as > per case 1) thus there's no point in supporting case 2) as per my > earlier writings on the topic. => Right, I guess I stopped at the foundational assumption and it didn't sit well with me so I consider the whole scenario invalid, but yes you're right, it can be done that way if the AAA assumption was realistic, but it's not. Hesham > > --julien From rkoodli@cisco.com Thu Feb 24 17:01:57 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04F5D3A659A for ; Thu, 24 Feb 2011 17:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.412 X-Spam-Level: X-Spam-Status: No, score=-108.412 tagged_above=-999 required=5 tests=[AWL=-1.009, BAYES_00=-2.599, J_CHICKENPOX_27=0.6, J_CHICKENPOX_28=0.6, J_CHICKENPOX_64=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdrvR1ItS8SA for ; Thu, 24 Feb 2011 17:01:55 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 517823A68C9 for ; Thu, 24 Feb 2011 17:01:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rkoodli@cisco.com; l=9569; q=dns/txt; s=iport; t=1298595766; x=1299805366; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=33BPWz25LxFichOSSTAOeHUTWeCp7RvCMcA3noaoRQA=; b=RIChRNmr6qD32cz0mZCu82113t1IdTMS+ydot7SRIuvdIB9IH9OKt2R3 3of//sNuOvyCNRLpjjXZdTMJDrEFO6yPEkczdfpIR7i5nTIRKQKQ4enMm sPauHLlFYGtB3dmsh5xeOY1JqolTF5mH6FHxpbiZ1wSTWjTW6dv4BJhsD o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANCOZk2tJXG+/2dsb2JhbAClV1x0oVibcIVgBIUQhwyDRIMN X-IronPort-AV: E=Sophos;i="4.62,221,1297036800"; d="scan'208";a="220043647" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rtp-iport-2.cisco.com with ESMTP; 25 Feb 2011 01:02:45 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p1P12jHt023079; Fri, 25 Feb 2011 01:02:45 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Feb 2011 19:02:45 -0600 Received: from 10.21.74.210 ([10.21.74.210]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Fri, 25 Feb 2011 01:02:45 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 24 Feb 2011 17:03:11 -0800 From: Rajeev Koodli To: Julien Laganier Message-ID: Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvUh8WJKyftzdUdYUG9bggSRNqFBQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 25 Feb 2011 01:02:45.0492 (UTC) FILETIME=[B6557B40:01CBD487] Cc: netext@ietf.org Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 01:01:57 -0000 I do care about the PMIP6 interaction with AAA because the system design needs it. I don't know of a system where LMA relies on MAG for authorization. The use-case for being able to provide a new prefix at attach is robustness= . There is nothing I could see in 5213 that disallows an LMA from providing a prefix which is not in the session, and why should there be any restriction on what prefixes the LMA can provide at attach? I want flow mobility solution to work without only relying on L2 signaling, meaning we should be able to also provide it for HI=3DUnknown. This can be done with IP signaling between LMA and MAG. This is not replacing L2 signaling, but covers the case when HI=3Dunknown. As I have also said earlier, we have different opinions here. Let's move on.. -Rajeev On 2/24/11 1:20 PM, "Julien Laganier" wrote: > On Thu, Feb 24, 2011 at 12:38 PM, Rajeev Koodli wrote= : >>=20 >> Julien, >>=20 >> The presumed MAG-AAA interaction in 5213 is for authentication purposes. >> The LMA-AAA interaction is for authorization purposes. The intent in the >> multi-access ID is to enable AAA to authorize the LMA for flow mobility >> purposes. It's kind of interesting that you refer to 3GPP model sometime= s, >> but reticent about it for the LMA - AAA interaction in 3GPP (e.g., your >> statement below "LMA - AAA interaction is not required per se").. >=20 > As I said earlier, if AAA is required to be in place to authenticate > the MN towards the MAG, that can be used for authorization too. I do > not see what is the security requirement that authorization happens in > LMA rather than in MAG. >=20 > That being said, I don't care much about the specifics of the AAA > interactions with PMIPv6. My point was, and is, that if you assume > that the LMA can know from AAA about the ability for a MN network > stack to support flow mobility (as opposed to a legacy node), so can > the the MAG. Thus the MAG can set the HI =3D FM to provide flow > mobility. As a result the inability of a MAG to know about the MN > level of support for flow mobility can't be used as an argument in > favor of your model 2) where the LMA knows about MN flow mobility but > the MAG doesn't. >=20 >> You don't believe that there is a need to add a new prefix to the sessio= n. >> However, you didn't show me that 5213 prohibits adding a new prefix to a= n >> existing session. I believe that LMA should be allowed to provide any pr= efix >> it chooses to, including the previously assigned ones and the new ones. >=20 > I don't believe there's a need to add a new prefix to an existing > session to provide flow mobility. Can you point to a usecase that > _requires_ adding a new prefix to an existing session for purposes of > providing flow mobility? >=20 > My reading of 5213 is that it documents a protocol in which the prefix > set is allocated at session creation and remains unmodified throughout > that session lifetime. 5213 doesn't provide a mean to change the > prefix set after session creation. Can you point to a provision of > 5213 that allows changing the prefix set of a session after its > creation? >=20 >> So, let's agree to disagree :-) >=20 > I can certainly agree to disagree on your reading of 5213 on the > ability to add prefixes to an existing session, and on the requirement > to add new prefix to provide mobility. I do not see any documented or > reasoned evidence about these. >=20 > --julien >=20 >> On 2/24/11 11:17 AM, "Julien Laganier" wrote: >>=20 >>> Rajeev, >>>=20 >>> Please see inline. >>>=20 >>> On Thu, Feb 24, 2011 at 10:42 AM, Rajeev Koodli wro= te: >>>>=20 >>>> Julien, >>>>=20 >>>> Please treat this as a combined response to your other e-mail as well. >>>>=20 >>>> On 2/24/11 8:05 AM, "Julien Laganier" wrote: >>>>=20 >>>>>>=20 >>>>>> =3D> I think we need to be careful about using AAA as a potential silv= er >>>>>> bullet for things we don't know how to do in our protocol. More >>>>>> specifically, the property discussed above is a device attribute. AA= A is >>>>>> usually a user profile not a device profile unless you assume a 1:1 >>>>>> mapping >>>>>> of device:user, which might be the case in some systems in the US bu= t is >>>>>> certainly not the case in the rest of the world. So assuming the dev= ice >>>>>> properties will be stored in AAA and attributed to the user is not a= good >>>>>> way to go. >>>>>> Furthermore, users use devices that have not be "initialised" in AAA= all >>>>>> the >>>>>> time. A user doesn't ask for an operator's permission before they st= ick >>>>>> their SIM in a device. So device properties are not known in advance= . >>>>>=20 >>>>> I agree with this entirely, which is why I said: >>>>>=20 >>>>=20 >>>> Good points. >>>> The purpose of the multi-access indicator ID is twofold: to enable the= MN >>>> to >>>> indicate its capability and willingness for flow mobility (through the >>>> AT_MA_IND attribute). Second, to enable AAA to authorize the user for = flow >>>> mobility. So, it's the MN which is indicating the device capability, a= nd >>>> the >>>> AAA providing the authorization for the flow mobility service. >>>>=20 >>>>=20 >>>>>>>> I think whether or not AAA can really knows what are the capabilit= ies >>>>>>>> of a network stack on a device is questionable, but let's skip on = that >>>>>>>> for now: >>>>>=20 >>>>> but still I wanted to make the point that if to support scenario 2) i= n >>>>> Rajeev's mail one needs to assume LMA is told by AAA the device >>>>> capabilities, then the =A0MAG can be told that as well by AAA (e.g., at >>>>> same time it gets to know the MNID) and set HI =3D FM appropriately as >>>>> per case 1) thus there's no point in supporting case 2) as per my >>>>> earlier writings on the topic. >>>>>=20 >>>>=20 >>>> There are two parts to consider here. First, the issue of LMA knowing = that >>>> the MN is capable and willing to have flow mobility (I think you broug= ht up >>>> the issue of legacy host). Whether or not MAG is informed by the AAA, = there >>>> is LMA - AAA interaction. >>>=20 >>> MAG has to be informed of an authenticated MNID for PMIPv6 to work. >>> When authentication of the MNID is based on AAA, the MAG already >>> receives information from AAA. So in a basic 5213 deployment that uses >>> AAA for authentication, there is MAG-AAA interaction. >>>=20 >>> On the other hand LMA - AAA interaction isn't required per se in the 52= 13 >>> model. >>>=20 >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0In other words, LMA will go to AAA an= yway. >>>> So, the >>>> AAA providing the attribute to the MAG is redundant exchange which we >>>> thought unnecessary for the multi-access ID. >>>=20 >>> This backward: As above, if AAA is used the MAG will go to AAA, so the >>> AAA providing the attribute to the LMA is the redundant exchange which >>> is unnecessary for multi-access ID. >>>=20 >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0And, >>>> whether >>>> the LMA will >>>> actually accept the indicator provided by MAG is moot, since the >>>> authorization should come from elsewhere (AAA). >>>=20 >>> PMIPv6 assumes that the MAG is trusted by the LMA, thus the LMA can >>> accept the indicator provided by the MAG. >>>=20 >>>> Second, the issue of assigning prefixes at the LMA. The LMA should be = able >>>> to assign any prefix freely upon any attach. >>>=20 >>> As I said earlier many times, the 5213 model is that of a prefix set >>> allocated at session creation and there has been no reason to depart >>> from that model for purposes of flow mobility, i.e., I can provide >>> flow mobility under that same model thus there's no basis to change >>> that model under this work item. >>>=20 >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 >>>> With >>>> HI=3DHandover, it returns >>>> the previously assigned prefix, but there is no prohibition to also re= turn >>>> a >>>> hitherto unassigned prefix, AFAICT. >>>=20 >>> As above, the 5213 model factually does not change the prefix set that >>> was allocated at session creation after a handover or at any other >>> point in the session lifetime. As above, there's no basis to change >>> that for the purpose of flow mobility since it is not required / >>> necessary. >>>=20 >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Similarly,= even >>>> with HI =3D FM, the LMA >>>> can assign a new prefix which is not in the current set. >>>=20 >>> Disagree. This is an unwarranted modification of the 5213 model. >>>=20 >>>> This is not a new feature which we need to support. >>>=20 >>> Compared to the 5213 model it is indeed a new feature that a prefix >>> set for a PMIPv6 session can be modified after that session creation, >>> as I've kept explaining again and again. And that new feature is not >>> required to complete the flow mobility work item thus there's no basis >>> to alter the 5213 model in that context. >>>=20 >>> I am surprised we are still discussing this. >>>=20 >>> --julien >>=20 >>=20 From Xiangsong.Cui@huawei.com Thu Feb 24 18:13:06 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2CCC3A68D8 for ; Thu, 24 Feb 2011 18:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLaHu45+w3hW for ; Thu, 24 Feb 2011 18:13:06 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id B318C3A67A3 for ; Thu, 24 Feb 2011 18:13:05 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LH5001VBI6XX6@szxga03-in.huawei.com> for netext@ietf.org; Fri, 25 Feb 2011 10:13:46 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LH5001NZI6XJY@szxga03-in.huawei.com> for netext@ietf.org; Fri, 25 Feb 2011 10:13:45 +0800 (CST) Received: from [172.24.1.33] (Forwarded-For: [10.111.16.128]) by szxmc03-in.huawei.com (mshttpd); Fri, 25 Feb 2011 10:13:45 +0800 Date: Fri, 25 Feb 2011 10:13:45 +0800 From: Xiangsong Cui In-reply-to: <4D662C48.8070506@neclab.eu> To: Marco Liebsch Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: multipart/mixed; boundary="Boundary_(ID_naHeFCe3oFYFk7xoB6dfFw)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal References: <004001cbd2fb$4e9b3590$ebd1a0b0$%cui@huawei.com> <4D64D88E.6090202@neclab.eu> <006701cbd3cc$4251fe50$c6f5faf0$%cui@huawei.com> <4D662C48.8070506@neclab.eu> Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Request to progress Netext WG I-D: draft-ietf-netext-pmip6-lr-ps-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 02:13:06 -0000 This is a multi-part message in MIME format. --Boundary_(ID_naHeFCe3oFYFk7xoB6dfFw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline > > Do you mean this section is about the situations before and > after "roaming", > > but not about the procedure of "roaming"? > > > yes. > So it seems a bit strange to me. Roaming action does not happen before "roaming" or after "roaming". In the section which is named "Roaming Considerations", it happens that description of "roaming" is absent. Anyway, this is not an objection, but just a minor comment. Best regards, Xiangsong --Boundary_(ID_naHeFCe3oFYFk7xoB6dfFw) Content-type: text/x-vcard; name=c00111037.vcf; charset=gb2312 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=c00111037.vcf Content-description: Card for Xiangsong Cui begin:vcard n:Cui;Xiangsong fn:Xiangsong Cui version:2.1 email;internet:Xiangsong.Cui@huawei.com end:vcard --Boundary_(ID_naHeFCe3oFYFk7xoB6dfFw)-- From julien.ietf@gmail.com Thu Feb 24 18:19:59 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65D2A3A68F3 for ; Thu, 24 Feb 2011 18:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.909 X-Spam-Level: X-Spam-Status: No, score=-2.909 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lp8Th8IpJ7iW for ; Thu, 24 Feb 2011 18:19:58 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 3FE6C3A68F2 for ; Thu, 24 Feb 2011 18:19:58 -0800 (PST) Received: by fxm15 with SMTP id 15so1253951fxm.31 for ; Thu, 24 Feb 2011 18:20:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5jkx92QE/pHeFrywK9qrkCvSgI1RO6BQt4kcSa2SOJc=; b=Tix/86xotULvVjc+mBu6VY535CajUzYX9fdRJr/+zxBxGRAGGGrn+tRHQecNJDiPe9 VO5z5zAuch1du8FKKQyEYOpyk1TYxtCCESEo5PpKEwqZZIadqEY6U7y/iJpTwqTBdhm6 VdyXYmTRBYQ2z6CXDIdByrY3joG5qBPYICoys= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lMdpmQtrDku1BOSa1bInnUN/oMZtNFN1nM3hG9GfUpQhOgOxq3j6qjySbCs3n5kAIO +EcAd6BRywc2QO07KFvjAS9NF5aicdjJ9LBJPteBTzB9TMCxkIg87VgrijDOIKe4YsAT gqi/guU2fom8xRRh4Dwr/1CLnFleL0tUxTojg= MIME-Version: 1.0 Received: by 10.223.103.8 with SMTP id i8mr1912552fao.47.1298600358603; Thu, 24 Feb 2011 18:19:18 -0800 (PST) Received: by 10.223.74.142 with HTTP; Thu, 24 Feb 2011 18:19:18 -0800 (PST) In-Reply-To: References: Date: Thu, 24 Feb 2011 19:19:18 -0700 Message-ID: From: Julien Laganier To: Rajeev Koodli Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 02:19:59 -0000 On Thu, Feb 24, 2011 at 6:03 PM, Rajeev Koodli wrote: > > I do care about the PMIP6 interaction with AAA because the system design > needs it. I don't know of a system where LMA relies on MAG for > authorization. I know of one such a system: In 3GPP the MAG in the ePDG is the PMIPv6 entity that verifies that the user has a subscription that authorizes access via a non-3GPP access by querying AAA. > The use-case for being able to provide a new prefix at attach is robustness. This alone doesn't mean anything. Please explain the relationship between new prefixes and protocol robustness. > There is nothing I could see in 5213 that disallows an LMA from providing a > prefix which is not in the session, and why should there be any restriction > on what prefixes the LMA can provide at attach? I am not talking about attach. I said the prefix set is fixed at session creation and does not change thereafter. If you disagree, please point me to, or write one here, a conformant RFC 5213 PMIPv6 call flow that changes the prefix set _after_ session creation. > I want flow mobility solution to work without only relying on L2 signaling, > meaning we should be able to also provide it for HI=Unknown. This can be > done with IP signaling between LMA and MAG. This is not replacing L2 > signaling, but covers the case when HI=unknown. Again, PMIPV6 has to rely on L2 signaling and does not work without it. You said in an earlier email that the MN indicates to the network its support for flow mobility. If so, that information can be made available to the MAG and the MAG to set the HI to FM appropriately. The case HI=unknown shouldn't happen if the MN indicates to the network its support for flow mobility. > As I have also said earlier, we have different opinions here. Let's move > on.. Not sure I understand. What do you mean by "let's move on"? --julien From trungtm2909@gmail.com Thu Feb 24 19:05:30 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 433903A6903 for ; Thu, 24 Feb 2011 19:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.615 X-Spam-Level: X-Spam-Status: No, score=-2.615 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueuWmey83RtY for ; Thu, 24 Feb 2011 19:05:29 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 514313A6902 for ; Thu, 24 Feb 2011 19:05:29 -0800 (PST) Received: by vws6 with SMTP id 6so1161188vws.31 for ; Thu, 24 Feb 2011 19:06:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eo5Ib2OiDQg25bBHE3HIIE7KjIbUIu0yCceLMHZ9dN8=; b=ikzV4wUFp2yLXYpGI6bQZIn9uGlNakZqv64fbKsrQO9X9Jm2sGlPugnw/vP30icjL9 uDGYFyj/aWRERkz971pZdbt+wwSEcgGtXhplqsijsH7RERi8wmcxsiZOqzfybRJrsw8/ XUTEiStNill+WWs/k8HongKUDjXUKwVGgg6sM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=K+gYbArrisO0qXgSeymqUGJbGhgqJjFI6bn8FZ4xCWyg1+90gKKaBfnB5Sgy8H2l4J IuTTl9bXl+QGmCL2y5yuiA1b+/nAeKJX5UeWt0AxpAMNvqSAOtmT4GKtAvfONauYr975 TYj7eyca2+I0NEFeYdIK6lF/jhW4eGjF3v56U= MIME-Version: 1.0 Received: by 10.52.167.42 with SMTP id zl10mr2855725vdb.299.1298603179260; Thu, 24 Feb 2011 19:06:19 -0800 (PST) Received: by 10.52.162.1 with HTTP; Thu, 24 Feb 2011 19:06:19 -0800 (PST) In-Reply-To: References: Date: Fri, 25 Feb 2011 12:06:19 +0900 Message-ID: From: Tran Minh Trung To: Julien Laganier Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 03:05:30 -0000 Hi Julien, I agree with your arguments that the case HI=3Dunknow shouldn't happen since the MAG is aware of MN's capacity, and the prefix set is fixed at session creation and does not need to be changed thereafter. However, I still wonder about the case that a new session is created on the= fly. Since the PHY interfaces are already attached, how the MN can send L2 signaling to all MAGs to inform that a new session is created when the user starts an application and activate a new PDN connection or a new VPN connection? Could you elaborate more detail in the ML?. It would be nice if you can provide an example from a real system. Regards, TrungTM On Fri, Feb 25, 2011 at 11:19 AM, Julien Laganier w= rote: > On Thu, Feb 24, 2011 at 6:03 PM, Rajeev Koodli wrote: >> >> I do care about the PMIP6 interaction with AAA because the system design >> needs it. I don't know of a system where LMA relies on MAG for >> authorization. > > I know of one such a system: In 3GPP the MAG in the ePDG is the PMIPv6 > entity that verifies that the user has a subscription that authorizes > access via a non-3GPP access by querying AAA. > >> The use-case for being able to provide a new prefix at attach is robustn= ess. > > This alone doesn't mean anything. Please explain the relationship > between new prefixes and protocol robustness. > >> There is nothing I could see in 5213 that disallows an LMA from providin= g a >> prefix which is not in the session, and why should there be any restrict= ion >> on what prefixes the LMA can provide at attach? > > I am not talking about attach. I said the prefix set is fixed at > session creation and does not change thereafter. If you disagree, > please point me to, or write one here, a conformant RFC 5213 PMIPv6 > call flow that changes the prefix set _after_ session creation. > >> I want flow mobility solution to work without only relying on L2 signali= ng, >> meaning we should be able to also provide it for HI=3DUnknown. This can = be >> done with IP signaling between LMA and MAG. This is not replacing L2 >> signaling, but covers the case when HI=3Dunknown. > > Again, PMIPV6 has to rely on L2 signaling and does not work without > it. You said in an earlier email that the MN indicates to the network > its support for flow mobility. If so, that information can be made > available to the MAG and the MAG to set the HI to FM appropriately. > The case HI=3Dunknown shouldn't happen if the MN indicates to the > network its support for flow mobility. > >> As I have also said earlier, we have different opinions here. Let's move >> on.. > > Not sure I understand. What do you mean by "let's move on"? > > --julien > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 From Marco.Liebsch@neclab.eu Fri Feb 25 01:56:17 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45D073A6947 for ; Fri, 25 Feb 2011 01:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fhhuKyGIoZV for ; Fri, 25 Feb 2011 01:56:16 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 5722B3A694D for ; Fri, 25 Feb 2011 01:56:16 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 698772C000203; Fri, 25 Feb 2011 10:58:00 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2k0EkOfvG5c0; Fri, 25 Feb 2011 10:58:00 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.neclab.eu (Postfix) with ESMTP id 4654B2C0001DE; Fri, 25 Feb 2011 10:57:45 +0100 (CET) Received: from [10.1.6.62] (10.1.6.62) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 25 Feb 2011 10:56:52 +0100 Message-ID: <4D677CE4.1050703@neclab.eu> Date: Fri, 25 Feb 2011 10:56:52 +0100 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Xiangsong Cui References: <004001cbd2fb$4e9b3590$ebd1a0b0$%cui@huawei.com> <4D64D88E.6090202@neclab.eu> <006701cbd3cc$4251fe50$c6f5faf0$%cui@huawei.com> <4D662C48.8070506@neclab.eu> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.6.62] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Request to progress Netext WG I-D: draft-ietf-netext-pmip6-lr-ps-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 09:56:17 -0000 Hi Xiangsong, Xiangsong Cui wrote: >>> Do you mean this section is about the situations before and >>> >> after "roaming", >> >>> but not about the procedure of "roaming"? >>> >>> >> yes. >> >> > > So it seems a bit strange to me. > Roaming action does not happen before "roaming" or after "roaming". In the section which is named "Roaming Considerations", it happens that description of "roaming" is absent. > well, roaming covers both, maintaining a session during the the actual movement from an access network of a home provider to a visited provider as well as the set up of a session while being attached already to a visited provider. I think stating the requirement to set up localized routing only when MN's and CN's MAGs share the same provider domain is sufficient and rules out one possible dynamic roaming scenario for the following reason: Assume MN and CN being attached to MAGs in provider domain A and set up a data session. MN moves to provider domain B, which turns the situation into an out of scope use case, as MN's and CN's MAG do not share the same provider domain. Another scenario you refer to is rather rare, I'd say, which is the simultaneous movement of MN and CN from domain A to domain B while having the intention to maintain a localized route between their MAGs. As for the problem statement, I think the current problem analysis and conclusion is sufficient to cover both of the dynamic use cases as well. > Anyway, this is not an objection, but just a minor comment. > Agree and it's good to have such comments and discussion. If we really find out that something needs to be added to the PS, we may get the chance to do this. So far I do not see the need. Thanks for your comments. Best regards, marco > Best regards, > Xiangsong > From Xiangsong.Cui@huawei.com Fri Feb 25 02:38:24 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF8783A695C for ; Fri, 25 Feb 2011 02:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7UhE8SEMxNO for ; Fri, 25 Feb 2011 02:38:24 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id C64BB3A6958 for ; Fri, 25 Feb 2011 02:38:23 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LH600GO05IB6Y@szxga05-in.huawei.com> for netext@ietf.org; Fri, 25 Feb 2011 18:37:23 +0800 (CST) Received: from c00111037 ([10.111.16.128]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LH600KO45I9U8@szxga05-in.huawei.com> for netext@ietf.org; Fri, 25 Feb 2011 18:37:23 +0800 (CST) Date: Fri, 25 Feb 2011 18:37:21 +0800 From: Xiangsong Cui In-reply-to: <4D677CE4.1050703@neclab.eu> To: 'Marco Liebsch' Message-id: <007301cbd4d7$fc7fc440$f57f4cc0$%cui@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcvU0pWz2fqTgBz9Rw2lttmxVDQXPwABUY0Q References: <004001cbd2fb$4e9b3590$ebd1a0b0$%cui@huawei.com> <4D64D88E.6090202@neclab.eu> <006701cbd3cc$4251fe50$c6f5faf0$%cui@huawei.com> <4D662C48.8070506@neclab.eu> <4D677CE4.1050703@neclab.eu> Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Request to progress Netext WG I-D: draft-ietf-netext-pmip6-lr-ps-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 10:38:25 -0000 OK, thanks for your clarification. Best regards, Xiangsong > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of > Marco Liebsch > Sent: Friday, February 25, 2011 5:57 PM > To: Xiangsong Cui > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > Subject: Re: [netext] Request to progress Netext WG I-D: > draft-ietf-netext-pmip6-lr-ps-05.txt > > Hi Xiangsong, > > > Xiangsong Cui wrote: > >>> Do you mean this section is about the situations before and > >>> > >> after "roaming", > >> > >>> but not about the procedure of "roaming"? > >>> > >>> > >> yes. > >> > >> > > > > So it seems a bit strange to me. > > Roaming action does not happen before "roaming" or after "roaming". In the > section which is named "Roaming Considerations", it happens that description > of "roaming" is absent. > > > well, roaming covers both, maintaining a session during the the actual > movement > from an access network of a home provider to a visited provider as well > as the > set up of a session while being attached already to a visited provider. > I think stating > the requirement to set up localized routing only when MN's and CN's MAGs > share the > same provider domain is sufficient and rules out one possible dynamic > roaming scenario > for the following reason: Assume MN and CN being attached to MAGs in > provider domain A > and set up a data session. MN moves to provider domain B, which turns > the situation into > an out of scope use case, as MN's and CN's MAG do not share the same > provider domain. > Another scenario you refer to is rather rare, I'd say, which is the > simultaneous movement > of MN and CN from domain A to domain B while having the intention to > maintain a > localized route between their MAGs. > > As for the problem statement, I think the current problem analysis and > conclusion is > sufficient to cover both of the dynamic use cases as well. > > > Anyway, this is not an objection, but just a minor comment. > > > Agree and it's good to have such comments and discussion. If we really find > out that something needs to be added to the PS, we may get the chance to do > this. So far I do not see the need. > > Thanks for your comments. > > Best regards, > marco > > > > Best regards, > > Xiangsong > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From JuanCarlos.Zuniga@InterDigital.com Fri Feb 25 07:20:45 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54DA03A69DF for ; Fri, 25 Feb 2011 07:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_27=0.6, J_CHICKENPOX_28=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGPEAtId+7ki for ; Fri, 25 Feb 2011 07:20:43 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 183333A682C for ; Fri, 25 Feb 2011 07:20:42 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Feb 2011 10:21:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Feb 2011 10:21:33 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvUh8WJKyftzdUdYUG9bggSRNqFBQAd3hOQ References: From: "Zuniga, Juan Carlos" To: "Rajeev Koodli" X-OriginalArrivalTime: 25 Feb 2011 15:21:34.0626 (UTC) FILETIME=[B0175820:01CBD4FF] Cc: netext@ietf.org Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 15:20:45 -0000 Rajeev, I agree with you.=20 Even if L2 signalling can help the scenario, we should not -only- rely = on that as we might end up in a catch-22 situation. By providing an L3 MAG-LMA signalling solution we would be covered in = case L2 signalling is not there (HI=3Dunknown), and at the same time we = would not preempt a solution that has that L2 signalling to use it. This seems to me like a good way to progress this and move forward. JC > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > Behalf Of Rajeev Koodli > Sent: February 24, 2011 8:03 PM > To: Julien Laganier > Cc: netext@ietf.org > Subject: Re: [netext] Flow Mobility discussion - way forward? >=20 >=20 > I do care about the PMIP6 interaction with AAA because the system > design > needs it. I don't know of a system where LMA relies on MAG for > authorization. >=20 > The use-case for being able to provide a new prefix at attach is > robustness. > There is nothing I could see in 5213 that disallows an LMA from > providing a > prefix which is not in the session, and why should there be any > restriction > on what prefixes the LMA can provide at attach? >=20 > I want flow mobility solution to work without only relying on L2 > signaling, > meaning we should be able to also provide it for HI=3DUnknown. This = can > be > done with IP signaling between LMA and MAG. This is not replacing L2 > signaling, but covers the case when HI=3Dunknown. >=20 > As I have also said earlier, we have different opinions here. Let's > move > on.. >=20 > -Rajeev >=20 >=20 > On 2/24/11 1:20 PM, "Julien Laganier" wrote: >=20 > > On Thu, Feb 24, 2011 at 12:38 PM, Rajeev Koodli > wrote: > >> > >> Julien, > >> > >> The presumed MAG-AAA interaction in 5213 is for authentication > purposes. > >> The LMA-AAA interaction is for authorization purposes. The intent = in > the > >> multi-access ID is to enable AAA to authorize the LMA for flow > mobility > >> purposes. It's kind of interesting that you refer to 3GPP model > sometimes, > >> but reticent about it for the LMA - AAA interaction in 3GPP (e.g., > your > >> statement below "LMA - AAA interaction is not required per se").. > > > > As I said earlier, if AAA is required to be in place to authenticate > > the MN towards the MAG, that can be used for authorization too. I do > > not see what is the security requirement that authorization happens > in > > LMA rather than in MAG. > > > > That being said, I don't care much about the specifics of the AAA > > interactions with PMIPv6. My point was, and is, that if you assume > > that the LMA can know from AAA about the ability for a MN network > > stack to support flow mobility (as opposed to a legacy node), so can > > the the MAG. Thus the MAG can set the HI =3D FM to provide flow > > mobility. As a result the inability of a MAG to know about the MN > > level of support for flow mobility can't be used as an argument in > > favor of your model 2) where the LMA knows about MN flow mobility = but > > the MAG doesn't. > > > >> You don't believe that there is a need to add a new prefix to the > session. > >> However, you didn't show me that 5213 prohibits adding a new prefix > to an > >> existing session. I believe that LMA should be allowed to provide > any prefix > >> it chooses to, including the previously assigned ones and the new > ones. > > > > I don't believe there's a need to add a new prefix to an existing > > session to provide flow mobility. Can you point to a usecase that > > _requires_ adding a new prefix to an existing session for purposes = of > > providing flow mobility? > > > > My reading of 5213 is that it documents a protocol in which the > prefix > > set is allocated at session creation and remains unmodified > throughout > > that session lifetime. 5213 doesn't provide a mean to change the > > prefix set after session creation. Can you point to a provision of > > 5213 that allows changing the prefix set of a session after its > > creation? > > > >> So, let's agree to disagree :-) > > > > I can certainly agree to disagree on your reading of 5213 on the > > ability to add prefixes to an existing session, and on the > requirement > > to add new prefix to provide mobility. I do not see any documented = or > > reasoned evidence about these. > > > > --julien > > > >> On 2/24/11 11:17 AM, "Julien Laganier" > wrote: > >> > >>> Rajeev, > >>> > >>> Please see inline. > >>> > >>> On Thu, Feb 24, 2011 at 10:42 AM, Rajeev Koodli = > wrote: > >>>> > >>>> Julien, > >>>> > >>>> Please treat this as a combined response to your other e-mail as > well. > >>>> > >>>> On 2/24/11 8:05 AM, "Julien Laganier" > wrote: > >>>> > >>>>>> > >>>>>> =3D> I think we need to be careful about using AAA as a = potential > silver > >>>>>> bullet for things we don't know how to do in our protocol. More > >>>>>> specifically, the property discussed above is a device > attribute. AAA is > >>>>>> usually a user profile not a device profile unless you assume a > 1:1 > >>>>>> mapping > >>>>>> of device:user, which might be the case in some systems in the > US but is > >>>>>> certainly not the case in the rest of the world. So assuming = the > device > >>>>>> properties will be stored in AAA and attributed to the user is > not a good > >>>>>> way to go. > >>>>>> Furthermore, users use devices that have not be "initialised" = in > AAA all > >>>>>> the > >>>>>> time. A user doesn't ask for an operator's permission before > they stick > >>>>>> their SIM in a device. So device properties are not known in > advance. > >>>>> > >>>>> I agree with this entirely, which is why I said: > >>>>> > >>>> > >>>> Good points. > >>>> The purpose of the multi-access indicator ID is twofold: to = enable > the MN > >>>> to > >>>> indicate its capability and willingness for flow mobility = (through > the > >>>> AT_MA_IND attribute). Second, to enable AAA to authorize the user > for flow > >>>> mobility. So, it's the MN which is indicating the device > capability, and > >>>> the > >>>> AAA providing the authorization for the flow mobility service. > >>>> > >>>> > >>>>>>>> I think whether or not AAA can really knows what are the > capabilities > >>>>>>>> of a network stack on a device is questionable, but let's = skip > on that > >>>>>>>> for now: > >>>>> > >>>>> but still I wanted to make the point that if to support scenario > 2) in > >>>>> Rajeev's mail one needs to assume LMA is told by AAA the device > >>>>> capabilities, then the =A0MAG can be told that as well by AAA > (e.g., at > >>>>> same time it gets to know the MNID) and set HI =3D FM = appropriately > as > >>>>> per case 1) thus there's no point in supporting case 2) as per = my > >>>>> earlier writings on the topic. > >>>>> > >>>> > >>>> There are two parts to consider here. First, the issue of LMA > knowing that > >>>> the MN is capable and willing to have flow mobility (I think you > brought up > >>>> the issue of legacy host). Whether or not MAG is informed by the > AAA, there > >>>> is LMA - AAA interaction. > >>> > >>> MAG has to be informed of an authenticated MNID for PMIPv6 to = work. > >>> When authentication of the MNID is based on AAA, the MAG already > >>> receives information from AAA. So in a basic 5213 deployment that > uses > >>> AAA for authentication, there is MAG-AAA interaction. > >>> > >>> On the other hand LMA - AAA interaction isn't required per se in > the 5213 > >>> model. > >>> > >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0In other words, LMA will go to > AAA anyway. > >>>> So, the > >>>> AAA providing the attribute to the MAG is redundant exchange = which > we > >>>> thought unnecessary for the multi-access ID. > >>> > >>> This backward: As above, if AAA is used the MAG will go to AAA, so > the > >>> AAA providing the attribute to the LMA is the redundant exchange > which > >>> is unnecessary for multi-access ID. > >>> > >>>> > =A0And, > >>>> whether > >>>> the LMA will > >>>> actually accept the indicator provided by MAG is moot, since the > >>>> authorization should come from elsewhere (AAA). > >>> > >>> PMIPv6 assumes that the MAG is trusted by the LMA, thus the LMA = can > >>> accept the indicator provided by the MAG. > >>> > >>>> Second, the issue of assigning prefixes at the LMA. The LMA = should > be able > >>>> to assign any prefix freely upon any attach. > >>> > >>> As I said earlier many times, the 5213 model is that of a prefix > set > >>> allocated at session creation and there has been no reason to > depart > >>> from that model for purposes of flow mobility, i.e., I can provide > >>> flow mobility under that same model thus there's no basis to = change > >>> that model under this work item. > >>> > >>>> >=20 > >>>> With > >>>> HI=3DHandover, it returns > >>>> the previously assigned prefix, but there is no prohibition to > also return > >>>> a > >>>> hitherto unassigned prefix, AFAICT. > >>> > >>> As above, the 5213 model factually does not change the prefix set > that > >>> was allocated at session creation after a handover or at any other > >>> point in the session lifetime. As above, there's no basis to = change > >>> that for the purpose of flow mobility since it is not required / > >>> necessary. > >>> > >>>> > Similarly, even > >>>> with HI =3D FM, the LMA > >>>> can assign a new prefix which is not in the current set. > >>> > >>> Disagree. This is an unwarranted modification of the 5213 model. > >>> > >>>> This is not a new feature which we need to support. > >>> > >>> Compared to the 5213 model it is indeed a new feature that a = prefix > >>> set for a PMIPv6 session can be modified after that session > creation, > >>> as I've kept explaining again and again. And that new feature is > not > >>> required to complete the flow mobility work item thus there's no > basis > >>> to alter the 5213 model in that context. > >>> > >>> I am surprised we are still discussing this. > >>> > >>> --julien > >> > >> >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From julien.ietf@gmail.com Fri Feb 25 08:00:59 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 670553A6A08 for ; Fri, 25 Feb 2011 08:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[AWL=-0.511, BAYES_00=-2.599, J_CHICKENPOX_27=0.6, J_CHICKENPOX_28=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLrNsbjHTlkY for ; Fri, 25 Feb 2011 08:00:58 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id AFBF83A6A07 for ; Fri, 25 Feb 2011 08:00:57 -0800 (PST) Received: by fxm15 with SMTP id 15so1832760fxm.31 for ; Fri, 25 Feb 2011 08:01:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Oc1hFThPRorIzOuESVHN2bWwp84eFi1QdhiZrRxiT4k=; b=PjPU0kiWK0HIRVxvX4BeVt8hKGHpniEjmJnxkZUgzCRxmv1dCFnA2IZtB2c3PmOa0L xAYAm2Df6lClw9va282rS2huoCoA7aRN0CVFnIrNOCL1W2Ue9at70it8vsAoDd2awDIJ kxS8GPbt6woT1aib+SoFtFADrGqYWqF2LcWPI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WD37ZhjS6PG5fHAa1BYVoohOLONnPcoMX+u2RcXTBEynkstSdtqP3nq8lGG/ykvmzz +Zvlql3v5hPjoX0X6RD7sG/kbX3713eEcxm7X2yLTjeTngJ/3w6MBPTFboIfnsjft4GS rltlMyXfUllDtit/2k+KkdKOR3pWfH3ChKGaA= MIME-Version: 1.0 Received: by 10.223.103.8 with SMTP id i8mr2856007fao.47.1298649709764; Fri, 25 Feb 2011 08:01:49 -0800 (PST) Received: by 10.223.74.142 with HTTP; Fri, 25 Feb 2011 08:01:48 -0800 (PST) In-Reply-To: References: Date: Fri, 25 Feb 2011 09:01:48 -0700 Message-ID: From: Julien Laganier To: "Zuniga, Juan Carlos" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 16:00:59 -0000 JC, Since no PMIPv6 based system can possibly work without the L2 signaling, the L3 MAG-LMA signaling is factually useless. This is has to be the conclusion of this discussion unless someone can provide us with a description of how a system would work without the L2 signaling. --julien On Fri, Feb 25, 2011 at 8:21 AM, Zuniga, Juan Carlos wrote: > Rajeev, > > I agree with you. > > Even if L2 signalling can help the scenario, we should not -only- rely on= that as we might end up in a catch-22 situation. > > By providing an L3 MAG-LMA signalling solution we would be covered in cas= e L2 signalling is not there (HI=3Dunknown), and at the same time we would = not preempt a solution that has that L2 signalling to use it. > > This seems to me like a good way to progress this and move forward. > > JC > >> -----Original Message----- >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On >> Behalf Of Rajeev Koodli >> Sent: February 24, 2011 8:03 PM >> To: Julien Laganier >> Cc: netext@ietf.org >> Subject: Re: [netext] Flow Mobility discussion - way forward? >> >> >> I do care about the PMIP6 interaction with AAA because the system >> design >> needs it. I don't know of a system where LMA relies on MAG for >> authorization. >> >> The use-case for being able to provide a new prefix at attach is >> robustness. >> There is nothing I could see in 5213 that disallows an LMA from >> providing a >> prefix which is not in the session, and why should there be any >> restriction >> on what prefixes the LMA can provide at attach? >> >> I want flow mobility solution to work without only relying on L2 >> signaling, >> meaning we should be able to also provide it for HI=3DUnknown. This can >> be >> done with IP signaling between LMA and MAG. This is not replacing L2 >> signaling, but covers the case when HI=3Dunknown. >> >> As I have also said earlier, we have different opinions here. Let's >> move >> on.. >> >> -Rajeev >> >> >> On 2/24/11 1:20 PM, "Julien Laganier" wrote: >> >> > On Thu, Feb 24, 2011 at 12:38 PM, Rajeev Koodli >> wrote: >> >> >> >> Julien, >> >> >> >> The presumed MAG-AAA interaction in 5213 is for authentication >> purposes. >> >> The LMA-AAA interaction is for authorization purposes. The intent in >> the >> >> multi-access ID is to enable AAA to authorize the LMA for flow >> mobility >> >> purposes. It's kind of interesting that you refer to 3GPP model >> sometimes, >> >> but reticent about it for the LMA - AAA interaction in 3GPP (e.g., >> your >> >> statement below "LMA - AAA interaction is not required per se").. >> > >> > As I said earlier, if AAA is required to be in place to authenticate >> > the MN towards the MAG, that can be used for authorization too. I do >> > not see what is the security requirement that authorization happens >> in >> > LMA rather than in MAG. >> > >> > That being said, I don't care much about the specifics of the AAA >> > interactions with PMIPv6. My point was, and is, that if you assume >> > that the LMA can know from AAA about the ability for a MN network >> > stack to support flow mobility (as opposed to a legacy node), so can >> > the the MAG. Thus the MAG can set the HI =3D FM to provide flow >> > mobility. As a result the inability of a MAG to know about the MN >> > level of support for flow mobility can't be used as an argument in >> > favor of your model 2) where the LMA knows about MN flow mobility but >> > the MAG doesn't. >> > >> >> You don't believe that there is a need to add a new prefix to the >> session. >> >> However, you didn't show me that 5213 prohibits adding a new prefix >> to an >> >> existing session. I believe that LMA should be allowed to provide >> any prefix >> >> it chooses to, including the previously assigned ones and the new >> ones. >> > >> > I don't believe there's a need to add a new prefix to an existing >> > session to provide flow mobility. Can you point to a usecase that >> > _requires_ adding a new prefix to an existing session for purposes of >> > providing flow mobility? >> > >> > My reading of 5213 is that it documents a protocol in which the >> prefix >> > set is allocated at session creation and remains unmodified >> throughout >> > that session lifetime. 5213 doesn't provide a mean to change the >> > prefix set after session creation. Can you point to a provision of >> > 5213 that allows changing the prefix set of a session after its >> > creation? >> > >> >> So, let's agree to disagree :-) >> > >> > I can certainly agree to disagree on your reading of 5213 on the >> > ability to add prefixes to an existing session, and on the >> requirement >> > to add new prefix to provide mobility. I do not see any documented or >> > reasoned evidence about these. >> > >> > --julien >> > >> >> On 2/24/11 11:17 AM, "Julien Laganier" >> wrote: >> >> >> >>> Rajeev, >> >>> >> >>> Please see inline. >> >>> >> >>> On Thu, Feb 24, 2011 at 10:42 AM, Rajeev Koodli >> wrote: >> >>>> >> >>>> Julien, >> >>>> >> >>>> Please treat this as a combined response to your other e-mail as >> well. >> >>>> >> >>>> On 2/24/11 8:05 AM, "Julien Laganier" >> wrote: >> >>>> >> >>>>>> >> >>>>>> =3D> I think we need to be careful about using AAA as a potential >> silver >> >>>>>> bullet for things we don't know how to do in our protocol. More >> >>>>>> specifically, the property discussed above is a device >> attribute. AAA is >> >>>>>> usually a user profile not a device profile unless you assume a >> 1:1 >> >>>>>> mapping >> >>>>>> of device:user, which might be the case in some systems in the >> US but is >> >>>>>> certainly not the case in the rest of the world. So assuming the >> device >> >>>>>> properties will be stored in AAA and attributed to the user is >> not a good >> >>>>>> way to go. >> >>>>>> Furthermore, users use devices that have not be "initialised" in >> AAA all >> >>>>>> the >> >>>>>> time. A user doesn't ask for an operator's permission before >> they stick >> >>>>>> their SIM in a device. So device properties are not known in >> advance. >> >>>>> >> >>>>> I agree with this entirely, which is why I said: >> >>>>> >> >>>> >> >>>> Good points. >> >>>> The purpose of the multi-access indicator ID is twofold: to enable >> the MN >> >>>> to >> >>>> indicate its capability and willingness for flow mobility (through >> the >> >>>> AT_MA_IND attribute). Second, to enable AAA to authorize the user >> for flow >> >>>> mobility. So, it's the MN which is indicating the device >> capability, and >> >>>> the >> >>>> AAA providing the authorization for the flow mobility service. >> >>>> >> >>>> >> >>>>>>>> I think whether or not AAA can really knows what are the >> capabilities >> >>>>>>>> of a network stack on a device is questionable, but let's skip >> on that >> >>>>>>>> for now: >> >>>>> >> >>>>> but still I wanted to make the point that if to support scenario >> 2) in >> >>>>> Rajeev's mail one needs to assume LMA is told by AAA the device >> >>>>> capabilities, then the =A0MAG can be told that as well by AAA >> (e.g., at >> >>>>> same time it gets to know the MNID) and set HI =3D FM appropriatel= y >> as >> >>>>> per case 1) thus there's no point in supporting case 2) as per my >> >>>>> earlier writings on the topic. >> >>>>> >> >>>> >> >>>> There are two parts to consider here. First, the issue of LMA >> knowing that >> >>>> the MN is capable and willing to have flow mobility (I think you >> brought up >> >>>> the issue of legacy host). Whether or not MAG is informed by the >> AAA, there >> >>>> is LMA - AAA interaction. >> >>> >> >>> MAG has to be informed of an authenticated MNID for PMIPv6 to work. >> >>> When authentication of the MNID is based on AAA, the MAG already >> >>> receives information from AAA. So in a basic 5213 deployment that >> uses >> >>> AAA for authentication, there is MAG-AAA interaction. >> >>> >> >>> On the other hand LMA - AAA interaction isn't required per se in >> the 5213 >> >>> model. >> >>> >> >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= In other words, LMA will go to >> AAA anyway. >> >>>> So, the >> >>>> AAA providing the attribute to the MAG is redundant exchange which >> we >> >>>> thought unnecessary for the multi-access ID. >> >>> >> >>> This backward: As above, if AAA is used the MAG will go to AAA, so >> the >> >>> AAA providing the attribute to the LMA is the redundant exchange >> which >> >>> is unnecessary for multi-access ID. >> >>> >> >>>> >> =A0And, >> >>>> whether >> >>>> the LMA will >> >>>> actually accept the indicator provided by MAG is moot, since the >> >>>> authorization should come from elsewhere (AAA). >> >>> >> >>> PMIPv6 assumes that the MAG is trusted by the LMA, thus the LMA can >> >>> accept the indicator provided by the MAG. >> >>> >> >>>> Second, the issue of assigning prefixes at the LMA. The LMA should >> be able >> >>>> to assign any prefix freely upon any attach. >> >>> >> >>> As I said earlier many times, the 5213 model is that of a prefix >> set >> >>> allocated at session creation and there has been no reason to >> depart >> >>> from that model for purposes of flow mobility, i.e., I can provide >> >>> flow mobility under that same model thus there's no basis to change >> >>> that model under this work item. >> >>> >> >>>> >> >> >>>> With >> >>>> HI=3DHandover, it returns >> >>>> the previously assigned prefix, but there is no prohibition to >> also return >> >>>> a >> >>>> hitherto unassigned prefix, AFAICT. >> >>> >> >>> As above, the 5213 model factually does not change the prefix set >> that >> >>> was allocated at session creation after a handover or at any other >> >>> point in the session lifetime. As above, there's no basis to change >> >>> that for the purpose of flow mobility since it is not required / >> >>> necessary. >> >>> >> >>>> >> Similarly, even >> >>>> with HI =3D FM, the LMA >> >>>> can assign a new prefix which is not in the current set. >> >>> >> >>> Disagree. This is an unwarranted modification of the 5213 model. >> >>> >> >>>> This is not a new feature which we need to support. >> >>> >> >>> Compared to the 5213 model it is indeed a new feature that a prefix >> >>> set for a PMIPv6 session can be modified after that session >> creation, >> >>> as I've kept explaining again and again. And that new feature is >> not >> >>> required to complete the flow mobility work item thus there's no >> basis >> >>> to alter the 5213 model in that context. >> >>> >> >>> I am surprised we are still discussing this. >> >>> >> >>> --julien >> >> >> >> >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From julien.ietf@gmail.com Fri Feb 25 08:06:11 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AE003A6A0E for ; Fri, 25 Feb 2011 08:06:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00xitkVOK0XL for ; Fri, 25 Feb 2011 08:06:10 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 098693A6A10 for ; Fri, 25 Feb 2011 08:06:09 -0800 (PST) Received: by fxm15 with SMTP id 15so1837868fxm.31 for ; Fri, 25 Feb 2011 08:07:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gLI9vKQmkIPZQHTcn60+Hoq4jNBSq0jrDoZgy7bIUkw=; b=EZMpIgMzDPheOMlMUqLzZI0hRwzroGtdR4KADf3HyBY2Ao/tgjTXC1AJn6aCN81TrS 45Ga2tDMvwxlQvvVN/YDQG/Z6d6mhUNtQRdRz7hHEmYJEG0OVntHLcbqSe9I9Dnsbf5t vYb0FS5mPuATP/RkDaV/OT2tAhksBzEWalkiI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=f7WgnhQfi0DpPvxc9/p2JRg4z7+879OguwqGbea8nfmpmJkZyjJtURVZun3TTrWTGA P20JnPRWmJtYvDbQc+r0jWEsfIcio26ByYNfIBjaRF7yxiSdcVpkn5gIa9cvEx6XmFg5 2g+KnEbAokigtyzJaTnriXh0V93RZbNJI0Uwk= MIME-Version: 1.0 Received: by 10.223.100.16 with SMTP id w16mr2872106fan.85.1298650019081; Fri, 25 Feb 2011 08:06:59 -0800 (PST) Received: by 10.223.74.142 with HTTP; Fri, 25 Feb 2011 08:06:58 -0800 (PST) In-Reply-To: References: Date: Fri, 25 Feb 2011 09:06:58 -0700 Message-ID: From: Julien Laganier To: Tran Minh Trung Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 16:06:11 -0000 Tran, When parallel sessions are running across a same physical interface, there will need to be session separation at L2 because otherwise packets from different sessions can't be distnguished from each others by either of the MAG or the MN. This L2 separation has to be triggered by some L2 signaling: even though the physical interface might already be attached, there will have to be another L2 signaling to attach the new logical interface for the new session. If you want to see example of real system, please have a look at the relevant 3GPP specifications, e.g., TS 23.402. Thanks, --julien On Thu, Feb 24, 2011 at 8:06 PM, Tran Minh Trung wr= ote: > Hi Julien, > > I agree with your arguments that the case HI=3Dunknow shouldn't happen > since the MAG is aware of MN's capacity, and the prefix set is fixed > at session creation and does not need to be changed thereafter. > > However, I still wonder about the case that a new session is created on t= he fly. > > Since the PHY interfaces are already attached, how the MN can send L2 > signaling to all MAGs to inform that a new session is created when the > user starts an application and activate a new PDN connection or a new > VPN connection? > > Could you elaborate more detail in the ML?. > =A0It would be nice if you can provide an example from a real system. > > Regards, > TrungTM > > > > > On Fri, Feb 25, 2011 at 11:19 AM, Julien Laganier = wrote: >> On Thu, Feb 24, 2011 at 6:03 PM, Rajeev Koodli wrote= : >>> >>> I do care about the PMIP6 interaction with AAA because the system desig= n >>> needs it. I don't know of a system where LMA relies on MAG for >>> authorization. >> >> I know of one such a system: In 3GPP the MAG in the ePDG is the PMIPv6 >> entity that verifies that the user has a subscription that authorizes >> access via a non-3GPP access by querying AAA. >> >>> The use-case for being able to provide a new prefix at attach is robust= ness. >> >> This alone doesn't mean anything. Please explain the relationship >> between new prefixes and protocol robustness. >> >>> There is nothing I could see in 5213 that disallows an LMA from providi= ng a >>> prefix which is not in the session, and why should there be any restric= tion >>> on what prefixes the LMA can provide at attach? >> >> I am not talking about attach. I said the prefix set is fixed at >> session creation and does not change thereafter. If you disagree, >> please point me to, or write one here, a conformant RFC 5213 PMIPv6 >> call flow that changes the prefix set _after_ session creation. >> >>> I want flow mobility solution to work without only relying on L2 signal= ing, >>> meaning we should be able to also provide it for HI=3DUnknown. This can= be >>> done with IP signaling between LMA and MAG. This is not replacing L2 >>> signaling, but covers the case when HI=3Dunknown. >> >> Again, PMIPV6 has to rely on L2 signaling and does not work without >> it. You said in an earlier email that the MN indicates to the network >> its support for flow mobility. If so, that information can be made >> available to the MAG and the MAG to set the HI to FM appropriately. >> The case HI=3Dunknown shouldn't happen if the MN indicates to the >> network its support for flow mobility. >> >>> As I have also said earlier, we have different opinions here. Let's mov= e >>> on.. >> >> Not sure I understand. What do you mean by "let's move on"? >> >> --julien >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> > > > > -- > Ph.D., Senior Member > Electronics and Telecommunications Research Institute > Standards Research Center > 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA > Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 > From cjbc@it.uc3m.es Fri Feb 25 11:49:33 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5368C3A6831 for ; Fri, 25 Feb 2011 11:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_28=0.6, J_CHICKENPOX_64=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kt4qjSQGiUZ7 for ; Fri, 25 Feb 2011 11:49:31 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 316433A67FB for ; Fri, 25 Feb 2011 11:49:30 -0800 (PST) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id F41666FE0D2; Fri, 25 Feb 2011 20:50:21 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Julien Laganier In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Nz1IQfghI4I+wF7fZnmS" Organization: Universidad Carlos III de Madrid Date: Fri, 25 Feb 2011 20:51:41 +0100 Message-ID: <1298663501.3608.141.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17978.000 Cc: netext@ietf.org, "Zuniga, Juan Carlos" Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 19:49:33 -0000 --=-Nz1IQfghI4I+wF7fZnmS Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Julien, On Fri, 2011-02-25 at 09:01 -0700, Julien Laganier wrote: > JC, >=20 > Since no PMIPv6 based system can possibly work without the L2 > signaling, the L3 MAG-LMA signaling is factually useless. I have a PMIPv6 system working in my lab and there is no L2 signaling at all. Optionally, I can enable the APs attached to the MAG detect the MN attachment and use that as trigger for the PBU (instead of relaying on ND). I agree L2 signaling is used by most deployments as in fact PMIPv6 was designed with many things "out-of-the-scope of the spec" (it's there where L2 signaling appears), but I disagree L2 signaling is completely necessarily.=20 I agree with Rajeev's suggestion to move forward. Thanks, Carlos >=20 > This is has to be the conclusion of this discussion unless someone can > provide us with a description of how a system would work without the > L2 signaling. >=20 > --julien >=20 > On Fri, Feb 25, 2011 at 8:21 AM, Zuniga, Juan Carlos > wrote: > > Rajeev, > > > > I agree with you. > > > > Even if L2 signalling can help the scenario, we should not -only- rely = on that as we might end up in a catch-22 situation. > > > > By providing an L3 MAG-LMA signalling solution we would be covered in c= ase L2 signalling is not there (HI=3Dunknown), and at the same time we woul= d not preempt a solution that has that L2 signalling to use it. > > > > This seems to me like a good way to progress this and move forward. > > > > JC > > > >> -----Original Message----- > >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > >> Behalf Of Rajeev Koodli > >> Sent: February 24, 2011 8:03 PM > >> To: Julien Laganier > >> Cc: netext@ietf.org > >> Subject: Re: [netext] Flow Mobility discussion - way forward? > >> > >> > >> I do care about the PMIP6 interaction with AAA because the system > >> design > >> needs it. I don't know of a system where LMA relies on MAG for > >> authorization. > >> > >> The use-case for being able to provide a new prefix at attach is > >> robustness. > >> There is nothing I could see in 5213 that disallows an LMA from > >> providing a > >> prefix which is not in the session, and why should there be any > >> restriction > >> on what prefixes the LMA can provide at attach? > >> > >> I want flow mobility solution to work without only relying on L2 > >> signaling, > >> meaning we should be able to also provide it for HI=3DUnknown. This ca= n > >> be > >> done with IP signaling between LMA and MAG. This is not replacing L2 > >> signaling, but covers the case when HI=3Dunknown. > >> > >> As I have also said earlier, we have different opinions here. Let's > >> move > >> on.. > >> > >> -Rajeev > >> > >> > >> On 2/24/11 1:20 PM, "Julien Laganier" wrote: > >> > >> > On Thu, Feb 24, 2011 at 12:38 PM, Rajeev Koodli > >> wrote: > >> >> > >> >> Julien, > >> >> > >> >> The presumed MAG-AAA interaction in 5213 is for authentication > >> purposes. > >> >> The LMA-AAA interaction is for authorization purposes. The intent i= n > >> the > >> >> multi-access ID is to enable AAA to authorize the LMA for flow > >> mobility > >> >> purposes. It's kind of interesting that you refer to 3GPP model > >> sometimes, > >> >> but reticent about it for the LMA - AAA interaction in 3GPP (e.g., > >> your > >> >> statement below "LMA - AAA interaction is not required per se").. > >> > > >> > As I said earlier, if AAA is required to be in place to authenticate > >> > the MN towards the MAG, that can be used for authorization too. I do > >> > not see what is the security requirement that authorization happens > >> in > >> > LMA rather than in MAG. > >> > > >> > That being said, I don't care much about the specifics of the AAA > >> > interactions with PMIPv6. My point was, and is, that if you assume > >> > that the LMA can know from AAA about the ability for a MN network > >> > stack to support flow mobility (as opposed to a legacy node), so can > >> > the the MAG. Thus the MAG can set the HI =3D FM to provide flow > >> > mobility. As a result the inability of a MAG to know about the MN > >> > level of support for flow mobility can't be used as an argument in > >> > favor of your model 2) where the LMA knows about MN flow mobility bu= t > >> > the MAG doesn't. > >> > > >> >> You don't believe that there is a need to add a new prefix to the > >> session. > >> >> However, you didn't show me that 5213 prohibits adding a new prefix > >> to an > >> >> existing session. I believe that LMA should be allowed to provide > >> any prefix > >> >> it chooses to, including the previously assigned ones and the new > >> ones. > >> > > >> > I don't believe there's a need to add a new prefix to an existing > >> > session to provide flow mobility. Can you point to a usecase that > >> > _requires_ adding a new prefix to an existing session for purposes o= f > >> > providing flow mobility? > >> > > >> > My reading of 5213 is that it documents a protocol in which the > >> prefix > >> > set is allocated at session creation and remains unmodified > >> throughout > >> > that session lifetime. 5213 doesn't provide a mean to change the > >> > prefix set after session creation. Can you point to a provision of > >> > 5213 that allows changing the prefix set of a session after its > >> > creation? > >> > > >> >> So, let's agree to disagree :-) > >> > > >> > I can certainly agree to disagree on your reading of 5213 on the > >> > ability to add prefixes to an existing session, and on the > >> requirement > >> > to add new prefix to provide mobility. I do not see any documented o= r > >> > reasoned evidence about these. > >> > > >> > --julien > >> > > >> >> On 2/24/11 11:17 AM, "Julien Laganier" > >> wrote: > >> >> > >> >>> Rajeev, > >> >>> > >> >>> Please see inline. > >> >>> > >> >>> On Thu, Feb 24, 2011 at 10:42 AM, Rajeev Koodli > >> wrote: > >> >>>> > >> >>>> Julien, > >> >>>> > >> >>>> Please treat this as a combined response to your other e-mail as > >> well. > >> >>>> > >> >>>> On 2/24/11 8:05 AM, "Julien Laganier" > >> wrote: > >> >>>> > >> >>>>>> > >> >>>>>> =3D> I think we need to be careful about using AAA as a potenti= al > >> silver > >> >>>>>> bullet for things we don't know how to do in our protocol. More > >> >>>>>> specifically, the property discussed above is a device > >> attribute. AAA is > >> >>>>>> usually a user profile not a device profile unless you assume a > >> 1:1 > >> >>>>>> mapping > >> >>>>>> of device:user, which might be the case in some systems in the > >> US but is > >> >>>>>> certainly not the case in the rest of the world. So assuming th= e > >> device > >> >>>>>> properties will be stored in AAA and attributed to the user is > >> not a good > >> >>>>>> way to go. > >> >>>>>> Furthermore, users use devices that have not be "initialised" i= n > >> AAA all > >> >>>>>> the > >> >>>>>> time. A user doesn't ask for an operator's permission before > >> they stick > >> >>>>>> their SIM in a device. So device properties are not known in > >> advance. > >> >>>>> > >> >>>>> I agree with this entirely, which is why I said: > >> >>>>> > >> >>>> > >> >>>> Good points. > >> >>>> The purpose of the multi-access indicator ID is twofold: to enabl= e > >> the MN > >> >>>> to > >> >>>> indicate its capability and willingness for flow mobility (throug= h > >> the > >> >>>> AT_MA_IND attribute). Second, to enable AAA to authorize the user > >> for flow > >> >>>> mobility. So, it's the MN which is indicating the device > >> capability, and > >> >>>> the > >> >>>> AAA providing the authorization for the flow mobility service. > >> >>>> > >> >>>> > >> >>>>>>>> I think whether or not AAA can really knows what are the > >> capabilities > >> >>>>>>>> of a network stack on a device is questionable, but let's ski= p > >> on that > >> >>>>>>>> for now: > >> >>>>> > >> >>>>> but still I wanted to make the point that if to support scenario > >> 2) in > >> >>>>> Rajeev's mail one needs to assume LMA is told by AAA the device > >> >>>>> capabilities, then the MAG can be told that as well by AAA > >> (e.g., at > >> >>>>> same time it gets to know the MNID) and set HI =3D FM appropriat= ely > >> as > >> >>>>> per case 1) thus there's no point in supporting case 2) as per m= y > >> >>>>> earlier writings on the topic. > >> >>>>> > >> >>>> > >> >>>> There are two parts to consider here. First, the issue of LMA > >> knowing that > >> >>>> the MN is capable and willing to have flow mobility (I think you > >> brought up > >> >>>> the issue of legacy host). Whether or not MAG is informed by the > >> AAA, there > >> >>>> is LMA - AAA interaction. > >> >>> > >> >>> MAG has to be informed of an authenticated MNID for PMIPv6 to work= . > >> >>> When authentication of the MNID is based on AAA, the MAG already > >> >>> receives information from AAA. So in a basic 5213 deployment that > >> uses > >> >>> AAA for authentication, there is MAG-AAA interaction. > >> >>> > >> >>> On the other hand LMA - AAA interaction isn't required per se in > >> the 5213 > >> >>> model. > >> >>> > >> >>>> In other words, LMA will go to > >> AAA anyway. > >> >>>> So, the > >> >>>> AAA providing the attribute to the MAG is redundant exchange whic= h > >> we > >> >>>> thought unnecessary for the multi-access ID. > >> >>> > >> >>> This backward: As above, if AAA is used the MAG will go to AAA, so > >> the > >> >>> AAA providing the attribute to the LMA is the redundant exchange > >> which > >> >>> is unnecessary for multi-access ID. > >> >>> > >> >>>> > >> And, > >> >>>> whether > >> >>>> the LMA will > >> >>>> actually accept the indicator provided by MAG is moot, since the > >> >>>> authorization should come from elsewhere (AAA). > >> >>> > >> >>> PMIPv6 assumes that the MAG is trusted by the LMA, thus the LMA ca= n > >> >>> accept the indicator provided by the MAG. > >> >>> > >> >>>> Second, the issue of assigning prefixes at the LMA. The LMA shoul= d > >> be able > >> >>>> to assign any prefix freely upon any attach. > >> >>> > >> >>> As I said earlier many times, the 5213 model is that of a prefix > >> set > >> >>> allocated at session creation and there has been no reason to > >> depart > >> >>> from that model for purposes of flow mobility, i.e., I can provide > >> >>> flow mobility under that same model thus there's no basis to chang= e > >> >>> that model under this work item. > >> >>> > >> >>>> > >> > >> >>>> With > >> >>>> HI=3DHandover, it returns > >> >>>> the previously assigned prefix, but there is no prohibition to > >> also return > >> >>>> a > >> >>>> hitherto unassigned prefix, AFAICT. > >> >>> > >> >>> As above, the 5213 model factually does not change the prefix set > >> that > >> >>> was allocated at session creation after a handover or at any other > >> >>> point in the session lifetime. As above, there's no basis to chang= e > >> >>> that for the purpose of flow mobility since it is not required / > >> >>> necessary. > >> >>> > >> >>>> > >> Similarly, even > >> >>>> with HI =3D FM, the LMA > >> >>>> can assign a new prefix which is not in the current set. > >> >>> > >> >>> Disagree. This is an unwarranted modification of the 5213 model. > >> >>> > >> >>>> This is not a new feature which we need to support. > >> >>> > >> >>> Compared to the 5213 model it is indeed a new feature that a prefi= x > >> >>> set for a PMIPv6 session can be modified after that session > >> creation, > >> >>> as I've kept explaining again and again. And that new feature is > >> not > >> >>> required to complete the flow mobility work item thus there's no > >> basis > >> >>> to alter the 5213 model in that context. > >> >>> > >> >>> I am surprised we are still discussing this. > >> >>> > >> >>> --julien > >> >> > >> >> > >> > >> _______________________________________________ > >> netext mailing list > >> netext@ietf.org > >> https://www.ietf.org/mailman/listinfo/netext > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-Nz1IQfghI4I+wF7fZnmS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1oCE0ACgkQNdy6TdFwT2f+YwCglLfftRsAhAR5NarpVL+vp/JN 4xsAmgNlfwCHqYCPt7GYm4TEbJnqM139 =nQAz -----END PGP SIGNATURE----- --=-Nz1IQfghI4I+wF7fZnmS-- From julien.ietf@gmail.com Fri Feb 25 11:58:21 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C09633A6A0E for ; Fri, 25 Feb 2011 11:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTKZbp54Hreu for ; Fri, 25 Feb 2011 11:58:21 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id B12373A67FB for ; Fri, 25 Feb 2011 11:58:20 -0800 (PST) Received: by fxm15 with SMTP id 15so2082597fxm.31 for ; Fri, 25 Feb 2011 11:59:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=asFamo8gK1wFmpP/8Qd0cfYgYVvU0qdRhL3+WYLXvgI=; b=qZF0NbhQVRHSfivDl1TTtsQc/LUp87UVtUzxJGuJ9L1R8ibggZ77OedzRVXE9RRdJM y11KwtWdEGLUfKJ1L7L6U8DOLxhlL2EdVb0olDgesmWVTo8B7pZ7TIZR4m+DkNar3sJz buq9QqjLy8jBGAnFmVBj1ecCAHWwPSz0AUQWA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZYEMmChdDdGXjhSPxgfdJ6uqpsu3f97Tc3jvNPKU90ISwSGplOfnIjL0D52JIVKJu3 snA1AqZaPXENBsbD0bMMLntAyrHqarVUKhHa1m20bmOt8/m2vpMj9yxKqmeYZ+w1yVZA iEmGp6A5HF5hou6XHNOeHiFug08NasU7btsho= MIME-Version: 1.0 Received: by 10.223.103.4 with SMTP id i4mr2748244fao.123.1298663953092; Fri, 25 Feb 2011 11:59:13 -0800 (PST) Received: by 10.223.74.142 with HTTP; Fri, 25 Feb 2011 11:59:12 -0800 (PST) In-Reply-To: <1298663501.3608.141.camel@acorde.it.uc3m.es> References: <1298663501.3608.141.camel@acorde.it.uc3m.es> Date: Fri, 25 Feb 2011 12:59:12 -0700 Message-ID: From: Julien Laganier To: cjbc@it.uc3m.es Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org, "Zuniga, Juan Carlos" Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 19:58:21 -0000 2011/2/25 Carlos Jes=FAs Bernardos Cano : > Hi Julien, > > On Fri, 2011-02-25 at 09:01 -0700, Julien Laganier wrote: >> JC, >> >> Since no PMIPv6 based system can possibly work without the L2 >> signaling, the L3 MAG-LMA signaling is factually useless. > > I have a PMIPv6 system working in my lab and there is no L2 signaling at > all. Optionally, I can enable the APs attached to the MAG detect the MN > attachment and use that as trigger for the PBU (instead of relaying on > ND). I agree L2 signaling is used by most deployments as in fact PMIPv6 > was designed with many things "out-of-the-scope of the spec" (it's there > where L2 signaling appears), but I disagree L2 signaling is completely > necessarily. Having a prototype that works in a lab isn't a proof that the system works in the real world. From my perspective L2 signaling is a requirement and I do not know how to build a real world system based on PMIPv6 that doesn't have them. I have two questions regarding the real world world applicability of your system that works without L2 signaling: 1) what is the trigger to the PBU if it's not the L2 signaling? 2) How does the network decides it can offer flow mobility to a host in the absence of a layer 2 signaling from the host that indicates this host's support for flow mobility / inter-access handoffs? > I agree with Rajeev's suggestion to move forward. I am happy to move forward when the valid technical questions I've asked are answered. --julien From JuanCarlos.Zuniga@InterDigital.com Sat Feb 26 12:03:24 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 750623A6816 for ; Sat, 26 Feb 2011 12:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.249 X-Spam-Level: X-Spam-Status: No, score=-1.249 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_27=0.6, J_CHICKENPOX_28=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3xf7Nvan9sU for ; Sat, 26 Feb 2011 12:03:23 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id AA7F43A6814 for ; Sat, 26 Feb 2011 12:03:22 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 26 Feb 2011 15:04:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 26 Feb 2011 15:04:15 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvVBVHJF9cDsamzRL+4ToVk1Bz6uQA6vPBQ References: From: "Zuniga, Juan Carlos" To: "Julien Laganier" X-OriginalArrivalTime: 26 Feb 2011 20:04:17.0345 (UTC) FILETIME=[59129B10:01CBD5F0] Cc: netext@ietf.org Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 20:03:24 -0000 Julien, Ok, let me rephrase it. I should have said "new" L2 signalling. If IP Flow Mobility L2 signalling becomes available in the future, fine. = However, not to rely on this assumption and also to support scenarios = where the decision for the flow mobility could come from the LMA, I see = value in defining also the L3 signalling. In other words, if L2 signalling for IP Flow mobility is there, you = simply don't use this L3 signalling. If new L2 is NOT there, then you = can rely on this L3 mechanism.=20 I see no harm and a lot of value with this approach.=20 To me this is a good compromise and good way to move forward. JC > -----Original Message----- > From: Julien Laganier [mailto:julien.ietf@gmail.com] > Sent: February 25, 2011 11:02 AM > To: Zuniga, Juan Carlos > Cc: Rajeev Koodli; netext@ietf.org > Subject: Re: [netext] Flow Mobility discussion - way forward? >=20 > JC, >=20 > Since no PMIPv6 based system can possibly work without the L2 > signaling, the L3 MAG-LMA signaling is factually useless. >=20 > This is has to be the conclusion of this discussion unless someone can > provide us with a description of how a system would work without the > L2 signaling. >=20 > --julien >=20 > On Fri, Feb 25, 2011 at 8:21 AM, Zuniga, Juan Carlos > wrote: > > Rajeev, > > > > I agree with you. > > > > Even if L2 signalling can help the scenario, we should not -only- > rely on that as we might end up in a catch-22 situation. > > > > By providing an L3 MAG-LMA signalling solution we would be covered = in > case L2 signalling is not there (HI=3Dunknown), and at the same time = we > would not preempt a solution that has that L2 signalling to use it. > > > > This seems to me like a good way to progress this and move forward. > > > > JC > > > >> -----Original Message----- > >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > >> Behalf Of Rajeev Koodli > >> Sent: February 24, 2011 8:03 PM > >> To: Julien Laganier > >> Cc: netext@ietf.org > >> Subject: Re: [netext] Flow Mobility discussion - way forward? > >> > >> > >> I do care about the PMIP6 interaction with AAA because the system > >> design > >> needs it. I don't know of a system where LMA relies on MAG for > >> authorization. > >> > >> The use-case for being able to provide a new prefix at attach is > >> robustness. > >> There is nothing I could see in 5213 that disallows an LMA from > >> providing a > >> prefix which is not in the session, and why should there be any > >> restriction > >> on what prefixes the LMA can provide at attach? > >> > >> I want flow mobility solution to work without only relying on L2 > >> signaling, > >> meaning we should be able to also provide it for HI=3DUnknown. This > can > >> be > >> done with IP signaling between LMA and MAG. This is not replacing = L2 > >> signaling, but covers the case when HI=3Dunknown. > >> > >> As I have also said earlier, we have different opinions here. Let's > >> move > >> on.. > >> > >> -Rajeev > >> > >> > >> On 2/24/11 1:20 PM, "Julien Laganier" = wrote: > >> > >> > On Thu, Feb 24, 2011 at 12:38 PM, Rajeev Koodli > > >> wrote: > >> >> > >> >> Julien, > >> >> > >> >> The presumed MAG-AAA interaction in 5213 is for authentication > >> purposes. > >> >> The LMA-AAA interaction is for authorization purposes. The = intent > in > >> the > >> >> multi-access ID is to enable AAA to authorize the LMA for flow > >> mobility > >> >> purposes. It's kind of interesting that you refer to 3GPP model > >> sometimes, > >> >> but reticent about it for the LMA - AAA interaction in 3GPP > (e.g., > >> your > >> >> statement below "LMA - AAA interaction is not required per = se").. > >> > > >> > As I said earlier, if AAA is required to be in place to > authenticate > >> > the MN towards the MAG, that can be used for authorization too. I > do > >> > not see what is the security requirement that authorization > happens > >> in > >> > LMA rather than in MAG. > >> > > >> > That being said, I don't care much about the specifics of the AAA > >> > interactions with PMIPv6. My point was, and is, that if you = assume > >> > that the LMA can know from AAA about the ability for a MN network > >> > stack to support flow mobility (as opposed to a legacy node), so > can > >> > the the MAG. Thus the MAG can set the HI =3D FM to provide flow > >> > mobility. As a result the inability of a MAG to know about the MN > >> > level of support for flow mobility can't be used as an argument = in > >> > favor of your model 2) where the LMA knows about MN flow mobility > but > >> > the MAG doesn't. > >> > > >> >> You don't believe that there is a need to add a new prefix to = the > >> session. > >> >> However, you didn't show me that 5213 prohibits adding a new > prefix > >> to an > >> >> existing session. I believe that LMA should be allowed to = provide > >> any prefix > >> >> it chooses to, including the previously assigned ones and the = new > >> ones. > >> > > >> > I don't believe there's a need to add a new prefix to an existing > >> > session to provide flow mobility. Can you point to a usecase that > >> > _requires_ adding a new prefix to an existing session for = purposes > of > >> > providing flow mobility? > >> > > >> > My reading of 5213 is that it documents a protocol in which the > >> prefix > >> > set is allocated at session creation and remains unmodified > >> throughout > >> > that session lifetime. 5213 doesn't provide a mean to change the > >> > prefix set after session creation. Can you point to a provision = of > >> > 5213 that allows changing the prefix set of a session after its > >> > creation? > >> > > >> >> So, let's agree to disagree :-) > >> > > >> > I can certainly agree to disagree on your reading of 5213 on the > >> > ability to add prefixes to an existing session, and on the > >> requirement > >> > to add new prefix to provide mobility. I do not see any = documented > or > >> > reasoned evidence about these. > >> > > >> > --julien > >> > > >> >> On 2/24/11 11:17 AM, "Julien Laganier" > >> wrote: > >> >> > >> >>> Rajeev, > >> >>> > >> >>> Please see inline. > >> >>> > >> >>> On Thu, Feb 24, 2011 at 10:42 AM, Rajeev Koodli > > >> wrote: > >> >>>> > >> >>>> Julien, > >> >>>> > >> >>>> Please treat this as a combined response to your other e-mail > as > >> well. > >> >>>> > >> >>>> On 2/24/11 8:05 AM, "Julien Laganier" > >> wrote: > >> >>>> > >> >>>>>> > >> >>>>>> =3D> I think we need to be careful about using AAA as a > potential > >> silver > >> >>>>>> bullet for things we don't know how to do in our protocol. > More > >> >>>>>> specifically, the property discussed above is a device > >> attribute. AAA is > >> >>>>>> usually a user profile not a device profile unless you = assume > a > >> 1:1 > >> >>>>>> mapping > >> >>>>>> of device:user, which might be the case in some systems in > the > >> US but is > >> >>>>>> certainly not the case in the rest of the world. So assuming > the > >> device > >> >>>>>> properties will be stored in AAA and attributed to the user > is > >> not a good > >> >>>>>> way to go. > >> >>>>>> Furthermore, users use devices that have not be = "initialised" > in > >> AAA all > >> >>>>>> the > >> >>>>>> time. A user doesn't ask for an operator's permission before > >> they stick > >> >>>>>> their SIM in a device. So device properties are not known in > >> advance. > >> >>>>> > >> >>>>> I agree with this entirely, which is why I said: > >> >>>>> > >> >>>> > >> >>>> Good points. > >> >>>> The purpose of the multi-access indicator ID is twofold: to > enable > >> the MN > >> >>>> to > >> >>>> indicate its capability and willingness for flow mobility > (through > >> the > >> >>>> AT_MA_IND attribute). Second, to enable AAA to authorize the > user > >> for flow > >> >>>> mobility. So, it's the MN which is indicating the device > >> capability, and > >> >>>> the > >> >>>> AAA providing the authorization for the flow mobility service. > >> >>>> > >> >>>> > >> >>>>>>>> I think whether or not AAA can really knows what are the > >> capabilities > >> >>>>>>>> of a network stack on a device is questionable, but let's > skip > >> on that > >> >>>>>>>> for now: > >> >>>>> > >> >>>>> but still I wanted to make the point that if to support > scenario > >> 2) in > >> >>>>> Rajeev's mail one needs to assume LMA is told by AAA the > device > >> >>>>> capabilities, then the =A0MAG can be told that as well by AAA > >> (e.g., at > >> >>>>> same time it gets to know the MNID) and set HI =3D FM > appropriately > >> as > >> >>>>> per case 1) thus there's no point in supporting case 2) as = per > my > >> >>>>> earlier writings on the topic. > >> >>>>> > >> >>>> > >> >>>> There are two parts to consider here. First, the issue of LMA > >> knowing that > >> >>>> the MN is capable and willing to have flow mobility (I think > you > >> brought up > >> >>>> the issue of legacy host). Whether or not MAG is informed by > the > >> AAA, there > >> >>>> is LMA - AAA interaction. > >> >>> > >> >>> MAG has to be informed of an authenticated MNID for PMIPv6 to > work. > >> >>> When authentication of the MNID is based on AAA, the MAG = already > >> >>> receives information from AAA. So in a basic 5213 deployment > that > >> uses > >> >>> AAA for authentication, there is MAG-AAA interaction. > >> >>> > >> >>> On the other hand LMA - AAA interaction isn't required per se = in > >> the 5213 > >> >>> model. > >> >>> > >> >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0In other words, LMA will go to > >> AAA anyway. > >> >>>> So, the > >> >>>> AAA providing the attribute to the MAG is redundant exchange > which > >> we > >> >>>> thought unnecessary for the multi-access ID. > >> >>> > >> >>> This backward: As above, if AAA is used the MAG will go to AAA, > so > >> the > >> >>> AAA providing the attribute to the LMA is the redundant = exchange > >> which > >> >>> is unnecessary for multi-access ID. > >> >>> > >> >>>> > >> =A0And, > >> >>>> whether > >> >>>> the LMA will > >> >>>> actually accept the indicator provided by MAG is moot, since > the > >> >>>> authorization should come from elsewhere (AAA). > >> >>> > >> >>> PMIPv6 assumes that the MAG is trusted by the LMA, thus the LMA > can > >> >>> accept the indicator provided by the MAG. > >> >>> > >> >>>> Second, the issue of assigning prefixes at the LMA. The LMA > should > >> be able > >> >>>> to assign any prefix freely upon any attach. > >> >>> > >> >>> As I said earlier many times, the 5213 model is that of a = prefix > >> set > >> >>> allocated at session creation and there has been no reason to > >> depart > >> >>> from that model for purposes of flow mobility, i.e., I can > provide > >> >>> flow mobility under that same model thus there's no basis to > change > >> >>> that model under this work item. > >> >>> > >> >>>> > >> > >> >>>> With > >> >>>> HI=3DHandover, it returns > >> >>>> the previously assigned prefix, but there is no prohibition to > >> also return > >> >>>> a > >> >>>> hitherto unassigned prefix, AFAICT. > >> >>> > >> >>> As above, the 5213 model factually does not change the prefix > set > >> that > >> >>> was allocated at session creation after a handover or at any > other > >> >>> point in the session lifetime. As above, there's no basis to > change > >> >>> that for the purpose of flow mobility since it is not required = / > >> >>> necessary. > >> >>> > >> >>>> > >> Similarly, even > >> >>>> with HI =3D FM, the LMA > >> >>>> can assign a new prefix which is not in the current set. > >> >>> > >> >>> Disagree. This is an unwarranted modification of the 5213 = model. > >> >>> > >> >>>> This is not a new feature which we need to support. > >> >>> > >> >>> Compared to the 5213 model it is indeed a new feature that a > prefix > >> >>> set for a PMIPv6 session can be modified after that session > >> creation, > >> >>> as I've kept explaining again and again. And that new feature = is > >> not > >> >>> required to complete the flow mobility work item thus there's = no > >> basis > >> >>> to alter the 5213 model in that context. > >> >>> > >> >>> I am surprised we are still discussing this. > >> >>> > >> >>> --julien > >> >> > >> >> > >> > >> _______________________________________________ > >> netext mailing list > >> netext@ietf.org > >> https://www.ietf.org/mailman/listinfo/netext > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > > From jouni.nospam@gmail.com Sun Feb 27 12:13:14 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF37C3A6A21 for ; Sun, 27 Feb 2011 12:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8A2KIvs48Na for ; Sun, 27 Feb 2011 12:13:14 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id C10F63A67E2 for ; Sun, 27 Feb 2011 12:13:13 -0800 (PST) Received: by eye13 with SMTP id 13so1299534eye.31 for ; Sun, 27 Feb 2011 12:14:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:references:to:message-id:mime-version:x-mailer; bh=5P+M/ZSwSR91FwmUaKpX92CL5XssMd9Fpn6Y9SQSRLM=; b=t87oJAoQb99S/FTXa+MTpUhvRLVEcxwVlTp4BRdAQX6/2WvE9V7bMDHUWMEBtJJah2 GJmq8bEy9/Zfx/1XpJYTJFGWI16Z7PxwXD4THGc8YIwGC+zfM3GEa4xft5z3fux2kNHA nlKtZ1JO7ChN49wNVzZpcovR/LWBR6ULCQ/0U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version:x-mailer; b=FE3nbMXPMqGME8GH44oBFDqFCXJM4fP21OEn7Pkt+1Qzz8JvAe7qiZb/0iB4Z461w/ efa4NtAC0eLFiUNpLVudKQdVjyGMjUvQmL6HBnfugR9NUE4Ym6yTqrFwOvVlw+2EmDZR z2bcXSbZFFeoS/dDGP8Z7Ps5cWoqsrozhJPf4= Received: by 10.213.21.205 with SMTP id k13mr3735569ebb.98.1298837649809; Sun, 27 Feb 2011 12:14:09 -0800 (PST) Received: from a88-114-171-138.elisa-laajakaista.fi (a88-114-171-138.elisa-laajakaista.fi [88.114.171.138]) by mx.google.com with ESMTPS id t5sm2521888eeh.14.2011.02.27.12.14.08 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 Feb 2011 12:14:08 -0800 (PST) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 27 Feb 2011 22:14:06 +0200 References: <20110218023001.28836.73630.idtracker@localhost> To: netext@ietf.org Message-Id: <88D13406-578A-4F16-A7CE-F5160037278E@gmail.com> Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [netext] Fwd: I-D Action:draft-gundavelli-netext-access-network-option-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 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, 27 Feb 2011 20:13:14 -0000 Folks, We worked on a simple extension to PMIPv6 signaling that allows a MAG to = inform an LMA about the access network provider and technology specific = information upon MN attachment to the MAG. The protocol extension allows = the LMA make better policy decisions on the traffic sourced = from/destined to the MN. What we propose here extends the in-band policy = signaling capabilities of the PMIPv6 that previously were only limited = to the Access Technology Type. - Jouni Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: February 18, 2011 4:30:01 AM GMT+02:00 > To: i-d-announce@ietf.org > Subject: I-D = Action:draft-gundavelli-netext-access-network-option-00.txt > Reply-To: internet-drafts@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Access Network Information Option for Proxy = Mobile IPv6 > Author(s) : S. Gundavelli, et al. > Filename : = draft-gundavelli-netext-access-network-option-00.txt > Pages : 9 > Date : 2011-02-17 >=20 > This specification defines a mechanism and a related mobility option > for carrying the access network identifier and the access operator > identification information from the mobile access gateway to the > local mobility anchor over Proxy Mobile IPv6. Based on the received > information, the local mobility anchor is able to provide access > network and access operator specific handling or policing for the > mobile node traffic. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-gundavelli-netext-access-network= -option-00.txt From trungtm2909@gmail.com Mon Feb 28 01:07:29 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 471C23A6AC2 for ; Mon, 28 Feb 2011 01:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziMjq5opbkp3 for ; Mon, 28 Feb 2011 01:07:28 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 0BEF33A692D for ; Mon, 28 Feb 2011 01:07:27 -0800 (PST) Received: by vws6 with SMTP id 6so3316829vws.31 for ; Mon, 28 Feb 2011 01:08:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=u3J9LbtrJS9Dv5obs1Str2fc0qWHqBZBysgBoDQi+qY=; b=b9w0ownzH0Z2l256QfpgYRAineJjMNFBCZl6r1R3lkCDITZrCetYrrZENLjiOpkKiy Ga4L9KuH0Ay0P5fzmDMHwvQ331XGJ8H+Au1OKYQiVPAjPlFT/TGqc0ThTFnpiZs1yNeD sMN8W4KnVfUdqKKO02jxB1ZrCQ+JWv/SUqifo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rHs55tZrYjlmbc+mA3ew0cSAlIBF7oyJhOz3c3PR1DqngcE46EbXjd0CiwYgoLJh5E RysziW87GYg+8ou67V9S7v15oybC5nEbRsDxgKGSA1kmK7/eQKe1Em4T3RoqEZ5GvPMB FPkbnsEFoflGZTsM+0222/BLDh73luh4vCzwk= MIME-Version: 1.0 Received: by 10.52.162.135 with SMTP id ya7mr1428241vdb.120.1298884107658; Mon, 28 Feb 2011 01:08:27 -0800 (PST) Received: by 10.52.162.1 with HTTP; Mon, 28 Feb 2011 01:08:27 -0800 (PST) In-Reply-To: References: Date: Mon, 28 Feb 2011 18:08:27 +0900 Message-ID: From: Tran Minh Trung To: Julien Laganier Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 09:07:29 -0000 Hi Julien, On Sat, Feb 26, 2011 at 1:06 AM, Julien Laganier wr= ote: > Tran, > > When parallel sessions are running across a same physical interface, > there will need to be session separation at L2 because otherwise > packets from different sessions can't be distnguished from each others > by either of the MAG or the MN. This L2 separation has to be triggered > by some L2 signaling: What is the type of the L2 signaling that you mentioned here?. Is it different with the L2 signaling used in RFC5213?. Can this L2 signaling be sent to all MAGs even though the UE just activates a PDN connection over a specific PHY interface (MAG)?. It is still magic to me to assume that a L2 signaling can be used to add ALL attached PHY interfaces to a new session. >even though the physical interface might already > be attached, there will have to be another L2 signaling to attach the > new logical interface for the new session. > > If you want to see example of real system, please have a look at the > relevant 3GPP specifications, e.g., TS 23.402. > I have checked TS 23.402, 401 as well as TR 23.861 (Multi access PDN connectivity and IP flow mobility). However I can not find the answer for my question. Could you elaborate it step by step for the following scenario: 1. The UE attaches to the 3GPP as defined in TS 23.401, clause 5.3.2. -> Session 1 is created [{IF1, 3GPP, MAG1} | Prefix 1] 2. The UE discovers a WiFi access and attaches to it as per TS 23.402, clause 8.4.2, steps 2-6. Since 3GPP and WiFi interfaces are in the same set (of a logical interface), the WiFi interface is added to Session 1: [{IF1, 3GPP, MAG1};{IF2, WiFi, MAG1} | Prefix 1] (PMIPv6 extension for flow mobility) 3. User starts an application and activates a new PDN connection over 3GPP interface -> Session 2 must be created. -> other steps are from TS 23.401, clause 5.10.2: UE requested PDN connecti= vity Q1. What is the information in Session 2?. Dose it include the PDN logical interface ID or just 3GPP Interface ID? Q2. When the L2 signaling, that you mentioned, is sent to both MAG1 and MAG2?. Is it before "PDN Connectivity Request" or after "RRC Connection Reconfiguration Complete"?. Thank you. Regards, TrungTM > Thanks, > > --julien > > On Thu, Feb 24, 2011 at 8:06 PM, Tran Minh Trung = wrote: >> Hi Julien, >> >> I agree with your arguments that the case HI=3Dunknow shouldn't happen >> since the MAG is aware of MN's capacity, and the prefix set is fixed >> at session creation and does not need to be changed thereafter. >> >> However, I still wonder about the case that a new session is created on = the fly. >> >> Since the PHY interfaces are already attached, how the MN can send L2 >> signaling to all MAGs to inform that a new session is created when the >> user starts an application and activate a new PDN connection or a new >> VPN connection? >> >> Could you elaborate more detail in the ML?. >> =A0It would be nice if you can provide an example from a real system. >> >> Regards, >> TrungTM >> >> >> >> >> On Fri, Feb 25, 2011 at 11:19 AM, Julien Laganier wrote: >>> On Thu, Feb 24, 2011 at 6:03 PM, Rajeev Koodli wrot= e: >>>> >>>> I do care about the PMIP6 interaction with AAA because the system desi= gn >>>> needs it. I don't know of a system where LMA relies on MAG for >>>> authorization. >>> >>> I know of one such a system: In 3GPP the MAG in the ePDG is the PMIPv6 >>> entity that verifies that the user has a subscription that authorizes >>> access via a non-3GPP access by querying AAA. >>> >>>> The use-case for being able to provide a new prefix at attach is robus= tness. >>> >>> This alone doesn't mean anything. Please explain the relationship >>> between new prefixes and protocol robustness. >>> >>>> There is nothing I could see in 5213 that disallows an LMA from provid= ing a >>>> prefix which is not in the session, and why should there be any restri= ction >>>> on what prefixes the LMA can provide at attach? >>> >>> I am not talking about attach. I said the prefix set is fixed at >>> session creation and does not change thereafter. If you disagree, >>> please point me to, or write one here, a conformant RFC 5213 PMIPv6 >>> call flow that changes the prefix set _after_ session creation. >>> >>>> I want flow mobility solution to work without only relying on L2 signa= ling, >>>> meaning we should be able to also provide it for HI=3DUnknown. This ca= n be >>>> done with IP signaling between LMA and MAG. This is not replacing L2 >>>> signaling, but covers the case when HI=3Dunknown. >>> >>> Again, PMIPV6 has to rely on L2 signaling and does not work without >>> it. You said in an earlier email that the MN indicates to the network >>> its support for flow mobility. If so, that information can be made >>> available to the MAG and the MAG to set the HI to FM appropriately. >>> The case HI=3Dunknown shouldn't happen if the MN indicates to the >>> network its support for flow mobility. >>> >>>> As I have also said earlier, we have different opinions here. Let's mo= ve >>>> on.. >>> >>> Not sure I understand. What do you mean by "let's move on"? >>> >>> --julien >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>> >> >> >> >> -- >> Ph.D., Senior Member >> Electronics and Telecommunications Research Institute >> Standards Research Center >> 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA >> Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 >> > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 From trungtm2909@gmail.com Mon Feb 28 01:09:46 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 911483A6AF1 for ; Mon, 28 Feb 2011 01:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_28=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkdPgqNfRSiQ for ; Mon, 28 Feb 2011 01:09:38 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 73EA93A6AED for ; Mon, 28 Feb 2011 01:09:38 -0800 (PST) Received: by vxg33 with SMTP id 33so3242535vxg.31 for ; Mon, 28 Feb 2011 01:10:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XNJvrbPO4uY5F+6JLtByweF110u6ias+6o4JrMObvvE=; b=mBDJdeVMvE+3iSISV31MdQ2oKO07yvomqH0bGmBzW0sTK9WJHNM4b8cy0uUe46+1fw Vd+HEZbpWR9SkMumeOAA3D/gMu4m0uFBxW5q8rnx4zYRxMhBJS1Xy5BZNVsApdjcmI5k okUg1ors8zqXDDn2+l09zw5Nr4Y6pVA5lC4Rs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LYhZumh8drr85VTVswwKWwsjQSkuQJg3cc3TXHeY4tGE2FoP6FqJf+UAFq4x20tvp4 U6Ks8/qDBwCR0gNG199Nx1ceD5GT89gixHWwiJ6vG8HSdIldutKK4Fnz1N3Kk1QGWboI KATRqdq2rgMO3eGMD7Gos1m8ulEl0F+sok154= MIME-Version: 1.0 Received: by 10.52.166.226 with SMTP id zj2mr3973509vdb.80.1298884238207; Mon, 28 Feb 2011 01:10:38 -0800 (PST) Received: by 10.52.162.1 with HTTP; Mon, 28 Feb 2011 01:10:38 -0800 (PST) In-Reply-To: <1298663501.3608.141.camel@acorde.it.uc3m.es> References: <1298663501.3608.141.camel@acorde.it.uc3m.es> Date: Mon, 28 Feb 2011 18:10:38 +0900 Message-ID: From: Tran Minh Trung To: cjbc@it.uc3m.es Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Zuniga, Juan Carlos" , netext@ietf.org Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 09:09:46 -0000 Hi Carlos, 2011/2/26 Carlos Jes=FAs Bernardos Cano : > Hi Julien, > > On Fri, 2011-02-25 at 09:01 -0700, Julien Laganier wrote: >> JC, >> >> Since no PMIPv6 based system can possibly work without the L2 >> signaling, the L3 MAG-LMA signaling is factually useless. > > I have a PMIPv6 system working in my lab and there is no L2 signaling at > all. I think it is not fully implemented system. How can you support handover without the L2 signaling message? Regards, TrungTM > Optionally, I can enable the APs attached to the MAG detect the MN > attachment and use that as trigger for the PBU (instead of relaying on > ND). I agree L2 signaling is used by most deployments as in fact PMIPv6 > was designed with many things "out-of-the-scope of the spec" (it's there > where L2 signaling appears), but I disagree L2 signaling is completely > necessarily. > > I agree with Rajeev's suggestion to move forward. > > Thanks, > > Carlos > >> >> This is has to be the conclusion of this discussion unless someone can >> provide us with a description of how a system would work without the >> L2 signaling. >> >> --julien >> >> On Fri, Feb 25, 2011 at 8:21 AM, Zuniga, Juan Carlos >> wrote: >> > Rajeev, >> > >> > I agree with you. >> > >> > Even if L2 signalling can help the scenario, we should not -only- rely= on that as we might end up in a catch-22 situation. >> > >> > By providing an L3 MAG-LMA signalling solution we would be covered in = case L2 signalling is not there (HI=3Dunknown), and at the same time we wou= ld not preempt a solution that has that L2 signalling to use it. >> > >> > This seems to me like a good way to progress this and move forward. >> > >> > JC >> > >> >> -----Original Message----- >> >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On >> >> Behalf Of Rajeev Koodli >> >> Sent: February 24, 2011 8:03 PM >> >> To: Julien Laganier >> >> Cc: netext@ietf.org >> >> Subject: Re: [netext] Flow Mobility discussion - way forward? >> >> >> >> >> >> I do care about the PMIP6 interaction with AAA because the system >> >> design >> >> needs it. I don't know of a system where LMA relies on MAG for >> >> authorization. >> >> >> >> The use-case for being able to provide a new prefix at attach is >> >> robustness. >> >> There is nothing I could see in 5213 that disallows an LMA from >> >> providing a >> >> prefix which is not in the session, and why should there be any >> >> restriction >> >> on what prefixes the LMA can provide at attach? >> >> >> >> I want flow mobility solution to work without only relying on L2 >> >> signaling, >> >> meaning we should be able to also provide it for HI=3DUnknown. This c= an >> >> be >> >> done with IP signaling between LMA and MAG. This is not replacing L2 >> >> signaling, but covers the case when HI=3Dunknown. >> >> >> >> As I have also said earlier, we have different opinions here. Let's >> >> move >> >> on.. >> >> >> >> -Rajeev >> >> >> >> >> >> On 2/24/11 1:20 PM, "Julien Laganier" wrote: >> >> >> >> > On Thu, Feb 24, 2011 at 12:38 PM, Rajeev Koodli >> >> wrote: >> >> >> >> >> >> Julien, >> >> >> >> >> >> The presumed MAG-AAA interaction in 5213 is for authentication >> >> purposes. >> >> >> The LMA-AAA interaction is for authorization purposes. The intent = in >> >> the >> >> >> multi-access ID is to enable AAA to authorize the LMA for flow >> >> mobility >> >> >> purposes. It's kind of interesting that you refer to 3GPP model >> >> sometimes, >> >> >> but reticent about it for the LMA - AAA interaction in 3GPP (e.g., >> >> your >> >> >> statement below "LMA - AAA interaction is not required per se").. >> >> > >> >> > As I said earlier, if AAA is required to be in place to authenticat= e >> >> > the MN towards the MAG, that can be used for authorization too. I d= o >> >> > not see what is the security requirement that authorization happens >> >> in >> >> > LMA rather than in MAG. >> >> > >> >> > That being said, I don't care much about the specifics of the AAA >> >> > interactions with PMIPv6. My point was, and is, that if you assume >> >> > that the LMA can know from AAA about the ability for a MN network >> >> > stack to support flow mobility (as opposed to a legacy node), so ca= n >> >> > the the MAG. Thus the MAG can set the HI =3D FM to provide flow >> >> > mobility. As a result the inability of a MAG to know about the MN >> >> > level of support for flow mobility can't be used as an argument in >> >> > favor of your model 2) where the LMA knows about MN flow mobility b= ut >> >> > the MAG doesn't. >> >> > >> >> >> You don't believe that there is a need to add a new prefix to the >> >> session. >> >> >> However, you didn't show me that 5213 prohibits adding a new prefi= x >> >> to an >> >> >> existing session. I believe that LMA should be allowed to provide >> >> any prefix >> >> >> it chooses to, including the previously assigned ones and the new >> >> ones. >> >> > >> >> > I don't believe there's a need to add a new prefix to an existing >> >> > session to provide flow mobility. Can you point to a usecase that >> >> > _requires_ adding a new prefix to an existing session for purposes = of >> >> > providing flow mobility? >> >> > >> >> > My reading of 5213 is that it documents a protocol in which the >> >> prefix >> >> > set is allocated at session creation and remains unmodified >> >> throughout >> >> > that session lifetime. 5213 doesn't provide a mean to change the >> >> > prefix set after session creation. Can you point to a provision of >> >> > 5213 that allows changing the prefix set of a session after its >> >> > creation? >> >> > >> >> >> So, let's agree to disagree :-) >> >> > >> >> > I can certainly agree to disagree on your reading of 5213 on the >> >> > ability to add prefixes to an existing session, and on the >> >> requirement >> >> > to add new prefix to provide mobility. I do not see any documented = or >> >> > reasoned evidence about these. >> >> > >> >> > --julien >> >> > >> >> >> On 2/24/11 11:17 AM, "Julien Laganier" >> >> wrote: >> >> >> >> >> >>> Rajeev, >> >> >>> >> >> >>> Please see inline. >> >> >>> >> >> >>> On Thu, Feb 24, 2011 at 10:42 AM, Rajeev Koodli >> >> wrote: >> >> >>>> >> >> >>>> Julien, >> >> >>>> >> >> >>>> Please treat this as a combined response to your other e-mail as >> >> well. >> >> >>>> >> >> >>>> On 2/24/11 8:05 AM, "Julien Laganier" >> >> wrote: >> >> >>>> >> >> >>>>>> >> >> >>>>>> =3D> I think we need to be careful about using AAA as a potent= ial >> >> silver >> >> >>>>>> bullet for things we don't know how to do in our protocol. Mor= e >> >> >>>>>> specifically, the property discussed above is a device >> >> attribute. AAA is >> >> >>>>>> usually a user profile not a device profile unless you assume = a >> >> 1:1 >> >> >>>>>> mapping >> >> >>>>>> of device:user, which might be the case in some systems in the >> >> US but is >> >> >>>>>> certainly not the case in the rest of the world. So assuming t= he >> >> device >> >> >>>>>> properties will be stored in AAA and attributed to the user is >> >> not a good >> >> >>>>>> way to go. >> >> >>>>>> Furthermore, users use devices that have not be "initialised" = in >> >> AAA all >> >> >>>>>> the >> >> >>>>>> time. A user doesn't ask for an operator's permission before >> >> they stick >> >> >>>>>> their SIM in a device. So device properties are not known in >> >> advance. >> >> >>>>> >> >> >>>>> I agree with this entirely, which is why I said: >> >> >>>>> >> >> >>>> >> >> >>>> Good points. >> >> >>>> The purpose of the multi-access indicator ID is twofold: to enab= le >> >> the MN >> >> >>>> to >> >> >>>> indicate its capability and willingness for flow mobility (throu= gh >> >> the >> >> >>>> AT_MA_IND attribute). Second, to enable AAA to authorize the use= r >> >> for flow >> >> >>>> mobility. So, it's the MN which is indicating the device >> >> capability, and >> >> >>>> the >> >> >>>> AAA providing the authorization for the flow mobility service. >> >> >>>> >> >> >>>> >> >> >>>>>>>> I think whether or not AAA can really knows what are the >> >> capabilities >> >> >>>>>>>> of a network stack on a device is questionable, but let's sk= ip >> >> on that >> >> >>>>>>>> for now: >> >> >>>>> >> >> >>>>> but still I wanted to make the point that if to support scenari= o >> >> 2) in >> >> >>>>> Rajeev's mail one needs to assume LMA is told by AAA the device >> >> >>>>> capabilities, then the =A0MAG can be told that as well by AAA >> >> (e.g., at >> >> >>>>> same time it gets to know the MNID) and set HI =3D FM appropria= tely >> >> as >> >> >>>>> per case 1) thus there's no point in supporting case 2) as per = my >> >> >>>>> earlier writings on the topic. >> >> >>>>> >> >> >>>> >> >> >>>> There are two parts to consider here. First, the issue of LMA >> >> knowing that >> >> >>>> the MN is capable and willing to have flow mobility (I think you >> >> brought up >> >> >>>> the issue of legacy host). Whether or not MAG is informed by the >> >> AAA, there >> >> >>>> is LMA - AAA interaction. >> >> >>> >> >> >>> MAG has to be informed of an authenticated MNID for PMIPv6 to wor= k. >> >> >>> When authentication of the MNID is based on AAA, the MAG already >> >> >>> receives information from AAA. So in a basic 5213 deployment that >> >> uses >> >> >>> AAA for authentication, there is MAG-AAA interaction. >> >> >>> >> >> >>> On the other hand LMA - AAA interaction isn't required per se in >> >> the 5213 >> >> >>> model. >> >> >>> >> >> >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0In other words, LMA will go to >> >> AAA anyway. >> >> >>>> So, the >> >> >>>> AAA providing the attribute to the MAG is redundant exchange whi= ch >> >> we >> >> >>>> thought unnecessary for the multi-access ID. >> >> >>> >> >> >>> This backward: As above, if AAA is used the MAG will go to AAA, s= o >> >> the >> >> >>> AAA providing the attribute to the LMA is the redundant exchange >> >> which >> >> >>> is unnecessary for multi-access ID. >> >> >>> >> >> >>>> >> >> =A0And, >> >> >>>> whether >> >> >>>> the LMA will >> >> >>>> actually accept the indicator provided by MAG is moot, since the >> >> >>>> authorization should come from elsewhere (AAA). >> >> >>> >> >> >>> PMIPv6 assumes that the MAG is trusted by the LMA, thus the LMA c= an >> >> >>> accept the indicator provided by the MAG. >> >> >>> >> >> >>>> Second, the issue of assigning prefixes at the LMA. The LMA shou= ld >> >> be able >> >> >>>> to assign any prefix freely upon any attach. >> >> >>> >> >> >>> As I said earlier many times, the 5213 model is that of a prefix >> >> set >> >> >>> allocated at session creation and there has been no reason to >> >> depart >> >> >>> from that model for purposes of flow mobility, i.e., I can provid= e >> >> >>> flow mobility under that same model thus there's no basis to chan= ge >> >> >>> that model under this work item. >> >> >>> >> >> >>>> >> >> >> >> >>>> With >> >> >>>> HI=3DHandover, it returns >> >> >>>> the previously assigned prefix, but there is no prohibition to >> >> also return >> >> >>>> a >> >> >>>> hitherto unassigned prefix, AFAICT. >> >> >>> >> >> >>> As above, the 5213 model factually does not change the prefix set >> >> that >> >> >>> was allocated at session creation after a handover or at any othe= r >> >> >>> point in the session lifetime. As above, there's no basis to chan= ge >> >> >>> that for the purpose of flow mobility since it is not required / >> >> >>> necessary. >> >> >>> >> >> >>>> >> >> Similarly, even >> >> >>>> with HI =3D FM, the LMA >> >> >>>> can assign a new prefix which is not in the current set. >> >> >>> >> >> >>> Disagree. This is an unwarranted modification of the 5213 model. >> >> >>> >> >> >>>> This is not a new feature which we need to support. >> >> >>> >> >> >>> Compared to the 5213 model it is indeed a new feature that a pref= ix >> >> >>> set for a PMIPv6 session can be modified after that session >> >> creation, >> >> >>> as I've kept explaining again and again. And that new feature is >> >> not >> >> >>> required to complete the flow mobility work item thus there's no >> >> basis >> >> >>> to alter the 5213 model in that context. >> >> >>> >> >> >>> I am surprised we are still discussing this. >> >> >>> >> >> >>> --julien >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> netext mailing list >> >> netext@ietf.org >> >> https://www.ietf.org/mailman/listinfo/netext >> > _______________________________________________ >> > netext mailing list >> > netext@ietf.org >> > https://www.ietf.org/mailman/listinfo/netext >> > >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > > -- > Carlos Jes=FAs Bernardos Cano =A0 =A0 http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA =A04D55 35DC BA4D D170 4F67 > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 From pierrick.seite@orange-ftgroup.com Mon Feb 28 02:51:52 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FE4E3A6B16 for ; Mon, 28 Feb 2011 02:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.09 X-Spam-Level: X-Spam-Status: No, score=-1.09 tagged_above=-999 required=5 tests=[AWL=-0.641, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_27=0.6, J_CHICKENPOX_28=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOLuOhqsSjsB for ; Mon, 28 Feb 2011 02:51:50 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 555BB3A6AF7 for ; Mon, 28 Feb 2011 02:51:49 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 36B51FC4006; Mon, 28 Feb 2011 11:52:54 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 275C1FC4002; Mon, 28 Feb 2011 11:52:54 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Feb 2011 11:52:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Feb 2011 11:52:40 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C4620188756A@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvVBVHJF9cDsamzRL+4ToVk1Bz6uQA6vPBQAFCX5kA= References: From: To: , X-OriginalArrivalTime: 28 Feb 2011 10:52:48.0276 (UTC) FILETIME=[A346DD40:01CBD735] Cc: netext@ietf.org Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 10:51:52 -0000 Hi all, Just to be sure to discuss on solid basis and common understanding:=20 Are we, now, in agreement on the following statement: "All prefixes are = assigned when the first session is created" ? It's fundamental, since, if this statement is aggreed, MAG/LMA L3 = signalling is useless (FMU). Pierrick > -----Message d'origine----- > De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org]=20 > De la part de Zuniga, Juan Carlos > Envoy=E9 : samedi 26 f=E9vrier 2011 21:04 > =C0 : Julien Laganier > Cc : netext@ietf.org > Objet : Re: [netext] Flow Mobility discussion - way forward? >=20 > Julien, >=20 > Ok, let me rephrase it. I should have said "new" L2 signalling. >=20 > If IP Flow Mobility L2 signalling becomes available in the=20 > future, fine. However, not to rely on this assumption and=20 > also to support scenarios where the decision for the flow=20 > mobility could come from the LMA, I see value in defining=20 > also the L3 signalling. >=20 > In other words, if L2 signalling for IP Flow mobility is=20 > there, you simply don't use this L3 signalling. If new L2 is=20 > NOT there, then you can rely on this L3 mechanism.=20 >=20 > I see no harm and a lot of value with this approach.=20 >=20 > To me this is a good compromise and good way to move forward. >=20 > JC >=20 > > -----Original Message----- > > From: Julien Laganier [mailto:julien.ietf@gmail.com] > > Sent: February 25, 2011 11:02 AM > > To: Zuniga, Juan Carlos > > Cc: Rajeev Koodli; netext@ietf.org > > Subject: Re: [netext] Flow Mobility discussion - way forward? > >=20 > > JC, > >=20 > > Since no PMIPv6 based system can possibly work without the L2=20 > > signaling, the L3 MAG-LMA signaling is factually useless. > >=20 > > This is has to be the conclusion of this discussion unless=20 > someone can=20 > > provide us with a description of how a system would work without the > > L2 signaling. > >=20 > > --julien > >=20 > > On Fri, Feb 25, 2011 at 8:21 AM, Zuniga, Juan Carlos=20 > > wrote: > > > Rajeev, > > > > > > I agree with you. > > > > > > Even if L2 signalling can help the scenario, we should not -only- > > rely on that as we might end up in a catch-22 situation. > > > > > > By providing an L3 MAG-LMA signalling solution we would=20 > be covered=20 > > > in > > case L2 signalling is not there (HI=3Dunknown), and at the=20 > same time we=20 > > would not preempt a solution that has that L2 signalling to use it. > > > > > > This seems to me like a good way to progress this and=20 > move forward. > > > > > > JC > > > > > >> -----Original Message----- > > >> From: netext-bounces@ietf.org=20 > [mailto:netext-bounces@ietf.org] On=20 > > >> Behalf Of Rajeev Koodli > > >> Sent: February 24, 2011 8:03 PM > > >> To: Julien Laganier > > >> Cc: netext@ietf.org > > >> Subject: Re: [netext] Flow Mobility discussion - way forward? > > >> > > >> > > >> I do care about the PMIP6 interaction with AAA because=20 > the system=20 > > >> design needs it. I don't know of a system where LMA=20 > relies on MAG=20 > > >> for authorization. > > >> > > >> The use-case for being able to provide a new prefix at attach is=20 > > >> robustness. > > >> There is nothing I could see in 5213 that disallows an LMA from=20 > > >> providing a prefix which is not in the session, and why should=20 > > >> there be any restriction on what prefixes the LMA can provide at=20 > > >> attach? > > >> > > >> I want flow mobility solution to work without only relying on L2=20 > > >> signaling, meaning we should be able to also provide it for=20 > > >> HI=3DUnknown. This > > can > > >> be > > >> done with IP signaling between LMA and MAG. This is not=20 > replacing=20 > > >> L2 signaling, but covers the case when HI=3Dunknown. > > >> > > >> As I have also said earlier, we have different opinions=20 > here. Let's=20 > > >> move on.. > > >> > > >> -Rajeev > > >> > > >> > > >> On 2/24/11 1:20 PM, "Julien Laganier"=20 > wrote: > > >> > > >> > On Thu, Feb 24, 2011 at 12:38 PM, Rajeev Koodli > > > > >> wrote: > > >> >> > > >> >> Julien, > > >> >> > > >> >> The presumed MAG-AAA interaction in 5213 is for authentication > > >> purposes. > > >> >> The LMA-AAA interaction is for authorization purposes. The=20 > > >> >> intent > > in > > >> the > > >> >> multi-access ID is to enable AAA to authorize the LMA for flow > > >> mobility > > >> >> purposes. It's kind of interesting that you refer to=20 > 3GPP model > > >> sometimes, > > >> >> but reticent about it for the LMA - AAA interaction in 3GPP > > (e.g., > > >> your > > >> >> statement below "LMA - AAA interaction is not=20 > required per se").. > > >> > > > >> > As I said earlier, if AAA is required to be in place to > > authenticate > > >> > the MN towards the MAG, that can be used for=20 > authorization too. I > > do > > >> > not see what is the security requirement that authorization > > happens > > >> in > > >> > LMA rather than in MAG. > > >> > > > >> > That being said, I don't care much about the specifics=20 > of the AAA=20 > > >> > interactions with PMIPv6. My point was, and is, that if you=20 > > >> > assume that the LMA can know from AAA about the=20 > ability for a MN=20 > > >> > network stack to support flow mobility (as opposed to a legacy=20 > > >> > node), so > > can > > >> > the the MAG. Thus the MAG can set the HI =3D FM to provide flow = > > >> > mobility. As a result the inability of a MAG to know=20 > about the MN=20 > > >> > level of support for flow mobility can't be used as an=20 > argument=20 > > >> > in favor of your model 2) where the LMA knows about MN flow=20 > > >> > mobility > > but > > >> > the MAG doesn't. > > >> > > > >> >> You don't believe that there is a need to add a new prefix to=20 > > >> >> the > > >> session. > > >> >> However, you didn't show me that 5213 prohibits adding a new > > prefix > > >> to an > > >> >> existing session. I believe that LMA should be allowed to=20 > > >> >> provide > > >> any prefix > > >> >> it chooses to, including the previously assigned ones and the=20 > > >> >> new > > >> ones. > > >> > > > >> > I don't believe there's a need to add a new prefix to=20 > an existing=20 > > >> > session to provide flow mobility. Can you point to a=20 > usecase that=20 > > >> > _requires_ adding a new prefix to an existing session for=20 > > >> > purposes > > of > > >> > providing flow mobility? > > >> > > > >> > My reading of 5213 is that it documents a protocol in which the > > >> prefix > > >> > set is allocated at session creation and remains unmodified > > >> throughout > > >> > that session lifetime. 5213 doesn't provide a mean to=20 > change the=20 > > >> > prefix set after session creation. Can you point to a=20 > provision=20 > > >> > of > > >> > 5213 that allows changing the prefix set of a session=20 > after its=20 > > >> > creation? > > >> > > > >> >> So, let's agree to disagree :-) > > >> > > > >> > I can certainly agree to disagree on your reading of=20 > 5213 on the=20 > > >> > ability to add prefixes to an existing session, and on the > > >> requirement > > >> > to add new prefix to provide mobility. I do not see any=20 > > >> > documented > > or > > >> > reasoned evidence about these. > > >> > > > >> > --julien > > >> > > > >> >> On 2/24/11 11:17 AM, "Julien Laganier" > > >> wrote: > > >> >> > > >> >>> Rajeev, > > >> >>> > > >> >>> Please see inline. > > >> >>> > > >> >>> On Thu, Feb 24, 2011 at 10:42 AM, Rajeev Koodli > > > > >> wrote: > > >> >>>> > > >> >>>> Julien, > > >> >>>> > > >> >>>> Please treat this as a combined response to your=20 > other e-mail > > as > > >> well. > > >> >>>> > > >> >>>> On 2/24/11 8:05 AM, "Julien Laganier"=20 > > > >> wrote: > > >> >>>> > > >> >>>>>> > > >> >>>>>> =3D> I think we need to be careful about using AAA as a > > potential > > >> silver > > >> >>>>>> bullet for things we don't know how to do in our protocol. > > More > > >> >>>>>> specifically, the property discussed above is a device > > >> attribute. AAA is > > >> >>>>>> usually a user profile not a device profile unless you=20 > > >> >>>>>> assume > > a > > >> 1:1 > > >> >>>>>> mapping > > >> >>>>>> of device:user, which might be the case in some systems in > > the > > >> US but is > > >> >>>>>> certainly not the case in the rest of the world.=20 > So assuming > > the > > >> device > > >> >>>>>> properties will be stored in AAA and attributed=20 > to the user > > is > > >> not a good > > >> >>>>>> way to go. > > >> >>>>>> Furthermore, users use devices that have not be=20 > "initialised" > > in > > >> AAA all > > >> >>>>>> the > > >> >>>>>> time. A user doesn't ask for an operator's=20 > permission before > > >> they stick > > >> >>>>>> their SIM in a device. So device properties are=20 > not known in > > >> advance. > > >> >>>>> > > >> >>>>> I agree with this entirely, which is why I said: > > >> >>>>> > > >> >>>> > > >> >>>> Good points. > > >> >>>> The purpose of the multi-access indicator ID is twofold: to > > enable > > >> the MN > > >> >>>> to > > >> >>>> indicate its capability and willingness for flow mobility > > (through > > >> the > > >> >>>> AT_MA_IND attribute). Second, to enable AAA to authorize the > > user > > >> for flow > > >> >>>> mobility. So, it's the MN which is indicating the device > > >> capability, and > > >> >>>> the > > >> >>>> AAA providing the authorization for the flow=20 > mobility service. > > >> >>>> > > >> >>>> > > >> >>>>>>>> I think whether or not AAA can really knows what are the > > >> capabilities > > >> >>>>>>>> of a network stack on a device is questionable,=20 > but let's > > skip > > >> on that > > >> >>>>>>>> for now: > > >> >>>>> > > >> >>>>> but still I wanted to make the point that if to support > > scenario > > >> 2) in > > >> >>>>> Rajeev's mail one needs to assume LMA is told by AAA the > > device > > >> >>>>> capabilities, then the =A0MAG can be told that as well by = AAA > > >> (e.g., at > > >> >>>>> same time it gets to know the MNID) and set HI =3D FM > > appropriately > > >> as > > >> >>>>> per case 1) thus there's no point in supporting case 2) as=20 > > >> >>>>> per > > my > > >> >>>>> earlier writings on the topic. > > >> >>>>> > > >> >>>> > > >> >>>> There are two parts to consider here. First, the=20 > issue of LMA > > >> knowing that > > >> >>>> the MN is capable and willing to have flow mobility (I think > > you > > >> brought up > > >> >>>> the issue of legacy host). Whether or not MAG is informed by > > the > > >> AAA, there > > >> >>>> is LMA - AAA interaction. > > >> >>> > > >> >>> MAG has to be informed of an authenticated MNID for PMIPv6 to > > work. > > >> >>> When authentication of the MNID is based on AAA, the MAG=20 > > >> >>> already receives information from AAA. So in a basic 5213=20 > > >> >>> deployment > > that > > >> uses > > >> >>> AAA for authentication, there is MAG-AAA interaction. > > >> >>> > > >> >>> On the other hand LMA - AAA interaction isn't=20 > required per se=20 > > >> >>> in > > >> the 5213 > > >> >>> model. > > >> >>> > > >> >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0In other words,=20 > LMA will go=20 > > >> >>>> to > > >> AAA anyway. > > >> >>>> So, the > > >> >>>> AAA providing the attribute to the MAG is redundant exchange > > which > > >> we > > >> >>>> thought unnecessary for the multi-access ID. > > >> >>> > > >> >>> This backward: As above, if AAA is used the MAG will=20 > go to AAA, > > so > > >> the > > >> >>> AAA providing the attribute to the LMA is the redundant=20 > > >> >>> exchange > > >> which > > >> >>> is unnecessary for multi-access ID. > > >> >>> > > >> >>>> > > >> =A0And, > > >> >>>> whether > > >> >>>> the LMA will > > >> >>>> actually accept the indicator provided by MAG is moot, since > > the > > >> >>>> authorization should come from elsewhere (AAA). > > >> >>> > > >> >>> PMIPv6 assumes that the MAG is trusted by the LMA,=20 > thus the LMA > > can > > >> >>> accept the indicator provided by the MAG. > > >> >>> > > >> >>>> Second, the issue of assigning prefixes at the LMA. The LMA > > should > > >> be able > > >> >>>> to assign any prefix freely upon any attach. > > >> >>> > > >> >>> As I said earlier many times, the 5213 model is that of a=20 > > >> >>> prefix > > >> set > > >> >>> allocated at session creation and there has been no reason to > > >> depart > > >> >>> from that model for purposes of flow mobility, i.e., I can > > provide > > >> >>> flow mobility under that same model thus there's no basis to > > change > > >> >>> that model under this work item. > > >> >>> > > >> >>>> > > >> > > >> >>>> With > > >> >>>> HI=3DHandover, it returns > > >> >>>> the previously assigned prefix, but there is no=20 > prohibition to > > >> also return > > >> >>>> a > > >> >>>> hitherto unassigned prefix, AFAICT. > > >> >>> > > >> >>> As above, the 5213 model factually does not change the prefix > > set > > >> that > > >> >>> was allocated at session creation after a handover or at any > > other > > >> >>> point in the session lifetime. As above, there's no basis to > > change > > >> >>> that for the purpose of flow mobility since it is=20 > not required=20 > > >> >>> / necessary. > > >> >>> > > >> >>>> > > >> Similarly, even > > >> >>>> with HI =3D FM, the LMA > > >> >>>> can assign a new prefix which is not in the current set. > > >> >>> > > >> >>> Disagree. This is an unwarranted modification of the=20 > 5213 model. > > >> >>> > > >> >>>> This is not a new feature which we need to support. > > >> >>> > > >> >>> Compared to the 5213 model it is indeed a new feature that a > > prefix > > >> >>> set for a PMIPv6 session can be modified after that session > > >> creation, > > >> >>> as I've kept explaining again and again. And that=20 > new feature=20 > > >> >>> is > > >> not > > >> >>> required to complete the flow mobility work item=20 > thus there's=20 > > >> >>> no > > >> basis > > >> >>> to alter the 5213 model in that context. > > >> >>> > > >> >>> I am surprised we are still discussing this. > > >> >>> > > >> >>> --julien > > >> >> > > >> >> > > >> > > >> _______________________________________________ > > >> netext mailing list > > >> netext@ietf.org > > >> https://www.ietf.org/mailman/listinfo/netext > > > _______________________________________________ > > > netext mailing list > > > netext@ietf.org > > > https://www.ietf.org/mailman/listinfo/netext > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext >=20 From iesg-secretary@ietf.org Mon Feb 28 07:27:17 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E45C03A6C11; Mon, 28 Feb 2011 07:27:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.468 X-Spam-Level: X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7azh00KYI0W; Mon, 28 Feb 2011 07:27:17 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24C003A6944; Mon, 28 Feb 2011 07:27:17 -0800 (PST) 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: 3.12 Message-ID: <20110228152717.5032.46190.idtracker@localhost> Date: Mon, 28 Feb 2011 07:27:17 -0800 Cc: netext@ietf.org Subject: [netext] Last Call: (PMIPv6 Localized Routing Problem Statement) to Informational RFC X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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: Mon, 28 Feb 2011 15:27:18 -0000 The IESG has received a request from the Network-Based Mobility Extensions WG (netext) to consider the following document: - 'PMIPv6 Localized Routing Problem Statement' as an 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 2011-03-14. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-netext-pmip6-lr-ps/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-netext-pmip6-lr-ps/ No IPR declarations have been submitted directly on this I-D. From jari.arkko@piuha.net Mon Feb 28 12:14:45 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D8CB3A6C5B for ; Mon, 28 Feb 2011 12:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGhclD7KLHjz for ; Mon, 28 Feb 2011 12:14:44 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 144B23A67D9 for ; Mon, 28 Feb 2011 12:14:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B59972CC2C; Mon, 28 Feb 2011 22:15:43 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koI0pOmathAV; Mon, 28 Feb 2011 22:15:43 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 3077E2CC28; Mon, 28 Feb 2011 22:15:43 +0200 (EET) Message-ID: <4D6C026E.1040508@piuha.net> Date: Mon, 28 Feb 2011 22:15:42 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: draft-ietf-netext-pmip6-lr-ps@tools.ietf.org, "netext@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netext] AD review of draft-ietf-netext-pmip6-lr-ps X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 20:14:45 -0000 I have reviewed this draft. It is a well written draft and focuses on the right things. I have no major concerns and I have sent the document forward to an IETF last call and eventually an IESG evaluation (currently scheduled for March 17th). I did have a couple of comments, however, and I let the authors decide if they want to address them. Feel free to update the document even as it is beginning its last call period. Jari > Maintaining local forwarding between the MN and the > regular IPv6 CN gets more complex in case the MN performs a handover > to a different MAG. Such use case is not considered in the > specification and out of scope of this problem statement. This > document focuses on use cases, where both nodes, the MN and the CN, > are each registered with an LMA and both obtain PMIPv6 mobility > service. > I think you need to be clearer here. I think the point is that PMIP hosts are always regular IPv6 CNs but you only consider the case where both endpoints are *within a PMIP network* and in the area served by an LMA in a *domain of LMAs*. Section 4 seems to be missing some kind of a policy function. I think most deployments would need a way to control whether route optimization is desired or not. In some cases it might not be, e.g., if some accounting or firewall functions reside in the LMA. Section 6 should start with a short statement about the security concerns that a security solution for route optimization should help mitigate. For instance, it seems that an insecure route optimization mechanism would allow compromised network components or bad roaming partners to hijack or block any traffic for any mobile node. In insecure route optimization mechanism might also also outsiders (e.g., Internet hosts) to do the same, which would be even worse. There may also be some DoS issues. From cjbc@it.uc3m.es Mon Feb 28 13:57:43 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A67103A6C40 for ; Mon, 28 Feb 2011 13:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.056 X-Spam-Level: X-Spam-Status: No, score=-4.056 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4G6nJ9eAFPS for ; Mon, 28 Feb 2011 13:57:42 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 0D92E3A6C72 for ; Mon, 28 Feb 2011 13:57:42 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.3] (213.37.82.169.static.user.ono.com [213.37.82.169]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 10B69C27963; Mon, 28 Feb 2011 22:58:42 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Julien Laganier In-Reply-To: References: <1298663501.3608.141.camel@acorde.it.uc3m.es> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-aKqicqvmJhNu95Z8jLr0" Organization: Universidad Carlos III de Madrid Date: Mon, 28 Feb 2011 23:00:05 +0100 Message-ID: <1298930405.3785.18.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17984.000 Cc: netext@ietf.org, "Zuniga, Juan Carlos" Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 21:57:43 -0000 --=-aKqicqvmJhNu95Z8jLr0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Julien, On Fri, 2011-02-25 at 12:59 -0700, Julien Laganier wrote: > 2011/2/25 Carlos Jes=FAs Bernardos Cano : > > Hi Julien, > > > > On Fri, 2011-02-25 at 09:01 -0700, Julien Laganier wrote: > >> JC, > >> > >> Since no PMIPv6 based system can possibly work without the L2 > >> signaling, the L3 MAG-LMA signaling is factually useless. > > > > I have a PMIPv6 system working in my lab and there is no L2 signaling a= t > > all. Optionally, I can enable the APs attached to the MAG detect the MN > > attachment and use that as trigger for the PBU (instead of relaying on > > ND). I agree L2 signaling is used by most deployments as in fact PMIPv6 > > was designed with many things "out-of-the-scope of the spec" (it's ther= e > > where L2 signaling appears), but I disagree L2 signaling is completely > > necessarily. >=20 > Having a prototype that works in a lab isn't a proof that the system > works in the real world. From my perspective L2 signaling is a Well, my lab is in this world (and yes, Universities are real :) ), kidding. Please see inline below... > requirement and I do not know how to build a real world system based > on PMIPv6 that doesn't have them. I have two questions regarding the > real world world applicability of your system that works without L2 > signaling: >=20 > 1) what is the trigger to the PBU if it's not the L2 signaling? 2 possible options: a) RS from the MN (this is documented in RFC5213, though it does not work very well, as not all systems send an RS after moving). b) the AP where the MN attaches to detects the attachment and triggers the MAG. Note that this is not _new_ L2 signalling here, it's just attachment detection based on IEEE 802.11 frames (any standard station has to generate them). >=20 > 2) How does the network decides it can offer flow mobility to a host > in the absence of a layer 2 signaling from the host that indicates > this host's support for flow mobility / inter-access handoffs? For example, you can have that information in the profile of the user. >=20 > > I agree with Rajeev's suggestion to move forward. >=20 > I am happy to move forward when the valid technical questions I've > asked are answered. I think I've tried to answer your questions. Problem is we don't quite agree on the answers of all of them. Carlos >=20 > --julien --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-aKqicqvmJhNu95Z8jLr0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1sGuUACgkQNdy6TdFwT2dqUQCdFed9N92nZLUJ8Vg96PFJQZkf U/cAoId3Drm5IaR9Fg7Lym2TWZr9TNuo =YKBK -----END PGP SIGNATURE----- --=-aKqicqvmJhNu95Z8jLr0-- From cjbc@it.uc3m.es Mon Feb 28 13:57:47 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A752D3A6BEC for ; Mon, 28 Feb 2011 13:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.156 X-Spam-Level: X-Spam-Status: No, score=-3.156 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_28=0.6, J_CHICKENPOX_64=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjVitpKd4Dhu for ; Mon, 28 Feb 2011 13:57:46 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id AF56A3A6C72 for ; Mon, 28 Feb 2011 13:57:45 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.3] (213.37.82.169.static.user.ono.com [213.37.82.169]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id E7313875E54; Mon, 28 Feb 2011 22:58:43 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Tran Minh Trung In-Reply-To: References: <1298663501.3608.141.camel@acorde.it.uc3m.es> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-r+yMfNsmgOaxhayDGTGd" Organization: Universidad Carlos III de Madrid Date: Mon, 28 Feb 2011 23:00:07 +0100 Message-ID: <1298930407.3785.19.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17984.000 Cc: "Zuniga, Juan Carlos" , netext@ietf.org Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 21:57:47 -0000 --=-r+yMfNsmgOaxhayDGTGd Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Trung, On Mon, 2011-02-28 at 18:10 +0900, Tran Minh Trung wrote: > Hi Carlos, >=20 > 2011/2/26 Carlos Jes=FAs Bernardos Cano : > > Hi Julien, > > > > On Fri, 2011-02-25 at 09:01 -0700, Julien Laganier wrote: > >> JC, > >> > >> Since no PMIPv6 based system can possibly work without the L2 > >> signaling, the L3 MAG-LMA signaling is factually useless. > > > > I have a PMIPv6 system working in my lab and there is no L2 signaling a= t > > all. >=20 > I think it is not fully implemented system. > How can you support handover without the L2 signaling message? Please, see my reply to Julien's e-mail. It's true is not a fully RFC5213 system, but I can tell you we are not faking any event related to handovers. Carlos >=20 > Regards, > TrungTM >=20 >=20 > > Optionally, I can enable the APs attached to the MAG detect the MN > > attachment and use that as trigger for the PBU (instead of relaying on > > ND). I agree L2 signaling is used by most deployments as in fact PMIPv6 > > was designed with many things "out-of-the-scope of the spec" (it's ther= e > > where L2 signaling appears), but I disagree L2 signaling is completely > > necessarily. > > > > I agree with Rajeev's suggestion to move forward. > > > > Thanks, > > > > Carlos > > > >> > >> This is has to be the conclusion of this discussion unless someone can > >> provide us with a description of how a system would work without the > >> L2 signaling. > >> > >> --julien > >> > >> On Fri, Feb 25, 2011 at 8:21 AM, Zuniga, Juan Carlos > >> wrote: > >> > Rajeev, > >> > > >> > I agree with you. > >> > > >> > Even if L2 signalling can help the scenario, we should not -only- re= ly on that as we might end up in a catch-22 situation. > >> > > >> > By providing an L3 MAG-LMA signalling solution we would be covered i= n case L2 signalling is not there (HI=3Dunknown), and at the same time we w= ould not preempt a solution that has that L2 signalling to use it. > >> > > >> > This seems to me like a good way to progress this and move forward. > >> > > >> > JC > >> > > >> >> -----Original Message----- > >> >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > >> >> Behalf Of Rajeev Koodli > >> >> Sent: February 24, 2011 8:03 PM > >> >> To: Julien Laganier > >> >> Cc: netext@ietf.org > >> >> Subject: Re: [netext] Flow Mobility discussion - way forward? > >> >> > >> >> > >> >> I do care about the PMIP6 interaction with AAA because the system > >> >> design > >> >> needs it. I don't know of a system where LMA relies on MAG for > >> >> authorization. > >> >> > >> >> The use-case for being able to provide a new prefix at attach is > >> >> robustness. > >> >> There is nothing I could see in 5213 that disallows an LMA from > >> >> providing a > >> >> prefix which is not in the session, and why should there be any > >> >> restriction > >> >> on what prefixes the LMA can provide at attach? > >> >> > >> >> I want flow mobility solution to work without only relying on L2 > >> >> signaling, > >> >> meaning we should be able to also provide it for HI=3DUnknown. This= can > >> >> be > >> >> done with IP signaling between LMA and MAG. This is not replacing L= 2 > >> >> signaling, but covers the case when HI=3Dunknown. > >> >> > >> >> As I have also said earlier, we have different opinions here. Let's > >> >> move > >> >> on.. > >> >> > >> >> -Rajeev > >> >> > >> >> > >> >> On 2/24/11 1:20 PM, "Julien Laganier" wrote= : > >> >> > >> >> > On Thu, Feb 24, 2011 at 12:38 PM, Rajeev Koodli > >> >> wrote: > >> >> >> > >> >> >> Julien, > >> >> >> > >> >> >> The presumed MAG-AAA interaction in 5213 is for authentication > >> >> purposes. > >> >> >> The LMA-AAA interaction is for authorization purposes. The inten= t in > >> >> the > >> >> >> multi-access ID is to enable AAA to authorize the LMA for flow > >> >> mobility > >> >> >> purposes. It's kind of interesting that you refer to 3GPP model > >> >> sometimes, > >> >> >> but reticent about it for the LMA - AAA interaction in 3GPP (e.g= ., > >> >> your > >> >> >> statement below "LMA - AAA interaction is not required per se").= . > >> >> > > >> >> > As I said earlier, if AAA is required to be in place to authentic= ate > >> >> > the MN towards the MAG, that can be used for authorization too. I= do > >> >> > not see what is the security requirement that authorization happe= ns > >> >> in > >> >> > LMA rather than in MAG. > >> >> > > >> >> > That being said, I don't care much about the specifics of the AAA > >> >> > interactions with PMIPv6. My point was, and is, that if you assum= e > >> >> > that the LMA can know from AAA about the ability for a MN network > >> >> > stack to support flow mobility (as opposed to a legacy node), so = can > >> >> > the the MAG. Thus the MAG can set the HI =3D FM to provide flow > >> >> > mobility. As a result the inability of a MAG to know about the MN > >> >> > level of support for flow mobility can't be used as an argument i= n > >> >> > favor of your model 2) where the LMA knows about MN flow mobility= but > >> >> > the MAG doesn't. > >> >> > > >> >> >> You don't believe that there is a need to add a new prefix to th= e > >> >> session. > >> >> >> However, you didn't show me that 5213 prohibits adding a new pre= fix > >> >> to an > >> >> >> existing session. I believe that LMA should be allowed to provid= e > >> >> any prefix > >> >> >> it chooses to, including the previously assigned ones and the ne= w > >> >> ones. > >> >> > > >> >> > I don't believe there's a need to add a new prefix to an existing > >> >> > session to provide flow mobility. Can you point to a usecase that > >> >> > _requires_ adding a new prefix to an existing session for purpose= s of > >> >> > providing flow mobility? > >> >> > > >> >> > My reading of 5213 is that it documents a protocol in which the > >> >> prefix > >> >> > set is allocated at session creation and remains unmodified > >> >> throughout > >> >> > that session lifetime. 5213 doesn't provide a mean to change the > >> >> > prefix set after session creation. Can you point to a provision o= f > >> >> > 5213 that allows changing the prefix set of a session after its > >> >> > creation? > >> >> > > >> >> >> So, let's agree to disagree :-) > >> >> > > >> >> > I can certainly agree to disagree on your reading of 5213 on the > >> >> > ability to add prefixes to an existing session, and on the > >> >> requirement > >> >> > to add new prefix to provide mobility. I do not see any documente= d or > >> >> > reasoned evidence about these. > >> >> > > >> >> > --julien > >> >> > > >> >> >> On 2/24/11 11:17 AM, "Julien Laganier" > >> >> wrote: > >> >> >> > >> >> >>> Rajeev, > >> >> >>> > >> >> >>> Please see inline. > >> >> >>> > >> >> >>> On Thu, Feb 24, 2011 at 10:42 AM, Rajeev Koodli > >> >> wrote: > >> >> >>>> > >> >> >>>> Julien, > >> >> >>>> > >> >> >>>> Please treat this as a combined response to your other e-mail = as > >> >> well. > >> >> >>>> > >> >> >>>> On 2/24/11 8:05 AM, "Julien Laganier" > >> >> wrote: > >> >> >>>> > >> >> >>>>>> > >> >> >>>>>> =3D> I think we need to be careful about using AAA as a pote= ntial > >> >> silver > >> >> >>>>>> bullet for things we don't know how to do in our protocol. M= ore > >> >> >>>>>> specifically, the property discussed above is a device > >> >> attribute. AAA is > >> >> >>>>>> usually a user profile not a device profile unless you assum= e a > >> >> 1:1 > >> >> >>>>>> mapping > >> >> >>>>>> of device:user, which might be the case in some systems in t= he > >> >> US but is > >> >> >>>>>> certainly not the case in the rest of the world. So assuming= the > >> >> device > >> >> >>>>>> properties will be stored in AAA and attributed to the user = is > >> >> not a good > >> >> >>>>>> way to go. > >> >> >>>>>> Furthermore, users use devices that have not be "initialised= " in > >> >> AAA all > >> >> >>>>>> the > >> >> >>>>>> time. A user doesn't ask for an operator's permission before > >> >> they stick > >> >> >>>>>> their SIM in a device. So device properties are not known in > >> >> advance. > >> >> >>>>> > >> >> >>>>> I agree with this entirely, which is why I said: > >> >> >>>>> > >> >> >>>> > >> >> >>>> Good points. > >> >> >>>> The purpose of the multi-access indicator ID is twofold: to en= able > >> >> the MN > >> >> >>>> to > >> >> >>>> indicate its capability and willingness for flow mobility (thr= ough > >> >> the > >> >> >>>> AT_MA_IND attribute). Second, to enable AAA to authorize the u= ser > >> >> for flow > >> >> >>>> mobility. So, it's the MN which is indicating the device > >> >> capability, and > >> >> >>>> the > >> >> >>>> AAA providing the authorization for the flow mobility service. > >> >> >>>> > >> >> >>>> > >> >> >>>>>>>> I think whether or not AAA can really knows what are the > >> >> capabilities > >> >> >>>>>>>> of a network stack on a device is questionable, but let's = skip > >> >> on that > >> >> >>>>>>>> for now: > >> >> >>>>> > >> >> >>>>> but still I wanted to make the point that if to support scena= rio > >> >> 2) in > >> >> >>>>> Rajeev's mail one needs to assume LMA is told by AAA the devi= ce > >> >> >>>>> capabilities, then the MAG can be told that as well by AAA > >> >> (e.g., at > >> >> >>>>> same time it gets to know the MNID) and set HI =3D FM appropr= iately > >> >> as > >> >> >>>>> per case 1) thus there's no point in supporting case 2) as pe= r my > >> >> >>>>> earlier writings on the topic. > >> >> >>>>> > >> >> >>>> > >> >> >>>> There are two parts to consider here. First, the issue of LMA > >> >> knowing that > >> >> >>>> the MN is capable and willing to have flow mobility (I think y= ou > >> >> brought up > >> >> >>>> the issue of legacy host). Whether or not MAG is informed by t= he > >> >> AAA, there > >> >> >>>> is LMA - AAA interaction. > >> >> >>> > >> >> >>> MAG has to be informed of an authenticated MNID for PMIPv6 to w= ork. > >> >> >>> When authentication of the MNID is based on AAA, the MAG alread= y > >> >> >>> receives information from AAA. So in a basic 5213 deployment th= at > >> >> uses > >> >> >>> AAA for authentication, there is MAG-AAA interaction. > >> >> >>> > >> >> >>> On the other hand LMA - AAA interaction isn't required per se i= n > >> >> the 5213 > >> >> >>> model. > >> >> >>> > >> >> >>>> In other words, LMA will go t= o > >> >> AAA anyway. > >> >> >>>> So, the > >> >> >>>> AAA providing the attribute to the MAG is redundant exchange w= hich > >> >> we > >> >> >>>> thought unnecessary for the multi-access ID. > >> >> >>> > >> >> >>> This backward: As above, if AAA is used the MAG will go to AAA,= so > >> >> the > >> >> >>> AAA providing the attribute to the LMA is the redundant exchang= e > >> >> which > >> >> >>> is unnecessary for multi-access ID. > >> >> >>> > >> >> >>>> > >> >> And, > >> >> >>>> whether > >> >> >>>> the LMA will > >> >> >>>> actually accept the indicator provided by MAG is moot, since t= he > >> >> >>>> authorization should come from elsewhere (AAA). > >> >> >>> > >> >> >>> PMIPv6 assumes that the MAG is trusted by the LMA, thus the LMA= can > >> >> >>> accept the indicator provided by the MAG. > >> >> >>> > >> >> >>>> Second, the issue of assigning prefixes at the LMA. The LMA sh= ould > >> >> be able > >> >> >>>> to assign any prefix freely upon any attach. > >> >> >>> > >> >> >>> As I said earlier many times, the 5213 model is that of a prefi= x > >> >> set > >> >> >>> allocated at session creation and there has been no reason to > >> >> depart > >> >> >>> from that model for purposes of flow mobility, i.e., I can prov= ide > >> >> >>> flow mobility under that same model thus there's no basis to ch= ange > >> >> >>> that model under this work item. > >> >> >>> > >> >> >>>> > >> >> > >> >> >>>> With > >> >> >>>> HI=3DHandover, it returns > >> >> >>>> the previously assigned prefix, but there is no prohibition to > >> >> also return > >> >> >>>> a > >> >> >>>> hitherto unassigned prefix, AFAICT. > >> >> >>> > >> >> >>> As above, the 5213 model factually does not change the prefix s= et > >> >> that > >> >> >>> was allocated at session creation after a handover or at any ot= her > >> >> >>> point in the session lifetime. As above, there's no basis to ch= ange > >> >> >>> that for the purpose of flow mobility since it is not required = / > >> >> >>> necessary. > >> >> >>> > >> >> >>>> > >> >> Similarly, even > >> >> >>>> with HI =3D FM, the LMA > >> >> >>>> can assign a new prefix which is not in the current set. > >> >> >>> > >> >> >>> Disagree. This is an unwarranted modification of the 5213 model= . > >> >> >>> > >> >> >>>> This is not a new feature which we need to support. > >> >> >>> > >> >> >>> Compared to the 5213 model it is indeed a new feature that a pr= efix > >> >> >>> set for a PMIPv6 session can be modified after that session > >> >> creation, > >> >> >>> as I've kept explaining again and again. And that new feature i= s > >> >> not > >> >> >>> required to complete the flow mobility work item thus there's n= o > >> >> basis > >> >> >>> to alter the 5213 model in that context. > >> >> >>> > >> >> >>> I am surprised we are still discussing this. > >> >> >>> > >> >> >>> --julien > >> >> >> > >> >> >> > >> >> > >> >> _______________________________________________ > >> >> netext mailing list > >> >> netext@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/netext > >> > _______________________________________________ > >> > netext mailing list > >> > netext@ietf.org > >> > https://www.ietf.org/mailman/listinfo/netext > >> > > >> _______________________________________________ > >> netext mailing list > >> netext@ietf.org > >> https://www.ietf.org/mailman/listinfo/netext > > > > -- > > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > > > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > > > > >=20 >=20 >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-r+yMfNsmgOaxhayDGTGd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1sGucACgkQNdy6TdFwT2fdmACfevoMjLQeu0u/cncRoFWw/jv/ IuMAoN14rAg2VOJyWmCvlMYYYNYchCFy =xAgu -----END PGP SIGNATURE----- --=-r+yMfNsmgOaxhayDGTGd-- From hesham@elevatemobile.com Mon Feb 28 17:32:16 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E07623A6D1E for ; Mon, 28 Feb 2011 17:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5BWe1aylg1j for ; Mon, 28 Feb 2011 17:32:16 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 055C33A6CC1 for ; Mon, 28 Feb 2011 17:32:15 -0800 (PST) Received: from [122.110.178.244] (helo=[192.168.0.2]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1PuESa-00032D-3z; Tue, 01 Mar 2011 12:33:08 +1100 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 01 Mar 2011 12:32:55 +1100 From: Hesham Soliman To: , Julien Laganier Message-ID: Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvXsJaJzFBbDa5kD0unoEeOit7KtA== In-Reply-To: <1298930405.3785.18.camel@acorde.it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: netext@ietf.org, "Zuniga, Juan Carlos" Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 01:32:17 -0000 Carlos, >> requirement and I do not know how to build a real world system based >> on PMIPv6 that doesn't have them. I have two questions regarding the >> real world world applicability of your system that works without L2 >> signaling: >> >> 1) what is the trigger to the PBU if it's not the L2 signaling? > > 2 possible options: > > a) RS from the MN (this is documented in RFC5213, though it does not > work very well, as not all systems send an RS after moving). > > b) the AP where the MN attaches to detects the attachment and triggers > the MAG. Note that this is not _new_ L2 signalling here, it's just > attachment detection based on IEEE 802.11 frames (any standard station > has to generate them). => How do you identify the MN across MAGs? How does a new MAG know the MN's addresses? Are you transferring MAC addresses around? > >> >> 2) How does the network decides it can offer flow mobility to a host >> in the absence of a layer 2 signaling from the host that indicates >> this host's support for flow mobility / inter-access handoffs? > > For example, you can have that information in the profile of the user. => Do you have a user profile transfer mechanism in your lab? If you do please share some high level info. Hesham From julien.ietf@gmail.com Mon Feb 28 18:32:36 2011 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FE303A6B17 for ; Mon, 28 Feb 2011 18:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iB0AdIS5-Gm5 for ; Mon, 28 Feb 2011 18:32:30 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 2DC213A6C9B for ; Mon, 28 Feb 2011 18:32:30 -0800 (PST) Received: by fxm15 with SMTP id 15so4469543fxm.31 for ; Mon, 28 Feb 2011 18:33:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fqGOkrfRCnIK/9L7V+UsxNP3zbE2aYQ91oHRYrmc3hI=; b=VjxNMPY2ygPi3dbKqTKQHOM7DUpzUSVPvzaG5zpyIzpc+CIrIAPwqU+enUN0z6Z+wU 3Ess1JOCK+CS7xqSvDZD2akm6v7djhifJlOk2rF9I76MbnqeDMoAgUFsyUkdhqNcWHVd gUJDp5lGl09F1GBeDde3pZrclxt6RPq1n5cGI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Y272TjRWF6LO2WjaTx1ze9XiSc5aMgsstEKnhVTvpdK9V83ooC2/1HYOYriDsQVQE3 HnU6KbufDjVdwkCG3vHv6naZtYlLrbR+6sXC8nr+AkkswiyMBqfyRR6epBRQs/owD8+V nKHzoe52bFQjgXN0CfHlol2h/peJhaKAEkOjY= MIME-Version: 1.0 Received: by 10.223.119.68 with SMTP id y4mr7441459faq.104.1298946811492; Mon, 28 Feb 2011 18:33:31 -0800 (PST) Received: by 10.223.74.142 with HTTP; Mon, 28 Feb 2011 18:33:31 -0800 (PST) In-Reply-To: <1298930405.3785.18.camel@acorde.it.uc3m.es> References: <1298663501.3608.141.camel@acorde.it.uc3m.es> <1298930405.3785.18.camel@acorde.it.uc3m.es> Date: Mon, 28 Feb 2011 19:33:31 -0700 Message-ID: From: Julien Laganier To: cjbc@it.uc3m.es Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org, "Zuniga, Juan Carlos" Subject: Re: [netext] Flow Mobility discussion - way forward? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 02:32:36 -0000 2011/2/28 Carlos Jes=FAs Bernardos Cano : > Hi Julien, > > On Fri, 2011-02-25 at 12:59 -0700, Julien Laganier wrote: >> 2011/2/25 Carlos Jes=FAs Bernardos Cano : >> > Hi Julien, >> > >> > On Fri, 2011-02-25 at 09:01 -0700, Julien Laganier wrote: >> >> JC, >> >> >> >> Since no PMIPv6 based system can possibly work without the L2 >> >> signaling, the L3 MAG-LMA signaling is factually useless. >> > >> > I have a PMIPv6 system working in my lab and there is no L2 signaling = at >> > all. Optionally, I can enable the APs attached to the MAG detect the M= N >> > attachment and use that as trigger for the PBU (instead of relaying on >> > ND). I agree L2 signaling is used by most deployments as in fact PMIPv= 6 >> > was designed with many things "out-of-the-scope of the spec" (it's the= re >> > where L2 signaling appears), but I disagree L2 signaling is completely >> > necessarily. >> >> Having a prototype that works in a lab isn't a proof that the system >> works in the real world. From my perspective L2 signaling is a > > Well, my lab is in this world (and yes, Universities are real :) ), > kidding. Please see inline below... > >> requirement and I do not know how to build a real world system based >> on PMIPv6 that doesn't have them. I have two questions regarding the >> real world world applicability of your system that works without L2 >> signaling: >> >> 1) what is the trigger to the PBU if it's not the L2 signaling? > > 2 possible options: > > a) RS from the MN (this is documented in RFC5213, though it does not > work very well, as not all systems send an RS after moving). Right. It does not work because the system can't reliably expect these RS's to be sent and received by hosts. > b) the AP where the MN attaches to detects the attachment and triggers > the MAG. Note that this is not _new_ L2 signalling here, it's just > attachment detection based on IEEE 802.11 frames (any standard station > has to generate them). So you do rely on L2 signaling. That was my point. That L2 signalling is required. >> 2) How does the network decides it can offer flow mobility to a host >> in the absence of a layer 2 signaling from the host that indicates >> this host's support for flow mobility / inter-access handoffs? > > For example, you can have that information in the profile of the user. I don't think that user profile can adequately characterizes the capabilities of a device's network stack. I might own one device that supports flow mobility and one that doesn't, in which case, either I get no flow mobility on any of my devices, or I get flow mobility on one of the devices and no connectivity at all on the other. None of this two scenarios seems to be acceptable in a real system. The only entity that can reliably transmit that information to the network is the (network stack on the) host itself. So we do require L2 signaling. --julien