From cjbc@it.uc3m.es Tue Mar 1 01:36: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 1541F3A63CB for ; Tue, 1 Mar 2011 01:36:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.474 X-Spam-Level: X-Spam-Status: No, score=-5.474 tagged_above=-999 required=5 tests=[AWL=0.225, 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 mm8sexqb8z1e for ; Tue, 1 Mar 2011 01:36:26 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 491B43A63C9 for ; Tue, 1 Mar 2011 01:36:25 -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 ECE1A87D569; Tue, 1 Mar 2011 10:37:27 +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> <1298930405.3785.18.camel@acorde.it.uc3m.es> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-SEFv+WwlnGmjkJl3DG9x" Organization: Universidad Carlos III de Madrid Date: Tue, 01 Mar 2011 10:38:52 +0100 Message-ID: <1298972332.10293.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.003 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: Tue, 01 Mar 2011 09:36:28 -0000 --=-SEFv+WwlnGmjkJl3DG9x Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Julien, On Mon, 2011-02-28 at 19:33 -0700, Julien Laganier wrote: > 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 signalin= g 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 PMI= Pv6 > >> > was designed with many things "out-of-the-scope of the spec" (it's t= here > >> > where L2 signaling appears), but I disagree L2 signaling is complete= ly > >> > 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). >=20 > Right. It does not work because the system can't reliably expect these > RS's to be sent and received by hosts. >=20 > > 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 > So you do rely on L2 signaling. That was my point. That L2 signalling > is required. Well, there is a big difference between using the signalling that is always there (no matter if is PMIPv6 in place or just a single station attaching to an AP) and requiring L2 signalling to have additional semantics to enable PMIPv6 operation. We just use triggers from the AP. >=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 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. You can have information about the capabilities of the device in your database as well. Carlos >=20 > 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. >=20 > --julien --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-SEFv+WwlnGmjkJl3DG9x 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) iEYEABECAAYFAk1svqwACgkQNdy6TdFwT2cE6gCdGZ5kHQEoE8N7DiqLq2nnja2r +PsAoIheXCUFHM9em+lV1HmYoatzoQL0 =OkPe -----END PGP SIGNATURE----- --=-SEFv+WwlnGmjkJl3DG9x-- From cjbc@it.uc3m.es Tue Mar 1 01:36: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 954713A63D2 for ; Tue, 1 Mar 2011 01:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.519 X-Spam-Level: X-Spam-Status: No, score=-5.519 tagged_above=-999 required=5 tests=[AWL=0.180, 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 5+-PUOTP5a37 for ; Tue, 1 Mar 2011 01:36:28 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 32EE43A63C9 for ; Tue, 1 Mar 2011 01:36:28 -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 C4E7375A317; Tue, 1 Mar 2011 10:37:29 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Hesham Soliman In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-xTS/mFGoUsFMi+HMc+Hj" Organization: Universidad Carlos III de Madrid Date: Tue, 01 Mar 2011 10:38:54 +0100 Message-ID: <1298972334.10293.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.003 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: Tue, 01 Mar 2011 09:36:29 -0000 --=-xTS/mFGoUsFMi+HMc+Hj Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Hesham, On Tue, 2011-03-01 at 12:32 +1100, Hesham Soliman wrote: > Carlos,=20 >=20 > >> 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? > >=20 > > 2 possible options: > >=20 > > 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). > >=20 > > 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 > =3D> How do you identify the MN across MAGs? How does a new MAG know the = MN's > addresses? Are you transferring MAC addresses around? We identify the MN using its MAC address. >=20 > >=20 > >>=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? > >=20 > > For example, you can have that information in the profile of the user. >=20 > =3D> Do you have a user profile transfer mechanism in your lab? If you do > please share some high level info. In our lab the testbed is small, so we just have a config file with the profile. Carlos >=20 > Hesham >=20 >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-xTS/mFGoUsFMi+HMc+Hj 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) iEYEABECAAYFAk1svq4ACgkQNdy6TdFwT2dGPwCglnNgGXc7cabuqDMQCJplwfIH 8T8An0beUiwBbtFmLbBD6AnuEbDjp/zz =G320 -----END PGP SIGNATURE----- --=-xTS/mFGoUsFMi+HMc+Hj-- From hesham@elevatemobile.com Tue Mar 1 04:03: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 549243A67AD for ; Tue, 1 Mar 2011 04:03:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.649, 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 9T3o+BNJaM3N for ; Tue, 1 Mar 2011 04:03:58 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 83C683A67C1 for ; Tue, 1 Mar 2011 04:03:57 -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 1PuOJx-0007LC-HN; Tue, 01 Mar 2011 23:04:53 +1100 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 01 Mar 2011 23:04:46 +1100 From: Hesham Soliman To: Message-ID: Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvYCNtB30IuyPv7ekqpWU6RyZvggg== In-Reply-To: <1298972334.10293.19.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: "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: Tue, 01 Mar 2011 12:03:59 -0000 >> >> => How do you identify the MN across MAGs? How does a new MAG know the MN's >> addresses? Are you transferring MAC addresses around? > > We identify the MN using its MAC address. => I consider that a reliance on L2 obviously, but how does the new MAG recognise that this MN already has a binding? How does it get its old address? I'm asking these questions because I don't think any serious WLAN deployment would ever use PMIPv6. If for nothing else, PMIPv6 won't work on shared links. >> => Do you have a user profile transfer mechanism in your lab? If you do >> please share some high level info. > > In our lab the testbed is small, so we just have a config file with the > profile. => So as both myself and Julien already said, you must be assuming a 1:1 mapping between the MN and the user. Either that or your profile is a device profile not a user profile. The former is wrong in the real world and the latter is not used in the real world. Thanks, Hesham > > Carlos > >> >> Hesham >> >> From cjbc@it.uc3m.es Tue Mar 1 04:10: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 AF6723A67DA for ; Tue, 1 Mar 2011 04:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.549 X-Spam-Level: X-Spam-Status: No, score=-5.549 tagged_above=-999 required=5 tests=[AWL=0.150, 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 yGy5d82u08Jp for ; Tue, 1 Mar 2011 04:10:31 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 835F43A67C3 for ; Tue, 1 Mar 2011 04:10:31 -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 117617047ED; Tue, 1 Mar 2011 13:11:34 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Hesham Soliman In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-5nld+vEenCsv+3vAwj95" Organization: Universidad Carlos III de Madrid Date: Tue, 01 Mar 2011 13:12:58 +0100 Message-ID: <1298981578.5170.13.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.007 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: Tue, 01 Mar 2011 12:10:39 -0000 --=-5nld+vEenCsv+3vAwj95 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Hesham, On Tue, 2011-03-01 at 23:04 +1100, Hesham Soliman wrote: > >>=20 > >> =3D> How do you identify the MN across MAGs? How does a new MAG know t= he MN's > >> addresses? Are you transferring MAC addresses around? > >=20 > > We identify the MN using its MAC address. >=20 > =3D> I consider that a reliance on L2 obviously, but how does the new MAG > recognise that this MN already has a binding? How does it get its old This is a question related to the flow mobility solution itself. The prototype I mention is plain PMIPv6. Anyway, in the solution we have in our draft, it is the LMA that knows if the MN has already a binding, not the MAG, and for that we could thing of feasible approaches. > address? I'm asking these questions because I don't think any serious WLA= N > deployment would ever use PMIPv6. If for nothing else, PMIPv6 won't work = on Well, I see quite potential for PMIPv6 over WLAN, why do you think there would not be any serious WLAN deployment with PMIPv6? > shared links.=20 >=20 > >> =3D> Do you have a user profile transfer mechanism in your lab? If you= do > >> please share some high level info. > >=20 > > In our lab the testbed is small, so we just have a config file with the > > profile. >=20 > =3D> So as both myself and Julien already said, you must be assuming a 1:= 1 > mapping between the MN and the user. Either that or your profile is a dev= ice > profile not a user profile. The former is wrong in the real world and the > latter is not used in the real world. I was referring to a device profile and I don't see why this cannot be used in the real world. My operator here in Spain knows which device I use (even I have a flat rate that can just be used with my type of device). Carlos >=20 > Thanks, > Hesham >=20 >=20 > >=20 > > Carlos > >=20 > >>=20 > >> Hesham > >>=20 > >>=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 --=-5nld+vEenCsv+3vAwj95 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) iEYEABECAAYFAk1s4soACgkQNdy6TdFwT2fbpgCgrVNhUoQ+wZP8AGdnwK0L7xry dykAn2suflHXm5Z8l8HYtpuP7FOdMfaS =Ig5/ -----END PGP SIGNATURE----- --=-5nld+vEenCsv+3vAwj95-- From hesham@elevatemobile.com Tue Mar 1 04:17: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 698993A67EE for ; Tue, 1 Mar 2011 04:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 HgJBf+rZBnPU for ; Tue, 1 Mar 2011 04:17:18 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 87C423A67EA for ; Tue, 1 Mar 2011 04:17:17 -0800 (PST) Received: from [203.219.211.243] (helo=[192.168.0.4]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1PuOWt-00016l-FV; Tue, 01 Mar 2011 23:18:15 +1100 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 01 Mar 2011 23:18:10 +1100 From: Hesham Soliman To: Message-ID: Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvYCrp5v4eBnJKCJkmgtrVKeW3bJg== In-Reply-To: <1298981578.5170.13.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: "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: Tue, 01 Mar 2011 12:17:19 -0000 > > Well, I see quite potential for PMIPv6 over WLAN, why do you think there > would not be any serious WLAN deployment with PMIPv6? => Because of the nature of the links, a router doesn't always know who's attached. As you said earlier you make the MN send an RS, which is not required in IPv6. Also the address allocation is a mess and sharing the link with MIPv6 nodes is very problematic. I'm not the right person to say why PMIPv6 was created in the first place but I only see it used, if ever, on p2p links whose use is strictly defined in SDOs. It was never intended, even by its proponents, to do flow mobility or global mobility and it can't do either one. The irony is that people wanted something that doesn't involve MN signalling and now we'll expect signalling anyway, just not on L3. It's mind boggling. > >> shared links. >> >>>> => Do you have a user profile transfer mechanism in your lab? If you do >>>> please share some high level info. >>> >>> In our lab the testbed is small, so we just have a config file with the >>> profile. >> >> => So as both myself and Julien already said, you must be assuming a 1:1 >> mapping between the MN and the user. Either that or your profile is a device >> profile not a user profile. The former is wrong in the real world and the >> latter is not used in the real world. > > I was referring to a device profile and I don't see why this cannot be > used in the real world. My operator here in Spain knows which device I > use (even I have a flat rate that can just be used with my type of > device). => Really? And do you call your operator if you remove your SIM card and put it in another device?. Does you operator also know when you run new SW on your phone/laptop? This is not a serious approach, I'm sorry but it's completely unreliable for any serious deployment Hesham > > Carlos > >> >> Thanks, >> Hesham >> >> >>> >>> Carlos >>> >>>> >>>> Hesham >>>> >>>> >> >> From sgundave@cisco.com Tue Mar 1 10:17: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 7DEEF3A698E for ; Tue, 1 Mar 2011 10:17:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.146 X-Spam-Level: X-Spam-Status: No, score=-10.146 tagged_above=-999 required=5 tests=[AWL=0.453, 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 T3uv4NJ1QiHE for ; Tue, 1 Mar 2011 10:17:55 -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 909433A687C for ; Tue, 1 Mar 2011 10:17:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=2728; q=dns/txt; s=iport; t=1299003538; x=1300213138; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=Su/G1QWC5v6IdAGZX7EylVZtUk1ahRpfK+y7tIJsSv8=; b=Y38eC5YF3eiN5Afk7wwtioaXtXveobvLdQMs7QlWSOeJ9uPtqkMXjUx0 HHwBi63O3/4VpVRdLrLaEQ+G6c5Gd1yJGIsZx0otkA6z0o1F2K4Agir5c xt1zGDMZ3jsIuIhUnIjDYECLlUitbhpE/P6GnnknvQityrjPcD341cJJh k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AogGANrHbE2rR7H+/2dsb2JhbACYOI4WdKBSnCGDLQGCMwSFEocNg0Y X-IronPort-AV: E=Sophos;i="4.62,248,1297036800"; d="scan'208";a="272323657" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 01 Mar 2011 18:18:58 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p21IIx1D019520; Tue, 1 Mar 2011 18:18:59 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); Tue, 1 Mar 2011 10:18:59 -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 ; Tue, 1 Mar 2011 18:18:58 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 01 Mar 2011 10:20:20 -0800 From: Sri Gundavelli To: Message-ID: Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvYCrp5v4eBnJKCJkmgtrVKeW3bJgAMpgUv In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Mar 2011 18:18:59.0053 (UTC) FILETIME=[225101D0:01CBD83D] 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 18:17:56 -0000 Carlos: I've not been following this thread, pardon me for the ignorance on the context of the thread. Clarifying question (specific to this one comment). > As you said earlier you make the MN send an RS, which is not required in IPv6. A mobile node, or a simple IPv6 node, on a new link does not an RS ? How does it detect the IPv6 routers, if suppress-periodic RA is enabled ? Sri On 3/1/11 4:18 AM, "Hesham Soliman" wrote: > >> >> Well, I see quite potential for PMIPv6 over WLAN, why do you think there >> would not be any serious WLAN deployment with PMIPv6? > > => Because of the nature of the links, a router doesn't always know who's > attached. As you said earlier you make the MN send an RS, which is not > required in IPv6. Also the address allocation is a mess and sharing the link > with MIPv6 nodes is very problematic. I'm not the right person to say why > PMIPv6 was created in the first place but I only see it used, if ever, on > p2p links whose use is strictly defined in SDOs. It was never intended, even > by its proponents, to do flow mobility or global mobility and it can't do > either one. > The irony is that people wanted something that doesn't involve MN signalling > and now we'll expect signalling anyway, just not on L3. It's mind boggling. > >> >>> shared links. >>> >>>>> => Do you have a user profile transfer mechanism in your lab? If you do >>>>> please share some high level info. >>>> >>>> In our lab the testbed is small, so we just have a config file with the >>>> profile. >>> >>> => So as both myself and Julien already said, you must be assuming a 1:1 >>> mapping between the MN and the user. Either that or your profile is a device >>> profile not a user profile. The former is wrong in the real world and the >>> latter is not used in the real world. >> >> I was referring to a device profile and I don't see why this cannot be >> used in the real world. My operator here in Spain knows which device I >> use (even I have a flat rate that can just be used with my type of >> device). > > => Really? And do you call your operator if you remove your SIM card and > put it in another device?. Does you operator also know when you run new SW > on your phone/laptop? This is not a serious approach, I'm sorry but it's > completely unreliable for any serious deployment > > Hesham > >> >> Carlos >> >>> >>> Thanks, >>> Hesham >>> >>> >>>> >>>> Carlos >>>> >>>>> >>>>> Hesham >>>>> >>>>> >>> >>> > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From cjbc@it.uc3m.es Tue Mar 1 11:03: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 882843A6A74 for ; Tue, 1 Mar 2011 11:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.57 X-Spam-Level: X-Spam-Status: No, score=-5.57 tagged_above=-999 required=5 tests=[AWL=0.129, 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 kv+CFCVO8AEE for ; Tue, 1 Mar 2011 11:03:44 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id E562D3A6A60 for ; Tue, 1 Mar 2011 11:03:43 -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 smtp01.uc3m.es (Postfix) with ESMTP id DEF3AC1DF44; Tue, 1 Mar 2011 20:04:46 +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="=-kH/0ioP5nVbVZ1cTcczh" Organization: Universidad Carlos III de Madrid Date: Tue, 01 Mar 2011 20:06:11 +0100 Message-ID: <1299006371.5170.28.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-17986.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: Tue, 01 Mar 2011 19:03:45 -0000 --=-kH/0ioP5nVbVZ1cTcczh Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Sri, On Tue, 2011-03-01 at 10:20 -0800, Sri Gundavelli wrote: > Carlos: >=20 > I've not been following this thread, pardon me for the ignorance on the > context of the thread. Clarifying question (specific to this one comment)= . >=20 >=20 > > As you said earlier you make the MN send an RS, which is not required i= n IPv6. >=20 > A mobile node, or a simple IPv6 node, on a new link does not an RS ? How > does it detect the IPv6 routers, if suppress-periodic RA is enabled ? >=20 The point is that, in my experience, if you attach a node to a WLAN (i.e. connect to an AP), when you first bring up the interface an RS is sent. But if later on the device changes AP, my experience with Linux is that no more RS are generated (unless you bring down/up the interface). Thanks, Carlos >=20 > Sri >=20 >=20 >=20 >=20 >=20 > On 3/1/11 4:18 AM, "Hesham Soliman" wrote: >=20 > >=20 > >>=20 > >> Well, I see quite potential for PMIPv6 over WLAN, why do you think the= re > >> would not be any serious WLAN deployment with PMIPv6? > >=20 > > =3D> Because of the nature of the links, a router doesn't always know w= ho's > > attached. As you said earlier you make the MN send an RS, which is not > > required in IPv6. Also the address allocation is a mess and sharing the= link > > with MIPv6 nodes is very problematic. I'm not the right person to say w= hy > > PMIPv6 was created in the first place but I only see it used, if ever, = on > > p2p links whose use is strictly defined in SDOs. It was never intended,= even > > by its proponents, to do flow mobility or global mobility and it can't = do > > either one.=20 > > The irony is that people wanted something that doesn't involve MN signa= lling > > and now we'll expect signalling anyway, just not on L3. It's mind boggl= ing. > >=20 > >>=20 > >>> shared links.=20 > >>>=20 > >>>>> =3D> Do you have a user profile transfer mechanism in your lab? If = you do > >>>>> please share some high level info. > >>>>=20 > >>>> In our lab the testbed is small, so we just have a config file with = the > >>>> profile. > >>>=20 > >>> =3D> So as both myself and Julien already said, you must be assuming = a 1:1 > >>> mapping between the MN and the user. Either that or your profile is a= device > >>> profile not a user profile. The former is wrong in the real world and= the > >>> latter is not used in the real world. > >>=20 > >> I was referring to a device profile and I don't see why this cannot be > >> used in the real world. My operator here in Spain knows which device I > >> use (even I have a flat rate that can just be used with my type of > >> device). > >=20 > > =3D> Really? And do you call your operator if you remove your SIM card= and > > put it in another device?. Does you operator also know when you run new= SW > > on your phone/laptop? This is not a serious approach, I'm sorry but it'= s > > completely unreliable for any serious deployment > >=20 > > Hesham > >=20 > >>=20 > >> Carlos > >>=20 > >>>=20 > >>> Thanks, > >>> Hesham > >>>=20 > >>>=20 > >>>>=20 > >>>> Carlos > >>>>=20 > >>>>>=20 > >>>>> Hesham > >>>>>=20 > >>>>>=20 > >>>=20 > >>>=20 > >=20 > >=20 > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-kH/0ioP5nVbVZ1cTcczh 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) iEYEABECAAYFAk1tQ6MACgkQNdy6TdFwT2d1+gCgmN8mVytWmog6uRXrDLH9MJsO xqwAoNd3Tyou7PT9cA+aiPmXQybYNgHT =MbhN -----END PGP SIGNATURE----- --=-kH/0ioP5nVbVZ1cTcczh-- From cjbc@it.uc3m.es Tue Mar 1 11:28: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 A9D683A6A16 for ; Tue, 1 Mar 2011 11:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.587 X-Spam-Level: X-Spam-Status: No, score=-5.587 tagged_above=-999 required=5 tests=[AWL=0.112, 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 VW2u2LGHT8+H for ; Tue, 1 Mar 2011 11:28:35 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 4F6B03A6A76 for ; Tue, 1 Mar 2011 11:28: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 2991F96C5E1; Tue, 1 Mar 2011 20:29:23 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Hesham Soliman In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-aRwGcN7iajpBDzmDwOEK" Organization: Universidad Carlos III de Madrid Date: Tue, 01 Mar 2011 20:30:47 +0100 Message-ID: <1299007847.5170.49.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-17986.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: Tue, 01 Mar 2011 19:28:36 -0000 --=-aRwGcN7iajpBDzmDwOEK Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Hesham, On Tue, 2011-03-01 at 23:18 +1100, Hesham Soliman wrote: > >=20 > > Well, I see quite potential for PMIPv6 over WLAN, why do you think ther= e > > would not be any serious WLAN deployment with PMIPv6? >=20 > =3D> Because of the nature of the links, a router doesn't always know who= 's > attached. As you said earlier you make the MN send an RS, which is not > required in IPv6. Also the address allocation is a mess and sharing the l= ink PMIPv6 does not force any specific mechanism on how the MAG detects the attachment of a MN. My experience with WLAN is quite OK so far, never had a problem and it's quite easy to implement the AP trigger and the ptp-to-ptp emulation on WLAN. > with MIPv6 nodes is very problematic. I'm not the right person to say why > PMIPv6 was created in the first place but I only see it used, if ever, on > p2p links whose use is strictly defined in SDOs. It was never intended, e= ven > by its proponents, to do flow mobility or global mobility and it can't do > either one.=20 I don't know the intention of the proponents of the protocol, but as mentioned in other e-mail, I don't see any problem using it on WLAN links. I see it working every day, and even doing flow mobility across different technologies. > The irony is that people wanted something that doesn't involve MN signall= ing > and now we'll expect signalling anyway, just not on L3. It's mind bogglin= g. I don't expect signaling from the MN, that's the point. I see the value of PMIPv6 on this absence of MN involvement and that's why we are proposing signaling on the core (MAG-LMA) to enable flow mobility instead of putting all the requirements on the MN (for that we already have MIPv6). Carlos >=20 > >=20 > >> shared links.=20 > >>=20 > >>>> =3D> Do you have a user profile transfer mechanism in your lab? If y= ou do > >>>> please share some high level info. > >>>=20 > >>> In our lab the testbed is small, so we just have a config file with t= he > >>> profile. > >>=20 > >> =3D> So as both myself and Julien already said, you must be assuming a= 1:1 > >> mapping between the MN and the user. Either that or your profile is a = device > >> profile not a user profile. The former is wrong in the real world and = the > >> latter is not used in the real world. > >=20 > > I was referring to a device profile and I don't see why this cannot be > > used in the real world. My operator here in Spain knows which device I > > use (even I have a flat rate that can just be used with my type of > > device). >=20 > =3D> Really? And do you call your operator if you remove your SIM card a= nd > put it in another device?. Does you operator also know when you run new S= W > on your phone/laptop? This is not a serious approach, I'm sorry but it's > completely unreliable for any serious deployment You talking about serious approaches and operators?? from a pure-user only perspective, I'm sorry to say that most current practices of operators cannot be considered as "serious" :) Carlos >=20 > Hesham >=20 > >=20 > > Carlos > >=20 > >>=20 > >> Thanks, > >> Hesham > >>=20 > >>=20 > >>>=20 > >>> Carlos > >>>=20 > >>>>=20 > >>>> Hesham > >>>>=20 > >>>>=20 > >>=20 > >>=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 --=-aRwGcN7iajpBDzmDwOEK 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) iEYEABECAAYFAk1tSWcACgkQNdy6TdFwT2ey4QCg5kzZ0+KX9AR+mbduAFoBvmUw 658AnjBYWokv4/ihLrvKXY7m4QpGmgt5 =LldA -----END PGP SIGNATURE----- --=-aRwGcN7iajpBDzmDwOEK-- From sgundave@cisco.com Tue Mar 1 11:33: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 2DE043A6A76 for ; Tue, 1 Mar 2011 11:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.205 X-Spam-Level: X-Spam-Status: No, score=-9.205 tagged_above=-999 required=5 tests=[AWL=-0.602, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, 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 ArNlE7fGl6K8 for ; Tue, 1 Mar 2011 11:33:20 -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 DE53F3A6A4A for ; Tue, 1 Mar 2011 11:33:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=3890; q=dns/txt; s=iport; t=1299008064; x=1300217664; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=+FhSQwHstOYbGzmAHN0UfYBPH1Jn4mMIhQW+4z0dr+4=; b=FDjH/jGnirPEi98BzBBbZ0DoCxyI/3aRubcY3Bcem1ExYhfXoNO9eIwm GAcLNy2T6LEl4OMRZijNCpQaXIiWo11D58Oc0aqOmHaU/jAXPYiKcUfuL Ugk89ijDVFjuLO08z6waDYptzscp/NwsrL8FdtzMJFSRXxPfS20iBPVQn s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAE3ZbE2rR7H+/2dsb2JhbAClclx0oEucF4MtAYIzBIUShw2DRg Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 01 Mar 2011 19:34:24 +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 p21JYOSB024596; Tue, 1 Mar 2011 19:34:24 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 Mar 2011 11:34:24 -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 ; Tue, 1 Mar 2011 19:34:22 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 01 Mar 2011 11:35:44 -0800 From: Sri Gundavelli To: Message-ID: Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvYR9sUmUkiHLEzf0u+l4r36PfVaQ== In-Reply-To: <1299006371.5170.28.camel@acorde.it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 01 Mar 2011 19:34:24.0608 (UTC) FILETIME=[ABC1E600:01CBD847] 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 19:33:23 -0000 Hi Carlos: On 3/1/11 11:06 AM, "Carlos Jes=FAs Bernardos Cano" wrote: > Hi Sri, >=20 > On Tue, 2011-03-01 at 10:20 -0800, Sri Gundavelli wrote: >> Carlos: >>=20 >> I've not been following this thread, pardon me for the ignorance on the >> context of the thread. Clarifying question (specific to this one comment= ). >>=20 >>=20 >>> As you said earlier you make the MN send an RS, which is not required i= n >>> IPv6. >>=20 >> A mobile node, or a simple IPv6 node, on a new link does not an RS ? How >> does it detect the IPv6 routers, if suppress-periodic RA is enabled ? >>=20 >=20 > The point is that, in my experience, if you attach a node to a WLAN > (i.e. connect to an AP), when you first bring up the interface an RS is > sent. But if later on the device changes AP, my experience with Linux is > that no more RS are generated (unless you bring down/up the interface). >=20 All the stacks I've tested, any time there is a link flap, reassociation with a new 802.11 AP, the client will send an RS. This is true for IPv4 as well, the activation of DNAv4 procedures, ARP'ng for the DR MAC address. IMO, the node does send an RS message. Regards Sri > Thanks, >=20 > Carlos >=20 >>=20 >> Sri >>=20 >>=20 >>=20 >>=20 >>=20 >> On 3/1/11 4:18 AM, "Hesham Soliman" wrote: >>=20 >>>=20 >>>>=20 >>>> Well, I see quite potential for PMIPv6 over WLAN, why do you think the= re >>>> would not be any serious WLAN deployment with PMIPv6? >>>=20 >>> =3D> Because of the nature of the links, a router doesn't always know who= 's >>> attached. As you said earlier you make the MN send an RS, which is not >>> required in IPv6. Also the address allocation is a mess and sharing the= link >>> with MIPv6 nodes is very problematic. I'm not the right person to say w= hy >>> PMIPv6 was created in the first place but I only see it used, if ever, = on >>> p2p links whose use is strictly defined in SDOs. It was never intended,= even >>> by its proponents, to do flow mobility or global mobility and it can't = do >>> either one.=20 >>> The irony is that people wanted something that doesn't involve MN signa= lling >>> and now we'll expect signalling anyway, just not on L3. It's mind boggl= ing. >>>=20 >>>>=20 >>>>> shared links. >>>>>=20 >>>>>>> =3D> Do you have a user profile transfer mechanism in your lab? If yo= u do >>>>>>> please share some high level info. >>>>>>=20 >>>>>> In our lab the testbed is small, so we just have a config file with = the >>>>>> profile. >>>>>=20 >>>>> =3D> So as both myself and Julien already said, you must be assuming a = 1:1 >>>>> mapping between the MN and the user. Either that or your profile is a >>>>> device >>>>> profile not a user profile. The former is wrong in the real world and= the >>>>> latter is not used in the real world. >>>>=20 >>>> I was referring to a device profile and I don't see why this cannot be >>>> used in the real world. My operator here in Spain knows which device I >>>> use (even I have a flat rate that can just be used with my type of >>>> device). >>>=20 >>> =3D> Really? And do you call your operator if you remove your SIM card a= nd >>> put it in another device?. Does you operator also know when you run new= SW >>> on your phone/laptop? This is not a serious approach, I'm sorry but it'= s >>> completely unreliable for any serious deployment >>>=20 >>> Hesham >>>=20 >>>>=20 >>>> Carlos >>>>=20 >>>>>=20 >>>>> Thanks, >>>>> Hesham >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Carlos >>>>>>=20 >>>>>>>=20 >>>>>>> Hesham >>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>=20 From cjbc@it.uc3m.es Tue Mar 1 11: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 9D1FB3A6A76 for ; Tue, 1 Mar 2011 11:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_32=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 RLuEuhg3C5an for ; Tue, 1 Mar 2011 11:36:19 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id C02293A6A61 for ; Tue, 1 Mar 2011 11:36:18 -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 649E597C0A9; Tue, 1 Mar 2011 20:37:21 +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="=-RNTLNS3U/Jl/6lVI2wxI" Organization: Universidad Carlos III de Madrid Date: Tue, 01 Mar 2011 20:38:46 +0100 Message-ID: <1299008326.5170.52.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-17986.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: Tue, 01 Mar 2011 19:36:20 -0000 --=-RNTLNS3U/Jl/6lVI2wxI Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Sri, On Tue, 2011-03-01 at 11:35 -0800, Sri Gundavelli wrote: > Hi Carlos: >=20 >=20 >=20 >=20 > On 3/1/11 11:06 AM, "Carlos Jes=FAs Bernardos Cano" wro= te: >=20 > > Hi Sri, > >=20 > > On Tue, 2011-03-01 at 10:20 -0800, Sri Gundavelli wrote: > >> Carlos: > >>=20 > >> I've not been following this thread, pardon me for the ignorance on th= e > >> context of the thread. Clarifying question (specific to this one comme= nt). > >>=20 > >>=20 > >>> As you said earlier you make the MN send an RS, which is not required= in > >>> IPv6. > >>=20 > >> A mobile node, or a simple IPv6 node, on a new link does not an RS ? H= ow > >> does it detect the IPv6 routers, if suppress-periodic RA is enabled ? > >>=20 > >=20 > > The point is that, in my experience, if you attach a node to a WLAN > > (i.e. connect to an AP), when you first bring up the interface an RS is > > sent. But if later on the device changes AP, my experience with Linux i= s > > that no more RS are generated (unless you bring down/up the interface). > >=20 >=20 > All the stacks I've tested, any time there is a link flap, reassociation > with a new 802.11 AP, the client will send an RS. This is true for IPv4 a= s > well, the activation of DNAv4 procedures, ARP'ng for the DR MAC address. > IMO, the node does send an RS message. Then you haven't tested Linux ;). With Linux (at least the flavours I've tested) there is no such RS upon AP reassociation. Carlos >=20 >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 >=20 > > Thanks, > >=20 > > Carlos > >=20 > >>=20 > >> Sri > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >> On 3/1/11 4:18 AM, "Hesham Soliman" wrote: > >>=20 > >>>=20 > >>>>=20 > >>>> Well, I see quite potential for PMIPv6 over WLAN, why do you think t= here > >>>> would not be any serious WLAN deployment with PMIPv6? > >>>=20 > >>> =3D> Because of the nature of the links, a router doesn't always know= who's > >>> attached. As you said earlier you make the MN send an RS, which is no= t > >>> required in IPv6. Also the address allocation is a mess and sharing t= he link > >>> with MIPv6 nodes is very problematic. I'm not the right person to say= why > >>> PMIPv6 was created in the first place but I only see it used, if ever= , on > >>> p2p links whose use is strictly defined in SDOs. It was never intende= d, even > >>> by its proponents, to do flow mobility or global mobility and it can'= t do > >>> either one.=20 > >>> The irony is that people wanted something that doesn't involve MN sig= nalling > >>> and now we'll expect signalling anyway, just not on L3. It's mind bog= gling. > >>>=20 > >>>>=20 > >>>>> shared links. > >>>>>=20 > >>>>>>> =3D> Do you have a user profile transfer mechanism in your lab? I= f you do > >>>>>>> please share some high level info. > >>>>>>=20 > >>>>>> In our lab the testbed is small, so we just have a config file wit= h the > >>>>>> profile. > >>>>>=20 > >>>>> =3D> So as both myself and Julien already said, you must be assumin= g a 1:1 > >>>>> mapping between the MN and the user. Either that or your profile is= a > >>>>> device > >>>>> profile not a user profile. The former is wrong in the real world a= nd the > >>>>> latter is not used in the real world. > >>>>=20 > >>>> I was referring to a device profile and I don't see why this cannot = be > >>>> used in the real world. My operator here in Spain knows which device= I > >>>> use (even I have a flat rate that can just be used with my type of > >>>> device). > >>>=20 > >>> =3D> Really? And do you call your operator if you remove your SIM ca= rd and > >>> put it in another device?. Does you operator also know when you run n= ew SW > >>> on your phone/laptop? This is not a serious approach, I'm sorry but i= t's > >>> completely unreliable for any serious deployment > >>>=20 > >>> Hesham > >>>=20 > >>>>=20 > >>>> Carlos > >>>>=20 > >>>>>=20 > >>>>> Thanks, > >>>>> Hesham > >>>>>=20 > >>>>>=20 > >>>>>>=20 > >>>>>> Carlos > >>>>>>=20 > >>>>>>>=20 > >>>>>>> Hesham > >>>>>>>=20 > >>>>>>>=20 > >>>>>=20 > >>>>>=20 > >>>=20 > >>>=20 > >>> _______________________________________________ > >>> netext mailing list > >>> netext@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netext > >>=20 >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-RNTLNS3U/Jl/6lVI2wxI 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) iEYEABECAAYFAk1tS0YACgkQNdy6TdFwT2cqJgCg3JKdFFbbHsyWwelVc/4dYVE+ 2zUAnRzr3LkIaCNV9QoQZxLyhE1R0s04 =jnvO -----END PGP SIGNATURE----- --=-RNTLNS3U/Jl/6lVI2wxI-- From sgundave@cisco.com Tue Mar 1 11:44: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 B8FD83A6A82 for ; Tue, 1 Mar 2011 11:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.138 X-Spam-Level: X-Spam-Status: No, score=-9.138 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, 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 BAW-sYRrvsCP for ; Tue, 1 Mar 2011 11:44:17 -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 72C853A6A79 for ; Tue, 1 Mar 2011 11:44:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=1858; q=dns/txt; s=iport; t=1299008721; x=1300218321; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=cTem5Fspy6Rfj5oMZ3MDuO44CKE5hDZxsyVd1io5vyQ=; b=BpuUW6qRxGf5ceB8UJ13s5hm0dVZzDAnJpRujcThhQBJKsHL8hi2Afz+ Yzq8BiI8RmUoJ3/GAXEt+napBT1KRPytKs0NorcI3ApXp3rmUXvcryrKI dkG2pVV+QxDATptxbrqEEruP84p8EJRXuPRO3id3eDrgM5aLhOEkNb5Hc o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AokGAMfbbE2rR7H+/2dsb2JhbACYOI06XHSgaZwXhWEEhRKHDYNG X-IronPort-AV: E=Sophos;i="4.62,248,1297036800"; d="scan'208";a="272363947" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 01 Mar 2011 19:45:21 +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 p21JjL4p005378; Tue, 1 Mar 2011 19:45:21 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 Mar 2011 11:45:15 -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 ; Tue, 1 Mar 2011 19:45:15 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 01 Mar 2011 11:46:32 -0800 From: Sri Gundavelli To: Message-ID: Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvYSV1Rj9ja1W9hYUOkaefV39LxXg== In-Reply-To: <1299008326.5170.52.camel@acorde.it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 01 Mar 2011 19:45:15.0592 (UTC) FILETIME=[2FC62C80:01CBD849] 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 19:44:20 -0000 Hi Carlos: On 3/1/11 11:38 AM, "Carlos Jes=FAs Bernardos Cano" wrote: > Hi Sri, >=20 > On Tue, 2011-03-01 at 11:35 -0800, Sri Gundavelli wrote: >> Hi Carlos: >>=20 >>=20 >>=20 >>=20 >> On 3/1/11 11:06 AM, "Carlos Jes=FAs Bernardos Cano" wrot= e: >>=20 >>> Hi Sri, >>>=20 >>> On Tue, 2011-03-01 at 10:20 -0800, Sri Gundavelli wrote: >>>> Carlos: >>>>=20 >>>> I've not been following this thread, pardon me for the ignorance on th= e >>>> context of the thread. Clarifying question (specific to this one comme= nt). >>>>=20 >>>>=20 >>>>> As you said earlier you make the MN send an RS, which is not required= in >>>>> IPv6. >>>>=20 >>>> A mobile node, or a simple IPv6 node, on a new link does not an RS ? H= ow >>>> does it detect the IPv6 routers, if suppress-periodic RA is enabled ? >>>>=20 >>>=20 >>> The point is that, in my experience, if you attach a node to a WLAN >>> (i.e. connect to an AP), when you first bring up the interface an RS is >>> sent. But if later on the device changes AP, my experience with Linux i= s >>> that no more RS are generated (unless you bring down/up the interface). >>>=20 >>=20 >> All the stacks I've tested, any time there is a link flap, reassociation >> with a new 802.11 AP, the client will send an RS. This is true for IPv4 = as >> well, the activation of DNAv4 procedures, ARP'ng for the DR MAC address. >> IMO, the node does send an RS message. >=20 > Then you haven't tested Linux ;). With Linux (at least the flavours I've > tested) there is no such RS upon AP reassociation. >=20 Ok. I assume, on "that" Linux stack, your mobile IP client will not work. I= t will never send an RS and will never obtain a CCoA address. It will be happ= y with a stale binding using a CCoA address from the prev link. Sri From Basavaraj.Patil@nokia.com Tue Mar 1 11: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 65D8C3A6A79 for ; Tue, 1 Mar 2011 11:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.395 X-Spam-Level: X-Spam-Status: No, score=-102.395 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, 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 Pj+Dkabq72Ff for ; Tue, 1 Mar 2011 11:51:44 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id A6EB73A6A8D for ; Tue, 1 Mar 2011 11:51:43 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p21JqaDU025059; Tue, 1 Mar 2011 21:52:43 +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); Tue, 1 Mar 2011 21:52:30 +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; Tue, 1 Mar 2011 20:52:30 +0100 Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.127]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0270.002; Tue, 1 Mar 2011 20:52:29 +0100 From: To: , Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvTH7hRFKVN0Kr67UiTaBIlg8gywgAejl2AAAHvnYAAAaltAAAAevCAAA8x8gAAE1N8AAADW1qAAANRXoAAAMIDgAADjsKAAAfFm4AAHfplgAABZ90AAAgHUYAAAEM0AACbGJiAAAdu4YAAEPkHAAAFGCYAAABJUQAAAC5+AAAMpgUAAAGZ74AAAQgyAAACoPMw Date: Tue, 1 Mar 2011 19:52:29 +0000 Message-ID: <97683F8C138FB243AAC90CEFB48ABF15092670F3@008-AM1MPN1-004.mgdnok.nokia.com> References: <1299006371.5170.28.camel@acorde.it.uc3m.es> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.59.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Mar 2011 19:52:30.0942 (UTC) FILETIME=[33434FE0:01CBD84A] X-Nokia-AV: Clean Cc: netext@ietf.org, JuanCarlos.Zuniga@interdigital.com 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 19:51:45 -0000 FWIW, I would remind you that we have agreed (during chartering) to not do = any L3 signaling between MN-MAG. Hence use of RS/RA is not an option here and hence do not need to spend tim= e on that. -Raj -----Original Message----- From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of= ext Sri Gundavelli Sent: Tuesday, March 01, 2011 1:36 PM To: cjbc@it.uc3m.es Cc: netext@ietf.org; Zuniga, Juan Carlos Subject: Re: [netext] Flow Mobility discussion - way forward? Hi Carlos: On 3/1/11 11:06 AM, "Carlos Jes=FAs Bernardos Cano" wrote= : > Hi Sri, >=20 > On Tue, 2011-03-01 at 10:20 -0800, Sri Gundavelli wrote: >> Carlos: >>=20 >> I've not been following this thread, pardon me for the ignorance on the >> context of the thread. Clarifying question (specific to this one comment= ). >>=20 >>=20 >>> As you said earlier you make the MN send an RS, which is not required i= n >>> IPv6. >>=20 >> A mobile node, or a simple IPv6 node, on a new link does not an RS ? How >> does it detect the IPv6 routers, if suppress-periodic RA is enabled ? >>=20 >=20 > The point is that, in my experience, if you attach a node to a WLAN > (i.e. connect to an AP), when you first bring up the interface an RS is > sent. But if later on the device changes AP, my experience with Linux is > that no more RS are generated (unless you bring down/up the interface). >=20 All the stacks I've tested, any time there is a link flap, reassociation with a new 802.11 AP, the client will send an RS. This is true for IPv4 as well, the activation of DNAv4 procedures, ARP'ng for the DR MAC address. IMO, the node does send an RS message. Regards Sri > Thanks, >=20 > Carlos >=20 >>=20 >> Sri >>=20 >>=20 >>=20 >>=20 >>=20 >> On 3/1/11 4:18 AM, "Hesham Soliman" wrote: >>=20 >>>=20 >>>>=20 >>>> Well, I see quite potential for PMIPv6 over WLAN, why do you think the= re >>>> would not be any serious WLAN deployment with PMIPv6? >>>=20 >>> =3D> Because of the nature of the links, a router doesn't always know w= ho's >>> attached. As you said earlier you make the MN send an RS, which is not >>> required in IPv6. Also the address allocation is a mess and sharing the= link >>> with MIPv6 nodes is very problematic. I'm not the right person to say w= hy >>> PMIPv6 was created in the first place but I only see it used, if ever, = on >>> p2p links whose use is strictly defined in SDOs. It was never intended,= even >>> by its proponents, to do flow mobility or global mobility and it can't = do >>> either one.=20 >>> The irony is that people wanted something that doesn't involve MN signa= lling >>> and now we'll expect signalling anyway, just not on L3. It's mind boggl= ing. >>>=20 >>>>=20 >>>>> shared links. >>>>>=20 >>>>>>> =3D> Do you have a user profile transfer mechanism in your lab? If = you do >>>>>>> please share some high level info. >>>>>>=20 >>>>>> In our lab the testbed is small, so we just have a config file with = the >>>>>> profile. >>>>>=20 >>>>> =3D> So as both myself and Julien already said, you must be assuming = a 1:1 >>>>> mapping between the MN and the user. Either that or your profile is a >>>>> device >>>>> profile not a user profile. The former is wrong in the real world and= the >>>>> latter is not used in the real world. >>>>=20 >>>> I was referring to a device profile and I don't see why this cannot be >>>> used in the real world. My operator here in Spain knows which device I >>>> use (even I have a flat rate that can just be used with my type of >>>> device). >>>=20 >>> =3D> Really? And do you call your operator if you remove your SIM card= and >>> put it in another device?. Does you operator also know when you run new= SW >>> on your phone/laptop? This is not a serious approach, I'm sorry but it'= s >>> completely unreliable for any serious deployment >>>=20 >>> Hesham >>>=20 >>>>=20 >>>> Carlos >>>>=20 >>>>>=20 >>>>> Thanks, >>>>> Hesham >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Carlos >>>>>>=20 >>>>>>>=20 >>>>>>> Hesham >>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>=20 >>>=20 >>>=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 From sgundave@cisco.com Tue Mar 1 11: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 C5D963A6A2D for ; Tue, 1 Mar 2011 11:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.084 X-Spam-Level: X-Spam-Status: No, score=-9.084 tagged_above=-999 required=5 tests=[AWL=-0.481, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, 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 I1L0vsAfxaea for ; Tue, 1 Mar 2011 11:58:32 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 40F713A6A95 for ; Tue, 1 Mar 2011 11:58:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=5104; q=dns/txt; s=iport; t=1299009559; x=1300219159; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=DHcqQaNO6wB5H0dM14Fl8q8lKAK5Qrak67e1SklYKdg=; b=dlygyUj/frixpZoOi1+cHBizQGDcGk5m6vJiBGUjPeKANmmcJNBTmyRl fhblQ0wVVXWHnnDDYzY/qyHPnDqPIEf9lbkd1kJdqBIlXuAOWHF2eWMNf fzA2eka3bjGjZr8cmduh7m9uinA0eLKNQIPrH0bcHsxI7PflIoxoaTx6V 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcAANPebE2rR7Ht/2dsb2JhbACXeo15XHShCJwUgy0BgjMEhRKHDYNG X-IronPort-AV: E=Sophos;i="4.62,248,1297036800"; d="scan'208";a="316295304" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 01 Mar 2011 19:59:19 +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 p21JxJmP028585; Tue, 1 Mar 2011 19:59:19 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 Mar 2011 11:59:18 -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 ; Tue, 1 Mar 2011 19:59:18 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 01 Mar 2011 12:00:37 -0800 From: Sri Gundavelli To: , Message-ID: Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvTH7hRFKVN0Kr67UiTaBIlg8gywgAejl2AAAHvnYAAAaltAAAAevCAAA8x8gAAE1N8AAADW1qAAANRXoAAAMIDgAADjsKAAAfFm4AAHfplgAABZ90AAAgHUYAAAEM0AACbGJiAAAdu4YAAEPkHAAAFGCYAAABJUQAAAC5+AAAMpgUAAAGZ74AAAQgyAAACoPMwAABV+IM= In-Reply-To: <97683F8C138FB243AAC90CEFB48ABF15092670F3@008-AM1MPN1-004.mgdnok.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 01 Mar 2011 19:59:18.0737 (UTC) FILETIME=[2653E410:01CBD84B] Cc: netext@ietf.org, JuanCarlos.Zuniga@interdigital.com 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 19:58:33 -0000 This is unrelated to the L3 interface between MAG-MN question, or about LMA-MAG signaling. The basic node behavior, if this comment were to be true= , many apps and the basic host IP stack is broken. Sri On 3/1/11 11:52 AM, "Basavaraj.Patil@nokia.com" wrote: >=20 > FWIW, I would remind you that we have agreed (during chartering) to not d= o any > L3 signaling between MN-MAG. > Hence use of RS/RA is not an option here and hence do not need to spend t= ime > on that. >=20 > -Raj >=20 > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of > ext Sri Gundavelli > Sent: Tuesday, March 01, 2011 1:36 PM > To: cjbc@it.uc3m.es > Cc: netext@ietf.org; Zuniga, Juan Carlos > Subject: Re: [netext] Flow Mobility discussion - way forward? >=20 > Hi Carlos: >=20 >=20 >=20 >=20 > On 3/1/11 11:06 AM, "Carlos Jes=FAs Bernardos Cano" wrote= : >=20 >> Hi Sri, >>=20 >> On Tue, 2011-03-01 at 10:20 -0800, Sri Gundavelli wrote: >>> Carlos: >>>=20 >>> I've not been following this thread, pardon me for the ignorance on the >>> context of the thread. Clarifying question (specific to this one commen= t). >>>=20 >>>=20 >>>> As you said earlier you make the MN send an RS, which is not required = in >>>> IPv6. >>>=20 >>> A mobile node, or a simple IPv6 node, on a new link does not an RS ? Ho= w >>> does it detect the IPv6 routers, if suppress-periodic RA is enabled ? >>>=20 >>=20 >> The point is that, in my experience, if you attach a node to a WLAN >> (i.e. connect to an AP), when you first bring up the interface an RS is >> sent. But if later on the device changes AP, my experience with Linux is >> that no more RS are generated (unless you bring down/up the interface). >>=20 >=20 > All the stacks I've tested, any time there is a link flap, reassociation > with a new 802.11 AP, the client will send an RS. This is true for IPv4 a= s > well, the activation of DNAv4 procedures, ARP'ng for the DR MAC address. > IMO, the node does send an RS message. >=20 >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 >=20 >> Thanks, >>=20 >> Carlos >>=20 >>>=20 >>> Sri >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On 3/1/11 4:18 AM, "Hesham Soliman" wrote: >>>=20 >>>>=20 >>>>>=20 >>>>> Well, I see quite potential for PMIPv6 over WLAN, why do you think th= ere >>>>> would not be any serious WLAN deployment with PMIPv6? >>>>=20 >>>> =3D> Because of the nature of the links, a router doesn't always know wh= o's >>>> attached. As you said earlier you make the MN send an RS, which is not >>>> required in IPv6. Also the address allocation is a mess and sharing th= e >>>> link >>>> with MIPv6 nodes is very problematic. I'm not the right person to say = why >>>> PMIPv6 was created in the first place but I only see it used, if ever,= on >>>> p2p links whose use is strictly defined in SDOs. It was never intended= , >>>> even >>>> by its proponents, to do flow mobility or global mobility and it can't= do >>>> either one.=20 >>>> The irony is that people wanted something that doesn't involve MN >>>> signalling >>>> and now we'll expect signalling anyway, just not on L3. It's mind bogg= ling. >>>>=20 >>>>>=20 >>>>>> shared links. >>>>>>=20 >>>>>>>> =3D> Do you have a user profile transfer mechanism in your lab? If y= ou do >>>>>>>> please share some high level info. >>>>>>>=20 >>>>>>> In our lab the testbed is small, so we just have a config file with= the >>>>>>> profile. >>>>>>=20 >>>>>> =3D> So as both myself and Julien already said, you must be assuming a= 1:1 >>>>>> mapping between the MN and the user. Either that or your profile is = a >>>>>> device >>>>>> profile not a user profile. The former is wrong in the real world an= d the >>>>>> latter is not used in the real world. >>>>>=20 >>>>> I was referring to a device profile and I don't see why this cannot b= e >>>>> used in the real world. My operator here in Spain knows which device = I >>>>> use (even I have a flat rate that can just be used with my type of >>>>> device). >>>>=20 >>>> =3D> Really? And do you call your operator if you remove your SIM card = and >>>> put it in another device?. Does you operator also know when you run ne= w SW >>>> on your phone/laptop? This is not a serious approach, I'm sorry but it= 's >>>> completely unreliable for any serious deployment >>>>=20 >>>> Hesham >>>>=20 >>>>>=20 >>>>> Carlos >>>>>=20 >>>>>>=20 >>>>>> Thanks, >>>>>> Hesham >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Carlos >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Hesham >>>>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>=20 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From alexandru.petrescu@gmail.com Tue Mar 1 12:25: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 367B03A6A24 for ; Tue, 1 Mar 2011 12:25:16 -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_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 xlsiYRwFQXeN for ; Tue, 1 Mar 2011 12:25:15 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id AD1BD3A68A4 for ; Tue, 1 Mar 2011 12:25:13 -0800 (PST) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 5AAFE940369 for ; Tue, 1 Mar 2011 21:26:11 +0100 (CET) Message-ID: <4D6D5660.1040604@gmail.com> Date: Tue, 01 Mar 2011 21:26:08 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: netext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 110301-0, 01/03/2011), Outbound message X-Antivirus-Status: Clean Subject: Re: [netext] PMIPv6 and WiFi (was: 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 20:25:16 -0000 Hello Sri, netext, Sri - I take advantage of your email to reply, but I also Cc the group. Please excuse my ignorance of netext developments, and generally on the PMIPv6 text. But, even accepting that MH does send an RS upon attachment to a new attachment to a new WiFi AP. I would like to tell about difficult issues when trying to implement PMIPv6 on WiFi (not me, but related). o even though an MN does send an RS: does it contain an MN-ID? For PMIPv6 to work it should contain an MN-ID otherwise MAG can't know to whom to allocate a prefix. What is the RFC/draft telling how to encode an MN-ID into an RS and eventually RA? I am not aware. Do you really _mean_ MN-ID (like a NAI) or do you silently assume that MN-ID could be the MAC address of MH? o how do you make work ptp links on WiFi? Name of open source software please thank you. o what does one use in implementation to make this "prefix-per-MH" concept work; how does one do "point-to-point" links on WiFi in practice? Is it L2TP? Is it another? Which document? Don't say it is out of scope - it is fully in scope if one wants to do PMIPv6 with WiFi - without this PMIPv6/WiFi can't work. o how does one do several prefixes on a single WiFi link? What draft/RFC tells how to do it? Typically a WiFi link has a single prefix, or maybe a few; how does one make sure that each different prefix (HNP) sent on a single WiFi link is never advertised to everyone else, but only to a single MH? (make sure dst address is unicast, not multicast). o is there an radvd implementation doing this per-MN prefix advertisement? o radvd on linux is driven by a config file, and there is difficulty in updating that file dynamically and re-start radvd daemon. Anybody did that already? Where? radvd software is GPL - so any modifications to do this behaviour should be available - whom should I ask? o are implementers of PMIPv6/WiFi use something else than radvd to send RAs from MAG? What software please? o when supposedly the MAG does advertise a number of independent "per-MH" HNPs, does is still advertise a non-HNP prefix valid for every other MH which does not assume PMIPv6 is working (a "natural" prefix if I can say so)? What does this prefix look like? o does a MAG receiving 2 MHs coming from 2 different other MAG's assign 2 link local addresses on its WiFi interface (the next-hop for default route)? These are doubts only about MAG-MH interface. But there are a number of doubts about how the LMA assigns the prefix to MHas well. I assume this is not performed with DHCP - then how is it performed? The PMIPv6 specification is silent about this (lifetimes? confirmations?). It is very little tempting to start writing a new implementation of prefix allocation, especially when knowing DHCPv6 implementations include prefix allocation, all readily available. My current state of thinking is that PMIPv6 is written for 3GPP and has not been experimented on WiFi beyond proof of concept. I mean - all my respect to statements of implementations of PMIPv6 on WiFi, but, however, when compared to MIPv6 implementations, these are much less working on WiFi. For example, MIPv6 implementation work with out-of-the-box radvd, and out-of-the-box dhcp3. But PMIPv6 implementations on WiFi can only work according to non-specified and behaviour which is claimed out of scope in PMIPv6 specs. Finally, I may be not updated with draft/RFC developments of PMIPv6, excuses. Alex Le 01/03/2011 19:20, Sri Gundavelli a écrit : > Carlos: > > I've not been following this thread, pardon me for the ignorance on > the context of the thread. Clarifying question (specific to this one > comment). > > >> As you said earlier you make the MN send an RS, which is not >> required in IPv6. > > A mobile node, or a simple IPv6 node, on a new link does not an RS ? > How does it detect the IPv6 routers, if suppress-periodic RA is > enabled ? > > > Sri > > > > > > On 3/1/11 4:18 AM, "Hesham Soliman" wrote: > >> >>> >>> Well, I see quite potential for PMIPv6 over WLAN, why do you >>> think there would not be any serious WLAN deployment with >>> PMIPv6? >> >> => Because of the nature of the links, a router doesn't always >> know who's attached. As you said earlier you make the MN send an >> RS, which is not required in IPv6. Also the address allocation is a >> mess and sharing the link with MIPv6 nodes is very problematic. I'm >> not the right person to say why PMIPv6 was created in the first >> place but I only see it used, if ever, on p2p links whose use is >> strictly defined in SDOs. It was never intended, even by its >> proponents, to do flow mobility or global mobility and it can't do >> either one. The irony is that people wanted something that doesn't >> involve MN signalling and now we'll expect signalling anyway, just >> not on L3. It's mind boggling. >> >>> >>>> shared links. >>>> >>>>>> => Do you have a user profile transfer mechanism in your >>>>>> lab? If you do please share some high level info. >>>>> >>>>> In our lab the testbed is small, so we just have a config >>>>> file with the profile. >>>> >>>> => So as both myself and Julien already said, you must be >>>> assuming a 1:1 mapping between the MN and the user. Either that >>>> or your profile is a device profile not a user profile. The >>>> former is wrong in the real world and the latter is not used in >>>> the real world. >>> >>> I was referring to a device profile and I don't see why this >>> cannot be used in the real world. My operator here in Spain knows >>> which device I use (even I have a flat rate that can just be used >>> with my type of device). >> >> => Really? And do you call your operator if you remove your SIM >> card and put it in another device?. Does you operator also know >> when you run new SW on your phone/laptop? This is not a serious >> approach, I'm sorry but it's completely unreliable for any serious >> deployment >> >> Hesham >> >>> >>> Carlos >>> >>>> >>>> Thanks, Hesham >>>> >>>> >>>>> >>>>> Carlos >>>>> >>>>>> >>>>>> Hesham >>>>>> >>>>>> >>>> >>>> >> >> >> _______________________________________________ netext mailing >> list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext > > _______________________________________________ netext mailing list > netext@ietf.org https://www.ietf.org/mailman/listinfo/netext > From sgundave@cisco.com Tue Mar 1 12: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 85AA53A69CC for ; Tue, 1 Mar 2011 12:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[AWL=0.560, 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 t0xQanHpGW7I for ; Tue, 1 Mar 2011 12:46:13 -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 10DC33A6AAB for ; Tue, 1 Mar 2011 12:46:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=9164; q=dns/txt; s=iport; t=1299012437; x=1300222037; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=oI5gZoF50zY+gEyIsAnm6vTl303UVwkpX6onzDNFQuU=; b=GIK60L2lbIe7zEgErA6hRn8MmRhv5hKDpQoaVvtdqrKJHoj5K1R6gOPK FUYpsuLf+Gqg4qFzrGyL/n1iKLik/3dung8c1xHuwcbgYFsdFzRWLlmS7 x7SgVHH3smbf3q+Bd2CiM9BE5WQpH32SAZnb5MPy0w3OWwD7tySe7obHC A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABPqbE2rR7Ht/2dsb2JhbACmUHShVZwJgn+CYgSFEocNg0aDDg X-IronPort-AV: E=Sophos;i="4.62,248,1297036800"; d="scan'208";a="337267859" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 01 Mar 2011 20:47:16 +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 p21KlGoD012206; Tue, 1 Mar 2011 20:47:16 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 Mar 2011 12:47:16 -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 ; Tue, 1 Mar 2011 20:47:16 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 01 Mar 2011 12:48:35 -0800 From: Sri Gundavelli To: Alexandru Petrescu , Message-ID: Thread-Topic: [netext] PMIPv6 and WiFi (was: Flow Mobility discussion - way forward?) Thread-Index: AcvYUghl5YEU8ZrGl0e5oo9k9pObSQ== In-Reply-To: <4D6D5660.1040604@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 01 Mar 2011 20:47:16.0599 (UTC) FILETIME=[D9AAC870:01CBD851] Subject: Re: [netext] PMIPv6 and WiFi (was: 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 20:46:14 -0000 Hi Alex, Thanks for your note and for your agreement on the host having to send RS after reattach. Few points without going into details as we have related products in this space.=20 - There is access authentication on 802.11 link, where there is a mapping between a link-layer address and a mobile identity. - MN-ID need not be a MAC address - There is the ability to segregate shared links as p2p links, there are semantics - There are semantics to sends unicast RA's. There is this RFC-6085. =20 - RADVD is a specific implementation, I'm not sure I can comment in that tool context. But, we can stay with the standard IP host behavior for this discussion, as that is what we need, except for inter-tech handovers where we need logical interface construct - How the LMA allocates prefixes for a mobility session is out of scope. It can very well use local pools, depend on AAA, or use DHCP PD. Some folks have attempted to specific this LMA-DHCP interface. It should be good to have such details specified - The comment on link-local address is valid and as we have seen early proposals to avoid that remote conflicts - MAG can certainly advertise local prefixes which have no mobility. But, w= e will be hit with the issue of lack of SAS ability. So, lets assume the MAG advertises the prefixes on a per-MN basis, just that prefixes it gets from the LMA for that session. - The implementors of PMIPv6 I know, use Cisco IOS, Linux and number of platforms that we have obviously. - We have tried PMIPv6 beyond 3GPP and we have understanding how this works= . There are other folks like Juan Carlos, Carlos, Telemaco, who have even implementations of some of advanced features working. I will surely try to provide you some working images on some platforms that you can play with. I will try to get you that. Sri On 3/1/11 12:26 PM, "Alexandru Petrescu" wrote: > Hello Sri, netext, >=20 > Sri - I take advantage of your email to reply, but I also Cc the group. >=20 > Please excuse my ignorance of netext developments, and generally on the > PMIPv6 text. >=20 > But, even accepting that MH does send an RS upon attachment to a new > attachment to a new WiFi AP. >=20 > I would like to tell about difficult issues when trying to implement > PMIPv6 on WiFi (not me, but related). >=20 > o even though an MN does send an RS: does it contain an MN-ID? For > PMIPv6 to work it should contain an MN-ID otherwise MAG can't know to > whom to allocate a prefix. What is the RFC/draft telling how to > encode an MN-ID into an RS and eventually RA? I am not aware. >=20 > Do you really _mean_ MN-ID (like a NAI) or do you silently assume > that MN-ID could be the MAC address of MH? >=20 > o how do you make work ptp links on WiFi? Name of open source software > please thank you. >=20 > o what does one use in implementation to make this "prefix-per-MH" > concept work; how does one do "point-to-point" links on WiFi in > practice? Is it L2TP? Is it another? Which document? Don't say it > is out of scope - it is fully in scope if one wants to do PMIPv6 > with WiFi - without this PMIPv6/WiFi can't work. >=20 > o how does one do several prefixes on a single WiFi link? What > draft/RFC tells how to do it? Typically a WiFi link has a single > prefix, or maybe a few; how does one make sure that each different > prefix (HNP) sent on a single WiFi link is never advertised to > everyone else, but only to a single MH? (make sure dst address is > unicast, not multicast). >=20 > o is there an radvd implementation doing this per-MN prefix > advertisement? >=20 > o radvd on linux is driven by a config file, and there is difficulty in > updating that file dynamically and re-start radvd daemon. Anybody > did that already? Where? radvd software is GPL - so any > modifications to do this behaviour should be available - whom should > I ask? >=20 > o are implementers of PMIPv6/WiFi use something else than radvd to send > RAs from MAG? What software please? >=20 > o when supposedly the MAG does advertise a number of independent > "per-MH" HNPs, does is still advertise a non-HNP prefix valid for > every other MH which does not assume PMIPv6 is working (a "natural" > prefix if I can say so)? What does this prefix look like? >=20 > o does a MAG receiving 2 MHs coming from 2 different other MAG's assign > 2 link local addresses on its WiFi interface (the next-hop for > default route)? >=20 > These are doubts only about MAG-MH interface. But there are a number of > doubts about how the LMA assigns the prefix to MHas well. I assume this > is not performed with DHCP - then how is it performed? The PMIPv6 > specification is silent about this (lifetimes? confirmations?). It is > very little tempting to start writing a new implementation of prefix > allocation, especially when knowing DHCPv6 implementations include > prefix allocation, all readily available. >=20 > My current state of thinking is that PMIPv6 is written for 3GPP and has > not been experimented on WiFi beyond proof of concept. I mean - all my > respect to statements of implementations of PMIPv6 on WiFi, but, > however, when compared to MIPv6 implementations, these are much less > working on WiFi. For example, MIPv6 implementation work with > out-of-the-box radvd, and out-of-the-box dhcp3. But PMIPv6 > implementations on WiFi can only work according to non-specified and > behaviour which is claimed out of scope in PMIPv6 specs. >=20 > Finally, I may be not updated with draft/RFC developments of PMIPv6, > excuses. >=20 > Alex >=20 > Le 01/03/2011 19:20, Sri Gundavelli a =E9crit : >> Carlos: >>=20 >> I've not been following this thread, pardon me for the ignorance on >> the context of the thread. Clarifying question (specific to this one >> comment). >>=20 >>=20 >>> As you said earlier you make the MN send an RS, which is not >>> required in IPv6. >>=20 >> A mobile node, or a simple IPv6 node, on a new link does not an RS ? >> How does it detect the IPv6 routers, if suppress-periodic RA is >> enabled ? >>=20 >>=20 >> Sri >>=20 >>=20 >>=20 >>=20 >>=20 >> On 3/1/11 4:18 AM, "Hesham Soliman" wrote: >>=20 >>>=20 >>>>=20 >>>> Well, I see quite potential for PMIPv6 over WLAN, why do you >>>> think there would not be any serious WLAN deployment with >>>> PMIPv6? >>>=20 >>> =3D> Because of the nature of the links, a router doesn't always >>> know who's attached. As you said earlier you make the MN send an >>> RS, which is not required in IPv6. Also the address allocation is a >>> mess and sharing the link with MIPv6 nodes is very problematic. I'm >>> not the right person to say why PMIPv6 was created in the first >>> place but I only see it used, if ever, on p2p links whose use is >>> strictly defined in SDOs. It was never intended, even by its >>> proponents, to do flow mobility or global mobility and it can't do >>> either one. The irony is that people wanted something that doesn't >>> involve MN signalling and now we'll expect signalling anyway, just >>> not on L3. It's mind boggling. >>>=20 >>>>=20 >>>>> shared links. >>>>>=20 >>>>>>> =3D> Do you have a user profile transfer mechanism in your >>>>>>> lab? If you do please share some high level info. >>>>>>=20 >>>>>> In our lab the testbed is small, so we just have a config >>>>>> file with the profile. >>>>>=20 >>>>> =3D> So as both myself and Julien already said, you must be >>>>> assuming a 1:1 mapping between the MN and the user. Either that >>>>> or your profile is a device profile not a user profile. The >>>>> former is wrong in the real world and the latter is not used in >>>>> the real world. >>>>=20 >>>> I was referring to a device profile and I don't see why this >>>> cannot be used in the real world. My operator here in Spain knows >>>> which device I use (even I have a flat rate that can just be used >>>> with my type of device). >>>=20 >>> =3D> Really? And do you call your operator if you remove your SIM >>> card and put it in another device?. Does you operator also know >>> when you run new SW on your phone/laptop? This is not a serious >>> approach, I'm sorry but it's completely unreliable for any serious >>> deployment >>>=20 >>> Hesham >>>=20 >>>>=20 >>>> Carlos >>>>=20 >>>>>=20 >>>>> Thanks, Hesham >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Carlos >>>>>>=20 >>>>>>>=20 >>>>>>> Hesham >>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>=20 >>>=20 >>>=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 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From alexandru.petrescu@gmail.com Tue Mar 1 12:49: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 40F983A69CC for ; Tue, 1 Mar 2011 12:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_32=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 vtGlymARBEWR for ; Tue, 1 Mar 2011 12:49:42 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id D7FCA3A6AA8 for ; Tue, 1 Mar 2011 12:49:40 -0800 (PST) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 2F09F94019A; Tue, 1 Mar 2011 21:50:37 +0100 (CET) Message-ID: <4D6D5C1A.3040108@gmail.com> Date: Tue, 01 Mar 2011 21:50:34 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: <1299006371.5170.28.camel@acorde.it.uc3m.es> <97683F8C138FB243AAC90CEFB48ABF15092670F3@008-AM1MPN1-004.mgdnok.nokia.com> In-Reply-To: <97683F8C138FB243AAC90CEFB48ABF15092670F3@008-AM1MPN1-004.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 110301-0, 01/03/2011), Outbound message X-Antivirus-Status: Clean Cc: netext@ietf.org, JuanCarlos.Zuniga@interdigital.com 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 20:49:43 -0000 Hi Raj, Please allow to give an oppinion on this. I agree we should leave the Host unmodified. But in more detail: what do you mean we should not spend time on signalling MH-MAG? (you say MN, and I suppose MH, because MR-MAG doesn't work with PMIPv6, and MN can be an MR; also this MH is not assumed Mobile IPv6, so it could as well be an H actually - making it a 'H-MAG' interface). To me that signalling is of paramount importance for PMIPv6/WiFi to work. YEs, the MH should send the typical RS it sends, unmodified, and MAG should adapt to it. In this sense, only the MH is out of scope, but MAG is modified and its modifications are in scope. I do think we need to spend time telling (at least on the mailing list, or for an implementer clarification) how does the MH tell the MAG its MN-ID when that happens on WiFi (not on cellular). I take advantage of this remark to tell that this is true for a number of other aspects in the PMIPv6 RFC. A number of such aspects ('stateful', 'policy') are currently said to be out of scope in the PMIPv6 spec. This is strange! A spec would leave aspects as 'out-of-scope' when non-interoperable implementations of it are ok. I.e., it would be ok to have local proprietary implementations of 'policy server'. But when the inherent working of PMIPv6 is at stake then that can't be left out of scope. I may be not updated about PMIPv6 documents, excuses, but this MN-ID between MH and MAG question is very much in-scope IMHO. Yours, Alex Le 01/03/2011 20:52, Basavaraj.Patil@nokia.com a écrit : > > FWIW, I would remind you that we have agreed (during chartering) to > not do any L3 signaling between MN-MAG. Hence use of RS/RA is not an > option here and hence do not need to spend time on that. > > -Raj > > -----Original Message----- From: netext-bounces@ietf.org > [mailto:netext-bounces@ietf.org] On Behalf Of ext Sri Gundavelli > Sent: Tuesday, March 01, 2011 1:36 PM To: cjbc@it.uc3m.es Cc: > netext@ietf.org; Zuniga, Juan Carlos Subject: Re: [netext] Flow > Mobility discussion - way forward? > > Hi Carlos: > > > > > On 3/1/11 11:06 AM, "Carlos Jesús Bernardos Cano" > wrote: > >> Hi Sri, >> >> On Tue, 2011-03-01 at 10:20 -0800, Sri Gundavelli wrote: >>> Carlos: >>> >>> I've not been following this thread, pardon me for the ignorance >>> on the context of the thread. Clarifying question (specific to >>> this one comment). >>> >>> >>>> As you said earlier you make the MN send an RS, which is not >>>> required in IPv6. >>> >>> A mobile node, or a simple IPv6 node, on a new link does not an >>> RS ? How does it detect the IPv6 routers, if suppress-periodic RA >>> is enabled ? >>> >> >> The point is that, in my experience, if you attach a node to a >> WLAN (i.e. connect to an AP), when you first bring up the interface >> an RS is sent. But if later on the device changes AP, my experience >> with Linux is that no more RS are generated (unless you bring >> down/up the interface). >> > > All the stacks I've tested, any time there is a link flap, > reassociation with a new 802.11 AP, the client will send an RS. This > is true for IPv4 as well, the activation of DNAv4 procedures, ARP'ng > for the DR MAC address. IMO, the node does send an RS message. > > > > Regards Sri > > > > > >> Thanks, >> >> Carlos >> >>> >>> Sri >>> >>> >>> >>> >>> >>> On 3/1/11 4:18 AM, "Hesham Soliman" >>> wrote: >>> >>>> >>>>> >>>>> Well, I see quite potential for PMIPv6 over WLAN, why do you >>>>> think there would not be any serious WLAN deployment with >>>>> PMIPv6? >>>> >>>> => Because of the nature of the links, a router doesn't always >>>> know who's attached. As you said earlier you make the MN send >>>> an RS, which is not required in IPv6. Also the address >>>> allocation is a mess and sharing the link with MIPv6 nodes is >>>> very problematic. I'm not the right person to say why PMIPv6 >>>> was created in the first place but I only see it used, if ever, >>>> on p2p links whose use is strictly defined in SDOs. It was >>>> never intended, even by its proponents, to do flow mobility or >>>> global mobility and it can't do either one. The irony is that >>>> people wanted something that doesn't involve MN signalling and >>>> now we'll expect signalling anyway, just not on L3. It's mind >>>> boggling. >>>> >>>>> >>>>>> shared links. >>>>>> >>>>>>>> => Do you have a user profile transfer mechanism in >>>>>>>> your lab? If you do please share some high level info. >>>>>>> >>>>>>> In our lab the testbed is small, so we just have a config >>>>>>> file with the profile. >>>>>> >>>>>> => So as both myself and Julien already said, you must be >>>>>> assuming a 1:1 mapping between the MN and the user. Either >>>>>> that or your profile is a device profile not a user >>>>>> profile. The former is wrong in the real world and the >>>>>> latter is not used in the real world. >>>>> >>>>> I was referring to a device profile and I don't see why this >>>>> cannot be used in the real world. My operator here in Spain >>>>> knows which device I use (even I have a flat rate that can >>>>> just be used with my type of device). >>>> >>>> => Really? And do you call your operator if you remove your >>>> SIM card and put it in another device?. Does you operator also >>>> know when you run new SW on your phone/laptop? This is not a >>>> serious approach, I'm sorry but it's completely unreliable for >>>> any serious deployment >>>> >>>> Hesham >>>> >>>>> >>>>> Carlos >>>>> >>>>>> >>>>>> Thanks, Hesham >>>>>> >>>>>> >>>>>>> >>>>>>> Carlos >>>>>>> >>>>>>>> >>>>>>>> Hesham >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >>>> _______________________________________________ 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 alexandru.petrescu@gmail.com Tue Mar 1 13:02: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 5BBB93A67B5 for ; Tue, 1 Mar 2011 13:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_32=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 tYBgWQVMciiy for ; Tue, 1 Mar 2011 13:02:19 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id C16C03A6AA5 for ; Tue, 1 Mar 2011 13:02:17 -0800 (PST) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 7C6AE940229 for ; Tue, 1 Mar 2011 22:03:16 +0100 (CET) Message-ID: <4D6D5F11.9040409@gmail.com> Date: Tue, 01 Mar 2011 22:03:13 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: netext@ietf.org References: <1299008326.5170.52.camel@acorde.it.uc3m.es> In-Reply-To: <1299008326.5170.52.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 110301-0, 01/03/2011), Outbound message X-Antivirus-Status: Clean 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 21:02:20 -0000 Le 01/03/2011 20:38, Carlos Jesús Bernardos Cano a écrit : > Hi Sri, > > On Tue, 2011-03-01 at 11:35 -0800, Sri Gundavelli wrote: >> Hi Carlos: >> >> >> >> >> On 3/1/11 11:06 AM, "Carlos Jesús Bernardos Cano" >> wrote: >> >>> Hi Sri, >>> >>> On Tue, 2011-03-01 at 10:20 -0800, Sri Gundavelli wrote: >>>> Carlos: >>>> >>>> I've not been following this thread, pardon me for the >>>> ignorance on the context of the thread. Clarifying question >>>> (specific to this one comment). >>>> >>>> >>>>> As you said earlier you make the MN send an RS, which is not >>>>> required in IPv6. >>>> >>>> A mobile node, or a simple IPv6 node, on a new link does not an >>>> RS ? How does it detect the IPv6 routers, if suppress-periodic >>>> RA is enabled ? >>>> >>> >>> The point is that, in my experience, if you attach a node to a >>> WLAN (i.e. connect to an AP), when you first bring up the >>> interface an RS is sent. But if later on the device changes AP, >>> my experience with Linux is that no more RS are generated (unless >>> you bring down/up the interface). >>> >> >> All the stacks I've tested, any time there is a link flap, >> reassociation with a new 802.11 AP, the client will send an RS. >> This is true for IPv4 as well, the activation of DNAv4 procedures, >> ARP'ng for the DR MAC address. IMO, the node does send an RS >> message. > > Then you haven't tested Linux ;). With Linux (at least the flavours > I've tested) there is no such RS upon AP reassociation. I agree. On some linux implementations of WiFi driver the RS doesn't happen, especially when the ESSID is the same as on the previous AP, and the two coverages overlap (typical for hotspot deployments). The RS does happen when putting interface down/up, and that does happen when new association (i.e. previous iwconfig listed less lines than current). This behaviour is so since a number of years. To circumvent it I think there is a flag somewhere in /proc/sys, or a sequence ifconfig down/up which forces sending an RS. This method is good when experimenting - implementer can trigger sending an RS. There may even exist some distribution-specific linux software in the userspace ("Connection Manager"(?) on Ubuntu is the latest I tried) which does provoke sending an RS when the user manually selects an ESSID to connect to, IIRC. But this is different from deployment, because at deployment time no new software trigger should be added: use a Host out of the box. Use only its kernel stack - that is the only vanilla stuff we can assume on an unmodified Host (non-modified Host). (I mean the assumption here, in this group). Alex > > Carlos > >> >> >> >> Regards Sri >> >> >> >> >> >>> Thanks, >>> >>> Carlos >>> >>>> >>>> Sri >>>> >>>> >>>> >>>> >>>> >>>> On 3/1/11 4:18 AM, "Hesham Soliman" >>>> wrote: >>>> >>>>> >>>>>> >>>>>> Well, I see quite potential for PMIPv6 over WLAN, why do >>>>>> you think there would not be any serious WLAN deployment >>>>>> with PMIPv6? >>>>> >>>>> => Because of the nature of the links, a router doesn't >>>>> always know who's attached. As you said earlier you make the >>>>> MN send an RS, which is not required in IPv6. Also the >>>>> address allocation is a mess and sharing the link with MIPv6 >>>>> nodes is very problematic. I'm not the right person to say >>>>> why PMIPv6 was created in the first place but I only see it >>>>> used, if ever, on p2p links whose use is strictly defined in >>>>> SDOs. It was never intended, even by its proponents, to do >>>>> flow mobility or global mobility and it can't do either one. >>>>> The irony is that people wanted something that doesn't >>>>> involve MN signalling and now we'll expect signalling anyway, >>>>> just not on L3. It's mind boggling. >>>>> >>>>>> >>>>>>> shared links. >>>>>>> >>>>>>>>> => Do you have a user profile transfer mechanism in >>>>>>>>> your lab? If you do please share some high level >>>>>>>>> info. >>>>>>>> >>>>>>>> In our lab the testbed is small, so we just have a >>>>>>>> config file with the profile. >>>>>>> >>>>>>> => So as both myself and Julien already said, you must >>>>>>> be assuming a 1:1 mapping between the MN and the user. >>>>>>> Either that or your profile is a device profile not a >>>>>>> user profile. The former is wrong in the real world and >>>>>>> the latter is not used in the real world. >>>>>> >>>>>> I was referring to a device profile and I don't see why >>>>>> this cannot be used in the real world. My operator here in >>>>>> Spain knows which device I use (even I have a flat rate >>>>>> that can just be used with my type of device). >>>>> >>>>> => Really? And do you call your operator if you remove your >>>>> SIM card and put it in another device?. Does you operator >>>>> also know when you run new SW on your phone/laptop? This is >>>>> not a serious approach, I'm sorry but it's completely >>>>> unreliable for any serious deployment >>>>> >>>>> Hesham >>>>> >>>>>> >>>>>> Carlos >>>>>> >>>>>>> >>>>>>> Thanks, Hesham >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Carlos >>>>>>>> >>>>>>>>> >>>>>>>>> Hesham >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> _______________________________________________ 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 alexandru.petrescu@gmail.com Tue Mar 1 13:25: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 AA9A83A6A16 for ; Tue, 1 Mar 2011 13:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.200, 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 FzHouilz-XEv for ; Tue, 1 Mar 2011 13:25:36 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 3C9E73A67B5 for ; Tue, 1 Mar 2011 13:25:33 -0800 (PST) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 5A90E940175; Tue, 1 Mar 2011 22:26:32 +0100 (CET) Message-ID: <4D6D6485.7040601@gmail.com> Date: Tue, 01 Mar 2011 22:26:29 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Sri Gundavelli References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 110301-0, 01/03/2011), Outbound message X-Antivirus-Status: Clean Cc: netext@ietf.org Subject: Re: [netext] PMIPv6 and WiFi (was: 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 21:25:40 -0000 Le 01/03/2011 21:48, Sri Gundavelli a écrit : > Hi Alex, > > Thanks for your note and for your agreement on the host having to > send RS after reattach. > > Few points without going into details as we have related products in > this space. > > - There is access authentication on 802.11 link, where there is a > mapping between a link-layer address and a mobile identity. Specific authentication method and software name please, so I can try here in my lab the same so I don't grow white hairs wondering how others do it. It will be very good for me to learn whether PMIPv6 on WiFi absolutely needs this mapping MAC address - mobile identity, you mention above. I currently suppose that PMIPv6 can't work without this mapping. (a mapping which is not documented BTW). > - MN-ID need not be a MAC address Must one insert MN-ID in RA or RS? Or are we free to not do it? > - There is the ability to segregate shared links as p2p links, there > are semantics Software name please? RFC/draft name please? > - There are semantics to sends unicast RA's. There is this RFC-6085. Is it implemented on linux? How should I configure it? Or is it a Cisco-only thing (judging by authorship)? (I do appreciate and sometimes even buy Cisco). > - RADVD is a specific implementation, I'm not sure I can comment in > that tool context. Yes, radvd is specific implementation. I can comment on it, if needed. > But, we can stay with the standard IP host behavior for this > discussion, as that is what we need, except for inter-tech handovers > where we need logical interface construct. Yes, but we don't understand the same thing by IP host standard behavior. One of the divergences is on the use of RAs. Or we can't say PMIPv6 works with all IPv6 "standard" Hosts if we don't understand the same thing by standard. > - How the LMA allocates prefixes for a mobility session is out of > scope. No no, it is fully in scope. > It can very well use local pools, depend on AAA, or use DHCP PD. Even the simple concept of local pools is not that easy to implement. I can tell that DHCP PD is not as simple as you seem to assume it. BAsically it is next to impossible for LMA to act on behalf of the Host, without modifications to DHCP specs and implementation. AAA is a huge concept. If I only knew which part of AAA software to install and try with PMIPv6 to avoid coding local pool. Which one? > Some folks have attempted to specific this LMA-DHCP interface. It > should be good to have such details specified. Well yes, I think without such kind of LMA-DHCP interface, PMIP can't work for a H on WiFi. > - The comment on link-local address is valid and as we have seen > early proposals to avoid that remote conflicts > > - MAG can certainly advertise local prefixes which have no mobility. > But, we will be hit with the issue of lack of SAS ability. So, lets > assume the MAG advertises the prefixes on a per-MN basis, just that > prefixes it gets from the LMA for that session. Assume yes, but implement how? > - The implementors of PMIPv6 I know, use Cisco IOS, Linux and number > of platforms that we have obviously. Well please direct them to the list to answer this: is their PMIPv6 used without link-specific authentication (without EAP, without PEAP, without WPA)? > - We have tried PMIPv6 beyond 3GPP and we have understanding how > this works. There are other folks like Juan Carlos, Carlos, Telemaco, > who have even implementations of some of advanced features working. > I will surely try to provide you some working images on some > platforms that you can play with. I will try to get you that. Thanks for the offer, appreciated. That can be useful. But I am currently looking at linux implementations. When that is done, I will 'promote' one to the core made of Cisco routers, later. But currently I consider PMIPv6 on linux for WiFi. Alex > > > Sri > > > > > On 3/1/11 12:26 PM, "Alexandru > Petrescu" wrote: > >> Hello Sri, netext, >> >> Sri - I take advantage of your email to reply, but I also Cc the >> group. >> >> Please excuse my ignorance of netext developments, and generally >> on the PMIPv6 text. >> >> But, even accepting that MH does send an RS upon attachment to a >> new attachment to a new WiFi AP. >> >> I would like to tell about difficult issues when trying to >> implement PMIPv6 on WiFi (not me, but related). >> >> o even though an MN does send an RS: does it contain an MN-ID? For >> PMIPv6 to work it should contain an MN-ID otherwise MAG can't know >> to whom to allocate a prefix. What is the RFC/draft telling how >> to encode an MN-ID into an RS and eventually RA? I am not aware. >> >> Do you really _mean_ MN-ID (like a NAI) or do you silently assume >> that MN-ID could be the MAC address of MH? >> >> o how do you make work ptp links on WiFi? Name of open source >> software please thank you. >> >> o what does one use in implementation to make this "prefix-per-MH" >> concept work; how does one do "point-to-point" links on WiFi in >> practice? Is it L2TP? Is it another? Which document? Don't say >> it is out of scope - it is fully in scope if one wants to do PMIPv6 >> with WiFi - without this PMIPv6/WiFi can't work. >> >> o how does one do several prefixes on a single WiFi link? What >> draft/RFC tells how to do it? Typically a WiFi link has a single >> prefix, or maybe a few; how does one make sure that each different >> prefix (HNP) sent on a single WiFi link is never advertised to >> everyone else, but only to a single MH? (make sure dst address is >> unicast, not multicast). >> >> o is there an radvd implementation doing this per-MN prefix >> advertisement? >> >> o radvd on linux is driven by a config file, and there is >> difficulty in updating that file dynamically and re-start radvd >> daemon. Anybody did that already? Where? radvd software is GPL >> - so any modifications to do this behaviour should be available - >> whom should I ask? >> >> o are implementers of PMIPv6/WiFi use something else than radvd to >> send RAs from MAG? What software please? >> >> o when supposedly the MAG does advertise a number of independent >> "per-MH" HNPs, does is still advertise a non-HNP prefix valid for >> every other MH which does not assume PMIPv6 is working (a "natural" >> prefix if I can say so)? What does this prefix look like? >> >> o does a MAG receiving 2 MHs coming from 2 different other MAG's >> assign 2 link local addresses on its WiFi interface (the next-hop >> for default route)? >> >> These are doubts only about MAG-MH interface. But there are a >> number of doubts about how the LMA assigns the prefix to MHas >> well. I assume this is not performed with DHCP - then how is it >> performed? The PMIPv6 specification is silent about this >> (lifetimes? confirmations?). It is very little tempting to start >> writing a new implementation of prefix allocation, especially when >> knowing DHCPv6 implementations include prefix allocation, all >> readily available. >> >> My current state of thinking is that PMIPv6 is written for 3GPP >> and has not been experimented on WiFi beyond proof of concept. I >> mean - all my respect to statements of implementations of PMIPv6 >> on WiFi, but, however, when compared to MIPv6 implementations, >> these are much less working on WiFi. For example, MIPv6 >> implementation work with out-of-the-box radvd, and out-of-the-box >> dhcp3. But PMIPv6 implementations on WiFi can only work according >> to non-specified and behaviour which is claimed out of scope in >> PMIPv6 specs. >> >> Finally, I may be not updated with draft/RFC developments of >> PMIPv6, excuses. >> >> Alex >> >> Le 01/03/2011 19:20, Sri Gundavelli a écrit : >>> Carlos: >>> >>> I've not been following this thread, pardon me for the ignorance >>> on the context of the thread. Clarifying question (specific to >>> this one comment). >>> >>> >>>> As you said earlier you make the MN send an RS, which is not >>>> required in IPv6. >>> >>> A mobile node, or a simple IPv6 node, on a new link does not an >>> RS ? How does it detect the IPv6 routers, if suppress-periodic >>> RA is enabled ? >>> >>> >>> Sri >>> >>> >>> >>> >>> >>> On 3/1/11 4:18 AM, "Hesham Soliman" >>> wrote: >>> >>>> >>>>> >>>>> Well, I see quite potential for PMIPv6 over WLAN, why do you >>>>> think there would not be any serious WLAN deployment with >>>>> PMIPv6? >>>> >>>> => Because of the nature of the links, a router doesn't >>>> always know who's attached. As you said earlier you make the >>>> MN send an RS, which is not required in IPv6. Also the address >>>> allocation is a mess and sharing the link with MIPv6 nodes is >>>> very problematic. I'm not the right person to say why PMIPv6 >>>> was created in the first place but I only see it used, if >>>> ever, on p2p links whose use is strictly defined in SDOs. It >>>> was never intended, even by its proponents, to do flow mobility >>>> or global mobility and it can't do either one. The irony is >>>> that people wanted something that doesn't involve MN signalling >>>> and now we'll expect signalling anyway, just not on L3. It's >>>> mind boggling. >>>> >>>>> >>>>>> shared links. >>>>>> >>>>>>>> => Do you have a user profile transfer mechanism in >>>>>>>> your lab? If you do please share some high level info. >>>>>>> >>>>>>> In our lab the testbed is small, so we just have a config >>>>>>> file with the profile. >>>>>> >>>>>> => So as both myself and Julien already said, you must be >>>>>> assuming a 1:1 mapping between the MN and the user. Either >>>>>> that or your profile is a device profile not a user >>>>>> profile. The former is wrong in the real world and the >>>>>> latter is not used in the real world. >>>>> >>>>> I was referring to a device profile and I don't see why this >>>>> cannot be used in the real world. My operator here in Spain >>>>> knows which device I use (even I have a flat rate that can >>>>> just be used with my type of device). >>>> >>>> => Really? And do you call your operator if you remove your >>>> SIM card and put it in another device?. Does you operator also >>>> know when you run new SW on your phone/laptop? This is not a >>>> serious approach, I'm sorry but it's completely unreliable for >>>> any serious deployment >>>> >>>> Hesham >>>> >>>>> >>>>> Carlos >>>>> >>>>>> >>>>>> Thanks, Hesham >>>>>> >>>>>> >>>>>>> >>>>>>> Carlos >>>>>>> >>>>>>>> >>>>>>>> Hesham >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >>>> _______________________________________________ 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 Tue Mar 1 15:45: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 1A1F43A6BF2 for ; Tue, 1 Mar 2011 15:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.577 X-Spam-Level: X-Spam-Status: No, score=-1.577 tagged_above=-999 required=5 tests=[AWL=-0.373, 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 SsIIiRboRh5A for ; Tue, 1 Mar 2011 15:45:20 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 04D7F3A6BF1 for ; Tue, 1 Mar 2011 15:45:19 -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 1PuZGg-0005TR-HC; Wed, 02 Mar 2011 10:46:14 +1100 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Wed, 02 Mar 2011 10:46:08 +1100 From: Hesham Soliman To: Message-ID: Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvYatYUOiiz0b8pR0qA3UXgXfFbUw== In-Reply-To: <1299007847.5170.49.camel@acorde.it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-User: hesham@elevatemobile.com 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: Tue, 01 Mar 2011 23:45:21 -0000 On 2/03/11 6:30 AM, "Carlos Jes=FAs Bernardos Cano" wrote: > Hi Hesham, >=20 > On Tue, 2011-03-01 at 23:18 +1100, Hesham Soliman wrote: >>>=20 >>> Well, I see quite potential for PMIPv6 over WLAN, why do you think ther= e >>> would not be any serious WLAN deployment with PMIPv6? >>=20 >> =3D> Because of the nature of the links, a router doesn't always know who'= s >> attached. As you said earlier you make the MN send an RS, which is not >> required in IPv6. Also the address allocation is a mess and sharing the = link >=20 > PMIPv6 does not force any specific mechanism on how the MAG detects the > attachment of a MN. My experience with WLAN is quite OK so far, never > had a problem and it's quite easy to implement the AP trigger and the > ptp-to-ptp emulation on WLAN. =3D> Quiet easy? I think you must have a special WLAN in your lab :) I don't think so, if you think it's easy I think you've missed a lot of issues. See my points above and please respond specifically. >=20 >> with MIPv6 nodes is very problematic. I'm not the right person to say wh= y >> PMIPv6 was created in the first place but I only see it used, if ever, o= n >> p2p links whose use is strictly defined in SDOs. It was never intended, = even >> by its proponents, to do flow mobility or global mobility and it can't d= o >> either one.=20 >=20 > I don't know the intention of the proponents of the protocol, but as > mentioned in other e-mail, I don't see any problem using it on WLAN > links. I see it working every day, and even doing flow mobility across > different technologies. =3D>I notice that you're giving generic responses. You're not addressing specific issues above. >=20 >> The irony is that people wanted something that doesn't involve MN signal= ling >> and now we'll expect signalling anyway, just not on L3. It's mind boggli= ng. >=20 > I don't expect signaling from the MN, that's the point. I see the value > of PMIPv6 on this absence of MN involvement and that's why we are > proposing signaling on the core (MAG-LMA) to enable flow mobility > instead of putting all the requirements on the MN (for that we already > have MIPv6). =3D> If you think you can do flow mobility without MN involvement then good luck with that. I'm starting to think that people on this list are in denia= l and it doesn't matter how many arguments are not being responded to, everyone comes back and says "it's doable". I think we're going to have to leave this to the AD's because we're not making any progress. >> =3D> Really? And do you call your operator if you remove your SIM card an= d >> put it in another device?. Does you operator also know when you run new = SW >> on your phone/laptop? This is not a serious approach, I'm sorry but it's >> completely unreliable for any serious deployment >=20 > You talking about serious approaches and operators?? from a pure-user > only perspective, I'm sorry to say that most current practices of > operators cannot be considered as "serious" :) =3D> Again, you're backing out of your points mentioned earlier :) Please respond to how you will make it work. Hesham >=20 > Carlos >=20 >>=20 >> Hesham >>=20 >>>=20 >>> Carlos >>>=20 >>>>=20 >>>> Thanks, >>>> Hesham >>>>=20 >>>>=20 >>>>>=20 >>>>> Carlos >>>>>=20 >>>>>>=20 >>>>>> Hesham >>>>>>=20 >>>>>>=20 >>>>=20 >>>>=20 >>=20 >>=20 From Basavaraj.Patil@nokia.com Tue Mar 1 18: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 BB65F3A6C01 for ; Tue, 1 Mar 2011 18:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.38 X-Spam-Level: X-Spam-Status: No, score=-102.38 tagged_above=-999 required=5 tests=[AWL=-0.381, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, 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 7UwE88xNAusw for ; Tue, 1 Mar 2011 18:07:49 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id 55CDF3A6A24 for ; Tue, 1 Mar 2011 18:07:49 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2228nVX008573; Wed, 2 Mar 2011 04:08:49 +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, 2 Mar 2011 04:08:44 +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 Mar 2011 03:08:32 +0100 Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.127]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0270.002; Wed, 2 Mar 2011 03:08:32 +0100 From: To: Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvTH7hRFKVN0Kr67UiTaBIlg8gywgAejl2AAAHvnYAAAaltAAAAevCAAA8x8gAAE1N8AAADW1qAAANRXoAAAMIDgAADjsKAAAfFm4AAHfplgAABZ90AAAgHUYAAAEM0AACbGJiAAAdu4YAAEPkHAAAFGCYAAABJUQAAAC5+AAAMpgUAAAGZ74AAAQgyAAACoPMw////4AD//+M8IA== Date: Wed, 2 Mar 2011 02:08:31 +0000 Message-ID: <97683F8C138FB243AAC90CEFB48ABF1509267222@008-AM1MPN1-004.mgdnok.nokia.com> References: <1299006371.5170.28.camel@acorde.it.uc3m.es> <97683F8C138FB243AAC90CEFB48ABF15092670F3@008-AM1MPN1-004.mgdnok.nokia.com> <4D6D5C1A.3040108@gmail.com> In-Reply-To: <4D6D5C1A.3040108@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.64.197.89] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Mar 2011 02:08:44.0991 (UTC) FILETIME=[C271D4F0:01CBD87E] X-Nokia-AV: Clean Cc: netext@ietf.org, JuanCarlos.Zuniga@interdigital.com 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, 02 Mar 2011 02:07:50 -0000 Hi Alex, Comments inline: -----Original Message----- From: ext Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Sent: Tuesday, March 01, 2011 2:51 PM To: Patil Basavaraj (Nokia-MS/Dallas) Cc: sgundave@cisco.com; cjbc@it.uc3m.es; netext@ietf.org; JuanCarlos.Zuniga= @interdigital.com Subject: Re: [netext] Flow Mobility discussion - way forward? Hi Raj, Please allow to give an oppinion on this. I agree we should leave the Host unmodified. But in more detail: what do you mean we should not spend time on signalling MH-MAG? (you say MN, and I suppose MH, because MR-MAG doesn't work with PMIPv6, and MN can be an MR; also this MH is not assumed Mobile IPv6, so it could as well be an H actually - making it a 'H-MAG' interface). Raj> Good. We are in agreement that the protocol ought to work with no expe= ctations of host modifications. To me that signalling is of paramount importance for PMIPv6/WiFi to work. YEs, the MH should send the typical RS it sends, unmodified, and MAG should adapt to it. In this sense, only the MH is out of scope, but MAG is modified and its modifications are in scope. Raj> In the context of the flow mobility discussion, that RS (as it exists = today) will not be of much help even if it is only the MAG that is being mo= dified.=20 I do think we need to spend time telling (at least on the mailing list, or for an implementer clarification) how does the MH tell the MAG its MN-ID when that happens on WiFi (not on cellular). Raj> Potentially via L2 means. But if your question is if this is or can be= done at L3, then no.=20 I take advantage of this remark to tell that this is true for a number of other aspects in the PMIPv6 RFC. A number of such aspects ('stateful', 'policy') are currently said to be out of scope in the PMIPv6 spec. Raj> It's a bit late to start asking questions about the basic PMIP6 RFC (5= 213). You may want to refer to the Netlmm archives. This is strange! A spec would leave aspects as 'out-of-scope' when non-interoperable implementations of it are ok. I.e., it would be ok to have local proprietary implementations of 'policy server'. But when the inherent working of PMIPv6 is at stake then that can't be left out of scope. Raj> Would advise you to go revisit Netlmm discussion archives.=20 I may be not updated about PMIPv6 documents, excuses, but this MN-ID between MH and MAG question is very much in-scope IMHO. Raj> I don't believe that to be the case in the context of flow mobility fo= r PMIP6. At least not in terms of how flow mobility for PMIP6 is envisioned= . -Raj Yours, Alex Le 01/03/2011 20:52, Basavaraj.Patil@nokia.com a =E9crit : > > FWIW, I would remind you that we have agreed (during chartering) to > not do any L3 signaling between MN-MAG. Hence use of RS/RA is not an > option here and hence do not need to spend time on that. > > -Raj > > -----Original Message----- From: netext-bounces@ietf.org > [mailto:netext-bounces@ietf.org] On Behalf Of ext Sri Gundavelli > Sent: Tuesday, March 01, 2011 1:36 PM To: cjbc@it.uc3m.es Cc: > netext@ietf.org; Zuniga, Juan Carlos Subject: Re: [netext] Flow > Mobility discussion - way forward? > > Hi Carlos: > > > > > On 3/1/11 11:06 AM, "Carlos Jes=FAs Bernardos Cano" > wrote: > >> Hi Sri, >> >> On Tue, 2011-03-01 at 10:20 -0800, Sri Gundavelli wrote: >>> Carlos: >>> >>> I've not been following this thread, pardon me for the ignorance >>> on the context of the thread. Clarifying question (specific to >>> this one comment). >>> >>> >>>> As you said earlier you make the MN send an RS, which is not >>>> required in IPv6. >>> >>> A mobile node, or a simple IPv6 node, on a new link does not an >>> RS ? How does it detect the IPv6 routers, if suppress-periodic RA >>> is enabled ? >>> >> >> The point is that, in my experience, if you attach a node to a >> WLAN (i.e. connect to an AP), when you first bring up the interface >> an RS is sent. But if later on the device changes AP, my experience >> with Linux is that no more RS are generated (unless you bring >> down/up the interface). >> > > All the stacks I've tested, any time there is a link flap, > reassociation with a new 802.11 AP, the client will send an RS. This > is true for IPv4 as well, the activation of DNAv4 procedures, ARP'ng > for the DR MAC address. IMO, the node does send an RS message. > > > > Regards Sri > > > > > >> Thanks, >> >> Carlos >> >>> >>> Sri >>> >>> >>> >>> >>> >>> On 3/1/11 4:18 AM, "Hesham Soliman" >>> wrote: >>> >>>> >>>>> >>>>> Well, I see quite potential for PMIPv6 over WLAN, why do you >>>>> think there would not be any serious WLAN deployment with >>>>> PMIPv6? >>>> >>>> =3D> Because of the nature of the links, a router doesn't always >>>> know who's attached. As you said earlier you make the MN send >>>> an RS, which is not required in IPv6. Also the address >>>> allocation is a mess and sharing the link with MIPv6 nodes is >>>> very problematic. I'm not the right person to say why PMIPv6 >>>> was created in the first place but I only see it used, if ever, >>>> on p2p links whose use is strictly defined in SDOs. It was >>>> never intended, even by its proponents, to do flow mobility or >>>> global mobility and it can't do either one. The irony is that >>>> people wanted something that doesn't involve MN signalling and >>>> now we'll expect signalling anyway, just not on L3. It's mind >>>> boggling. >>>> >>>>> >>>>>> shared links. >>>>>> >>>>>>>> =3D> Do you have a user profile transfer mechanism in >>>>>>>> your lab? If you do please share some high level info. >>>>>>> >>>>>>> In our lab the testbed is small, so we just have a config >>>>>>> file with the profile. >>>>>> >>>>>> =3D> So as both myself and Julien already said, you must be >>>>>> assuming a 1:1 mapping between the MN and the user. Either >>>>>> that or your profile is a device profile not a user >>>>>> profile. The former is wrong in the real world and the >>>>>> latter is not used in the real world. >>>>> >>>>> I was referring to a device profile and I don't see why this >>>>> cannot be used in the real world. My operator here in Spain >>>>> knows which device I use (even I have a flat rate that can >>>>> just be used with my type of device). >>>> >>>> =3D> Really? And do you call your operator if you remove your >>>> SIM card and put it in another device?. Does you operator also >>>> know when you run new SW on your phone/laptop? This is not a >>>> serious approach, I'm sorry but it's completely unreliable for >>>> any serious deployment >>>> >>>> Hesham >>>> >>>>> >>>>> Carlos >>>>> >>>>>> >>>>>> Thanks, Hesham >>>>>> >>>>>> >>>>>>> >>>>>>> Carlos >>>>>>> >>>>>>>> >>>>>>>> Hesham >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >>>> _______________________________________________ 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 cjbc@it.uc3m.es Wed Mar 2 03:31: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 AF34F3A67A7 for ; Wed, 2 Mar 2011 03:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.279 X-Spam-Level: X-Spam-Status: No, score=-5.279 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_32=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 S+fl6JJpmtPk for ; Wed, 2 Mar 2011 03:31:58 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 28F1B3A6A91 for ; Wed, 2 Mar 2011 03:31:58 -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 smtp01.uc3m.es (Postfix) with ESMTP id 24FF7BF3153; Wed, 2 Mar 2011 12:33:02 +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="=-ovV0vxnymo7j5B7qKXGN" Organization: Universidad Carlos III de Madrid Date: Wed, 02 Mar 2011 12:34:27 +0100 Message-ID: <1299065667.5356.9.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-17986.006 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: Wed, 02 Mar 2011 11:31:59 -0000 --=-ovV0vxnymo7j5B7qKXGN Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Sri, On Tue, 2011-03-01 at 11:46 -0800, Sri Gundavelli wrote: > Hi Carlos: >=20 >=20 >=20 > On 3/1/11 11:38 AM, "Carlos Jes=FAs Bernardos Cano" wro= te: >=20 > > Hi Sri, > >=20 > > On Tue, 2011-03-01 at 11:35 -0800, Sri Gundavelli wrote: > >> Hi Carlos: > >>=20 > >>=20 > >>=20 > >>=20 > >> On 3/1/11 11:06 AM, "Carlos Jes=FAs Bernardos Cano" = wrote: > >>=20 > >>> Hi Sri, > >>>=20 > >>> On Tue, 2011-03-01 at 10:20 -0800, Sri Gundavelli wrote: > >>>> Carlos: > >>>>=20 > >>>> I've not been following this thread, pardon me for the ignorance on = the > >>>> context of the thread. Clarifying question (specific to this one com= ment). > >>>>=20 > >>>>=20 > >>>>> As you said earlier you make the MN send an RS, which is not requir= ed in > >>>>> IPv6. > >>>>=20 > >>>> A mobile node, or a simple IPv6 node, on a new link does not an RS ?= How > >>>> does it detect the IPv6 routers, if suppress-periodic RA is enabled = ? > >>>>=20 > >>>=20 > >>> The point is that, in my experience, if you attach a node to a WLAN > >>> (i.e. connect to an AP), when you first bring up the interface an RS = is > >>> sent. But if later on the device changes AP, my experience with Linux= is > >>> that no more RS are generated (unless you bring down/up the interface= ). > >>>=20 > >>=20 > >> All the stacks I've tested, any time there is a link flap, reassociati= on > >> with a new 802.11 AP, the client will send an RS. This is true for IPv= 4 as > >> well, the activation of DNAv4 procedures, ARP'ng for the DR MAC addres= s. > >> IMO, the node does send an RS message. > >=20 > > Then you haven't tested Linux ;). With Linux (at least the flavours I'v= e > > tested) there is no such RS upon AP reassociation. > >=20 >=20 > Ok. I assume, on "that" Linux stack, your mobile IP client will not work.= It > will never send an RS and will never obtain a CCoA address. It will be ha= ppy > with a stale binding using a CCoA address from the prev link. I'm talking about a legacu IPv6 host. If I install Mobile IPv6 in that Linux stack, don't worry, the MIPv6 client takes care of configuring a CoA (sending an RS if no RA is received). Carlos >=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 --=-ovV0vxnymo7j5B7qKXGN 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) iEYEABECAAYFAk1uK0MACgkQNdy6TdFwT2c1iACg3XbBioxqlu7h1yIB903PCANP IM8AoNyii37rb2UF7Veg9fqlaZq1Qgdo =TvVu -----END PGP SIGNATURE----- --=-ovV0vxnymo7j5B7qKXGN-- From cjbc@it.uc3m.es Wed Mar 2 03:33: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 EA8673A676A for ; Wed, 2 Mar 2011 03:33:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.263 X-Spam-Level: X-Spam-Status: No, score=-5.263 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_32=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 zRNUuHlx5C71 for ; Wed, 2 Mar 2011 03:33:27 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 336773A67A7 for ; Wed, 2 Mar 2011 03:33:27 -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 smtp01.uc3m.es (Postfix) with ESMTP id 115C5BF36BE; Wed, 2 Mar 2011 12:34:32 +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="=-YD90G/G6w1L4rToMMV9q" Organization: Universidad Carlos III de Madrid Date: Wed, 02 Mar 2011 12:35:57 +0100 Message-ID: <1299065757.5356.10.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-17986.006 Cc: netext@ietf.org, JuanCarlos.Zuniga@interdigital.com, Basavaraj.Patil@nokia.com 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: Wed, 02 Mar 2011 11:33:29 -0000 --=-YD90G/G6w1L4rToMMV9q Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Sri, On Tue, 2011-03-01 at 12:00 -0800, Sri Gundavelli wrote: > This is unrelated to the L3 interface between MAG-MN question, or about > LMA-MAG signaling. The basic node behavior, if this comment were to be tr= ue, > many apps and the basic host IP stack is broken. Well, I'd not sya the basic host IP stack is broken. The behaviour I've noticed with Linux is not the one I like the most, but I'd not call it broken. Carlos >=20 >=20 >=20 > Sri >=20 >=20 >=20 >=20 > On 3/1/11 11:52 AM, "Basavaraj.Patil@nokia.com" > wrote: >=20 > >=20 > > FWIW, I would remind you that we have agreed (during chartering) to not= do any > > L3 signaling between MN-MAG. > > Hence use of RS/RA is not an option here and hence do not need to spend= time > > on that. > >=20 > > -Raj > >=20 > > -----Original Message----- > > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behal= f Of > > ext Sri Gundavelli > > Sent: Tuesday, March 01, 2011 1:36 PM > > To: cjbc@it.uc3m.es > > Cc: netext@ietf.org; Zuniga, Juan Carlos > > Subject: Re: [netext] Flow Mobility discussion - way forward? > >=20 > > Hi Carlos: > >=20 > >=20 > >=20 > >=20 > > On 3/1/11 11:06 AM, "Carlos Jes=FAs Bernardos Cano" w= rote: > >=20 > >> Hi Sri, > >>=20 > >> On Tue, 2011-03-01 at 10:20 -0800, Sri Gundavelli wrote: > >>> Carlos: > >>>=20 > >>> I've not been following this thread, pardon me for the ignorance on t= he > >>> context of the thread. Clarifying question (specific to this one comm= ent). > >>>=20 > >>>=20 > >>>> As you said earlier you make the MN send an RS, which is not require= d in > >>>> IPv6. > >>>=20 > >>> A mobile node, or a simple IPv6 node, on a new link does not an RS ? = How > >>> does it detect the IPv6 routers, if suppress-periodic RA is enabled ? > >>>=20 > >>=20 > >> The point is that, in my experience, if you attach a node to a WLAN > >> (i.e. connect to an AP), when you first bring up the interface an RS i= s > >> sent. But if later on the device changes AP, my experience with Linux = is > >> that no more RS are generated (unless you bring down/up the interface)= . > >>=20 > >=20 > > All the stacks I've tested, any time there is a link flap, reassociatio= n > > with a new 802.11 AP, the client will send an RS. This is true for IPv4= as > > well, the activation of DNAv4 procedures, ARP'ng for the DR MAC address= . > > IMO, the node does send an RS message. > >=20 > >=20 > >=20 > > Regards > > Sri > >=20 > >=20 > >=20 > >=20 > >=20 > >> Thanks, > >>=20 > >> Carlos > >>=20 > >>>=20 > >>> Sri > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>> On 3/1/11 4:18 AM, "Hesham Soliman" wrote: > >>>=20 > >>>>=20 > >>>>>=20 > >>>>> Well, I see quite potential for PMIPv6 over WLAN, why do you think = there > >>>>> would not be any serious WLAN deployment with PMIPv6? > >>>>=20 > >>>> =3D> Because of the nature of the links, a router doesn't always kno= w who's > >>>> attached. As you said earlier you make the MN send an RS, which is n= ot > >>>> required in IPv6. Also the address allocation is a mess and sharing = the > >>>> link > >>>> with MIPv6 nodes is very problematic. I'm not the right person to sa= y why > >>>> PMIPv6 was created in the first place but I only see it used, if eve= r, on > >>>> p2p links whose use is strictly defined in SDOs. It was never intend= ed, > >>>> even > >>>> by its proponents, to do flow mobility or global mobility and it can= 't do > >>>> either one.=20 > >>>> The irony is that people wanted something that doesn't involve MN > >>>> signalling > >>>> and now we'll expect signalling anyway, just not on L3. It's mind bo= ggling. > >>>>=20 > >>>>>=20 > >>>>>> shared links. > >>>>>>=20 > >>>>>>>> =3D> Do you have a user profile transfer mechanism in your lab? = If you do > >>>>>>>> please share some high level info. > >>>>>>>=20 > >>>>>>> In our lab the testbed is small, so we just have a config file wi= th the > >>>>>>> profile. > >>>>>>=20 > >>>>>> =3D> So as both myself and Julien already said, you must be assumi= ng a 1:1 > >>>>>> mapping between the MN and the user. Either that or your profile i= s a > >>>>>> device > >>>>>> profile not a user profile. The former is wrong in the real world = and the > >>>>>> latter is not used in the real world. > >>>>>=20 > >>>>> I was referring to a device profile and I don't see why this cannot= be > >>>>> used in the real world. My operator here in Spain knows which devic= e I > >>>>> use (even I have a flat rate that can just be used with my type of > >>>>> device). > >>>>=20 > >>>> =3D> Really? And do you call your operator if you remove your SIM c= ard and > >>>> put it in another device?. Does you operator also know when you run = new SW > >>>> on your phone/laptop? This is not a serious approach, I'm sorry but = it's > >>>> completely unreliable for any serious deployment > >>>>=20 > >>>> Hesham > >>>>=20 > >>>>>=20 > >>>>> Carlos > >>>>>=20 > >>>>>>=20 > >>>>>> Thanks, > >>>>>> Hesham > >>>>>>=20 > >>>>>>=20 > >>>>>>>=20 > >>>>>>> Carlos > >>>>>>>=20 > >>>>>>>>=20 > >>>>>>>> Hesham > >>>>>>>>=20 > >>>>>>>>=20 > >>>>>>=20 > >>>>>>=20 > >>>>=20 > >>>>=20 > >>>> _______________________________________________ > >>>> netext mailing list > >>>> netext@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/netext > >>>=20 > >=20 > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-YD90G/G6w1L4rToMMV9q 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) iEYEABECAAYFAk1uK50ACgkQNdy6TdFwT2dHgwCdG0HadWsf7ltgA4UCeWnfQiZZ Z1sAnjVtkaGjloXxVC1xS/faFjquT0+0 =KmCI -----END PGP SIGNATURE----- --=-YD90G/G6w1L4rToMMV9q-- From cjbc@it.uc3m.es Wed Mar 2 03:41: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 9F3853A6B63 for ; Wed, 2 Mar 2011 03:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.549 X-Spam-Level: X-Spam-Status: No, score=-5.549 tagged_above=-999 required=5 tests=[AWL=0.150, 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 o0B5z2-huf3b for ; Wed, 2 Mar 2011 03:41:13 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id E175B3A6AA4 for ; Wed, 2 Mar 2011 03:41:12 -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 097947103CF; Wed, 2 Mar 2011 12:42:17 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Hesham Soliman In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-HgVgEp8kkLntwbAJ/EA0" Organization: Universidad Carlos III de Madrid Date: Wed, 02 Mar 2011 12:43:42 +0100 Message-ID: <1299066222.5356.17.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-17986.006 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: Wed, 02 Mar 2011 11:41:14 -0000 --=-HgVgEp8kkLntwbAJ/EA0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable On Wed, 2011-03-02 at 10:46 +1100, Hesham Soliman wrote: >=20 >=20 > On 2/03/11 6:30 AM, "Carlos Jes=FAs Bernardos Cano" wro= te: >=20 > > Hi Hesham, > >=20 > > On Tue, 2011-03-01 at 23:18 +1100, Hesham Soliman wrote: > >>>=20 > >>> Well, I see quite potential for PMIPv6 over WLAN, why do you think th= ere > >>> would not be any serious WLAN deployment with PMIPv6? > >>=20 > >> =3D> Because of the nature of the links, a router doesn't always know = who's > >> attached. As you said earlier you make the MN send an RS, which is not > >> required in IPv6. Also the address allocation is a mess and sharing th= e link > >=20 > > PMIPv6 does not force any specific mechanism on how the MAG detects the > > attachment of a MN. My experience with WLAN is quite OK so far, never > > had a problem and it's quite easy to implement the AP trigger and the > > ptp-to-ptp emulation on WLAN. >=20 > =3D> Quiet easy? I think you must have a special WLAN in your lab :) > I don't think so, if you think it's easy I think you've missed a lot of > issues. See my points above and please respond specifically. - MN attachment detection: software on the AP that monitors the association table (most drivers provide that feature). - Point-to-point emulation: MAG send the RA to the unicast link-local address of the MN or it sends it multicast in IPv6 but addressed to the L2 address of the MN only. - We use L2 address as MN-ID (just for the sake of simplicity) What else do we need? with that I have legacy IPv6 clients (no modification at all) roaming happily between MAGs :) >=20 > >=20 > >> with MIPv6 nodes is very problematic. I'm not the right person to say = why > >> PMIPv6 was created in the first place but I only see it used, if ever,= on > >> p2p links whose use is strictly defined in SDOs. It was never intended= , even > >> by its proponents, to do flow mobility or global mobility and it can't= do > >> either one.=20 > >=20 > > I don't know the intention of the proponents of the protocol, but as > > mentioned in other e-mail, I don't see any problem using it on WLAN > > links. I see it working every day, and even doing flow mobility across > > different technologies. >=20 > =3D>I notice that you're giving generic responses. You're not addressing > specific issues above. >=20 > >=20 > >> The irony is that people wanted something that doesn't involve MN sign= alling > >> and now we'll expect signalling anyway, just not on L3. It's mind bogg= ling. > >=20 > > I don't expect signaling from the MN, that's the point. I see the value > > of PMIPv6 on this absence of MN involvement and that's why we are > > proposing signaling on the core (MAG-LMA) to enable flow mobility > > instead of putting all the requirements on the MN (for that we already > > have MIPv6). >=20 > =3D> If you think you can do flow mobility without MN involvement then go= od > luck with that. I'm starting to think that people on this list are in den= ial > and it doesn't matter how many arguments are not being responded to, > everyone comes back and says "it's doable". I think we're going to have t= o > leave this to the AD's because we're not making any progress. Well, I've seen prototypes of flow mobility working, with the only artifact of the logical interface (or the weak host model) in the terminal. So I say "it's doable" because I've done it or I've seen it done. >=20 > >> =3D> Really? And do you call your operator if you remove your SIM car= d and > >> put it in another device?. Does you operator also know when you run ne= w SW > >> on your phone/laptop? This is not a serious approach, I'm sorry but it= 's > >> completely unreliable for any serious deployment > >=20 > > You talking about serious approaches and operators?? from a pure-user > > only perspective, I'm sorry to say that most current practices of > > operators cannot be considered as "serious" :) >=20 > =3D> Again, you're backing out of your points mentioned earlier :) Please > respond to how you will make it work. We have a draft summarizing how solutions that I've seen working operate. Carlos >=20 > Hesham >=20 > >=20 > > Carlos > >=20 > >>=20 > >> Hesham > >>=20 > >>>=20 > >>> Carlos > >>>=20 > >>>>=20 > >>>> Thanks, > >>>> Hesham > >>>>=20 > >>>>=20 > >>>>>=20 > >>>>> Carlos > >>>>>=20 > >>>>>>=20 > >>>>>> Hesham > >>>>>>=20 > >>>>>>=20 > >>>>=20 > >>>>=20 > >>=20 > >>=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 --=-HgVgEp8kkLntwbAJ/EA0 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) iEYEABECAAYFAk1uLW4ACgkQNdy6TdFwT2emIACcCkCWUWvyS8C6syBDJu1eZc+B HVQAn3AqfkyjhrUjJa+7U7tJWgyj+N+6 =m+3/ -----END PGP SIGNATURE----- --=-HgVgEp8kkLntwbAJ/EA0-- From hesham@elevatemobile.com Wed Mar 2 06:27: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 981FE3A6817 for ; Wed, 2 Mar 2011 06:27:42 -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 UDP5MuKJwMsM for ; Wed, 2 Mar 2011 06:27:41 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 761723A6813 for ; Wed, 2 Mar 2011 06:27:40 -0800 (PST) Received: from [60.240.140.118] (helo=[192.168.0.2]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1Pun2Z-0004xS-OJ; Thu, 03 Mar 2011 01:28:38 +1100 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 03 Mar 2011 01:28:29 +1100 From: Hesham Soliman To: Message-ID: Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvY5hlgeCnD7U9Kf02Z1tpcmG6Ssw== In-Reply-To: <1299066222.5356.17.camel@acorde.it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-User: hesham@elevatemobile.com 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: Wed, 02 Mar 2011 14:27:42 -0000 On 2/03/11 10:43 PM, "Carlos Jes=FAs Bernardos Cano" wrote: > On Wed, 2011-03-02 at 10:46 +1100, Hesham Soliman wrote: >>=20 >>=20 >> On 2/03/11 6:30 AM, "Carlos Jes=FAs Bernardos Cano" wrot= e: >>=20 >>> Hi Hesham, >>>=20 >>> On Tue, 2011-03-01 at 23:18 +1100, Hesham Soliman wrote: >>>>>=20 >>>>> Well, I see quite potential for PMIPv6 over WLAN, why do you think th= ere >>>>> would not be any serious WLAN deployment with PMIPv6? >>>>=20 >>>> =3D> Because of the nature of the links, a router doesn't always know wh= o's >>>> attached. As you said earlier you make the MN send an RS, which is not >>>> required in IPv6. Also the address allocation is a mess and sharing th= e >>>> link >>>=20 >>> PMIPv6 does not force any specific mechanism on how the MAG detects the >>> attachment of a MN. My experience with WLAN is quite OK so far, never >>> had a problem and it's quite easy to implement the AP trigger and the >>> ptp-to-ptp emulation on WLAN. >>=20 >> =3D> Quiet easy? I think you must have a special WLAN in your lab :) >> I don't think so, if you think it's easy I think you've missed a lot of >> issues. See my points above and please respond specifically. >=20 > - MN attachment detection: software on the AP that monitors the > association table (most drivers provide that feature). =3D> How does the AP tell the MAG that a new host has attached? Is this documented in a standard somewhere? If there is a specific L2 mechanism for this then I guess you are relying on L2-specific hints, but I'm curious to know what they are. >=20 > - Point-to-point emulation: MAG send the RA to the unicast link-local > address of the MN or it sends it multicast in IPv6 but addressed to the > L2 address of the MN only. >=20 > - We use L2 address as MN-ID (just for the sake of simplicity) =3D> Are you expecting the host (we're not talking about MNs obviously) to send that MN-ID in a ND packet? I assume you're not. >> =3D> If you think you can do flow mobility without MN involvement then goo= d >> luck with that. I'm starting to think that people on this list are in de= nial >> and it doesn't matter how many arguments are not being responded to, >> everyone comes back and says "it's doable". I think we're going to have = to >> leave this to the AD's because we're not making any progress. >=20 > Well, I've seen prototypes of flow mobility working, with the only > artifact of the logical interface (or the weak host model) in the > terminal. So I say "it's doable" because I've done it or I've seen it > done. =3D> Of course it's doable in a prototype. We're talking about deploying it i= n a real fault tolerant system though, it's a different story. >> =3D> Again, you're backing out of your points mentioned earlier :) Please >> respond to how you will make it work. >=20 > We have a draft summarizing how solutions that I've seen working > operate. =3D> ok, I hope you answer the fundament questions about knowing the link state and the interface availability, congestion ...etc in that draft. Because they're the things that you don't know without checking with the host and you need them to do flow mobility. Hesham >=20 > Carlos >=20 >>=20 >> Hesham >>=20 >>>=20 >>> Carlos >>>=20 >>>>=20 >>>> Hesham >>>>=20 >>>>>=20 >>>>> Carlos >>>>>=20 >>>>>>=20 >>>>>> Thanks, >>>>>> Hesham >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Carlos >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Hesham >>>>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>=20 >>>>=20 >>=20 >>=20 From cjbc@it.uc3m.es Wed Mar 2 07:53: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 17EE33A6810 for ; Wed, 2 Mar 2011 07:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.561 X-Spam-Level: X-Spam-Status: No, score=-5.561 tagged_above=-999 required=5 tests=[AWL=0.138, 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 MebVjvWruxqm for ; Wed, 2 Mar 2011 07:53:21 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 61A073A67E1 for ; Wed, 2 Mar 2011 07:53:21 -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 smtp01.uc3m.es (Postfix) with ESMTP id 562F4BDE5FC; Wed, 2 Mar 2011 16:54:26 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Hesham Soliman In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-ENt1DVdnuPoMzmyC0wwz" Organization: Universidad Carlos III de Madrid Date: Wed, 02 Mar 2011 16:55:52 +0100 Message-ID: <1299081352.5356.36.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-17988.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: Wed, 02 Mar 2011 15:53:23 -0000 --=-ENt1DVdnuPoMzmyC0wwz Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Hesham, On Thu, 2011-03-03 at 01:28 +1100, Hesham Soliman wrote: >=20 >=20 > On 2/03/11 10:43 PM, "Carlos Jes=FAs Bernardos Cano" wr= ote: >=20 > > On Wed, 2011-03-02 at 10:46 +1100, Hesham Soliman wrote: > >>=20 > >>=20 > >> On 2/03/11 6:30 AM, "Carlos Jes=FAs Bernardos Cano" = wrote: > >>=20 > >>> Hi Hesham, > >>>=20 > >>> On Tue, 2011-03-01 at 23:18 +1100, Hesham Soliman wrote: > >>>>>=20 > >>>>> Well, I see quite potential for PMIPv6 over WLAN, why do you think = there > >>>>> would not be any serious WLAN deployment with PMIPv6? > >>>>=20 > >>>> =3D> Because of the nature of the links, a router doesn't always kno= w who's > >>>> attached. As you said earlier you make the MN send an RS, which is n= ot > >>>> required in IPv6. Also the address allocation is a mess and sharing = the > >>>> link > >>>=20 > >>> PMIPv6 does not force any specific mechanism on how the MAG detects t= he > >>> attachment of a MN. My experience with WLAN is quite OK so far, never > >>> had a problem and it's quite easy to implement the AP trigger and the > >>> ptp-to-ptp emulation on WLAN. > >>=20 > >> =3D> Quiet easy? I think you must have a special WLAN in your lab :) > >> I don't think so, if you think it's easy I think you've missed a lot o= f > >> issues. See my points above and please respond specifically. > >=20 > > - MN attachment detection: software on the AP that monitors the > > association table (most drivers provide that feature). >=20 > =3D> How does the AP tell the MAG that a new host has attached? Is this > documented in a standard somewhere? If there is a specific L2 mechanism f= or > this then I guess you are relying on L2-specific hints, but I'm curious t= o > know what they are. The AP detects that a host has attached looking at its association table. If the AP is collocated with the MAG, the AP can just use local communication to inform the MAG. If they are different boxes, you can use whatever kind of signaling channel between the AP and the MAG (in our prototype we just use UDP messages). This is compliant with RFC5213, with does not enforce any particular mechanism to detect MN attachment. >=20 > >=20 > > - Point-to-point emulation: MAG send the RA to the unicast link-local > > address of the MN or it sends it multicast in IPv6 but addressed to the > > L2 address of the MN only. > >=20 > > - We use L2 address as MN-ID (just for the sake of simplicity) >=20 > =3D> Are you expecting the host (we're not talking about MNs obviously) t= o > send that MN-ID in a ND packet? I assume you're not. No. In our scenario, the L2 address of the node appears in the association table of the AP and we use it as MN-ID. Alternatively, we could have a table mapping L2 addresses with MN-IDs or other possible approaches. >=20 > >> =3D> If you think you can do flow mobility without MN involvement then= good > >> luck with that. I'm starting to think that people on this list are in = denial > >> and it doesn't matter how many arguments are not being responded to, > >> everyone comes back and says "it's doable". I think we're going to hav= e to > >> leave this to the AD's because we're not making any progress. > >=20 > > Well, I've seen prototypes of flow mobility working, with the only > > artifact of the logical interface (or the weak host model) in the > > terminal. So I say "it's doable" because I've done it or I've seen it > > done. >=20 > =3D> Of course it's doable in a prototype. We're talking about deploying = it in > a real fault tolerant system though, it's a different story. Well, I just wanted to make the point that we talk about things that are working fine without many implementation effort and that we think can work properly in a real system without major efforts. >=20 > >> =3D> Again, you're backing out of your points mentioned earlier :) Ple= ase > >> respond to how you will make it work. > >=20 > > We have a draft summarizing how solutions that I've seen working > > operate. >=20 > =3D> ok, I hope you answer the fundament questions about knowing the link > state and the interface availability, congestion ...etc in that draft. > Because they're the things that you don't know without checking with the > host and you need them to do flow mobility. Of course there are many things that could be enhanced and adjusted based on the system where the solution is implemented. Most of them can be left up to the particular system (just as RFC5213 does for many key functions), as long as we come up with a solution that is interoperable and that do not pose strong requirements (such as particular L2 signaling) on the MN. Carlos >=20 > Hesham >=20 > >=20 > > Carlos > >=20 > >>=20 > >> Hesham > >>=20 > >>>=20 > >>> Carlos > >>>=20 > >>>>=20 > >>>> Hesham > >>>>=20 > >>>>>=20 > >>>>> Carlos > >>>>>=20 > >>>>>>=20 > >>>>>> Thanks, > >>>>>> Hesham > >>>>>>=20 > >>>>>>=20 > >>>>>>>=20 > >>>>>>> Carlos > >>>>>>>=20 > >>>>>>>>=20 > >>>>>>>> Hesham > >>>>>>>>=20 > >>>>>>>>=20 > >>>>>>=20 > >>>>>>=20 > >>>>=20 > >>>>=20 > >>=20 > >>=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 --=-ENt1DVdnuPoMzmyC0wwz 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) iEYEABECAAYFAk1uaIgACgkQNdy6TdFwT2eNewCaAlRGt8/7c+4nHZ3x7hUEq6rv inIAoNHWpD6RKQQ+p/tJ7bqu9ovDRXRN =3dM1 -----END PGP SIGNATURE----- --=-ENt1DVdnuPoMzmyC0wwz-- From sgundave@cisco.com Wed Mar 2 08:14: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 EB1883A6818 for ; Wed, 2 Mar 2011 08:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.085 X-Spam-Level: X-Spam-Status: No, score=-10.085 tagged_above=-999 required=5 tests=[AWL=0.514, 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 mUd-ZQVJMmbC for ; Wed, 2 Mar 2011 08:14:02 -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 3E24F3A6831 for ; Wed, 2 Mar 2011 08:14:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=1536; q=dns/txt; s=iport; t=1299082508; x=1300292108; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=NB2+PkqOK1T3HCp4cPSnhuoOMekneqstBzQ9WSbYwTQ=; b=XIwMZac5l6yn+xFvXd3Lg5Ef7AqKmkoJpvbZaPjpiVbjvHE2OuyI/lRN NP5dhwXTcd/NVEW12hZm/b5w95jXchUNfICM75cxCKc74DwMSBPRi7xQI LKecjhR8oApgj8vNHxRWVzo3SNcy3u7rPp+m4aoMuUDrg20LCnh+PSoPi A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAGAEr8bU2rR7Ht/2dsb2JhbACYQI4YdKF3m3KFYQSFF4cPg0Y X-IronPort-AV: E=Sophos;i="4.62,253,1297036800"; d="scan'208";a="337848542" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 02 Mar 2011 16:15:08 +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 p22GF8YP013810; Wed, 2 Mar 2011 16:15:08 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, 2 Mar 2011 08:15:08 -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 Mar 2011 16:15:07 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Wed, 02 Mar 2011 08:16:29 -0800 From: Sri Gundavelli To: Message-ID: Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvY9S/B5S6+KcfWc06ZigfmSsHpjA== In-Reply-To: <1299065667.5356.9.camel@acorde.it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 02 Mar 2011 16:15:08.0224 (UTC) FILETIME=[FF9C3C00:01CBD8F4] 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: Wed, 02 Mar 2011 16:14:03 -0000 > I'm talking about a legacu IPv6 host. If I install Mobile IPv6 in that > Linux stack, don't worry, the MIPv6 client takes care of configuring a > CoA (sending an RS if no RA is received). >=20 Hi Carlos: (Still keeping the discussion context to this one comment). - I assume MIPv6 stack is on top of IP stack, not the other way around - If IP stack does not detect movement detection across L3 links (in the absence of any other hints about same L3 link, in the forms essid or other hints), how does the MIPv6 stack which is relying on the stack/kernel events, decide to force an RA ? What is the hint ? How come ND/DHCP does no= t realize the same need to send an RS ? Is MIPv6 stack so smart ? - Assuming there is no MIPv6 stack on the host, an host moves across access links, it will never do an RS and will keep using the address from the previous link. So, the basic IPv6 connectivity is broken. This is a bug, no= t a protocol gap. PS: I heard about this RS problems 5 years back, when most WLAN drivers wer= e not handling IPv6 correctly. I'm pretty sure all the WLAN drivers have fixe= d those problems now. You may want to replace your buggy NIC card driver :) Regards Sri On 3/2/11 3:34 AM, "Carlos Jes=FAs Bernardos Cano" wrote: >=20 > I'm talking about a legacu IPv6 host. If I install Mobile IPv6 in that > Linux stack, don't worry, the MIPv6 client takes care of configuring a > CoA (sending an RS if no RA is received). >=20 > Carlos >=20 > From cjbc@it.uc3m.es Wed Mar 2 08:46: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 8B01E3A6849 for ; Wed, 2 Mar 2011 08:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.57 X-Spam-Level: X-Spam-Status: No, score=-5.57 tagged_above=-999 required=5 tests=[AWL=0.129, 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 KN73IPQzjdKm for ; Wed, 2 Mar 2011 08:46:57 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id DA2DA3A684E for ; Wed, 2 Mar 2011 08:46:56 -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 2628387B03F; Wed, 2 Mar 2011 17:48:01 +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="=-R+NcoZBk6ag95lZ5L/SM" Organization: Universidad Carlos III de Madrid Date: Wed, 02 Mar 2011 17:49:26 +0100 Message-ID: <1299084566.5356.41.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-17988.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: Wed, 02 Mar 2011 16:46:58 -0000 --=-R+NcoZBk6ag95lZ5L/SM Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Sri, On Wed, 2011-03-02 at 08:16 -0800, Sri Gundavelli wrote: > > I'm talking about a legacu IPv6 host. If I install Mobile IPv6 in that > > Linux stack, don't worry, the MIPv6 client takes care of configuring a > > CoA (sending an RS if no RA is received). > >=20 >=20 > Hi Carlos: >=20 > (Still keeping the discussion context to this one comment). >=20 > - I assume MIPv6 stack is on top of IP stack, not the other way around Well, i reality MIPv6 is part of IPv6, not really sits on top. >=20 > - If IP stack does not detect movement detection across L3 links (in the > absence of any other hints about same L3 link, in the forms essid or othe= r > hints), how does the MIPv6 stack which is relying on the stack/kernel > events, decide to force an RA ? What is the hint ? How come ND/DHCP does = not > realize the same need to send an RS ? Is MIPv6 stack so smart ? The implementations that I'm familiar with do the following: - They wait for an unsolicited RA - If no unsolicited RA is received in a time interval equal to 2 times the frequency of RAs (there is information about that on the RAs), the MN sends an RS. >=20 > - Assuming there is no MIPv6 stack on the host, an host moves across acce= ss > links, it will never do an RS and will keep using the address from the > previous link. So, the basic IPv6 connectivity is broken. This is a bug, = not > a protocol gap. With WLAN and Linux, that's the behavior. I guess developers understood that two APs with the same ESSID belongs to the same ESS, and therefore the same IP subnet. That actually is correct and cannot be cataloged as "bug". >=20 > PS: I heard about this RS problems 5 years back, when most WLAN drivers w= ere > not handling IPv6 correctly. I'm pretty sure all the WLAN drivers have fi= xed > those problems now. You may want to replace your buggy NIC card driver :) It's not a buggy NIC card driver. You may say a buggy OS, but I honestly will not call Linux "buggy" (or at least buggier than many others that are out there). Carlos >=20 >=20 >=20 > Regards > Sri >=20 >=20 >=20 > On 3/2/11 3:34 AM, "Carlos Jes=FAs Bernardos Cano" wrot= e: >=20 > >=20 > > I'm talking about a legacu IPv6 host. If I install Mobile IPv6 in that > > Linux stack, don't worry, the MIPv6 client takes care of configuring a > > CoA (sending an RS if no RA is received). > >=20 > > Carlos > >=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+NcoZBk6ag95lZ5L/SM 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) iEYEABECAAYFAk1udRYACgkQNdy6TdFwT2cHUACfbJK/QmAPfZUIFBjR3jNe1cON sT0AnRjhVOUju9hwZ8TOIpJovu2mWrTX =2vf/ -----END PGP SIGNATURE----- --=-R+NcoZBk6ag95lZ5L/SM-- From Basavaraj.Patil@nokia.com Wed Mar 2 08:52: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 CA98F3A67B8 for ; Wed, 2 Mar 2011 08:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=-0.368, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 lOiqFt9iQPXL for ; Wed, 2 Mar 2011 08:52:31 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 7395C3A67B3 for ; Wed, 2 Mar 2011 08:52:31 -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 p22GrZQV028550; Wed, 2 Mar 2011 18:53:35 +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, 2 Mar 2011 18:53:28 +0200 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 2 Mar 2011 17:53:28 +0100 Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.127]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0270.002; Wed, 2 Mar 2011 17:53:27 +0100 From: To: , Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvTH7hRFKVN0Kr67UiTaBIlg8gywgAejl2AAAHvnYAAAaltAAAAevCAAA8x8gAAE1N8AAADW1qAAANRXoAAAMIDgAADjsKAAAfFm4AAHfplgAABZ90AAAgHUYAAAEM0AACbGJiAAAdu4YAAEPkHAAAFGCYAAABJUQAAAC5+AAAMpgUAAAGZ74AAAQgyAAAAGx8AAABFcAAAIRsJgAAJ2ZSAAAEmmAAAHNINcA== Date: Wed, 2 Mar 2011 16:53:26 +0000 Message-ID: <97683F8C138FB243AAC90CEFB48ABF1509267582@008-AM1MPN1-004.mgdnok.nokia.com> References: <1299084566.5356.41.camel@acorde.it.uc3m.es> In-Reply-To: <1299084566.5356.41.camel@acorde.it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.64.197.89] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Mar 2011 16:53:28.0566 (UTC) FILETIME=[5AB89160:01CBD8FA] X-Nokia-AV: Clean Cc: netext@ietf.org, JuanCarlos.Zuniga@interdigital.com 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, 02 Mar 2011 16:52:33 -0000 Folks, Is this discussion about how MIP6 works even relevant in the context of the= flow mobility discussion? There are other questions and concerns that have been raised which I would = advise the authors to focus on. If you need to understand how movement detection in MIP6 works, please refe= r to Sec 11.5 of RFC3775.=20 -Raj -----Original Message----- From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of= ext Carlos Jes=FAs Bernardos Cano Sent: Wednesday, March 02, 2011 10:49 AM To: Sri Gundavelli Cc: netext@ietf.org; Zuniga, Juan Carlos Subject: Re: [netext] Flow Mobility discussion - way forward? Hi Sri, On Wed, 2011-03-02 at 08:16 -0800, Sri Gundavelli wrote: > > I'm talking about a legacu IPv6 host. If I install Mobile IPv6 in=20 > > that Linux stack, don't worry, the MIPv6 client takes care of=20 > > configuring a CoA (sending an RS if no RA is received). > >=20 >=20 > Hi Carlos: >=20 > (Still keeping the discussion context to this one comment). >=20 > - I assume MIPv6 stack is on top of IP stack, not the other way around Well, i reality MIPv6 is part of IPv6, not really sits on top. >=20 > - If IP stack does not detect movement detection across L3 links (in=20 > the absence of any other hints about same L3 link, in the forms essid=20 > or other hints), how does the MIPv6 stack which is relying on the=20 > stack/kernel events, decide to force an RA ? What is the hint ? How=20 > come ND/DHCP does not realize the same need to send an RS ? Is MIPv6 stac= k so smart ? The implementations that I'm familiar with do the following: - They wait for an unsolicited RA - If no unsolicited RA is received in a time interval equal to 2 times the = frequency of RAs (there is information about that on the RAs), the MN sends= an RS. >=20 > - Assuming there is no MIPv6 stack on the host, an host moves across=20 > access links, it will never do an RS and will keep using the address=20 > from the previous link. So, the basic IPv6 connectivity is broken.=20 > This is a bug, not a protocol gap. With WLAN and Linux, that's the behavior. I guess developers understood tha= t two APs with the same ESSID belongs to the same ESS, and therefore the sa= me IP subnet. That actually is correct and cannot be cataloged as "bug". >=20 > PS: I heard about this RS problems 5 years back, when most WLAN=20 > drivers were not handling IPv6 correctly. I'm pretty sure all the WLAN=20 > drivers have fixed those problems now. You may want to replace your=20 > buggy NIC card driver :) It's not a buggy NIC card driver. You may say a buggy OS, but I honestly wi= ll not call Linux "buggy" (or at least buggier than many others that are ou= t there). Carlos >=20 >=20 >=20 > Regards > Sri >=20 >=20 >=20 > On 3/2/11 3:34 AM, "Carlos Jes=FAs Bernardos Cano" wrot= e: >=20 > >=20 > > I'm talking about a legacu IPv6 host. If I install Mobile IPv6 in=20 > > that Linux stack, don't worry, the MIPv6 client takes care of=20 > > configuring a CoA (sending an RS if no RA is received). > >=20 > > Carlos > >=20 > > >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 From Basavaraj.Patil@nokia.com Wed Mar 2 08:55: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 880643A67B3 for ; Wed, 2 Mar 2011 08:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.504 X-Spam-Level: X-Spam-Status: No, score=-101.504 tagged_above=-999 required=5 tests=[AWL=-1.206, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_AVOID=2.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 4C--b17eIeYm for ; Wed, 2 Mar 2011 08:55:49 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 7CAFA3A682C for ; Wed, 2 Mar 2011 08:55:49 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p22Gun4a031443; Wed, 2 Mar 2011 18:56:54 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Mar 2011 18:56:45 +0200 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 2 Mar 2011 17:56:45 +0100 Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.127]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0270.002; Wed, 2 Mar 2011 17:56:44 +0100 From: To: Thread-Topic: Update on flow mobility feature following discussion with ADs Thread-Index: AcvYfcH3kduI+mBDSeKdLeONYvXCHw== Date: Wed, 2 Mar 2011 16:56:44 +0000 Message-ID: <97683F8C138FB243AAC90CEFB48ABF150926759B@008-AM1MPN1-004.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {A1DDC361-27B1-4C22-B822-CD6F551A214A} x-cr-hashedpuzzle: BlXF CA31 Djfz D9Z3 EkqL GIY5 Gaqg Iwbg LNE6 LhcO Nj2l RuQy SwKm WFMd X6Ii ZrKI; 2; agBhAHIAaQAuAGEAcgBrAGsAbwBAAHAAaQB1AGgAYQAuAG4AZQB0ADsAbgBlAHQAZQB4AHQAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {A1DDC361-27B1-4C22-B822-CD6F551A214A}; YgBhAHMAYQB2AGEAcgBhAGoALgBwAGEAdABpAGwAQABuAG8AawBpAGEALgBjAG8AbQA=; Wed, 02 Mar 2011 02:01:34 GMT; VQBwAGQAYQB0AGUAIABvAG4AIABmAGwAbwB3ACAAbQBvAGIAaQBsAGkAdAB5ACAAZgBlAGEAdAB1AHIAZQAgAGYAbwBsAGwAbwB3AGkAbgBnACAAZABpAHMAYwB1AHMAcwBpAG8AbgAgAHcAaQB0AGgAIABBAEQAcwA= x-originating-ip: [173.64.197.89] Content-Type: multipart/alternative; boundary="_000_97683F8C138FB243AAC90CEFB48ABF150926759B008AM1MPN1004mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 02 Mar 2011 16:56:45.0144 (UTC) FILETIME=[CFE3FD80:01CBD8FA] X-Nokia-AV: Clean Subject: [netext] Update on flow mobility feature following discussion with ADs X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for 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 Mar 2011 16:55:50 -0000 --_000_97683F8C138FB243AAC90CEFB48ABF150926759B008AM1MPN1004mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just wanted to provide an update regarding the ongoing work on flow mobility for PMIP6 and my discussion with our ADs (Jari and Ralph) on March 1st: I have apprised our ADs about the state of the ongoing discussion on flow mobility. One of the concerns about the ongoing work on flow mobility was related to the logical interface feature. Flow mobility depends on the existence of a logical interface on the host. The WG has not addressed the concerns related to the logical interface I-D, that were raised at the previous WG meetings. Emphasised that we should get the logical interface spec done soon since it is a fundamental dependency for flow mobility. Regarding the current scope of the flow mobility work and the I-D which is now in consensus call, there are a few issues that need to be resolved. A few points below: 1. Flow mobility in the context of Proxy MIP6 is not analogous to the solution that has been developed for host based MIP6. The featureset and capabilities developed in Netext does not have to mirror, parallel or be equivalent to that of RFCs 6088/9. 2. There is no plan or expectation that there would be a way for the MN/host to do signaling related to flow mobility with a MAG at layer 3. Layer 2 is an option but obviously this requires such enhancements to be done in other SDOs. The preference is to develop a flow mobility solution that works with policies and signaling that is network centric (i.e MAG/LMA entities). 3. One of the major concerns raised on the mailing list is related to how flow mobility would work when an MN attaches to a wifi access and the LMA switches a flow(s) to the MAG serving the MN via that wifi. The MN has no way of indicating to the LMA if the wifi access is congested or for the MAG to indicate to the LMA about the state of the MNs attachment to the AP. Packets forwarded by the LMA to the MN via the wifi-MAG could be sent into a void. Without a solution for the above scenario, flow mobility would not be robust. Some clear answers are needed here. One option is that flow mobility for PMIP6 is applicable only in those access networks wherein the access network elements are aware of the state of the MNs connection and congestion state. The MAG can use this information to signal to an LMA attachment state and potentially cause flows to be switched to an alternative MAG. It may be okay to have specific statements about the limitations of flow mobility for PMIP6 documented as a sort of disclaimer. Other options? 4. The WG is free to extend the PMIP6 signaling between MAG/LMA to accomplish flow mobility. 5. And lastly the question about who is the customer for this work at this time is irrelevant. We have had this discussion during the chartering phase and there is no reason to revisit it. If I have missed any other significant (show-stopper) concern regarding the flow mobility feature, please do raise them. -Raj --_000_97683F8C138FB243AAC90CEFB48ABF150926759B008AM1MPN1004mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Just wanted to provide an update regarding the ongoi= ng work on flow

mobility for PMIP6 and my discussion with our ADs (J= ari and Ralph) on

March 1st:

 

I have apprised our ADs about the state of the ongoi= ng discussion on

flow mobility. One of the concerns about the ongoing= work on flow

mobility was related to the logical interface featur= e. Flow mobility

depends on the existence of a logical interface on t= he host. The WG

has not addressed the concerns related to the logica= l interface I-D,

that were raised at the previous WG meetings. Emphas= ised that we

should get the logical interface spec done soon sinc= e it is a

fundamental dependency for flow mobility.

 

Regarding the current scope of the flow mobility wor= k and the I-D

which is now in consensus call, there are a few issu= es that need to be

resolved. A few points below:

 

1. Flow mobility in the context of Proxy MIP6 is not= analogous to the

   solution that has been developed for ho= st based MIP6. The

   featureset and capabilities developed i= n Netext does not have to

   mirror, parallel or be equivalent to th= at of RFCs 6088/9.

 

2. There is no plan or expectation that there would = be a way for the

   MN/host to do signaling related to flow= mobility with a MAG at

   layer 3. Layer 2 is an option but obvio= usly this requires such

   enhancements to be done in other SDOs. = The preference is to develop

   a flow mobility solution that works wit= h policies and signaling

   that is network centric (i.e MAG/LMA en= tities).

 

3. One of the major concerns raised on the mailing l= ist is related to

   how flow mobility would work when an MN= attaches to a wifi access

   and the LMA switches a flow(s) to the M= AG serving the MN via that

   wifi. The MN has no way of indicating t= o the LMA if the wifi access

   is congested or for the MAG to indicate= to the LMA about the state

   of the MNs attachment to the AP. Packet= s forwarded by the LMA to

   the MN via the wifi-MAG could be sent i= nto a void.

   Without a solution for the above scenar= io, flow mobility would not

   be robust. Some clear answers are neede= d here.

 

   One option is that flow mobility for PM= IP6 is applicable only in

   those access networks wherein the acces= s network elements are aware

   of the state of the MNs connection and = congestion state. The MAG

   can use this information to signal to a= n LMA attachment state and

   potentially cause flows to be switched = to an alternative MAG. It

   may be okay to have specific statements= about the limitations of

   flow mobility for PMIP6 documented as a= sort of disclaimer.

  

   Other options?

 

4. The WG is free to extend the PMIP6 signaling betw= een MAG/LMA to

   accomplish flow mobility.

 

5. And lastly the question about who is the customer= for this work at

   this time is irrelevant. We have had th= is discussion during the

   chartering phase and there is no reason= to revisit it.

 

If I have missed any other significant (show-stopper= ) concern

regarding the flow mobility feature, please do raise= them.

 

-Raj

--_000_97683F8C138FB243AAC90CEFB48ABF150926759B008AM1MPN1004mg_-- From Basavaraj.Patil@nokia.com Wed Mar 2 09:03: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 DD1F73A6855 for ; Wed, 2 Mar 2011 09:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.463 X-Spam-Level: X-Spam-Status: No, score=-101.463 tagged_above=-999 required=5 tests=[AWL=-1.165, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_AVOID=2.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 QB9ZBUaoSz5B for ; Wed, 2 Mar 2011 09:03:03 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id C63143A6774 for ; Wed, 2 Mar 2011 09:03:03 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p22H48t4007630; Wed, 2 Mar 2011 19:04:09 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Mar 2011 19:04:03 +0200 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 2 Mar 2011 18:04:02 +0100 Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.127]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0270.002; Wed, 2 Mar 2011 18:04:01 +0100 From: To: Thread-Topic: Update on flow mobility following discussion with ADs Thread-Index: AcvYfuevlCz6SlKTRRGiPCBHi+Kqag== Date: Wed, 2 Mar 2011 17:04:01 +0000 Message-ID: <97683F8C138FB243AAC90CEFB48ABF15092675D6@008-AM1MPN1-004.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {E99E9FF0-6869-4C1A-912F-608CED28129F} x-cr-hashedpuzzle: BiZg CIsb ESVX Foxf GTwG HKHU JAns Lk2e MpI0 P4Vr QB2Q RPxZ UL4r VW18 XHR3 XJE2; 2; agBhAHIAaQAuAGEAcgBrAGsAbwBAAHAAaQB1AGgAYQAuAG4AZQB0ADsAbgBlAHQAZQB4AHQAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {E99E9FF0-6869-4C1A-912F-608CED28129F}; YgBhAHMAYQB2AGEAcgBhAGoALgBwAGEAdABpAGwAQABuAG8AawBpAGEALgBjAG8AbQA=; Wed, 02 Mar 2011 02:09:47 GMT; VQBwAGQAYQB0AGUAIABvAG4AIABmAGwAbwB3ACAAbQBvAGIAaQBsAGkAdAB5ACAAZgBvAGwAbABvAHcAaQBuAGcAIABkAGkAcwBjAHUAcwBzAGkAbwBuACAAdwBpAHQAaAAgAEEARABzAA== x-originating-ip: [173.64.197.89] Content-Type: multipart/alternative; boundary="_000_97683F8C138FB243AAC90CEFB48ABF15092675D6008AM1MPN1004mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 02 Mar 2011 17:04:03.0479 (UTC) FILETIME=[D5289A70:01CBD8FB] X-Nokia-AV: Clean Subject: [netext] Update on flow mobility following discussion with ADs X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for 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 Mar 2011 17:03:05 -0000 --_000_97683F8C138FB243AAC90CEFB48ABF15092675D6008AM1MPN1004mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just wanted to provide an update regarding the ongoing work on flow mobility for PMIP6 and my discussion with our ADs (Jari and Ralph) on March 1st: I have apprised our ADs about the state of the ongoing discussion on flow mobility. One of the concerns about the ongoing work on flow mobility was related to the logical interface feature. Flow mobility depends on the existence of a logical interface on the host. The WG has not addressed the concerns related to the logical interface I-D, that were raised at the previous WG meetings. Emphasised that we should get the logical interface spec done soon since it is a fundamental dependency for flow mobility. Regarding the current scope of the flow mobility work and the I-D which is now in consensus call, there are a few issues that need to be resolved. A few points below: 1. Flow mobility in the context of Proxy MIP6 is not analogous to the solution that has been developed for host based MIP6. The featureset and capabilities developed in Netext does not have to mirror, parallel or be equivalent to that of RFCs 6088/9. 2. There is no plan or expectation that there would be a way for the MN/host to do signaling related to flow mobility with a MAG at layer 3. Layer 2 is an option but obviously this requires such enhancements to be done in other SDOs. The preference is to develop a flow mobility solution that works with policies and signaling that is network centric (i.e MAG/LMA entities). 3. One of the major concerns raised on the mailing list is related to how flow mobility would work when an MN attaches to a wifi access and the LMA switches a flow(s) to the MAG serving the MN via that wifi. The MN has no way of indicating to the LMA if the wifi access is congested or for the MAG to indicate to the LMA about the state of the MNs attachment to the AP. Packets forwarded by the LMA to the MN via the wifi-MAG could be sent into a void. Without a solution for the above scenario, flow mobility would not be robust. Some clear answers are needed here. One option is that flow mobility for PMIP6 is applicable only in those access networks wherein the access network elements are aware of the state of the MNs connection and congestion state. The MAG can use this information to signal to an LMA attachment state and potentially cause flows to be switched to an alternative MAG. It may be okay to have specific statements about the limitations of flow mobility for PMIP6 documented as a sort of disclaimer. Other options? 4. The WG is free to extend the PMIP6 signaling between MAG/LMA to accomplish flow mobility. 5. And lastly the question about who is the customer for this work at this time is irrelevant. We have had this discussion during the chartering phase and there is no reason to revisit it. If I have missed any other significant (show-stopper) concern regarding the flow mobility feature, please do raise them. -Raj --_000_97683F8C138FB243AAC90CEFB48ABF15092675D6008AM1MPN1004mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Just wanted to provide an update regarding the ongoi= ng work on flow

mobility for PMIP6 and my discussion with our ADs (J= ari and Ralph) on

March 1st:

 

I have apprised our ADs about the state of the ongoi= ng discussion on

flow mobility. One of the concerns about the ongoing= work on flow

mobility was related to the logical interface featur= e. Flow mobility

depends on the existence of a logical interface on t= he host. The WG

has not addressed the concerns related to the logica= l interface I-D,

that were raised at the previous WG meetings. Emphas= ised that we

should get the logical interface spec done soon sinc= e it is a

fundamental dependency for flow mobility.

 

Regarding the current scope of the flow mobility wor= k and the I-D

which is now in consensus call, there are a few issu= es that need to be

resolved. A few points below:

 

1. Flow mobility in the context of Proxy MIP6 is not= analogous to the

   solution that has been developed for ho= st based MIP6. The

   featureset and capabilities developed i= n Netext does not have to

   mirror, parallel or be equivalent to th= at of RFCs 6088/9.

 

2. There is no plan or expectation that there would = be a way for the

   MN/host to do signaling related to flow= mobility with a MAG at

   layer 3. Layer 2 is an option but obvio= usly this requires such

   enhancements to be done in other SDOs. = The preference is to develop

   a flow mobility solution that works wit= h policies and signaling

   that is network centric (i.e MAG/LMA en= tities).

 

3. One of the major concerns raised on the mailing l= ist is related to

   how flow mobility would work when an MN= attaches to a wifi access

   and the LMA switches a flow(s) to the M= AG serving the MN via that

   wifi. The MN has no way of indicating t= o the LMA if the wifi access

   is congested or for the MAG to indicate= to the LMA about the state

   of the MNs attachment to the AP. Packet= s forwarded by the LMA to

   the MN via the wifi-MAG could be sent i= nto a void.

   Without a solution for the above scenar= io, flow mobility would not

   be robust. Some clear answers are neede= d here.

 

   One option is that flow mobility for PM= IP6 is applicable only in

   those access networks wherein the acces= s network elements are aware

   of the state of the MNs connection and = congestion state. The MAG

   can use this information to signal to a= n LMA attachment state and

   potentially cause flows to be switched = to an alternative MAG. It

   may be okay to have specific statements= about the limitations of

   flow mobility for PMIP6 documented as a= sort of disclaimer.

  

   Other options?

 

4. The WG is free to extend the PMIP6 signaling betw= een MAG/LMA to

   accomplish flow mobility.

 

5. And lastly the question about who is the customer= for this work at

   this time is irrelevant. We have had th= is discussion during the

   chartering phase and there is no reason= to revisit it.

 

If I have missed any other significant (show-stopper= ) concern

regarding the flow mobility feature, please do raise= them.

 

-Raj

--_000_97683F8C138FB243AAC90CEFB48ABF15092675D6008AM1MPN1004mg_-- From sgundave@cisco.com Wed Mar 2 09:11: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 53A0E3A6867 for ; Wed, 2 Mar 2011 09:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.427 X-Spam-Level: X-Spam-Status: No, score=-9.427 tagged_above=-999 required=5 tests=[AWL=-0.224, 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 EdEYp-CySt2t for ; Wed, 2 Mar 2011 09:11:13 -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 9EF513A6848 for ; Wed, 2 Mar 2011 09:11:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=3649; q=dns/txt; s=iport; t=1299085940; x=1300295540; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=zMIY7cb+UeDaW/qXWW3mArC2ZgNl7p+3nQR+in4WcDo=; b=kVL0unu9oGe1e4+Y/Qo0z/d+Ubzx++CXwYUG3XdcZYvNa9aHSCPJ3IX+ Gx3qIQyB4NT5jS07kyy3xUfZGiOGYEjGEhiMbomZeiSyoJbqCZPBSnZua +/MRaTNYHqSY61fBjeNvbxXQNXD1vq55w6q78jZzjyh6KmHxVKRYXBvfF o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAKcJbk2rR7Ht/2dsb2JhbACYAY15X3SiLpt4hWEEhReHD4NG X-IronPort-AV: E=Sophos;i="4.62,254,1297036800"; d="scan'208";a="268095402" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 02 Mar 2011 17:12:16 +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 p22HCF6C011371; Wed, 2 Mar 2011 17:12:16 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 Mar 2011 09:12:16 -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 Mar 2011 17:12:15 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Wed, 02 Mar 2011 09:13:36 -0800 From: Sri Gundavelli To: , Message-ID: Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvTH7hRFKVN0Kr67UiTaBIlg8gywgAejl2AAAHvnYAAAaltAAAAevCAAA8x8gAAE1N8AAADW1qAAANRXoAAAMIDgAADjsKAAAfFm4AAHfplgAABZ90AAAgHUYAAAEM0AACbGJiAAAdu4YAAEPkHAAAFGCYAAABJUQAAAC5+AAAMpgUAAAGZ74AAAQgyAAAAGx8AAABFcAAAIRsJgAAJ2ZSAAAEmmAAAHNINcAAZ4Ypm In-Reply-To: <97683F8C138FB243AAC90CEFB48ABF1509267582@008-AM1MPN1-004.mgdnok.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 02 Mar 2011 17:12:16.0334 (UTC) FILETIME=[FAEC4EE0:01CBD8FC] Cc: netext@ietf.org, JuanCarlos.Zuniga@interdigital.com 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, 02 Mar 2011 17:11:23 -0000 Yes, it is relevant in the context of the current discussion. If we are not on the same page, as how a simple IP host behaves across L3 roams, we are not going to converge on what new events L2 or L3 we need. So, this is relevant. Thanks Sri On 3/2/11 8:53 AM, "Basavaraj.Patil@nokia.com" wrote: >=20 > Folks, >=20 > Is this discussion about how MIP6 works even relevant in the context of t= he > flow mobility discussion? > There are other questions and concerns that have been raised which I woul= d > advise the authors to focus on. >=20 > If you need to understand how movement detection in MIP6 works, please re= fer > to Sec 11.5 of RFC3775. >=20 > -Raj >=20 > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of > ext Carlos Jes=FAs Bernardos Cano > Sent: Wednesday, March 02, 2011 10:49 AM > To: Sri Gundavelli > Cc: netext@ietf.org; Zuniga, Juan Carlos > Subject: Re: [netext] Flow Mobility discussion - way forward? >=20 > Hi Sri, >=20 > On Wed, 2011-03-02 at 08:16 -0800, Sri Gundavelli wrote: >>> I'm talking about a legacu IPv6 host. If I install Mobile IPv6 in >>> that Linux stack, don't worry, the MIPv6 client takes care of >>> configuring a CoA (sending an RS if no RA is received). >>>=20 >>=20 >> Hi Carlos: >>=20 >> (Still keeping the discussion context to this one comment). >>=20 >> - I assume MIPv6 stack is on top of IP stack, not the other way around >=20 > Well, i reality MIPv6 is part of IPv6, not really sits on top. >=20 >>=20 >> - If IP stack does not detect movement detection across L3 links (in >> the absence of any other hints about same L3 link, in the forms essid >> or other hints), how does the MIPv6 stack which is relying on the >> stack/kernel events, decide to force an RA ? What is the hint ? How >> come ND/DHCP does not realize the same need to send an RS ? Is MIPv6 sta= ck so >> smart ? >=20 > The implementations that I'm familiar with do the following: >=20 > - They wait for an unsolicited RA > - If no unsolicited RA is received in a time interval equal to 2 times th= e > frequency of RAs (there is information about that on the RAs), the MN sen= ds an > RS. >=20 >>=20 >> - Assuming there is no MIPv6 stack on the host, an host moves across >> access links, it will never do an RS and will keep using the address >> from the previous link. So, the basic IPv6 connectivity is broken. >> This is a bug, not a protocol gap. >=20 > With WLAN and Linux, that's the behavior. I guess developers understood t= hat > two APs with the same ESSID belongs to the same ESS, and therefore the sa= me IP > subnet. That actually is correct and cannot be cataloged as "bug". >=20 >>=20 >> PS: I heard about this RS problems 5 years back, when most WLAN >> drivers were not handling IPv6 correctly. I'm pretty sure all the WLAN >> drivers have fixed those problems now. You may want to replace your >> buggy NIC card driver :) >=20 > It's not a buggy NIC card driver. You may say a buggy OS, but I honestly = will > not call Linux "buggy" (or at least buggier than many others that are out > there). >=20 > Carlos >=20 >>=20 >>=20 >>=20 >> Regards >> Sri >>=20 >>=20 >>=20 >> On 3/2/11 3:34 AM, "Carlos Jes=FAs Bernardos Cano" wrote= : >>=20 >>>=20 >>> I'm talking about a legacu IPv6 host. If I install Mobile IPv6 in >>> that Linux stack, don't worry, the MIPv6 client takes care of >>> configuring a CoA (sending an RS if no RA is received). >>>=20 >>> Carlos >>>=20 >>>=20 >>=20 From sgundave@cisco.com Wed Mar 2 09:14: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 07DE63A681D for ; Wed, 2 Mar 2011 09:14:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.26 X-Spam-Level: X-Spam-Status: No, score=-8.26 tagged_above=-999 required=5 tests=[AWL=-1.358, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_AVOID=2.3, 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 8WlqRPClr1lz for ; Wed, 2 Mar 2011 09:14:42 -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 99AF73A67E1 for ; Wed, 2 Mar 2011 09:14:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=9259; q=dns/txt; s=iport; t=1299086149; x=1300295749; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=GxjoTrovoy2VL7bz3XEqwDsSjtJ6BdcMhYTlRClwJiU=; b=XQXyZYe17/X0ACtPlplwud1GrEypZEO9U6vHn6ZyoDkUN/qHC0JgpDvx Nd0OyGpEMm1I4I5YCNuDwk5pZh8DKwznMvGQqzN+C/ejERcwZHWpI7N7B 8/UmptjEa/ymfi3llYAIIHgL2XqUupjBVv8Qudcxvq0yhFChxfPWh5V+p Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAKcJbk2rR7H+/2dsb2JhbACCTqMsX3SiLpt4hWEEhReHD4NG X-IronPort-AV: E=Sophos;i="4.62,254,1297036800"; d="scan'208,217";a="268098211" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 02 Mar 2011 17:15:48 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p22HFmT5000271; Wed, 2 Mar 2011 17:15:48 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); Wed, 2 Mar 2011 09:15:48 -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 Mar 2011 17:15:48 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Wed, 02 Mar 2011 09:17:09 -0800 From: Sri Gundavelli To: , Message-ID: Thread-Topic: [netext] Update on flow mobility following discussion with ADs Thread-Index: AcvYfuevlCz6SlKTRRGiPCBHi+KqagAfsGtZ In-Reply-To: <97683F8C138FB243AAC90CEFB48ABF15092675D6@008-AM1MPN1-004.mgdnok.nokia.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3381902230_26830988" X-OriginalArrivalTime: 02 Mar 2011 17:15:48.0634 (UTC) FILETIME=[7976B7A0:01CBD8FD] Subject: Re: [netext] Update on flow mobility following discussion with ADs X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for 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 Mar 2011 17:14: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_3381902230_26830988 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Raj: Thanks for the meeting minutes. Can you comment on the AD inputs w.r.t bundling every flow mobility feature in a single spec, vs multiple document deliverables. Specifically, the scope of the current work and if it must be in a single document. Thanks Sri On 3/2/11 9:04 AM, "Basavaraj.Patil@nokia.com" wrote: > > Just wanted to provide an update regarding the ongoing work on flow > mobility for PMIP6 and my discussion with our ADs (Jari and Ralph) on > March 1st: > > I have apprised our ADs about the state of the ongoing discussion on > flow mobility. One of the concerns about the ongoing work on flow > mobility was related to the logical interface feature. Flow mobility > depends on the existence of a logical interface on the host. The WG > has not addressed the concerns related to the logical interface I-D, > that were raised at the previous WG meetings. Emphasised that we > should get the logical interface spec done soon since it is a > fundamental dependency for flow mobility. > > Regarding the current scope of the flow mobility work and the I-D > which is now in consensus call, there are a few issues that need to be > resolved. A few points below: > > 1. Flow mobility in the context of Proxy MIP6 is not analogous to the > solution that has been developed for host based MIP6. The > featureset and capabilities developed in Netext does not have to > mirror, parallel or be equivalent to that of RFCs 6088/9. > > 2. There is no plan or expectation that there would be a way for the > MN/host to do signaling related to flow mobility with a MAG at > layer 3. Layer 2 is an option but obviously this requires such > enhancements to be done in other SDOs. The preference is to develop > a flow mobility solution that works with policies and signaling > that is network centric (i.e MAG/LMA entities). > > 3. One of the major concerns raised on the mailing list is related to > how flow mobility would work when an MN attaches to a wifi access > and the LMA switches a flow(s) to the MAG serving the MN via that > wifi. The MN has no way of indicating to the LMA if the wifi access > is congested or for the MAG to indicate to the LMA about the state > of the MNs attachment to the AP. Packets forwarded by the LMA to > the MN via the wifi-MAG could be sent into a void. > Without a solution for the above scenario, flow mobility would not > be robust. Some clear answers are needed here. > > One option is that flow mobility for PMIP6 is applicable only in > those access networks wherein the access network elements are aware > of the state of the MNs connection and congestion state. The MAG > can use this information to signal to an LMA attachment state and > potentially cause flows to be switched to an alternative MAG. It > may be okay to have specific statements about the limitations of > flow mobility for PMIP6 documented as a sort of disclaimer. > > Other options? > > 4. The WG is free to extend the PMIP6 signaling between MAG/LMA to > accomplish flow mobility. > > 5. And lastly the question about who is the customer for this work at > this time is irrelevant. We have had this discussion during the > chartering phase and there is no reason to revisit it. > > If I have missed any other significant (show-stopper) concern > regarding the flow mobility feature, please do raise them. > > -Raj > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --B_3381902230_26830988 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [netext] Update on flow mobility following discussion with ADs</= TITLE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt= '>Raj:<BR> <BR> Thanks for the meeting minutes.<BR> <BR> Can you comment on the AD inputs w.r.t bundling every flow mobility feature= in a single spec, vs multiple document deliverables. Specifically, the scop= e of the current work and if it must be in a single document.<BR> <BR> <BR> Thanks<BR> Sri<BR> <BR> <BR> On 3/2/11 9:04 AM, "<a href=3D"Basavaraj.Patil@nokia.com">Basavaraj.Pati= l@nokia.com</a>" <<a href=3D"Basavaraj.Patil@nokia.com">Basavaraj.Pati= l@nokia.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><= SPAN STYLE=3D'font-size:11pt'> <BR> Just wanted to provide an update regarding the ongoing work on flow<BR> mobility for PMIP6 and my discussion with our ADs (Jari and Ralph) on<BR> March 1st:<BR>  <BR> I have apprised our ADs about the state of the ongoing discussion on<BR> flow mobility. One of the concerns about the ongoing work on flow<BR> mobility was related to the logical interface feature. Flow mobility<BR> depends on the existence of a logical interface on the host. The WG<BR> has not addressed the concerns related to the logical interface I-D,<BR> that were raised at the previous WG meetings. Emphasised that we<BR> should get the logical interface spec done soon since it is a<BR> fundamental dependency for flow mobility. <BR>  <BR> Regarding the current scope of the flow mobility work and the I-D<BR> which is now in consensus call, there are a few issues that need to be<BR> resolved. A few points below:<BR>  <BR> 1. Flow mobility in the context of Proxy MIP6 is not analogous to the<BR>    solution that has been developed for host based MIP6. The= <BR>    featureset and capabilities developed in Netext does not = have to<BR>    mirror, parallel or be equivalent to that of RFCs 6088/9.= <BR>  <BR> 2. There is no plan or expectation that there would be a way for the<BR>    MN/host to do signaling related to flow mobility with a M= AG at<BR>    layer 3. Layer 2 is an option but obviously this requires= such<BR>    enhancements to be done in other SDOs. The preference is = to develop<BR>    a flow mobility solution that works with policies and sig= naling<BR>    that is network centric (i.e MAG/LMA entities). <BR>  <BR> 3. One of the major concerns raised on the mailing list is related to<BR>    how flow mobility would work when an MN attaches to a wif= i access<BR>    and the LMA switches a flow(s) to the MAG serving the MN = via that<BR>    wifi. The MN has no way of indicating to the LMA if the w= ifi access<BR>    is congested or for the MAG to indicate to the LMA about = the state<BR>    of the MNs attachment to the AP. Packets forwarded by the= LMA to<BR>    the MN via the wifi-MAG could be sent into a void. <BR>    Without a solution for the above scenario, flow mobility = would not<BR>    be robust. Some clear answers are needed here.<BR>  <BR>    One option is that flow mobility for PMIP6 is applicable = only in<BR>    those access networks wherein the access network elements= are aware<BR>    of the state of the MNs connection and congestion state. = The MAG<BR>    can use this information to signal to an LMA attachment s= tate and<BR>    potentially cause flows to be switched to an alternative = MAG. It<BR>    may be okay to have specific statements about the limitat= ions of<BR>    flow mobility for PMIP6 documented as a sort of disclaime= r. <BR>    <BR>    Other options?<BR>  <BR> 4. The WG is free to extend the PMIP6 signaling between MAG/LMA to<BR>    accomplish flow mobility. <BR>  <BR> 5. And lastly the question about who is the customer for this work at<BR>    this time is irrelevant. We have had this discussion duri= ng the<BR>    chartering phase and there is no reason to revisit it. <B= R>  <BR> If I have missed any other significant (show-stopper) concern<BR> regarding the flow mobility feature, please do raise them.<BR>  <BR> -Raj<BR> <BR> <HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"></SPAN></FONT><FONT SIZE=3D"2"><FONT FA= CE=3D"Consolas, Courier New, Courier"><SPAN STYLE=3D'font-size:10pt'>___________= ____________________________________<BR> netext mailing list<BR> <a href=3D"netext@ietf.org">netext@ietf.org</a><BR> <a href=3D"https://www.ietf.org/mailman/listinfo/netext">https://www.ietf.org= /mailman/listinfo/netext</a><BR> </SPAN></FONT></FONT></BLOCKQUOTE> </BODY> </HTML> --B_3381902230_26830988-- From Basavaraj.Patil@nokia.com Wed Mar 2 10:02:46 2011 Return-Path: <Basavaraj.Patil@nokia.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A75DA3A67FD for <netext@core3.amsl.com>; Wed, 2 Mar 2011 10:02:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.426 X-Spam-Level: X-Spam-Status: No, score=-101.426 tagged_above=-999 required=5 tests=[AWL=-1.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_AVOID=2.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 FOc4OdWK6BKf for <netext@core3.amsl.com>; Wed, 2 Mar 2011 10:02:45 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 268DB3A67FB for <netext@ietf.org>; Wed, 2 Mar 2011 10:02:45 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p22I3SOv030208; Wed, 2 Mar 2011 20:03:44 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Mar 2011 20:03:27 +0200 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 2 Mar 2011 19:03:26 +0100 Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.127]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0270.002; Wed, 2 Mar 2011 19:03:25 +0100 From: <Basavaraj.Patil@nokia.com> To: <sgundave@cisco.com>, <netext@ietf.org> Thread-Topic: [netext] Update on flow mobility following discussion with ADs Thread-Index: AcvYfuevlCz6SlKTRRGiPCBHi+KqagAfsGtZAB2IlLA= Date: Wed, 2 Mar 2011 18:03:24 +0000 Message-ID: <97683F8C138FB243AAC90CEFB48ABF150926763D@008-AM1MPN1-004.mgdnok.nokia.com> References: <97683F8C138FB243AAC90CEFB48ABF15092675D6@008-AM1MPN1-004.mgdnok.nokia.com> <C993BB95.119F6%sgundave@cisco.com> In-Reply-To: <C993BB95.119F6%sgundave@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.64.197.89] Content-Type: multipart/alternative; boundary="_000_97683F8C138FB243AAC90CEFB48ABF150926763D008AM1MPN1004mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 02 Mar 2011 18:03:27.0134 (UTC) FILETIME=[214333E0:01CBD904] X-Nokia-AV: Clean Subject: Re: [netext] Update on flow mobility following discussion with ADs X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 02 Mar 2011 18:02:46 -0000 --_000_97683F8C138FB243AAC90CEFB48ABF150926763D008AM1MPN1004mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sri, We did not discuss the idea of single vs multiple documents for flow mobili= ty. As you can see from the ongoing discussion, there are concerns about the vi= ability of flow mobility as a feature in a PMIP6 deployment. These need to be addressed before we can even consider whether a single doc= ument or multiple documents are needed to specify the feature. -Raj From: ext Sri Gundavelli [mailto:sgundave@cisco.com] Sent: Wednesday, March 02, 2011 11:17 AM To: Patil Basavaraj (Nokia-MS/Dallas); netext@ietf.org Cc: Jari Arkko Subject: Re: [netext] Update on flow mobility following discussion with ADs Raj: Thanks for the meeting minutes. Can you comment on the AD inputs w.r.t bundling every flow mobility feature= in a single spec, vs multiple document deliverables. Specifically, the sco= pe of the current work and if it must be in a single document. Thanks Sri On 3/2/11 9:04 AM, "Basavaraj.Patil@nokia.com" <Basavaraj.Patil@nokia.com> = wrote: Just wanted to provide an update regarding the ongoing work on flow mobility for PMIP6 and my discussion with our ADs (Jari and Ralph) on March 1st: I have apprised our ADs about the state of the ongoing discussion on flow mobility. One of the concerns about the ongoing work on flow mobility was related to the logical interface feature. Flow mobility depends on the existence of a logical interface on the host. The WG has not addressed the concerns related to the logical interface I-D, that were raised at the previous WG meetings. Emphasised that we should get the logical interface spec done soon since it is a fundamental dependency for flow mobility. Regarding the current scope of the flow mobility work and the I-D which is now in consensus call, there are a few issues that need to be resolved. A few points below: 1. Flow mobility in the context of Proxy MIP6 is not analogous to the solution that has been developed for host based MIP6. The featureset and capabilities developed in Netext does not have to mirror, parallel or be equivalent to that of RFCs 6088/9. 2. There is no plan or expectation that there would be a way for the MN/host to do signaling related to flow mobility with a MAG at layer 3. Layer 2 is an option but obviously this requires such enhancements to be done in other SDOs. The preference is to develop a flow mobility solution that works with policies and signaling that is network centric (i.e MAG/LMA entities). 3. One of the major concerns raised on the mailing list is related to how flow mobility would work when an MN attaches to a wifi access and the LMA switches a flow(s) to the MAG serving the MN via that wifi. The MN has no way of indicating to the LMA if the wifi access is congested or for the MAG to indicate to the LMA about the state of the MNs attachment to the AP. Packets forwarded by the LMA to the MN via the wifi-MAG could be sent into a void. Without a solution for the above scenario, flow mobility would not be robust. Some clear answers are needed here. One option is that flow mobility for PMIP6 is applicable only in those access networks wherein the access network elements are aware of the state of the MNs connection and congestion state. The MAG can use this information to signal to an LMA attachment state and potentially cause flows to be switched to an alternative MAG. It may be okay to have specific statements about the limitations of flow mobility for PMIP6 documented as a sort of disclaimer. Other options? 4. The WG is free to extend the PMIP6 signaling between MAG/LMA to accomplish flow mobility. 5. And lastly the question about who is the customer for this work at this time is irrelevant. We have had this discussion during the chartering phase and there is no reason to revisit it. If I have missed any other significant (show-stopper) concern regarding the flow mobility feature, please do raise them. -Raj ________________________________ _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext --_000_97683F8C138FB243AAC90CEFB48ABF150926763D008AM1MPN1004mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--> <title>Re: [netext] Update on flow mobility following discussion with ADs</= title> <style> <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --> </style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D">Hi Sri,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D">We did not discuss the idea of single vs multiple documents = for flow mobility.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D">As you can see from the ongoing discussion, there are concer= ns about the viability of flow mobility as a feature in a PMIP6 deployment.= <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D">These need to be addressed before we can even consider wheth= er a single document or multiple documents are needed to specify the featur= e.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D">-Raj<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D"><o:p> </o:p></span></p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> ext Sri = Gundavelli [mailto:sgundave@cisco.com] <br> <b>Sent:</b> Wednesday, March 02, 2011 11:17 AM<br> <b>To:</b> Patil Basavaraj (Nokia-MS/Dallas); netext@ietf.org<br> <b>Cc:</b> Jari Arkko<br> <b>Subject:</b> Re: [netext] Update on flow mobility following discussion w= ith ADs<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"font-s= ize:11.0pt; font-family:"Calibri","sans-serif"">Raj:<br> <br> Thanks for the meeting minutes.<br> <br> Can you comment on the AD inputs w.r.t bundling every flow mobility feature= in a single spec, vs multiple document deliverables. Specifically, the sco= pe of the current work and if it must be in a single document.<br> <br> <br> Thanks<br> Sri<br> <br> <br> On 3/2/11 9:04 AM, "<a href=3D"Basavaraj.Patil@nokia.com">Basavaraj.Pa= til@nokia.com</a>" <<a href=3D"Basavaraj.Patil@nokia.com">Basavaraj= .Patil@nokia.com</a>> wrote:</span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"font-s= ize:11.0pt; font-family:"Calibri","sans-serif""><br> Just wanted to provide an update regarding the ongoing work on flow<br> mobility for PMIP6 and my discussion with our ADs (Jari and Ralph) on<br> March 1st:<br>  <br> I have apprised our ADs about the state of the ongoing discussion on<br> flow mobility. One of the concerns about the ongoing work on flow<br> mobility was related to the logical interface feature. Flow mobility<br> depends on the existence of a logical interface on the host. The WG<br> has not addressed the concerns related to the logical interface I-D,<br> that were raised at the previous WG meetings. Emphasised that we<br> should get the logical interface spec done soon since it is a<br> fundamental dependency for flow mobility. <br>  <br> Regarding the current scope of the flow mobility work and the I-D<br> which is now in consensus call, there are a few issues that need to be<br> resolved. A few points below:<br>  <br> 1. Flow mobility in the context of Proxy MIP6 is not analogous to the<br>    solution that has been developed for host based MIP6. The= <br>    featureset and capabilities developed in Netext does not = have to<br>    mirror, parallel or be equivalent to that of RFCs 6088/9.= <br>  <br> 2. There is no plan or expectation that there would be a way for the<br>    MN/host to do signaling related to flow mobility with a M= AG at<br>    layer 3. Layer 2 is an option but obviously this requires= such<br>    enhancements to be done in other SDOs. The preference is = to develop<br>    a flow mobility solution that works with policies and sig= naling<br>    that is network centric (i.e MAG/LMA entities). <br>  <br> 3. One of the major concerns raised on the mailing list is related to<br>    how flow mobility would work when an MN attaches to a wif= i access<br>    and the LMA switches a flow(s) to the MAG serving the MN = via that<br>    wifi. The MN has no way of indicating to the LMA if the w= ifi access<br>    is congested or for the MAG to indicate to the LMA about = the state<br>    of the MNs attachment to the AP. Packets forwarded by the= LMA to<br>    the MN via the wifi-MAG could be sent into a void. <br>    Without a solution for the above scenario, flow mobility = would not<br>    be robust. Some clear answers are needed here.<br>  <br>    One option is that flow mobility for PMIP6 is applicable = only in<br>    those access networks wherein the access network elements= are aware<br>    of the state of the MNs connection and congestion state. = The MAG<br>    can use this information to signal to an LMA attachment s= tate and<br>    potentially cause flows to be switched to an alternative = MAG. It<br>    may be okay to have specific statements about the limitat= ions of<br>    flow mobility for PMIP6 documented as a sort of disclaime= r. <br>    <br>    Other options?<br>  <br> 4. The WG is free to extend the PMIP6 signaling between MAG/LMA to<br>    accomplish flow mobility. <br>  <br> 5. And lastly the question about who is the customer for this work at<br>    this time is irrelevant. We have had this discussion duri= ng the<br>    chartering phase and there is no reason to revisit it. <b= r>  <br> If I have missed any other significant (show-stopper) concern<br> regarding the flow mobility feature, please do raise them.<br>  <br> -Raj<o:p></o:p></span></p> <div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><span= style=3D"font-size:11.0pt;font-family:"Calibri","sans-serif= ""> <hr size=3D"3" width=3D"95%" align=3D"center"> </span></div> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:Consolas= ">_______________________________________________<br> netext mailing list<br> <a href=3D"netext@ietf.org">netext@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/netext">https://www.ietf.o= rg/mailman/listinfo/netext</a></span><o:p></o:p></p> </div> </body> </html> --_000_97683F8C138FB243AAC90CEFB48ABF150926763D008AM1MPN1004mg_-- From jari.arkko@piuha.net Wed Mar 2 11:48:21 2011 Return-Path: <jari.arkko@piuha.net> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9AC43A6863 for <netext@core3.amsl.com>; Wed, 2 Mar 2011 11:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 N9aIxTO06gHz for <netext@core3.amsl.com>; Wed, 2 Mar 2011 11:48:21 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 022763A6831 for <netext@ietf.org>; Wed, 2 Mar 2011 11:48:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E89BB2CC32; Wed, 2 Mar 2011 21:49:25 +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 YvGv3scZzE9g; Wed, 2 Mar 2011 21:49:25 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 2BA6D2CC28; Wed, 2 Mar 2011 21:49:25 +0200 (EET) Message-ID: <4D6E9F44.7060202@piuha.net> Date: Wed, 02 Mar 2011 21:49:24 +0200 From: Jari Arkko <jari.arkko@piuha.net> User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: sgundave@cisco.com References: <97683F8C138FB243AAC90CEFB48ABF15092675D6@008-AM1MPN1-004.mgdnok.nokia.com> <C993BB95.119F6%sgundave@cisco.com> <97683F8C138FB243AAC90CEFB48ABF150926763D@008-AM1MPN1-004.mgdnok.nokia.com> In-Reply-To: <97683F8C138FB243AAC90CEFB48ABF150926763D@008-AM1MPN1-004.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Update on flow mobility following discussion with ADs X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 02 Mar 2011 19:48:22 -0000 Sri: What Basavaraj said. I don't think the number of specifications is a big concern either now or later. Split the documents the way you like. Lets discuss functionality, robustness, assumptions instead -- those are important. (And of course, splitting to different specifications should not be misused to hide a technical omission or a problem.) Jari From sfaccin@rim.com Wed Mar 2 11:50:31 2011 Return-Path: <sfaccin@rim.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 684193A6882 for <netext@core3.amsl.com>; Wed, 2 Mar 2011 11:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.098 X-Spam-Level: ** X-Spam-Status: No, score=2.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MANGLED_AVOID=2.3, 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 ERxz5rd8N8R4 for <netext@core3.amsl.com>; Wed, 2 Mar 2011 11:50:24 -0800 (PST) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by core3.amsl.com (Postfix) with ESMTP id D7CC73A687D for <netext@ietf.org>; Wed, 2 Mar 2011 11:50:23 -0800 (PST) X-AuditID: 0a41282f-b7cccae000000e40-34-4d6e9fbd77a0 Received: from XCH139CNC.rim.net (xch139cnc.rim.net [10.65.10.235]) by mhs060cnc.rim.net (SBG) with SMTP id F5.A6.03648.DBF9E6D4; Wed, 2 Mar 2011 19:51:25 +0000 (GMT) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH139CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Mar 2011 14:51:29 -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_01CBD913.37A62596" Date: Wed, 2 Mar 2011 13:51:25 -0600 Message-ID: <680854867F7FD04BB9B06EB8ACA8D5AC06325163@XCH02DFW.rim.net> In-Reply-To: <97683F8C138FB243AAC90CEFB48ABF15092675D6@008-AM1MPN1-004.mgdnok.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Update on flow mobility following discussion with ADs Thread-Index: AcvYfuevlCz6SlKTRRGiPCBHi+KqagAjGQMQ References: <97683F8C138FB243AAC90CEFB48ABF15092675D6@008-AM1MPN1-004.mgdnok.nokia.com> From: "Stefano Faccin" <sfaccin@rim.com> To: <Basavaraj.Patil@nokia.com>, <netext@ietf.org> X-OriginalArrivalTime: 02 Mar 2011 19:51:29.0228 (UTC) FILETIME=[38E440C0:01CBD913] X-Brightmail-Tracker: AAAAAQAAAZE= Subject: Re: [netext] Update on flow mobility following discussion with ADs X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 02 Mar 2011 19:50:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBD913.37A62596 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CBD913.37A62596" ------_=_NextPart_002_01CBD913.37A62596 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Raj, Thanks for the notes. There is one aspect that concerns me, and is related to : "2. There is no plan or expectation that there would be a way for the MN/host to do signaling related to flow mobility with a MAG at layer 3. Layer 2 is an option but obviously this requires such enhancements to be done in other SDOs. The preference is to develop a flow mobility solution that works with policies and signaling that is network centric (i.e MAG/LMA entities). " Personally I am concerned about this. What is the usefulness in netext providing an "alternative" IP flow mobility solution that provides only a subset of the functionality of a host-based solution. Deployments of such so called alternative would provide a limited services with respect to deployments of the host-based solution. Why would anybody want to step back in time? As for: "The preference is to develop a flow mobility solution that works with policies and signaling that is network centric (i.e MAG/LMA entities). " I can understand the point, but I have a question. As an example, 3GPP (that can be one of the potential customers and that we can surely not disregard) has been very keen in indicating that the user (whether it be the actual human being using the MN or e.g. the enterprise owning the MN) has priority wrt the policies defined by the operator. This is because in several scenarios the user may have preference for certain accesses (e.g. the enterprise WiFi) that are not provided by the operator for certain services (e.g. access to the enterprise resources). In such case, 3GPP has recognized the need to allow the user to have precedence. If the solution designed by netext is based solely on network policies and decisions, I am afraid we would have a solution that does not allow valid scenarios that have been identified by one of the potential customers for 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 <outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D41 49BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E000000 6F1BEA0000/www.rim.com> ; www.blackberry.com <outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D41 49BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E000000 6F1BEA0000/www.blackberry.com> <http://www.blackberry.com/> P Consider the environment before printing. From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Basavaraj.Patil@nokia.com Sent: Wednesday, March 02, 2011 9:04 AM To: netext@ietf.org Subject: [netext] Update on flow mobility following discussion with ADs Just wanted to provide an update regarding the ongoing work on flow mobility for PMIP6 and my discussion with our ADs (Jari and Ralph) on March 1st: I have apprised our ADs about the state of the ongoing discussion on flow mobility. One of the concerns about the ongoing work on flow mobility was related to the logical interface feature. Flow mobility depends on the existence of a logical interface on the host. The WG has not addressed the concerns related to the logical interface I-D, that were raised at the previous WG meetings. Emphasised that we should get the logical interface spec done soon since it is a fundamental dependency for flow mobility. Regarding the current scope of the flow mobility work and the I-D which is now in consensus call, there are a few issues that need to be resolved. A few points below: 1. Flow mobility in the context of Proxy MIP6 is not analogous to the solution that has been developed for host based MIP6. The featureset and capabilities developed in Netext does not have to mirror, parallel or be equivalent to that of RFCs 6088/9. 2. There is no plan or expectation that there would be a way for the MN/host to do signaling related to flow mobility with a MAG at layer 3. Layer 2 is an option but obviously this requires such enhancements to be done in other SDOs. The preference is to develop a flow mobility solution that works with policies and signaling that is network centric (i.e MAG/LMA entities). 3. One of the major concerns raised on the mailing list is related to how flow mobility would work when an MN attaches to a wifi access and the LMA switches a flow(s) to the MAG serving the MN via that wifi. The MN has no way of indicating to the LMA if the wifi access is congested or for the MAG to indicate to the LMA about the state of the MNs attachment to the AP. Packets forwarded by the LMA to the MN via the wifi-MAG could be sent into a void. Without a solution for the above scenario, flow mobility would not be robust. Some clear answers are needed here. One option is that flow mobility for PMIP6 is applicable only in those access networks wherein the access network elements are aware of the state of the MNs connection and congestion state. The MAG can use this information to signal to an LMA attachment state and potentially cause flows to be switched to an alternative MAG. It may be okay to have specific statements about the limitations of flow mobility for PMIP6 documented as a sort of disclaimer. Other options? 4. The WG is free to extend the PMIP6 signaling between MAG/LMA to accomplish flow mobility. 5. And lastly the question about who is the customer for this work at this time is irrelevant. We have had this discussion during the chartering phase and there is no reason to revisit it. If I have missed any other significant (show-stopper) concern regarding the flow mobility feature, please do raise them. -Raj --------------------------------------------------------------------- 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_01CBD913.37A62596 Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micro= soft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" xm= lns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-micr= osoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office:acc= ess" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"uuid:= BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsoft-com:= rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-com:offic= e:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" xmlns= :c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc=3D"u= rn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-microsoft-com:o= ffice:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" xmlns:q=3D"= http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://microsoft.com= /officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://schemas.micro= soft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/sharepoint/soap/mee= tings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" xmln= s:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=3D"http://schemas= .microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schemas.microsoft.c= om/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig= #" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc=3D"ht= tp://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://www.w3.org/2001/XML= Schema" xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/ale= rts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xmlns:sp=3D"http://sche= mas.microsoft.com/sharepoint/" xmlns:sps=3D"http://schemas.microsoft.com/sha= repoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" xmlns= :udcs=3D"http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf=3D"http://s= chemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p=3D"http://schemas.micros= oft.com/data/udc/parttopart" xmlns:wf=3D"http://schemas.microsoft.com/sharep= oint/soap/workflow/" xmlns:dsss=3D"http://schemas.microsoft.com/office/2006/= digsig-setup" xmlns:dssi=3D"http://schemas.microsoft.com/office/2006/digsig"= xmlns:mdssi=3D"http://schemas.openxmlformats.org/package/2006/digital-signa= ture" xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2= 006" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrel= s=3D"http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spw= p=3D"http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t=3D"http://sch= emas.microsoft.com/exchange/services/2006/types" xmlns:ex12m=3D"http://schem= as.microsoft.com/exchange/services/2006/messages" xmlns:pptsl=3D"http://sche= mas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl=3D"http://micros= oft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z=3D= "urn:schemas-microsoft-com:" xmlns:st=3D"" xmlns=3D"http://www.w3.org/TR= /REC-html40"><head><meta http-equiv=3DContent-Type content=3D"text/html; cha= rset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 12 (filter= ed medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style><![endif]--><style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Verdana; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Webdings; panose-1:5 3 1 2 1 5 9 6 7 3;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} span.EmailStyle17 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:windowtext;} span.EmailStyle18 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"2050" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vlin= k=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'col= or:#1F497D'>Raj,<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'co= lor:#1F497D'>Thanks for the notes. There is one aspect that concerns me, and= is related to :<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'co= lor:#1F497D'><o:p> </o:p></span></p><p class=3DMsoNormal><span style=3D= 'color:#1F497D'>“</span>2. There is no plan or expectation that there= would be a way for the<o:p></o:p></p><p class=3DMsoNormal>   MN/h= ost to do signaling related to flow mobility with a MAG at<o:p></o:p></p><p= class=3DMsoNormal>   layer 3. Layer 2 is an option but obviously= this requires such<o:p></o:p></p><p class=3DMsoNormal>   enhancem= ents to be done in other SDOs. The preference is to develop<o:p></o:p></p><p= class=3DMsoNormal>   a flow mobility solution that works with pol= icies and signaling<o:p></o:p></p><p class=3DMsoNormal>   that is= network centric (i.e MAG/LMA entities). <o:p></o:p></p><p class=3DMsoNormal= ><span style=3D'color:#1F497D'>”<o:p></o:p></span></p><p class=3DMsoNo= rmal><span style=3D'color:#1F497D'><o:p> </o:p></span></p><p class=3DMs= oNormal><span style=3D'color:#1F497D'>Personally I am concerned about this.= What is the usefulness in netext providing an “alternative” IP= flow mobility solution that provides only a subset of the functionality of= a host-based solution. Deployments of such so called alternative would prov= ide a limited services with respect to deployments of the host-based solutio= n. Why would anybody want to step back in time? <o:p></o:p></span></p><p cla= ss=3DMsoNormal><span style=3D'color:#1F497D'><o:p> </o:p></span></p><p= class=3DMsoNormal><span style=3D'color:#1F497D'>As for:<o:p></o:p></span></= p><p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p> </o:p></span= ></p><p class=3DMsoNormal><span style=3D'color:#1F497D'>“</span>The pr= eference is to develop<o:p></o:p></p><p class=3DMsoNormal>   a flo= w mobility solution that works with policies and signaling<o:p></o:p></p><p= class=3DMsoNormal>   that is network centric (i.e MAG/LMA entitie= s). <o:p></o:p></p><p class=3DMsoNormal><span style=3D'color:#1F497D'>”= ;<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'>I= can understand the point, but I have a question. As an example, 3GPP (that= can be one of the potential customers and that we can surely not disregard)= has been very keen in indicating that the user (whether it be the actual hu= man being using the MN or e.g. the enterprise owning the MN) has priority wr= t the policies defined by the operator. This is because in several scenarios= the user may have preference for certain accesses (e.g. the enterprise WiFi= ) that are not provided by the operator for certain services (e.g. access to= the enterprise resources). In such case, 3GPP has recognized the need to al= low the user to have precedence. If the solution designed by netext is based= solely on network policies and decisions, I am afraid we would have a solut= ion that does not allow valid scenarios that have been identified by one of= the potential customers for the solution.<o:p></o:p></span></p><p class=3DM= soNormal><span style=3D'color:#1F497D'><o:p> </o:p></span></p><p class= =3DMsoNormal><span style=3D'color:#1F497D'>Cheers,<o:p></o:p></span></p><div= ><table class=3DMsoNormalTable border=3D0 cellspacing=3D0 cellpadding=3D0><t= r><td style=3D'padding:0in 0in 0in 0in'><p class=3DMsoNormal><span style=3D'= color:#1F497D'>Stefano Faccin<o:p></o:p></span></p><p class=3DMsoNormal><spa= n style=3D'color:#1F497D'><o:p> </o:p></span></p><p class=3DMsoNormal><= span style=3D'color:#1F497D'>Standards Manager<o:p></o:p></span></p><p class= =3DMsoNormal><b><span style=3D'color:black'>Research In Motion Corporation</= span></b><span style=3D'color:black'> <br>5000 Riverside Drive <br>Building= 6, Brazos East, Ste. 100</span><span style=3D'color:black'><o:p></o:p></spa= n></p><p class=3DMsoNormal><span style=3D'color:black'>Irving, Texas 75039 U= SA <br>Office: (972) 910 3451  <o:p></o:p></span></p><p class=3DMsoNorm= al><span style=3D'color:black'>Internal: 820.63451<o:p></o:p></span></p><p c= lass=3DMsoNormal><span style=3D'color:black'><img width=3D14 height=3D10 id= =3D"Picture_x0020_1" src=3D"cid:image001.jpg@01CBD8C8.FC6D4730" alt=3DUntitl= ed-1>: (510) 230 8422<o:p></o:p></span></p><p class=3DMsoNormal style=3D'mar= gin-bottom:12.0pt'><span style=3D'color:#1F497D'><a href=3D"outbind://28-000= 00000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB000= 001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.rim.com" t= itle=3D"outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40= D4149BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006= F1BEA0000/www.rim.com www.rim.com"><span style=3D'color:black'>www.rim.c= om</span></a></span><span style=3D'color:black'>; </span><span style=3D'colo= r:#1F497D'><a href=3D"outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10= 700A3F06753D40D4149BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2= 313EF3E0000006F1BEA0000/www.blackberry.com" title=3D"outbind://28-0000000011= 9E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB000001B790= 8B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.blackberry.com= 0;www.blackberry.com"><span style=3D'color:black'>www.blackberry.com</span><= /a></span><span style=3D'color:black'> </span><span style=3D'color:black'><o= :p></o:p></span></p></td><td width=3D160 style=3D'width:120.0pt;padding:0in= 0in 0in 0in'></td></tr></table><p class=3DMsoNormal><a href=3D"http://www.b= lackberry.com/"><span style=3D'color:#1F497D;text-decoration:none'><img bord= er=3D0 width=3D138 height=3D62 id=3D"Picture_x0020_6" src=3D"cid:image002.pn= g@01CBD8C8.FC6D4730" alt=3D"cid:image004.png@01CB49EA.87D92140"></span></a><= span style=3D'color:#1F497D'><o:p></o:p></span></p><p class=3DMsoNormal><spa= n style=3D'color:#1F497D'><o:p> </o:p></span></p><p class=3DMsoNormal><= span style=3D'font-size:16.0pt;font-family:Webdings;color:#4F6228'>P</span><= span style=3D'font-size:14.0pt;font-family:"Verdana","sans-serif";color:#4F6= 228'> </span><span style=3D'font-size:9.0pt;color:#4F6228'>Consider the envi= ronment before printing.</span><span style=3D'color:#1F497D'><o:p></o:p></sp= an></p></div><p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p> <= /o:p></span></p><div><div style=3D'border:none;border-top:solid #B5C4DF 1.0p= t;padding:3.0pt 0in 0in 0in'><p class=3DMsoNormal><b><span style=3D'font-siz= e:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style=3D'f= ont-size:10.0pt;font-family:"Tahoma","sans-serif"'> netext-bounces@ietf.org= [mailto:netext-bounces@ietf.org] <b>On Behalf Of </b>Basavaraj.Patil@nokia.= com<br><b>Sent:</b> Wednesday, March 02, 2011 9:04 AM<br><b>To:</b> netext@i= etf.org<br><b>Subject:</b> [netext] Update on flow mobility following discus= sion with ADs<o:p></o:p></span></p></div></div><p class=3DMsoNormal><o:p>&nb= sp;</o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>= Just wanted to provide an update regarding the ongoing work on flow<o:p></o:= p></p><p class=3DMsoNormal>mobility for PMIP6 and my discussion with our ADs= (Jari and Ralph) on<o:p></o:p></p><p class=3DMsoNormal>March 1st:<o:p></o:p= ></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>I have a= pprised our ADs about the state of the ongoing discussion on<o:p></o:p></p><= p class=3DMsoNormal>flow mobility. One of the concerns about the ongoing wor= k on flow<o:p></o:p></p><p class=3DMsoNormal>mobility was related to the log= ical interface feature. Flow mobility<o:p></o:p></p><p class=3DMsoNormal>dep= ends on the existence of a logical interface on the host. The WG<o:p></o:p><= /p><p class=3DMsoNormal>has not addressed the concerns related to the logica= l interface I-D,<o:p></o:p></p><p class=3DMsoNormal>that were raised at the= previous WG meetings. Emphasised that we<o:p></o:p></p><p class=3DMsoNormal= >should get the logical interface spec done soon since it is a<o:p></o:p></p= ><p class=3DMsoNormal>fundamental dependency for flow mobility. <o:p></o:p><= /p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Regarding= the current scope of the flow mobility work and the I-D<o:p></o:p></p><p cl= ass=3DMsoNormal>which is now in consensus call, there are a few issues that= need to be<o:p></o:p></p><p class=3DMsoNormal>resolved. A few points below:= <o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNorma= l>1. Flow mobility in the context of Proxy MIP6 is not analogous to the<o:p>= </o:p></p><p class=3DMsoNormal>   solution that has been developed= for host based MIP6. The<o:p></o:p></p><p class=3DMsoNormal>   fe= atureset and capabilities developed in Netext does not have to<o:p></o:p></p= ><p class=3DMsoNormal>   mirror, parallel or be equivalent to that= of RFCs 6088/9. <o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p= class=3DMsoNormal>2. There is no plan or expectation that there would be a= way for the<o:p></o:p></p><p class=3DMsoNormal>   MN/host to do s= ignaling related to flow mobility with a MAG at<o:p></o:p></p><p class=3DMso= Normal>   layer 3. Layer 2 is an option but obviously this require= s such<o:p></o:p></p><p class=3DMsoNormal>   enhancements to be do= ne in other SDOs. The preference is to develop<o:p></o:p></p><p class=3DMsoN= ormal>   a flow mobility solution that works with policies and sig= naling<o:p></o:p></p><p class=3DMsoNormal>   that is network centr= ic (i.e MAG/LMA entities). <o:p></o:p></p><p class=3DMsoNormal><o:p> </= o:p></p><p class=3DMsoNormal>3. One of the major concerns raised on the mail= ing list is related to<o:p></o:p></p><p class=3DMsoNormal>   how f= low mobility would work when an MN attaches to a wifi access<o:p></o:p></p><= p class=3DMsoNormal>   and the LMA switches a flow(s) to the MAG s= erving the MN via that<o:p></o:p></p><p class=3DMsoNormal>   wifi.= The MN has no way of indicating to the LMA if the wifi access<o:p></o:p></p= ><p class=3DMsoNormal>   is congested or for the MAG to indicate t= o the LMA about the state<o:p></o:p></p><p class=3DMsoNormal>   of= the MNs attachment to the AP. Packets forwarded by the LMA to<o:p></o:p></p= ><p class=3DMsoNormal>   the MN via the wifi-MAG could be sent int= o a void. <o:p></o:p></p><p class=3DMsoNormal>   Without a solutio= n for the above scenario, flow mobility would not<o:p></o:p></p><p class=3DM= soNormal>   be robust. Some clear answers are needed here.<o:p></o= :p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal> =   One option is that flow mobility for PMIP6 is applicable only in<o:p>= </o:p></p><p class=3DMsoNormal>   those access networks wherein th= e access network elements are aware<o:p></o:p></p><p class=3DMsoNormal> = ;  of the state of the MNs connection and congestion state. The MAG<o:p= ></o:p></p><p class=3DMsoNormal>   can use this information to sig= nal to an LMA attachment state and<o:p></o:p></p><p class=3DMsoNormal> =   potentially cause flows to be switched to an alternative MAG. It<o:p>= </o:p></p><p class=3DMsoNormal>   may be okay to have specific sta= tements about the limitations of<o:p></o:p></p><p class=3DMsoNormal> &n= bsp; flow mobility for PMIP6 documented as a sort of disclaimer. <o:p></o:p>= </p><p class=3DMsoNormal>   <o:p></o:p></p><p class=3DMsoNormal>&n= bsp;  Other options?<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:= p></p><p class=3DMsoNormal>4. The WG is free to extend the PMIP6 signaling b= etween MAG/LMA to<o:p></o:p></p><p class=3DMsoNormal>   accomplish= flow mobility. <o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p= class=3DMsoNormal>5. And lastly the question about who is the customer for= this work at<o:p></o:p></p><p class=3DMsoNormal>   this time is i= rrelevant. We have had this discussion during the<o:p></o:p></p><p class=3DM= soNormal>   chartering phase and there is no reason to revisit it.= <o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNorm= al>If I have missed any other significant (show-stopper) concern<o:p></o:p><= /p><p class=3DMsoNormal>regarding the flow mobility feature, please do raise= them.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMs= oNormal>-Raj<o:p></o:p></p></div>-------------------------------------------= -------------------------- <br> 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. </body></html> ------_=_NextPart_002_01CBD913.37A62596-- ------_=_NextPart_001_01CBD913.37A62596 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: <image001.jpg@01CBD8C8.FC6D4730> 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_01CBD913.37A62596 Content-Type: image/png; name="image002.png" Content-Transfer-Encoding: base64 Content-ID: <image002.png@01CBD8C8.FC6D4730> 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_01CBD913.37A62596-- From sgundave@cisco.com Wed Mar 2 12:08:43 2011 Return-Path: <sgundave@cisco.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4D2A3A6831 for <netext@core3.amsl.com>; Wed, 2 Mar 2011 12:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.018 X-Spam-Level: X-Spam-Status: No, score=-10.018 tagged_above=-999 required=5 tests=[AWL=0.581, 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 0OZqvGJILYrS for <netext@core3.amsl.com>; Wed, 2 Mar 2011 12:08:43 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 034A73A6862 for <netext@ietf.org>; Wed, 2 Mar 2011 12:08:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=1154; q=dns/txt; s=iport; t=1299096589; x=1300306189; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=69fzniDzy8kpT5p3ZKUL4DkUGisYEkjIz/GJGojKqVw=; b=NEc0IYIcexE6UxXsdjECi62t0GX2Qj2UCbo0grIFsSK/t3PyJMS9XmH5 YGgR7e8JLjKrWov8tkwfWzRt+OSHbIxtDSJm4cOrW4n8/dl2S89HQU99I hYfFE+8S01MV46TP3tHLoBZ6Jj4X7leadRjESDJ4btSqwKZAGuBpklXKg s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALQybk2rRN+J/2dsb2JhbACmbnSiTpt9hWEEhReHD4NG X-IronPort-AV: E=Sophos;i="4.62,254,1297036800"; d="scan'208";a="316627920" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 02 Mar 2011 20:09:49 +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 p22K9nFa000272; Wed, 2 Mar 2011 20:09:49 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, 2 Mar 2011 12:09:49 -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 Mar 2011 20:09:49 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Wed, 02 Mar 2011 12:11:10 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: Jari Arkko <jari.arkko@piuha.net> Message-ID: <C993E45E.11A98%sgundave@cisco.com> Thread-Topic: [netext] Update on flow mobility following discussion with ADs Thread-Index: AcvZFfivoE5qZ/AUrkumPJFkMabQ7g== In-Reply-To: <4D6E9F44.7060202@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Mar 2011 20:09:49.0786 (UTC) FILETIME=[C8E013A0:01CBD915] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Update on flow mobility following discussion with ADs X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 02 Mar 2011 20:08:43 -0000 Hi Jari: Thanks for your response. Sure, technical correctness of the spec is more important than the document(s) structure management. > (And of course, splitting to different specifications should not be > misused to hide a technical omission or a problem.) On the contrary, I think we are discussing many features, mixing all the issues and without being able to differentiate between a real technical issue in the base feature, vs. a technical issue in some other requirement which is of interest to few folks. I hope and I'm certain, Basavaraj will structure the documents and put a proper context around the discussions and disagreements. Regards Sri On 3/2/11 11:49 AM, "Jari Arkko" <jari.arkko@piuha.net> wrote: > Sri: > > What Basavaraj said. I don't think the number of specifications is a big > concern either now or later. Split the documents the way you like. Lets > discuss functionality, robustness, assumptions instead -- those are > important. > > (And of course, splitting to different specifications should not be > misused to hide a technical omission or a problem.) > > Jari > From Basavaraj.Patil@nokia.com Wed Mar 2 12:31:20 2011 Return-Path: <Basavaraj.Patil@nokia.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 598983A6869 for <netext@core3.amsl.com>; Wed, 2 Mar 2011 12:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.391 X-Spam-Level: X-Spam-Status: No, score=-101.391 tagged_above=-999 required=5 tests=[AWL=-1.093, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MANGLED_AVOID=2.3, 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 yzdGnJXzspSx for <netext@core3.amsl.com>; Wed, 2 Mar 2011 12:31:16 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id E4C433A6823 for <netext@ietf.org>; Wed, 2 Mar 2011 12:31:12 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p22KVO4U025303; Wed, 2 Mar 2011 22:32:16 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Mar 2011 22:32:04 +0200 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 2 Mar 2011 21:32:03 +0100 Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.127]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0270.002; Wed, 2 Mar 2011 21:32:03 +0100 From: <Basavaraj.Patil@nokia.com> To: <sfaccin@rim.com>, <netext@ietf.org> Thread-Topic: [netext] Update on flow mobility following discussion with ADs Thread-Index: AcvYfuevlCz6SlKTRRGiPCBHi+KqagAjGQMQ//+lzYA= Date: Wed, 2 Mar 2011 20:32:02 +0000 Message-ID: <C9940198.116F1%basavaraj.patil@nokia.com> In-Reply-To: <680854867F7FD04BB9B06EB8ACA8D5AC06325163@XCH02DFW.rim.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [172.19.59.44] Content-Type: multipart/related; boundary="_005_C9940198116F1basavarajpatilnokiacom_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginalArrivalTime: 02 Mar 2011 20:32:04.0394 (UTC) FILETIME=[E45D18A0:01CBD918] X-Nokia-AV: Clean Subject: Re: [netext] Update on flow mobility following discussion with ADs X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 02 Mar 2011 20:31:20 -0000 --_005_C9940198116F1basavarajpatilnokiacom_ Content-Type: multipart/alternative; boundary="_000_C9940198116F1basavarajpatilnokiacom_" --_000_C9940198116F1basavarajpatilnokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Stefano, Inline below: From: ext Stefano Faccin <sfaccin@rim.com<mailto:sfaccin@rim.com>> Date: Wed, 2 Mar 2011 13:51:25 -0600 To: Patil Basavaraj <basavaraj.patil@nokia.com<mailto:basavaraj.patil@nokia= .com>>, Netext <netext@ietf.org<mailto:netext@ietf.org>> Subject: RE: [netext] Update on flow mobility following discussion with ADs Raj, Thanks for the notes. There is one aspect that concerns me, and is related = to : =932. There is no plan or expectation that there would be a way for the MN/host to do signaling related to flow mobility with a MAG at layer 3. Layer 2 is an option but obviously this requires such enhancements to be done in other SDOs. The preference is to develop a flow mobility solution that works with policies and signaling that is network centric (i.e MAG/LMA entities). =94 Personally I am concerned about this. What is the usefulness in netext prov= iding an =93alternative=94 IP flow mobility solution that provides only a s= ubset of the functionality of a host-based solution. Deployments of such so= called alternative would provide a limited services with respect to deploy= ments of the host-based solution. Why would anybody want to step back in ti= me? Raj> I would not consider PMIP6 based flow mobility as an alternative to th= e host based solution that is specified in RFCs 6088/9. The type of mobilit= y capability in a deployment can vary. The PMIP6 based flow mobility would = be applicable in deployments which leverage network based mobility. Whether= the functionality provided by this capability is sufficient, is a conscien= tious decision that will be made by the operator. It is a matter of choice = and what I am saying is that the scope of this work is NOT intended to prov= ide the same set of capabilities that exist in the host based flow mobility= solution. As for: =93The preference is to develop a flow mobility solution that works with policies and signaling that is network centric (i.e MAG/LMA entities). =94 I can understand the point, but I have a question. As an example, 3GPP (tha= t can be one of the potential customers and that we can surely not disregar= d) has been very keen in indicating that the user (whether it be the actual= human being using the MN or e.g. the enterprise owning the MN) has priorit= y wrt the policies defined by the operator. This is because in several scen= arios the user may have preference for certain accesses (e.g. the enterpris= e WiFi) that are not provided by the operator for certain services (e.g. ac= cess to the enterprise resources). In such case, 3GPP has recognized the ne= ed to allow the user to have precedence. If the solution designed by netext= is based solely on network policies and decisions, I am afraid we would ha= ve a solution that does not allow valid scenarios that have been identified= by one of the potential customers for the solution. Raj> A network centric flow-mobility solution may not be able to address al= l the scenarios that 3GPP is considering. But a subset of those may be deal= t with via this feature. As long as the document is clear about what is in = scope and possibly documenting some of the limitations as well, it would be= useful to specify it. There could be other types of networks that could us= e such a solution as well. -Raj 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 [Untitled-1]: (510) 230 8422 www.rim.com<outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F067= 53D40D4149BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0= 000006F1BEA0000/www.rim.com>; www.blackberry.com<outbind://28-00000000119E3= 389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB000001B7908B= 0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.blackberry.com> [cid:image004.png@01CB49EA.87D92140]<http://www.blackberry.com/> P Consider the environment before printing. From: netext-bounces@ietf.org<mailto:netext-bounces@ietf.org> [mailto:netex= t-bounces@ietf.org] On Behalf Of Basavaraj.Patil@nokia.com<mailto:Basavaraj= .Patil@nokia.com> Sent: Wednesday, March 02, 2011 9:04 AM To: netext@ietf.org<mailto:netext@ietf.org> Subject: [netext] Update on flow mobility following discussion with ADs Just wanted to provide an update regarding the ongoing work on flow mobility for PMIP6 and my discussion with our ADs (Jari and Ralph) on March 1st: I have apprised our ADs about the state of the ongoing discussion on flow mobility. One of the concerns about the ongoing work on flow mobility was related to the logical interface feature. Flow mobility depends on the existence of a logical interface on the host. The WG has not addressed the concerns related to the logical interface I-D, that were raised at the previous WG meetings. Emphasised that we should get the logical interface spec done soon since it is a fundamental dependency for flow mobility. Regarding the current scope of the flow mobility work and the I-D which is now in consensus call, there are a few issues that need to be resolved. A few points below: 1. Flow mobility in the context of Proxy MIP6 is not analogous to the solution that has been developed for host based MIP6. The featureset and capabilities developed in Netext does not have to mirror, parallel or be equivalent to that of RFCs 6088/9. 2. There is no plan or expectation that there would be a way for the MN/host to do signaling related to flow mobility with a MAG at layer 3. Layer 2 is an option but obviously this requires such enhancements to be done in other SDOs. The preference is to develop a flow mobility solution that works with policies and signaling that is network centric (i.e MAG/LMA entities). 3. One of the major concerns raised on the mailing list is related to how flow mobility would work when an MN attaches to a wifi access and the LMA switches a flow(s) to the MAG serving the MN via that wifi. The MN has no way of indicating to the LMA if the wifi access is congested or for the MAG to indicate to the LMA about the state of the MNs attachment to the AP. Packets forwarded by the LMA to the MN via the wifi-MAG could be sent into a void. Without a solution for the above scenario, flow mobility would not be robust. Some clear answers are needed here. One option is that flow mobility for PMIP6 is applicable only in those access networks wherein the access network elements are aware of the state of the MNs connection and congestion state. The MAG can use this information to signal to an LMA attachment state and potentially cause flows to be switched to an alternative MAG. It may be okay to have specific statements about the limitations of flow mobility for PMIP6 documented as a sort of disclaimer. Other options? 4. The WG is free to extend the PMIP6 signaling between MAG/LMA to accomplish flow mobility. 5. And lastly the question about who is the customer for this work at this time is irrelevant. We have had this discussion during the chartering phase and there is no reason to revisit it. If I have missed any other significant (show-stopper) concern regarding the flow mobility feature, please do raise them. -Raj --------------------------------------------------------------------- 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_C9940198116F1basavarajpatilnokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <E744D40D4CA3674DB28192A9C52B1AE4@nokia.com> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"> </head> <body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin= e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami= ly: Calibri, sans-serif; "> <div><br> </div> <div>Hi Stefano,</div> <div><br> </div> <div>Inline below:</div> <div><br> </div> <span id=3D"OLK_SRC_BODY_SECTION"> <div style=3D"font-family:Calibri; font-size:11pt; text-align:left; color:b= lack; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM:= 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;= BORDER-RIGHT: medium none; PADDING-TOP: 3pt"> <span style=3D"font-weight:bold">From: </span>ext Stefano Faccin <<a hre= f=3D"mailto:sfaccin@rim.com">sfaccin@rim.com</a>><br> <span style=3D"font-weight:bold">Date: </span>Wed, 2 Mar 2011 13:51:25 -060= 0<br> <span style=3D"font-weight:bold">To: </span>Patil Basavaraj <<a href=3D"= mailto:basavaraj.patil@nokia.com">basavaraj.patil@nokia.com</a>>, Netext= <<a href=3D"mailto:netext@ietf.org">netext@ietf.org</a>><br> <span style=3D"font-weight:bold">Subject: </span>RE: [netext] Update on flo= w mobility following discussion with ADs<br> </div> <div><br> </div> <div xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micro= soft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" x= mlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-mi= crosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office:= access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"u= uid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsoft= -com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-com= :office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet= " xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:= odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micros= oft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" x= mlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://mi= crosoft.com/officenet/conferencing" xmlns:d=3D"DAV:" xmlns:repl=3D"http://s= chemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/sharep= oint/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel/= 2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=3D= "http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://sch= emas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.or= g/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/ds= p" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://= www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sharep= oint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xm= lns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://sch= emas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XM= LSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap"= xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p= =3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http://sc= hemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://schemas= .microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.micro= soft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformats.o= rg/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlform= ats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.com/= office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/packa= ge/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpar= tpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/= types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/m= essages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideL= ibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalSer= ver/PublishedLinksService" xmlns:st=3D"" xmlns=3D"http://www.w3.org/TR/= REC-html40"> <!--[if !mso]><style>v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style><![endif]--><style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Verdana; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Webdings; panose-1:5 3 1 2 1 5 9 6 7 3;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} span.EmailStyle17 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:windowtext;} span.EmailStyle18 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"2050" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> <div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Raj,<o:p></o:p></span>= </p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Thanks for the notes. = There is one aspect that concerns me, and is related to :<o:p></o:p></span>= </p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">=93</span>2. There is = no plan or expectation that there would be a way for the<o:p></o:p></p> <p class=3D"MsoNormal">   MN/host to do signaling related to flow= mobility with a MAG at<o:p></o:p></p> <p class=3D"MsoNormal">   layer 3. Layer 2 is an option but obvio= usly this requires such<o:p></o:p></p> <p class=3D"MsoNormal">   enhancements to be done in other SDOs. = The preference is to develop<o:p></o:p></p> <p class=3D"MsoNormal">   a flow mobility solution that works wit= h policies and signaling<o:p></o:p></p> <p class=3D"MsoNormal">   that is network centric (i.e MAG/LMA en= tities). <o:p></o:p></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">=94<o:p></o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Personally I am concer= ned about this. What is the usefulness in netext providing an =93alternativ= e=94 IP flow mobility solution that provides only a subset of the functiona= lity of a host-based solution. Deployments of such so called alternative would provide a limited services with respec= t to deployments of the host-based solution. Why would anybody want to step= back in time? <o:p></o:p></span></p> </div> </div> </div> </span> <div><br> </div> <div><font class=3D"Apple-style-span" color=3D"#3400FE">Raj> I would not= consider PMIP6 based flow mobility as an alternative to the host based sol= ution that is specified in RFCs 6088/9. The type of mobility capability in = a deployment can vary. The PMIP6 based flow mobility would be applicable in deployments which leverage network ba= sed mobility. Whether the functionality provided by this capability is suff= icient, is a conscientious decision that will be made by the operator. It i= s a matter of choice and what I am saying is that the scope of this work is NOT intended to provide the sa= me set of capabilities that exist in the host based flow mobility solution.= </font></div> <span id=3D"OLK_SRC_BODY_SECTION"> <div xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micro= soft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" x= mlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-mi= crosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office:= access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"u= uid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsoft= -com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-com= :office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet= " xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:= odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micros= oft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" x= mlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://mi= crosoft.com/officenet/conferencing" xmlns:d=3D"DAV:" xmlns:repl=3D"http://s= chemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/sharep= oint/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel/= 2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=3D= "http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://sch= emas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.or= g/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/ds= p" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://= www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sharep= oint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xm= lns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://sch= emas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XM= LSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap"= xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p= =3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http://sc= hemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://schemas= .microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.micro= soft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformats.o= rg/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlform= ats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.com/= office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/packa= ge/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpar= tpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/= types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/m= essages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideL= ibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalSer= ver/PublishedLinksService" xmlns:st=3D"" xmlns=3D"http://www.w3.org/TR/= REC-html40"> <div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><font class=3D"Apple-style-span" color=3D"#1F497D"><= br> </font></p> </div> </div> </div> </span> <div><br> </div> <span id=3D"OLK_SRC_BODY_SECTION"> <div xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micro= soft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" x= mlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-mi= crosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office:= access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"u= uid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsoft= -com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-com= :office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet= " xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:= odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micros= oft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" x= mlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://mi= crosoft.com/officenet/conferencing" xmlns:d=3D"DAV:" xmlns:repl=3D"http://s= chemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/sharep= oint/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel/= 2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=3D= "http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://sch= emas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.or= g/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/ds= p" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://= www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sharep= oint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xm= lns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://sch= emas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XM= LSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap"= xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p= =3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http://sc= hemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://schemas= .microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.micro= soft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformats.o= rg/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlform= ats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.com/= office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/packa= ge/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpar= tpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/= types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/m= essages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideL= ibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalSer= ver/PublishedLinksService" xmlns:st=3D"" xmlns=3D"http://www.w3.org/TR/= REC-html40"> <div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">As for:<o:p></o:p></sp= an></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">=93</span>The preferen= ce is to develop<o:p></o:p></p> <p class=3D"MsoNormal">   a flow mobility solution that works wit= h policies and signaling<o:p></o:p></p> <p class=3D"MsoNormal">   that is network centric (i.e MAG/LMA en= tities). <o:p></o:p></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">=94<o:p></o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">I can understand the p= oint, but I have a question. As an example, 3GPP (that can be one of the po= tential customers and that we can surely not disregard) has been very keen = in indicating that the user (whether it be the actual human being using the MN or e.g. the enterprise owning th= e MN) has priority wrt the policies defined by the operator. This is becaus= e in several scenarios the user may have preference for certain accesses (e= .g. the enterprise WiFi) that are not provided by the operator for certain services (e.g. access to the ente= rprise resources). In such case, 3GPP has recognized the need to allow the = user to have precedence. If the solution designed by netext is based solely= on network policies and decisions, I am afraid we would have a solution that does not allow valid scenarios t= hat have been identified by one of the potential customers for the solution= .<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> </div> </div> </div> </span> <div><font class=3D"Apple-style-span" color=3D"#3400FE">Raj> A network c= entric flow-mobility solution may not be able to address all the scenarios = that 3GPP is considering. But a subset of those may be dealt with via this = feature. As long as the document is clear about what is in scope and possibly documenting some of the limitations as= well, it would be useful to specify it. There could be other types of netw= orks that could use such a solution as well.  </font></div> <div><font class=3D"Apple-style-span" color=3D"#3400FE"><br> </font></div> <div><font class=3D"Apple-style-span" color=3D"#3400FE">-Raj</font></div> <div><br> </div> <span id=3D"OLK_SRC_BODY_SECTION"> <div xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micro= soft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" x= mlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-mi= crosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office:= access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"u= uid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsoft= -com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-com= :office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet= " xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:= odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micros= oft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" x= mlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://mi= crosoft.com/officenet/conferencing" xmlns:d=3D"DAV:" xmlns:repl=3D"http://s= chemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/sharep= oint/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel/= 2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=3D= "http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://sch= emas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.or= g/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/ds= p" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://= www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sharep= oint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xm= lns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://sch= emas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XM= LSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap"= xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p= =3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http://sc= hemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://schemas= .microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.micro= soft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformats.o= rg/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlform= ats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.com/= office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/packa= ge/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpar= tpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/= types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/m= essages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideL= ibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalSer= ver/PublishedLinksService" xmlns:st=3D"" xmlns=3D"http://www.w3.org/TR/= REC-html40"> <div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Cheers,<o:p></o:p></sp= an></p> <div> <table class=3D"MsoNormalTable" border=3D"0" cellspacing=3D"0" cellpadding= =3D"0"> <tbody> <tr> <td style=3D"padding:0in 0in 0in 0in"> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Stefano Faccin<o:p></o= :p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Standards Manager<o:p>= </o:p></span></p> <p class=3D"MsoNormal"><b><span style=3D"color:black">Research In Motion Co= rporation</span></b><span style=3D"color:black"> <br> 5000 Riverside Drive <br> Building 6, Brazos East, Ste. 100</span><span style=3D"color:black"><o:p></= o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:black">Irving, Texas 75039 USA = <br> Office: (972) 910 3451  <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:black">Internal: 820.63451<o:p>= </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:black"><img width=3D"14" height= =3D"10" id=3D"Picture_x0020_1" src=3D"cid:image001.jpg@01CBD8C8.FC6D4730" a= lt=3D"Untitled-1">: (510) 230 8422<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"color:= #1F497D"><a href=3D"outbind://28-00000000119E3389DDC5E04593E90FB1332A08C107= 00A3F06753D40D4149BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2= 313EF3E0000006F1BEA0000/www.rim.com" title=3D"outbind://28-00000000119E3389= DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB000001B7908B000= 0F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.rim.com www.rim.com"><span style=3D"color:black">www.rim.com</span></a></span><span= style=3D"color:black">; </span><span style=3D"color:#1F497D"><a href=3D"outbind://28-00000000119E33= 89DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB000001B7908B0= 000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.blackberry.com" tit= le=3D"outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D= 4149BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006= F1BEA0000/www.blackberry.com www.blackberry.com"><span style=3D"color:black">www.blackberry.com</span></= a></span><span style=3D"color:black"> </span><span style=3D"color:black"><o:p></o:p></span></p> </td> <td width=3D"160" style=3D"width:120.0pt;padding:0in 0in 0in 0in"></td> </tr> </tbody> </table> <p class=3D"MsoNormal"><a href=3D"http://www.blackberry.com/"><span style= =3D"color:#1F497D;text-decoration:none"><img border=3D"0" width=3D"138" hei= ght=3D"62" id=3D"Picture_x0020_6" src=3D"cid:image002.png@01CBD8C8.FC6D4730= " alt=3D"cid:image004.png@01CB49EA.87D92140"></span></a><span style=3D"colo= r:#1F497D"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"font-size:16.0pt;font-family:Webdings= ;color:#4F6228">P</span><span style=3D"font-size: 14pt; color: rgb(79, 98, = 40); font-family: Verdana, sans-serif; "> </span><span style=3D"font-size:9.0pt;color:#4F6228">Consider the environme= nt before printing.</span><span style=3D"color:#1F497D"><o:p></o:p></span><= /p> </div> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size: 10pt; font-family: Taho= ma, sans-serif; ">From:</span></b><span style=3D"font-size: 10pt; font-fami= ly: Tahoma, sans-serif; "> <a href=3D"mailto:netext-bounces@ietf.org">netext-bounces@ietf.org</a> [<a = href=3D"mailto:netext-bounces@ietf.org">mailto:netext-bounces@ietf.org</a>] <b>On Behalf Of </b><a href=3D"mailto:Basavaraj.Patil@nokia.com">Basavaraj.= Patil@nokia.com</a><br> <b>Sent:</b> Wednesday, March 02, 2011 9:04 AM<br> <b>To:</b> <a href=3D"mailto:netext@ietf.org">netext@ietf.org</a><br> <b>Subject:</b> [netext] Update on flow mobility following discussion with = ADs<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Just wanted to provide an update regarding the ongoi= ng work on flow<o:p></o:p></p> <p class=3D"MsoNormal">mobility for PMIP6 and my discussion with our ADs (J= ari and Ralph) on<o:p></o:p></p> <p class=3D"MsoNormal">March 1st:<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">I have apprised our ADs about the state of the ongoi= ng discussion on<o:p></o:p></p> <p class=3D"MsoNormal">flow mobility. One of the concerns about the ongoing= work on flow<o:p></o:p></p> <p class=3D"MsoNormal">mobility was related to the logical interface featur= e. Flow mobility<o:p></o:p></p> <p class=3D"MsoNormal">depends on the existence of a logical interface on t= he host. The WG<o:p></o:p></p> <p class=3D"MsoNormal">has not addressed the concerns related to the logica= l interface I-D,<o:p></o:p></p> <p class=3D"MsoNormal">that were raised at the previous WG meetings. Emphas= ised that we<o:p></o:p></p> <p class=3D"MsoNormal">should get the logical interface spec done soon sinc= e it is a<o:p></o:p></p> <p class=3D"MsoNormal">fundamental dependency for flow mobility. <o:p></o:p= ></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Regarding the current scope of the flow mobility wor= k and the I-D<o:p></o:p></p> <p class=3D"MsoNormal">which is now in consensus call, there are a few issu= es that need to be<o:p></o:p></p> <p class=3D"MsoNormal">resolved. A few points below:<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">1. Flow mobility in the context of Proxy MIP6 is not= analogous to the<o:p></o:p></p> <p class=3D"MsoNormal">   solution that has been developed for ho= st based MIP6. The<o:p></o:p></p> <p class=3D"MsoNormal">   featureset and capabilities developed i= n Netext does not have to<o:p></o:p></p> <p class=3D"MsoNormal">   mirror, parallel or be equivalent to th= at of RFCs 6088/9. <o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">2. There is no plan or expectation that there would = be a way for the<o:p></o:p></p> <p class=3D"MsoNormal">   MN/host to do signaling related to flow= mobility with a MAG at<o:p></o:p></p> <p class=3D"MsoNormal">   layer 3. Layer 2 is an option but obvio= usly this requires such<o:p></o:p></p> <p class=3D"MsoNormal">   enhancements to be done in other SDOs. = The preference is to develop<o:p></o:p></p> <p class=3D"MsoNormal">   a flow mobility solution that works wit= h policies and signaling<o:p></o:p></p> <p class=3D"MsoNormal">   that is network centric (i.e MAG/LMA en= tities). <o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">3. One of the major concerns raised on the mailing l= ist is related to<o:p></o:p></p> <p class=3D"MsoNormal">   how flow mobility would work when an MN= attaches to a wifi access<o:p></o:p></p> <p class=3D"MsoNormal">   and the LMA switches a flow(s) to the M= AG serving the MN via that<o:p></o:p></p> <p class=3D"MsoNormal">   wifi. The MN has no way of indicating t= o the LMA if the wifi access<o:p></o:p></p> <p class=3D"MsoNormal">   is congested or for the MAG to indicate= to the LMA about the state<o:p></o:p></p> <p class=3D"MsoNormal">   of the MNs attachment to the AP. Packet= s forwarded by the LMA to<o:p></o:p></p> <p class=3D"MsoNormal">   the MN via the wifi-MAG could be sent i= nto a void. <o:p></o:p></p> <p class=3D"MsoNormal">   Without a solution for the above scenar= io, flow mobility would not<o:p></o:p></p> <p class=3D"MsoNormal">   be robust. Some clear answers are neede= d here.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">   One option is that flow mobility for PM= IP6 is applicable only in<o:p></o:p></p> <p class=3D"MsoNormal">   those access networks wherein the acces= s network elements are aware<o:p></o:p></p> <p class=3D"MsoNormal">   of the state of the MNs connection and = congestion state. The MAG<o:p></o:p></p> <p class=3D"MsoNormal">   can use this information to signal to a= n LMA attachment state and<o:p></o:p></p> <p class=3D"MsoNormal">   potentially cause flows to be switched = to an alternative MAG. It<o:p></o:p></p> <p class=3D"MsoNormal">   may be okay to have specific statements= about the limitations of<o:p></o:p></p> <p class=3D"MsoNormal">   flow mobility for PMIP6 documented as a= sort of disclaimer. <o:p></o:p></p> <p class=3D"MsoNormal">   <o:p></o:p></p> <p class=3D"MsoNormal">   Other options?<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">4. The WG is free to extend the PMIP6 signaling betw= een MAG/LMA to<o:p></o:p></p> <p class=3D"MsoNormal">   accomplish flow mobility. <o:p></o:p></= p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">5. And lastly the question about who is the customer= for this work at<o:p></o:p></p> <p class=3D"MsoNormal">   this time is irrelevant. We have had th= is discussion during the<o:p></o:p></p> <p class=3D"MsoNormal">   chartering phase and there is no reason= to revisit it. <o:p> </o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">If I have missed any other significant (show-stopper= ) concern<o:p></o:p></p> <p class=3D"MsoNormal">regarding the flow mobility feature, please do raise= them.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">-Raj<o:p></o:p></p> </div> --------------------------------------------------------------------- <br> 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 rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. </div> </div> </span> </body> </html> --_000_C9940198116F1basavarajpatilnokiacom_-- --_005_C9940198116F1basavarajpatilnokiacom_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=722; creation-date="Wed, 02 Mar 2011 20:32:02 GMT"; modification-date="Wed, 02 Mar 2011 20:32:02 GMT" Content-ID: <image001.jpg@01CBD8C8.FC6D4730> 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_C9940198116F1basavarajpatilnokiacom_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=9011; creation-date="Wed, 02 Mar 2011 20:32:02 GMT"; modification-date="Wed, 02 Mar 2011 20:32:02 GMT" Content-ID: <image002.png@01CBD8C8.FC6D4730> Content-Transfer-Encoding: base64 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= --_005_C9940198116F1basavarajpatilnokiacom_-- From rkoodli@cisco.com Wed Mar 2 12:37:14 2011 Return-Path: <rkoodli@cisco.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4F633A6850 for <netext@core3.amsl.com>; Wed, 2 Mar 2011 12:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.019 X-Spam-Level: X-Spam-Status: No, score=-110.019 tagged_above=-999 required=5 tests=[AWL=0.580, 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 Qw9PVkbQ6+yx for <netext@core3.amsl.com>; Wed, 2 Mar 2011 12:37:13 -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 BCEB73A6882 for <netext@ietf.org>; Wed, 2 Mar 2011 12:37:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rkoodli@cisco.com; l=1162; q=dns/txt; s=iport; t=1299098300; x=1300307900; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=AtDx4aINlyihzVhHA8oMCEfz2UwGEIoZ/Iak/ilXAZE=; b=bg2Cd+a8AP8Gpbi9QtTPHqge4aEGuJhsuWLud8VeKNOBXYktLxgvTRu9 7sdf8JIXywbRV3SidLMCxVfnTEYuF3/mxlc5ucCz/jGPapYrZWdrzrhD6 f01YrRVvKs4O6MHSLAqaFAPjKBi1aj7XKeIAoRRiaphkC/KVkz9Fwas3P 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALI5bk2tJV2a/2dsb2JhbACmbnSiept8hWEEhReHD4NG X-IronPort-AV: E=Sophos;i="4.62,255,1297036800"; d="scan'208";a="222007377" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 02 Mar 2011 20:38:20 +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 p22KcJnK022951; Wed, 2 Mar 2011 20:38: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); Wed, 2 Mar 2011 14:38:19 -0600 Received: from 10.21.87.130 ([10.21.87.130]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Wed, 2 Mar 2011 20:38:18 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Wed, 02 Mar 2011 12:39:06 -0800 From: Rajeev Koodli <rkoodli@cisco.com> To: Jari Arkko <jari.arkko@piuha.net>, <sgundave@cisco.com> Message-ID: <C993EAEA.E051%rkoodli@cisco.com> Thread-Topic: [netext] Update on flow mobility following discussion with ADs Thread-Index: AcvZGd+phy/PpL1ogkySF422nsR8/A== In-Reply-To: <4D6E9F44.7060202@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Mar 2011 20:38:19.0814 (UTC) FILETIME=[C421A460:01CBD919] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Update on flow mobility following discussion with ADs X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 02 Mar 2011 20:37:15 -0000 On 3/2/11 11:49 AM, "Jari Arkko" <jari.arkko@piuha.net> wrote: > Sri: > > What Basavaraj said. I don't think the number of specifications is a big > concern either now or later. Split the documents the way you like. Lets > discuss functionality, robustness, assumptions instead -- those are > important. I agree that the spec should be robust, and should work under conditions assuming existing & new L2 signaling, as well as under conditions when new L2 signaling is unavailable. It's a question of whether we agree that LMA-MAG signaling could also be used in addition to relying only on L2 signaling for flow mobility. > > (And of course, splitting to different specifications should not be > misused to hide a technical omission or a problem.) I would focus on getting a protocol that works under different cases and not just under continued reliance on (existing and new) L2 signaling. (I am not referring to new IP signaling between MN and MAG). -Rajeev > > Jari > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From trac+netext@trac.tools.ietf.org Wed Mar 2 14:04:26 2011 Return-Path: <trac+netext@trac.tools.ietf.org> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 639313A67D9 for <netext@core3.amsl.com>; Wed, 2 Mar 2011 14:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 wXM8DePSwtcU for <netext@core3.amsl.com>; Wed, 2 Mar 2011 14:04:20 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5DD323A67B5 for <netext@ietf.org>; Wed, 2 Mar 2011 14:04:20 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac+netext@trac.tools.ietf.org>) id 1PuuAa-00048x-IZ; Wed, 02 Mar 2011 14:05:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "netext issue tracker" <trac+netext@trac.tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: telemaco.melia@alcatel-lucent.com, basavaraj.patil@nokia.com X-Trac-Project: netext Date: Wed, 02 Mar 2011 22:05:20 -0000 X-URL: http://tools.ietf.org/netext/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/netext/trac/ticket/1 Message-ID: <066.e9f936f62456f0a0d9c6a916f3c93be2@trac.tools.ietf.org> X-Trac-Ticket-ID: 1 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: telemaco.melia@alcatel-lucent.com, basavaraj.patil@nokia.com, draft-ietf-netext-logical-interface-support@tools.ietf.org, netext@ietf.org X-SA-Exim-Mail-From: trac+netext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 02 Mar 2011 14:08:40 -0800 Cc: netext@ietf.org, draft-ietf-netext-logical-interface-support@tools.ietf.org Subject: [netext] #1: Behavior of ND X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 02 Mar 2011 22:04:26 -0000 #1: Behavior of ND At IETF79 there was a concern identified that the I-D did not clearly explain the behavior of ND in the case of the logical interface on a host. Please propose text that addresses this concern. -- ---------------------------------------+------------------------------------ Reporter: basavaraj.patil@… | Owner: telemaco.melia@… Type: defect | Status: new Priority: major | Milestone: Component: logical-interface-support | Version: 1.0 Severity: Active WG Document | Keywords: ND ---------------------------------------+------------------------------------ Ticket URL: <https://trac.tools.ietf.org/wg/netext/trac/ticket/1> netext <http://tools.ietf.org/netext/> From trac+netext@trac.tools.ietf.org Wed Mar 2 14:13:41 2011 Return-Path: <trac+netext@trac.tools.ietf.org> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1CD43A6889 for <netext@core3.amsl.com>; Wed, 2 Mar 2011 14:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 IGxwdOIkCsdg for <netext@core3.amsl.com>; Wed, 2 Mar 2011 14:13:41 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2439C3A68DA for <netext@ietf.org>; Wed, 2 Mar 2011 14:13:41 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac+netext@trac.tools.ietf.org>) id 1PuuJT-0005iQ-Gk; Wed, 02 Mar 2011 14:14:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "netext issue tracker" <trac+netext@trac.tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: liebsch@neclab.eu, basavaraj.patil@nokia.com X-Trac-Project: netext Date: Wed, 02 Mar 2011 22:14:31 -0000 X-URL: http://tools.ietf.org/netext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/netext/trac/ticket/2 Message-ID: <066.bd004dcbf6b92d5e3c4e63cc5fefdf64@trac.tools.ietf.org> X-Trac-Ticket-ID: 2 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: liebsch@neclab.eu, basavaraj.patil@nokia.com, draft-ietf-netext-pmip6-lr-ps@tools.ietf.org, netext@ietf.org X-SA-Exim-Mail-From: trac+netext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: netext@ietf.org, draft-ietf-netext-pmip6-lr-ps@tools.ietf.org Subject: [netext] #2: AD review comments on LR PS I-D X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 02 Mar 2011 22:13:42 -0000 #2: AD review comments on LR PS I-D Below is the review by Jari Arkko. Please address the issues raised by Jari. Propose revised text as needed. " 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. " -- ---------------------------------------+------------------------------------ Reporter: basavaraj.patil@… | Owner: liebsch@… Type: defect | Status: new Priority: major | Milestone: Component: pmip6-lr-ps | Version: Severity: Submitted WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/2> netext <http://tools.ietf.org/netext/> From hesham@elevatemobile.com Wed Mar 2 16:36:08 2011 Return-Path: <hesham@elevatemobile.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A08CE3A691A for <netext@core3.amsl.com>; Wed, 2 Mar 2011 16:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.751 X-Spam-Level: X-Spam-Status: No, score=-0.751 tagged_above=-999 required=5 tests=[AWL=-0.452, BAYES_00=-2.599, MANGLED_AVOID=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnmUXM0yLiLZ for <netext@core3.amsl.com>; Wed, 2 Mar 2011 16:36:07 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 90CA23A6919 for <netext@ietf.org>; Wed, 2 Mar 2011 16:36:06 -0800 (PST) Received: from [60.240.140.118] (helo=[192.168.0.2]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1PuwXW-00011L-PM; Thu, 03 Mar 2011 11:37:11 +1100 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 03 Mar 2011 11:37:06 +1100 From: Hesham Soliman <hesham@elevatemobile.com> To: <Basavaraj.Patil@nokia.com>, <netext@ietf.org> Message-ID: <C9952DE2.18353%hesham@elevatemobile.com> Thread-Topic: [netext] Update on flow mobility feature following discussion with ADs Thread-Index: AcvYfcH3kduI+mBDSeKdLeONYvXCHwAvV0+q In-Reply-To: <97683F8C138FB243AAC90CEFB48ABF150926759B@008-AM1MPN1-004.mgdnok.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Subject: Re: [netext] Update on flow mobility feature following discussion with ADs X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 03 Mar 2011 00:36:08 -0000 Hi Raj, One comment below: > 1. Flow mobility in the context of Proxy MIP6 is not analogous to the > solution that has been developed for host based MIP6. The > featureset and capabilities developed in Netext does not have to > mirror, parallel or be equivalent to that of RFCs 6088/9. => So can you please define what you mean by flow mobility? Because this term was only used to mean "moving flows from one interface to another" and was connected to 6088. If there is something else that you plan to do then lets define it and based on that decide whether it's the same thing or not. Hesham > > 2. There is no plan or expectation that there would be a way for the > MN/host to do signaling related to flow mobility with a MAG at > layer 3. Layer 2 is an option but obviously this requires such > enhancements to be done in other SDOs. The preference is to develop > a flow mobility solution that works with policies and signaling > that is network centric (i.e MAG/LMA entities). > > 3. One of the major concerns raised on the mailing list is related to > how flow mobility would work when an MN attaches to a wifi access > and the LMA switches a flow(s) to the MAG serving the MN via that > wifi. The MN has no way of indicating to the LMA if the wifi access > is congested or for the MAG to indicate to the LMA about the state > of the MNs attachment to the AP. Packets forwarded by the LMA to > the MN via the wifi-MAG could be sent into a void. > Without a solution for the above scenario, flow mobility would not > be robust. Some clear answers are needed here. > > One option is that flow mobility for PMIP6 is applicable only in > those access networks wherein the access network elements are aware > of the state of the MNs connection and congestion state. The MAG > can use this information to signal to an LMA attachment state and > potentially cause flows to be switched to an alternative MAG. It > may be okay to have specific statements about the limitations of > flow mobility for PMIP6 documented as a sort of disclaimer. > > Other options? > > 4. The WG is free to extend the PMIP6 signaling between MAG/LMA to > accomplish flow mobility. > > 5. And lastly the question about who is the customer for this work at > this time is irrelevant. We have had this discussion during the > chartering phase and there is no reason to revisit it. > > If I have missed any other significant (show-stopper) concern > regarding the flow mobility feature, please do raise them. > > -Raj > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Basavaraj.Patil@nokia.com Wed Mar 2 20:00:08 2011 Return-Path: <Basavaraj.Patil@nokia.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFE6F3A694D for <netext@core3.amsl.com>; Wed, 2 Mar 2011 20:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.358 X-Spam-Level: X-Spam-Status: No, score=-101.358 tagged_above=-999 required=5 tests=[AWL=-1.059, BAYES_00=-2.599, MANGLED_AVOID=2.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 fbAxT+7kJaak for <netext@core3.amsl.com>; Wed, 2 Mar 2011 20:00:06 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id C0CF63A6947 for <netext@ietf.org>; Wed, 2 Mar 2011 20:00:05 -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 p2340how016644; Thu, 3 Mar 2011 06:01:08 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Mar 2011 06:00:34 +0200 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 3 Mar 2011 05:00:34 +0100 Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.127]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0270.002; Thu, 3 Mar 2011 05:00:34 +0100 From: <Basavaraj.Patil@nokia.com> To: <hesham@elevatemobile.com>, <netext@ietf.org> Thread-Topic: [netext] Update on flow mobility feature following discussion with ADs Thread-Index: AcvYfcH3kduI+mBDSeKdLeONYvXCHwAvV0+qAAQSBhA= Date: Thu, 3 Mar 2011 04:00:33 +0000 Message-ID: <97683F8C138FB243AAC90CEFB48ABF1509268013@008-AM1MPN1-004.mgdnok.nokia.com> References: <97683F8C138FB243AAC90CEFB48ABF150926759B@008-AM1MPN1-004.mgdnok.nokia.com> <C9952DE2.18353%hesham@elevatemobile.com> In-Reply-To: <C9952DE2.18353%hesham@elevatemobile.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.64.197.89] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Mar 2011 04:00:34.0981 (UTC) FILETIME=[8C52CD50:01CBD957] X-Nokia-AV: Clean Subject: Re: [netext] Update on flow mobility feature following discussion with ADs X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 03 Mar 2011 04:00:08 -0000 Hi Hesham, >Hi Raj,=20 > >One comment below: > > >> 1. Flow mobility in the context of Proxy MIP6 is not analogous to the >> solution that has been developed for host based MIP6. The >> featureset and capabilities developed in Netext does not have to >> mirror, parallel or be equivalent to that of RFCs 6088/9. > >=3D> So can you please define what you mean by flow mobility? Because this >term was only used to mean "moving flows from one interface to another" an= d >was connected to 6088. If there is something else that you plan to do then >lets define it and based on that decide whether it's the same thing >or not. Flow mobility in the context of Proxy MIP6 is the switching of a flow by the LMA from MAGx to MAGy when the MN is attached to the LMA via multipl= e interfaces through different MAGs. The LMA makes the decision to move a flow based on some policy. Unlike MIP6 flow mobility where the MN signals to the HA flow switching, the PMIP6 based flow mobility has no MN involvement.=20 Do you have a better term to describe this functionality. Also note that there is a possibility that the MN could do some sort of L2 signaling with the access network w.r.t flow mobility in which case the solution starts looking similar to the one defined in 6088. The L2 signaling is of course out of IETF scope and would have to be specified for specific link types in the relevant SDOs.=20 -Raj > >Hesham > >>=20 >> 2. There is no plan or expectation that there would be a way for the >> MN/host to do signaling related to flow mobility with a MAG at >> layer 3. Layer 2 is an option but obviously this requires such >> enhancements to be done in other SDOs. The preference is to develop >> a flow mobility solution that works with policies and signaling >> that is network centric (i.e MAG/LMA entities). >>=20 >> 3. One of the major concerns raised on the mailing list is related to >> how flow mobility would work when an MN attaches to a wifi access >> and the LMA switches a flow(s) to the MAG serving the MN via that >> wifi. The MN has no way of indicating to the LMA if the wifi access >> is congested or for the MAG to indicate to the LMA about the state >> of the MNs attachment to the AP. Packets forwarded by the LMA to >> the MN via the wifi-MAG could be sent into a void. >> Without a solution for the above scenario, flow mobility would not >> be robust. Some clear answers are needed here. >>=20 >> One option is that flow mobility for PMIP6 is applicable only in >> those access networks wherein the access network elements are aware >> of the state of the MNs connection and congestion state. The MAG >> can use this information to signal to an LMA attachment state and >> potentially cause flows to be switched to an alternative MAG. It >> may be okay to have specific statements about the limitations of >> flow mobility for PMIP6 documented as a sort of disclaimer. >>=20 >> Other options? >>=20 >> 4. The WG is free to extend the PMIP6 signaling between MAG/LMA to >> accomplish flow mobility. >>=20 >> 5. And lastly the question about who is the customer for this work at >> this time is irrelevant. We have had this discussion during the >> chartering phase and there is no reason to revisit it. >>=20 >> If I have missed any other significant (show-stopper) concern >> regarding the flow mobility feature, please do raise them. >>=20 >> -Raj >> From hesham@elevatemobile.com Wed Mar 2 20:23:20 2011 Return-Path: <hesham@elevatemobile.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F64E3A6945 for <netext@core3.amsl.com>; Wed, 2 Mar 2011 20:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.525 X-Spam-Level: X-Spam-Status: No, score=-0.525 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, MANGLED_AVOID=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKetiU8p5eUg for <netext@core3.amsl.com>; Wed, 2 Mar 2011 20:23:18 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 6E9423A6947 for <netext@ietf.org>; Wed, 2 Mar 2011 20:23:17 -0800 (PST) Received: from [60.240.140.118] (helo=[192.168.0.2]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1Pv05O-0001Z7-0z; Thu, 03 Mar 2011 15:24:22 +1100 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 03 Mar 2011 15:24:17 +1100 From: Hesham Soliman <hesham@elevatemobile.com> To: <Basavaraj.Patil@nokia.com>, <netext@ietf.org> Message-ID: <C9956321.18360%hesham@elevatemobile.com> Thread-Topic: [netext] Update on flow mobility feature following discussion with ADs Thread-Index: AcvYfcH3kduI+mBDSeKdLeONYvXCHwAvV0+qAAQSBhAAA90nfw== In-Reply-To: <97683F8C138FB243AAC90CEFB48ABF1509268013@008-AM1MPN1-004.mgdnok.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Subject: Re: [netext] Update on flow mobility feature following discussion with ADs X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 03 Mar 2011 04:23:20 -0000 >> >> >>> 1. Flow mobility in the context of Proxy MIP6 is not analogous to the >>> solution that has been developed for host based MIP6. The >>> featureset and capabilities developed in Netext does not have to >>> mirror, parallel or be equivalent to that of RFCs 6088/9. >> >> => So can you please define what you mean by flow mobility? Because this >> term was only used to mean "moving flows from one interface to another" and >> was connected to 6088. If there is something else that you plan to do then >> lets define it and based on that decide whether it's the same thing >> or not. > > Flow mobility in the context of Proxy MIP6 is the switching of a flow > by the LMA from MAGx to MAGy when the MN is attached to the LMA via multiple > interfaces through different MAGs. The LMA makes the decision to move > a flow based on some policy. Unlike MIP6 flow mobility where the MN > signals to the HA flow switching, the PMIP6 based flow mobility has no > MN involvement. > Do you have a better term to describe this functionality. => No I don't have a better definition. That definition though is functionaly identical to 6088's assumption. I gathered from your notes that netext might do a subset of features, hence my question about the definition. My (and others') argument is that the policy would be flawed if it didn't include the MN's input. If that input happens to be on L2 it is still very limited as to what it can be. Hence, since it doesn't look like such policy will be defined by IETF, I think the solution is more likely to be harmful because it can be inadvertently miused. Please note that a bad or a wrong policy here would affect all MN's in a domain, which is obviously not the case in MIPv6. Hesham > > Also note that there is a possibility that the MN could do some sort > of L2 signaling with the access network w.r.t flow mobility in which > case the solution starts looking similar to the one defined in > 6088. The L2 signaling is of course out of IETF scope and would have > to be specified for specific link types in the relevant SDOs. > > -Raj >> >> Hesham >> >>> >>> 2. There is no plan or expectation that there would be a way for the >>> MN/host to do signaling related to flow mobility with a MAG at >>> layer 3. Layer 2 is an option but obviously this requires such >>> enhancements to be done in other SDOs. The preference is to develop >>> a flow mobility solution that works with policies and signaling >>> that is network centric (i.e MAG/LMA entities). >>> >>> 3. One of the major concerns raised on the mailing list is related to >>> how flow mobility would work when an MN attaches to a wifi access >>> and the LMA switches a flow(s) to the MAG serving the MN via that >>> wifi. The MN has no way of indicating to the LMA if the wifi access >>> is congested or for the MAG to indicate to the LMA about the state >>> of the MNs attachment to the AP. Packets forwarded by the LMA to >>> the MN via the wifi-MAG could be sent into a void. >>> Without a solution for the above scenario, flow mobility would not >>> be robust. Some clear answers are needed here. >>> >>> One option is that flow mobility for PMIP6 is applicable only in >>> those access networks wherein the access network elements are aware >>> of the state of the MNs connection and congestion state. The MAG >>> can use this information to signal to an LMA attachment state and >>> potentially cause flows to be switched to an alternative MAG. It >>> may be okay to have specific statements about the limitations of >>> flow mobility for PMIP6 documented as a sort of disclaimer. >>> >>> Other options? >>> >>> 4. The WG is free to extend the PMIP6 signaling between MAG/LMA to >>> accomplish flow mobility. >>> >>> 5. And lastly the question about who is the customer for this work at >>> this time is irrelevant. We have had this discussion during the >>> chartering phase and there is no reason to revisit it. >>> >>> If I have missed any other significant (show-stopper) concern >>> regarding the flow mobility feature, please do raise them. >>> >>> -Raj >>> > From Basavaraj.Patil@nokia.com Wed Mar 2 20:35:51 2011 Return-Path: <Basavaraj.Patil@nokia.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C31163A6947 for <netext@core3.amsl.com>; Wed, 2 Mar 2011 20:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 mX2quh4v7wbK for <netext@core3.amsl.com>; Wed, 2 Mar 2011 20:35:50 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id 62B3A3A694F for <netext@ietf.org>; Wed, 2 Mar 2011 20:35:49 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p234aoB6018703; Thu, 3 Mar 2011 06:36:52 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Mar 2011 06:36:39 +0200 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 3 Mar 2011 05:36:38 +0100 Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.127]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0270.002; Thu, 3 Mar 2011 05:36:38 +0100 From: <Basavaraj.Patil@nokia.com> To: <hesham@elevatemobile.com>, <netext@ietf.org> Thread-Topic: [netext] Update on flow mobility feature following discussion with ADs Thread-Index: AcvYfcH3kduI+mBDSeKdLeONYvXCHwAvV0+qAAQSBhAAA90nfwAKcqnQ Date: Thu, 3 Mar 2011 04:36:37 +0000 Message-ID: <97683F8C138FB243AAC90CEFB48ABF150926803C@008-AM1MPN1-004.mgdnok.nokia.com> References: <97683F8C138FB243AAC90CEFB48ABF1509268013@008-AM1MPN1-004.mgdnok.nokia.com> <C9956321.18360%hesham@elevatemobile.com> In-Reply-To: <C9956321.18360%hesham@elevatemobile.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.64.197.89] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Mar 2011 04:36:39.0374 (UTC) FILETIME=[9666F6E0:01CBD95C] X-Nokia-AV: Clean Subject: Re: [netext] Update on flow mobility feature following discussion with ADs X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 03 Mar 2011 04:35:52 -0000 >>>> 1. Flow mobility in the context of Proxy MIP6 is not analogous to the >>>> solution that has been developed for host based MIP6. The >>>> featureset and capabilities developed in Netext does not have to >>>> mirror, parallel or be equivalent to that of RFCs 6088/9. >>>=20 >>> =3D> So can you please define what you mean by flow mobility? Because t= his >>> term was only used to mean "moving flows from one interface to another"= and >>> was connected to 6088. If there is something else that you plan to do t= hen >>> lets define it and based on that decide whether it's the same thing >>> or not. >>=20 >> Flow mobility in the context of Proxy MIP6 is the switching of a flow >> by the LMA from MAGx to MAGy when the MN is attached to the LMA via mult= iple >> interfaces through different MAGs. The LMA makes the decision to move >> a flow based on some policy. Unlike MIP6 flow mobility where the MN >> signals to the HA flow switching, the PMIP6 based flow mobility has no >> MN involvement.=20 >> Do you have a better term to describe this functionality. > >=3D> No I don't have a better definition. That definition though is >functionaly identical to 6088's assumption. I gathered from your notes tha= t >netext might do a subset of features, hence my question about the >definition.=20 >My (and others') argument is that the policy would be flawed if it didn't >include the MN's input. If that input happens to be on L2 it is still very >limited as to what it can be. Agree. The limitation arises from the inability of the MN to do the sort of signaling that is possible in MIP6. Hence you would not have the same degree of control in terms of switching flows or the granularity in the case of PMIP6. At least this is IMO (chair hat off). I think the authors of the I-D may have additional opinions. I have some degree of skepticism about what can really be achieved at L2 since it is not easy to change existing link specs.=20 > >Hence, since it doesn't look like such policy will be defined by IETF, I >think the solution is more likely to be harmful because it can be >inadvertently miused. Please note that a bad or a wrong policy here would >affect all MN's in a domain, which is obviously not the case in >MIPv6. Policy that is used to switch a flow by the LMA can be configured locally (LMA), obtained via some interface to policy engines, etc. So yes, we are not specifying the actual policy itself. Misconfiguring policies will no doubt affect a larger set of MNs when compared to the equivalent in MIP6 based flow mobility where the impact would be to a single MN. But these are the tradeoffs. The I-D could document such issues in order to ensure that anyone using such a system would be aware of the pitfalls.=20 -Raj > >Hesham > > From hesham@elevatemobile.com Wed Mar 2 20:59:01 2011 Return-Path: <hesham@elevatemobile.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 848013A696E for <netext@core3.amsl.com>; Wed, 2 Mar 2011 20:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[AWL=0.999, 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 egpgPk7kIa4l for <netext@core3.amsl.com>; Wed, 2 Mar 2011 20:59:00 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 9F62C3A696B for <netext@ietf.org>; Wed, 2 Mar 2011 20:58:59 -0800 (PST) Received: from [60.240.140.118] (helo=[192.168.0.2]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1Pv0db-00078Y-2D; Thu, 03 Mar 2011 15:59:43 +1100 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 03 Mar 2011 15:59:37 +1100 From: Hesham Soliman <hesham@elevatemobile.com> To: <Basavaraj.Patil@nokia.com>, <netext@ietf.org> Message-ID: <C9956B69.18364%hesham@elevatemobile.com> Thread-Topic: [netext] Update on flow mobility feature following discussion with ADs Thread-Index: AcvYfcH3kduI+mBDSeKdLeONYvXCHwAvV0+qAAQSBhAAA90nfwAKcqnQAAk2wFY= In-Reply-To: <97683F8C138FB243AAC90CEFB48ABF150926803C@008-AM1MPN1-004.mgdnok.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Subject: Re: [netext] Update on flow mobility feature following discussion with ADs X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 03 Mar 2011 04:59:01 -0000 >> => No I don't have a better definition. That definition though is >> functionaly identical to 6088's assumption. I gathered from your notes that >> netext might do a subset of features, hence my question about the >> definition. >> My (and others') argument is that the policy would be flawed if it didn't >> include the MN's input. If that input happens to be on L2 it is still very >> limited as to what it can be. > > Agree. The limitation arises from the inability of the MN to do the > sort of signaling that is possible in MIP6. Hence you would not have > the same degree of control in terms of switching flows or the > granularity in the case of PMIP6. At least this is IMO (chair hat > off). I think the authors of the I-D may have additional > opinions. I have some degree of skepticism about what can really be > achieved at L2 since it is not easy to change existing link specs. => Right. So given that, I think we need to have a clear scope of what can be done. > >> >> Hence, since it doesn't look like such policy will be defined by IETF, I >> think the solution is more likely to be harmful because it can be >> inadvertently miused. Please note that a bad or a wrong policy here would >> affect all MN's in a domain, which is obviously not the case in >> MIPv6. > > Policy that is used to switch a flow by the LMA can be configured > locally (LMA), obtained via some interface to policy engines, etc. So > yes, we are not specifying the actual policy itself. Misconfiguring > policies will no doubt affect a larger set of MNs when compared to the > equivalent in MIP6 based flow mobility where the impact would be to a > single MN. But these are the tradeoffs. The I-D could document such > issues in order to ensure that anyone using such a system would be > aware of the pitfalls. => Hmm, the problem isn't misconfiguration, The problem is configuring things correctly :). I mean when you buy a car that has a mx speed of 300 km/hr but a bad suspension you shouldn't be going very fast on a winding road even if the claimed speed is achievable. My point is that you'll advertise a certain feature that you can't actually guarantee unless you explicitly restrict the scenarios it supports. I don't know how you intend to do that though. But if you do, I suggest you don't call it flow mobility because it's false advertising given the precedence in 6088 and 6089. It needs to be given a name that indicates its limitation so its clear to the users. Hesham > > -Raj > >> >> Hesham >> >> > From hesham@elevatemobile.com Wed Mar 2 21:07:39 2011 Return-Path: <hesham@elevatemobile.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 937303A695E for <netext@core3.amsl.com>; Wed, 2 Mar 2011 21:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, J_CHICKENPOX_46=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 kQRfP5GZkT+X for <netext@core3.amsl.com>; Wed, 2 Mar 2011 21:07:38 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 7391C3A6960 for <netext@ietf.org>; Wed, 2 Mar 2011 21:07:37 -0800 (PST) Received: from [60.240.140.118] (helo=[192.168.0.2]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1Pv0mD-0006Kv-6n; Thu, 03 Mar 2011 16:08:37 +1100 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 03 Mar 2011 16:08:28 +1100 From: Hesham Soliman <hesham@elevatemobile.com> To: <cjbc@it.uc3m.es> Message-ID: <C9956D7C.18368%hesham@elevatemobile.com> Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvZYQgIFssyBSoUxE+wO0EbEVhSaw== In-Reply-To: <1299081352.5356.36.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: "Zuniga, Juan Carlos" <JuanCarlos.Zuniga@interdigital.com>, 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 03 Mar 2011 05:07:39 -0000 >> => How does the AP tell the MAG that a new host has attached? Is this >> documented in a standard somewhere? If there is a specific L2 mechanism for >> this then I guess you are relying on L2-specific hints, but I'm curious to >> know what they are. > > The AP detects that a host has attached looking at its association > table. If the AP is collocated with the MAG, the AP can just use local > communication to inform the MAG. If they are different boxes, you can > use whatever kind of signaling channel between the AP and the MAG (in > our prototype we just use UDP messages). This is compliant with RFC5213, > with does not enforce any particular mechanism to detect MN attachment. => Ok since that protocol doesn't exist today, you basically require colocation of the AP with the MAG. >> >> => Of course it's doable in a prototype. We're talking about deploying it in >> a real fault tolerant system though, it's a different story. > > Well, I just wanted to make the point that we talk about things that are > working fine without many implementation effort and that we think can > work properly in a real system without major efforts. => I think "working fine" is a subjective description. You can make enough assumptions in a lab to make anything work. The point is, as myself and Julien mentioned several times, you can't assume a 1:1 mapping of user:device. It's a fact in today's world. >> >> => ok, I hope you answer the fundament questions about knowing the link >> state and the interface availability, congestion ...etc in that draft. >> Because they're the things that you don't know without checking with the >> host and you need them to do flow mobility. > > Of course there are many things that could be enhanced and adjusted > based on the system where the solution is implemented. => It's a fundamental assumption though! The only entity that knows if it's interface is up or down in a WLAN is the host. What can you do about that? Unless you define a new WLAN standard you're out of luck. The only entity that knows its apps is the end host. How can you change that? I'm not talking about well known ports, it's a generic assumption. Also, the only entity that knows what it's "about to do" is the end host. Nothing to change here either. Most of them can > be left up to the particular system (just as RFC5213 does for many key > functions), as long as we come up with a solution that is interoperable > and that do not pose strong requirements (such as particular L2 > signaling) on the MN. => Then do that first before you suggest building something on a foundation that doesn't exist. Shouldn't you have a foundation before you build? Hesham > > Carlos > >> >> Hesham >> >>> >>> Carlos >>> >>>> >>>> Hesham >>>> >>>>> >>>>> Carlos >>>>> >>>>>> >>>>>> Hesham >>>>>> >>>>>>> >>>>>>> Carlos >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Hesham >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Carlos >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hesham >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >> >> From cjbc@it.uc3m.es Thu Mar 3 02:05:18 2011 Return-Path: <cjbc@it.uc3m.es> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9028E3A67C1 for <netext@core3.amsl.com>; Thu, 3 Mar 2011 02:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.279 X-Spam-Level: X-Spam-Status: No, score=-5.279 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_46=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 k1YHUmJ466DD for <netext@core3.amsl.com>; Thu, 3 Mar 2011 02:05:17 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 004FA3A6827 for <netext@ietf.org>; Thu, 3 Mar 2011 02:05:13 -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 smtp01.uc3m.es (Postfix) with ESMTP id 5909EC1E5E8; Thu, 3 Mar 2011 11:06:18 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <cjbc@it.uc3m.es> To: Hesham Soliman <hesham@elevatemobile.com> In-Reply-To: <C9956D7C.18368%hesham@elevatemobile.com> References: <C9956D7C.18368%hesham@elevatemobile.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-XLPTYWtLujymNJPocD/o" Organization: Universidad Carlos III de Madrid Date: Thu, 03 Mar 2011 11:07:44 +0100 Message-ID: <1299146864.5356.61.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-17988.003 Cc: "Zuniga, Juan Carlos" <JuanCarlos.Zuniga@interdigital.com>, 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 03 Mar 2011 10:05:18 -0000 --=-XLPTYWtLujymNJPocD/o Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Hesham, On Thu, 2011-03-03 at 16:08 +1100, Hesham Soliman wrote: >=20 > >> =3D> How does the AP tell the MAG that a new host has attached? Is thi= s > >> documented in a standard somewhere? If there is a specific L2 mechanis= m for > >> this then I guess you are relying on L2-specific hints, but I'm curiou= s to > >> know what they are. > >=20 > > The AP detects that a host has attached looking at its association > > table. If the AP is collocated with the MAG, the AP can just use local > > communication to inform the MAG. If they are different boxes, you can > > use whatever kind of signaling channel between the AP and the MAG (in > > our prototype we just use UDP messages). This is compliant with RFC5213= , > > with does not enforce any particular mechanism to detect MN attachment. >=20 > =3D> Ok since that protocol doesn't exist today, you basically require > colocation of the AP with the MAG. Nope, you can use your own implementation of that mechanism if required. >=20 > >>=20 > >> =3D> Of course it's doable in a prototype. We're talking about deployi= ng it in > >> a real fault tolerant system though, it's a different story. > >=20 > > Well, I just wanted to make the point that we talk about things that ar= e > > working fine without many implementation effort and that we think can > > work properly in a real system without major efforts. >=20 > =3D> I think "working fine" is a subjective description. You can make eno= ugh > assumptions in a lab to make anything work. The point is, as myself and > Julien mentioned several times, you can't assume a 1:1 mapping of > user:device. It's a fact in today's world. You can have 1:n mappings as well. >=20 > >>=20 > >> =3D> ok, I hope you answer the fundament questions about knowing the l= ink > >> state and the interface availability, congestion ...etc in that draft. > >> Because they're the things that you don't know without checking with t= he > >> host and you need them to do flow mobility. > >=20 > > Of course there are many things that could be enhanced and adjusted > > based on the system where the solution is implemented. >=20 > =3D> It's a fundamental assumption though! The only entity that knows if = it's > interface is up or down in a WLAN is the host. What can you do about that= ? > Unless you define a new WLAN standard you're out of luck. The only entity > that knows its apps is the end host. How can you change that? I'm not > talking about well known ports, it's a generic assumption. > Also, the only entity that knows what it's "about to do" is the end host. > Nothing to change here either. That's a mobile-centric view, which is not quite aligned with a network-based mobility protocol. >=20 > Most of them can > > be left up to the particular system (just as RFC5213 does for many key > > functions), as long as we come up with a solution that is interoperable > > and that do not pose strong requirements (such as particular L2 > > signaling) on the MN. >=20 > =3D> Then do that first before you suggest building something on a founda= tion > that doesn't exist. Shouldn't you have a foundation before you build? >=20 Again, I have seen built systems working based on the same principles that we have been discussed here. Carlos > Hesham >=20 > >=20 > > Carlos > >=20 > >>=20 > >> Hesham > >>=20 > >>>=20 > >>> Carlos > >>>=20 > >>>>=20 > >>>> Hesham > >>>>=20 > >>>>>=20 > >>>>> Carlos > >>>>>=20 > >>>>>>=20 > >>>>>> Hesham > >>>>>>=20 > >>>>>>>=20 > >>>>>>> Carlos > >>>>>>>=20 > >>>>>>>>=20 > >>>>>>>> Thanks, > >>>>>>>> Hesham > >>>>>>>>=20 > >>>>>>>>=20 > >>>>>>>>>=20 > >>>>>>>>> Carlos > >>>>>>>>>=20 > >>>>>>>>>>=20 > >>>>>>>>>> Hesham > >>>>>>>>>>=20 > >>>>>>>>>>=20 > >>>>>>>>=20 > >>>>>>>>=20 > >>>>>>=20 > >>>>>>=20 > >>>>=20 > >>>>=20 > >>=20 > >>=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 --=-XLPTYWtLujymNJPocD/o 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) iEYEABECAAYFAk1vaG8ACgkQNdy6TdFwT2dvuACeIL/8ZHn8La+aLWCJF+m52ykF y9gAoJnqU0yjq3TSQM0Xu+1JMAMCergP =Zel3 -----END PGP SIGNATURE----- --=-XLPTYWtLujymNJPocD/o-- From hesham@elevatemobile.com Thu Mar 3 03:40:25 2011 Return-Path: <hesham@elevatemobile.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D7953A69BF for <netext@core3.amsl.com>; Thu, 3 Mar 2011 03:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, J_CHICKENPOX_46=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 OhKP4TUdjVG1 for <netext@core3.amsl.com>; Thu, 3 Mar 2011 03:40:24 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id B7E1B3A69BD for <netext@ietf.org>; Thu, 3 Mar 2011 03:40:22 -0800 (PST) Received: from [203.219.211.243] (helo=[192.168.0.4]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1Pv6uI-0007lV-G6; Thu, 03 Mar 2011 22:41:22 +1100 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 03 Mar 2011 22:41:17 +1100 From: Hesham Soliman <hesham@elevatemobile.com> To: <cjbc@it.uc3m.es> Message-ID: <C995C98D.1837C%hesham@elevatemobile.com> Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvZl+hAQcE50BnTtUmYCug7FFwuUw== In-Reply-To: <1299146864.5356.61.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: "Zuniga, Juan Carlos" <JuanCarlos.Zuniga@interdigital.com>, 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 03 Mar 2011 11:40:25 -0000 >>> Well, I just wanted to make the point that we talk about things that are >>> working fine without many implementation effort and that we think can >>> work properly in a real system without major efforts. >> >> => I think "working fine" is a subjective description. You can make enough >> assumptions in a lab to make anything work. The point is, as myself and >> Julien mentioned several times, you can't assume a 1:1 mapping of >> user:device. It's a fact in today's world. > > You can have 1:n mappings as well. => No you can't. You're assuming the device capability is in the profile. We've gone over this already... >>> Of course there are many things that could be enhanced and adjusted >>> based on the system where the solution is implemented. >> >> => It's a fundamental assumption though! The only entity that knows if it's >> interface is up or down in a WLAN is the host. What can you do about that? >> Unless you define a new WLAN standard you're out of luck. The only entity >> that knows its apps is the end host. How can you change that? I'm not >> talking about well known ports, it's a generic assumption. >> Also, the only entity that knows what it's "about to do" is the end host. >> Nothing to change here either. > > That's a mobile-centric view, which is not quite aligned with a > network-based mobility protocol. => It's aligned with the Internet as it is today.... Hesham From trac+netext@trac.tools.ietf.org Thu Mar 3 09:15:17 2011 Return-Path: <trac+netext@trac.tools.ietf.org> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A498E3A6A0C for <netext@core3.amsl.com>; Thu, 3 Mar 2011 09:15:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 8cv7j1GGBb2X for <netext@core3.amsl.com>; Thu, 3 Mar 2011 09:15:16 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E077F3A6830 for <netext@ietf.org>; Thu, 3 Mar 2011 09:15:16 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac+netext@trac.tools.ietf.org>) id 1PvC8S-0001UI-4s; Thu, 03 Mar 2011 09:16:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "netext issue tracker" <trac+netext@trac.tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: telemaco.melia@alcatel-lucent.com, basavaraj.patil@nokia.com X-Trac-Project: netext Date: Thu, 03 Mar 2011 17:16:20 -0000 X-URL: http://tools.ietf.org/netext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/netext/trac/ticket/3 Message-ID: <066.d2b1a47b864e8340579c7215fdc00464@trac.tools.ietf.org> X-Trac-Ticket-ID: 3 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: telemaco.melia@alcatel-lucent.com, basavaraj.patil@nokia.com, draft-ietf-netext-logical-interface-support@tools.ietf.org, netext@ietf.org X-SA-Exim-Mail-From: trac+netext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: netext@ietf.org, draft-ietf-netext-logical-interface-support@tools.ietf.org Subject: [netext] #3: Logical Interface: Use of the Virtual LLID X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 03 Mar 2011 17:15:17 -0000 #3: Logical Interface: Use of the Virtual LLID Clarify the use of virtual LLID and how this is used in the scope of PMIP6. Discuss the solution and propose text and ensure there is clear consensus before you can close this issue. -- ---------------------------------------+------------------------------------ Reporter: basavaraj.patil@… | Owner: telemaco.melia@… Type: defect | Status: new Priority: critical | Milestone: Component: logical-interface-support | Version: Severity: - | Keywords: ---------------------------------------+------------------------------------ Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/3> netext <http://tools.ietf.org/netext/> From trac+netext@trac.tools.ietf.org Thu Mar 3 09:16:51 2011 Return-Path: <trac+netext@trac.tools.ietf.org> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0E13A6830 for <netext@core3.amsl.com>; Thu, 3 Mar 2011 09:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 XJ0E6q9KDMHf for <netext@core3.amsl.com>; Thu, 3 Mar 2011 09:16:50 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 755A93A67F1 for <netext@ietf.org>; Thu, 3 Mar 2011 09:16:50 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac+netext@trac.tools.ietf.org>) id 1PvCA0-0004db-QH; Thu, 03 Mar 2011 09:17:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "netext issue tracker" <trac+netext@trac.tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: telemaco.melia@alcatel-lucent.com, basavaraj.patil@nokia.com X-Trac-Project: netext Date: Thu, 03 Mar 2011 17:17:56 -0000 X-URL: http://tools.ietf.org/netext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/netext/trac/ticket/4 Message-ID: <066.44c02c04592a11d868774e78f7db352d@trac.tools.ietf.org> X-Trac-Ticket-ID: 4 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: telemaco.melia@alcatel-lucent.com, basavaraj.patil@nokia.com, netext@ietf.org X-SA-Exim-Mail-From: trac+netext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: netext@ietf.org Subject: [netext] #4: Logical interface support: Point to point links X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 03 Mar 2011 17:16:51 -0000 #4: Logical interface support: Point to point links Clarify the use and behavior of the logical interface on PtP links. -- ---------------------------------------+------------------------------------ Reporter: basavaraj.patil@… | Owner: telemaco.melia@… Type: defect | Status: new Priority: major | Milestone: Component: logical-interface-support | Version: Severity: - | Keywords: ---------------------------------------+------------------------------------ Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/4> netext <http://tools.ietf.org/netext/> From trac+netext@trac.tools.ietf.org Thu Mar 3 09:17:58 2011 Return-Path: <trac+netext@trac.tools.ietf.org> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 844DF3A69FC for <netext@core3.amsl.com>; Thu, 3 Mar 2011 09:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 Fmf44BSiTARL for <netext@core3.amsl.com>; Thu, 3 Mar 2011 09:17:57 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1DD583A67F1 for <netext@ietf.org>; Thu, 3 Mar 2011 09:17:57 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac+netext@trac.tools.ietf.org>) id 1PvCB4-0006Hv-Gy; Thu, 03 Mar 2011 09:19:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "netext issue tracker" <trac+netext@trac.tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: telemaco.melia@alcatel-lucent.com, basavaraj.patil@nokia.com X-Trac-Project: netext Date: Thu, 03 Mar 2011 17:19:02 -0000 X-URL: http://tools.ietf.org/netext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/netext/trac/ticket/5 Message-ID: <066.d15938dc10856d20b122b59428c9c5bc@trac.tools.ietf.org> X-Trac-Ticket-ID: 5 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: telemaco.melia@alcatel-lucent.com, basavaraj.patil@nokia.com, netext@ietf.org X-SA-Exim-Mail-From: trac+netext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: netext@ietf.org Subject: [netext] #5: Logical interface support: Multicast traffic X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 03 Mar 2011 17:17:58 -0000 #5: Logical interface support: Multicast traffic Clarify how the logical interface deals with multicast traffic. -- ---------------------------------------+------------------------------------ Reporter: basavaraj.patil@… | Owner: telemaco.melia@… Type: defect | Status: new Priority: critical | Milestone: Component: logical-interface-support | Version: Severity: - | Keywords: ---------------------------------------+------------------------------------ Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/5> netext <http://tools.ietf.org/netext/> From julien.ietf@gmail.com Thu Mar 3 10:40:12 2011 Return-Path: <julien.ietf@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F07D3A69FE for <netext@core3.amsl.com>; Thu, 3 Mar 2011 10:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.211 X-Spam-Level: X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[AWL=0.388, 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 3Yun7Nlj8KqP for <netext@core3.amsl.com>; Thu, 3 Mar 2011 10:40: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 108D03A67D3 for <netext@ietf.org>; Thu, 3 Mar 2011 10:40:09 -0800 (PST) Received: by fxm15 with SMTP id 15so1483011fxm.31 for <netext@ietf.org>; Thu, 03 Mar 2011 10:41: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 :content-transfer-encoding; bh=pYNWMwMbhZj5fnWkbaSp89xChLJgBA088VZ+XXIWozk=; b=H8rRyJc7OptIGsvp5wRVRYEx3HE64C3a+AuFgohrIj6m97jak5S/9+gTM2BGE5dwQ1 HWAAYtsO74vX8HUez7f/o3Km9nXmEVXwsc8+8Wxw3dMG9hG4MhXyOkOhNUBMOcodR/8I YpCx8eKStVipofuOEY14iYRxmfMvMsXmH8iYc= 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=qAFcWWjMevyccLMSheiK/NVHLSnBAzKE8LD7Y849e9aXMt2etkyiN9YnnCkuj5TNDT Y5i8Zwl9mnVKwkVYmFaAe0k5inyEzpuw3pkQVKAya/XApkqmP2CQ+Q+ytebI1WpmyXIp bNoV3fbaUrLMdmQ6mZ5IC1FsJGjc308pxoBYs= MIME-Version: 1.0 Received: by 10.223.83.16 with SMTP id d16mr1846150fal.148.1299177656941; Thu, 03 Mar 2011 10:40:56 -0800 (PST) Received: by 10.223.93.141 with HTTP; Thu, 3 Mar 2011 10:40:56 -0800 (PST) In-Reply-To: <C993BAC0.119F0%sgundave@cisco.com> References: <97683F8C138FB243AAC90CEFB48ABF1509267582@008-AM1MPN1-004.mgdnok.nokia.com> <C993BAC0.119F0%sgundave@cisco.com> Date: Thu, 3 Mar 2011 10:40:56 -0800 Message-ID: <AANLkTinZUYi3PtGhD3NdORmouwHk-oJVDyLRamkU5JP2@mail.gmail.com> From: Julien Laganier <julien.ietf@gmail.com> To: Sri Gundavelli <sgundave@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org, JuanCarlos.Zuniga@interdigital.com, Basavaraj.Patil@nokia.com 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 03 Mar 2011 18:40:12 -0000 Sri, Whether or not a host stack send an RS when a link-up event happens is irrelevant to the design of the PMIPv6 flow mobility for the two following reasons: 1. Stacks with DNAv6 would send an RS, other stack would not. So it's not generic and can't be relied upon. 2. Even if all stacks were sending RS. RS can be lost. So it's not reliable and can' t be relied upon. --julien On Wed, Mar 2, 2011 at 9:13 AM, Sri Gundavelli <sgundave@cisco.com> wrote: > Yes, it is relevant in the context of the current discussion. If we are n= ot > on the same page, as how a simple IP host behaves across L3 roams, we are > not going to converge on what new events L2 or L3 we need. So, this is > relevant. > > > > Thanks > Sri > > > > On 3/2/11 8:53 AM, "Basavaraj.Patil@nokia.com" <Basavaraj.Patil@nokia.com= > > wrote: > >> >> Folks, >> >> Is this discussion about how MIP6 works even relevant in the context of = the >> flow mobility discussion? >> There are other questions and concerns that have been raised which I wou= ld >> advise the authors to focus on. >> >> If you need to understand how movement detection in MIP6 works, please r= efer >> to Sec 11.5 of RFC3775. >> >> -Raj >> >> -----Original Message----- >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf= Of >> ext Carlos Jes=FAs Bernardos Cano >> Sent: Wednesday, March 02, 2011 10:49 AM >> To: Sri Gundavelli >> Cc: netext@ietf.org; Zuniga, Juan Carlos >> Subject: Re: [netext] Flow Mobility discussion - way forward? >> >> Hi Sri, >> >> On Wed, 2011-03-02 at 08:16 -0800, Sri Gundavelli wrote: >>>> I'm talking about a legacu IPv6 host. If I install Mobile IPv6 in >>>> that Linux stack, don't worry, the MIPv6 client takes care of >>>> configuring a CoA (sending an RS if no RA is received). >>>> >>> >>> Hi Carlos: >>> >>> (Still keeping the discussion context to this one comment). >>> >>> - I assume MIPv6 stack is on top of IP stack, not the other way around >> >> Well, i reality MIPv6 is part of IPv6, not really sits on top. >> >>> >>> - If IP stack does not detect movement detection across L3 links (in >>> the absence of any other hints about same L3 link, in the forms essid >>> or other hints), how does the MIPv6 stack which is relying on the >>> stack/kernel events, decide to force an RA ? What is the hint ? How >>> come ND/DHCP does not realize the same need to send an RS ? Is MIPv6 st= ack so >>> smart ? >> >> The implementations that I'm familiar with do the following: >> >> - They wait for an unsolicited RA >> - If no unsolicited RA is received in a time interval equal to 2 times t= he >> frequency of RAs (there is information about that on the RAs), the MN se= nds an >> RS. >> >>> >>> - Assuming there is no MIPv6 stack on the host, an host moves across >>> access links, it will never do an RS and will keep using the address >>> from the previous link. So, the basic IPv6 connectivity is broken. >>> This is a bug, not a protocol gap. >> >> With WLAN and Linux, that's the behavior. I guess developers understood = that >> two APs with the same ESSID belongs to the same ESS, and therefore the s= ame IP >> subnet. That actually is correct and cannot be cataloged as "bug". >> >>> >>> PS: I heard about this RS problems 5 years back, when most WLAN >>> drivers were not handling IPv6 correctly. I'm pretty sure all the WLAN >>> drivers have fixed those problems now. You may want to replace your >>> buggy NIC card driver :) >> >> It's not a buggy NIC card driver. You may say a buggy OS, but I honestly= will >> not call Linux "buggy" (or at least buggier than many others that are ou= t >> there). >> >> Carlos >> >>> >>> >>> >>> Regards >>> Sri >>> >>> >>> >>> On 3/2/11 3:34 AM, "Carlos Jes=FAs Bernardos Cano" <cjbc@it.uc3m.es> wr= ote: >>> >>>> >>>> I'm talking about a legacu IPv6 host. If I install Mobile IPv6 in >>>> that Linux stack, don't worry, the MIPv6 client takes care of >>>> configuring a CoA (sending an RS if no RA is received). >>>> >>>> Carlos >>>> >>>> >>> > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From julien.ietf@gmail.com Thu Mar 3 10:48:40 2011 Return-Path: <julien.ietf@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A7A93A67D3 for <netext@core3.amsl.com>; Thu, 3 Mar 2011 10:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.215 X-Spam-Level: X-Spam-Status: No, score=-3.215 tagged_above=-999 required=5 tests=[AWL=0.384, 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 x3SSGc17Sy-X for <netext@core3.amsl.com>; Thu, 3 Mar 2011 10:48:39 -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 124C43A6A1B for <netext@ietf.org>; Thu, 3 Mar 2011 10:48:38 -0800 (PST) Received: by fxm15 with SMTP id 15so1491953fxm.31 for <netext@ietf.org>; Thu, 03 Mar 2011 10:49:46 -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=Ki6Vqq6VhrR0UFjZKZW+doOOBjR1A5CjbvEQsffoCGg=; b=EWKKrZU1sJX8KPhrn9aEeX964kEdfxsCyZJMpzUPQOpKN5AqMbCI0KZ2YYO9Q1VY2O HKH3nT+bgIveX1yR+7HnZgHEGpqHMTXXg0Bspsgc8Gy+w1l+D4LQpvr3+gvepkiG/bhO D97uh7oLHmJHVYLrKc5qa4zyEGmwUb/ILrByo= 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=ZjIjOg5ZzkfPxzL1FLxZaUkUSBKcCnOxzTEGA3QRjeQ9Mn35DRYL8r2eqvGuuSBxs2 lJBiuPtItMYaVfG52whOBY7vcq+dL0qoWtFrlKJ3YcpcrkKYtnkyQTZ/+5VROzRrM3AX 84Ktp6OkACEpSLFxH2bTpA4lX+1f+CUFzkObk= MIME-Version: 1.0 Received: by 10.223.70.142 with SMTP id d14mr1878730faj.110.1299178186465; Thu, 03 Mar 2011 10:49:46 -0800 (PST) Received: by 10.223.93.141 with HTTP; Thu, 3 Mar 2011 10:49:46 -0800 (PST) In-Reply-To: <1299066222.5356.17.camel@acorde.it.uc3m.es> References: <C993D070.182DA%hesham@elevatemobile.com> <1299066222.5356.17.camel@acorde.it.uc3m.es> Date: Thu, 3 Mar 2011 10:49:46 -0800 Message-ID: <AANLkTi=ScUtUfSJLMC-bMbvopwV-fJMroSyvf4hmXsQy@mail.gmail.com> From: Julien Laganier <julien.ietf@gmail.com> 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" <JuanCarlos.Zuniga@interdigital.com> 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 03 Mar 2011 18:48:40 -0000 Hi Carlos, 2011/3/2 Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es>: > On Wed, 2011-03-02 at 10:46 +1100, Hesham Soliman wrote: >> >> >> On 2/03/11 6:30 AM, "Carlos Jes=FAs Bernardos Cano" <cjbc@it.uc3m.es> wr= ote: >> >> > Hi Hesham, >> > >> > On Tue, 2011-03-01 at 23:18 +1100, Hesham Soliman wrote: >> >>> >> >>> Well, I see quite potential for PMIPv6 over WLAN, why do you think t= here >> >>> would not be any serious WLAN deployment with PMIPv6? >> >> >> >> =3D> Because of the nature of the links, a router doesn't always know= who's >> >> attached. As you said earlier you make the MN send an RS, which is no= t >> >> required in IPv6. Also the address allocation is a mess and sharing t= he link >> > >> > PMIPv6 does not force any specific mechanism on how the MAG detects th= e >> > attachment of a MN. My experience with WLAN is quite OK so far, never >> > had a problem and it's quite easy to implement the AP trigger and the >> > ptp-to-ptp emulation on WLAN. >> >> =3D> Quiet easy? I think you must have a special WLAN in your lab :) >> I don't think so, if you think it's easy I think you've missed a lot of >> issues. See my points above and please respond specifically. > > - MN attachment detection: software on the AP that monitors the > association table (most drivers provide that feature). Ok. > - Point-to-point emulation: MAG send the RA to the unicast link-local > address of the MN or it sends it multicast in IPv6 but addressed to the > L2 address of the MN only. PMIPv6 assumes a point-to-point *link*. You are talking about unicasting RAs which implements a subnet in which only one MN stands. This doesn't give you a point-to-point link. Since we do not change the L3 between MN and MAG, a point-to-point link has to be provided at L2. How do you do that? > - We use L2 address as MN-ID (just for the sake of simplicity) If you use IEEE EUI-48 as MN-ID, how do you do flow mobility to a system that isn't 802 (e.g. 3GPP)? If you do not use IEEE EUI-48 as MN-ID, where do you get the MN-ID from? > What else do we need? with that I have legacy IPv6 clients (no > modification at all) roaming happily between MAGs :) See above... >> >> with MIPv6 nodes is very problematic. I'm not the right person to say= why >> >> PMIPv6 was created in the first place but I only see it used, if ever= , on >> >> p2p links whose use is strictly defined in SDOs. It was never intende= d, even >> >> by its proponents, to do flow mobility or global mobility and it can'= t do >> >> either one. >> > >> > I don't know the intention of the proponents of the protocol, but as >> > mentioned in other e-mail, I don't see any problem using it on WLAN >> > links. I see it working every day, and even doing flow mobility across >> > different technologies. >> >> =3D>I notice that you're giving generic responses. You're not addressing >> specific issues above. >> >> > >> >> The irony is that people wanted something that doesn't involve MN sig= nalling >> >> and now we'll expect signalling anyway, just not on L3. It's mind bog= gling. >> > >> > I don't expect signaling from the MN, that's the point. I see the valu= e >> > of PMIPv6 on this absence of MN involvement and that's why we are >> > proposing signaling on the core (MAG-LMA) to enable flow mobility >> > instead of putting all the requirements on the MN (for that we already >> > have MIPv6). >> >> =3D> If you think you can do flow mobility without MN involvement then g= ood >> luck with that. I'm starting to think that people on this list are in de= nial >> and it doesn't matter how many arguments are not being responded to, >> everyone comes back and says "it's doable". I think we're going to have = to >> leave this to the AD's because we're not making any progress. > > Well, I've seen prototypes of flow mobility working, with the only > artifact of the logical interface (or the weak host model) in the > terminal. So I say "it's doable" because I've done it or I've seen it > done. You can't assume weak host model. Remember the IP layer is unmodified. You can assume logical interface, but it has loads of unresolved issues that need to be taken care of, as per my comments during the meetings. I haven' t seen those resolved yet, so I do not know how doable or not it is. >> >> =3D> Really? And do you =A0call your operator if you remove your SIM = card and >> >> put it in another device?. Does you operator also know when you run n= ew SW >> >> on your phone/laptop? This is not a serious approach, I'm sorry but i= t's >> >> completely unreliable for any serious deployment >> > >> > You talking about serious approaches and operators?? from a pure-user >> > only perspective, I'm sorry to say that most current practices of >> > operators cannot be considered as "serious" :) >> >> =3D> Again, you're backing out of your points mentioned earlier :) Pleas= e >> respond to how you will make it work. > > We have a draft summarizing how solutions that I've seen working > operate. We still have unanswered questions left on the table. The drafts on the table do not answer those. --julien From julien.ietf@gmail.com Thu Mar 3 11:33:33 2011 Return-Path: <julien.ietf@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CF713A6847 for <netext@core3.amsl.com>; Thu, 3 Mar 2011 11:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.219 X-Spam-Level: X-Spam-Status: No, score=-3.219 tagged_above=-999 required=5 tests=[AWL=0.380, 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 1GI+LsiFyHbV for <netext@core3.amsl.com>; Thu, 3 Mar 2011 11:33:32 -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 A43483A67EF for <netext@ietf.org>; Thu, 3 Mar 2011 11:33:31 -0800 (PST) Received: by fxm15 with SMTP id 15so1539352fxm.31 for <netext@ietf.org>; Thu, 03 Mar 2011 11:34: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=eDwKOISvRtBf6ECFVQ287zTHINzbAJOq3Ukai3JYNgM=; b=nKDK+P/Rs9og4ZSDGEbn0a/0hT2h44tOdzW9V8rxMI46l7cFDVgwDHV8ittTGFYjEc 5aY4mlZhCPOwA9CdJv0W7AypW1YePWue427a7wnb99Akpx7LQTeWGTqg7GCH4RQaZgg5 +nn6VYuQml+L/q1CEOD7hzQdSA5C+UaRCnAZw= 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=Dc0tH9gomiMqkuvaVUlxcZK6PgoP27AsWOY2Fm1Vp/YVPL3KqMnsi4yNrsS6MwVPDk N07LabHbgMvKLzQqnuWdyT0iQzfPpBhDWxuSbzhweULM0bEoWESx1pdg7E0A9Wqgw3bt ioDwNQqkEzLWoUdxmj3Qt+OG8CXSurKv+D6Ho= MIME-Version: 1.0 Received: by 10.223.48.194 with SMTP id s2mr1930425faf.129.1299180879126; Thu, 03 Mar 2011 11:34:39 -0800 (PST) Received: by 10.223.93.141 with HTTP; Thu, 3 Mar 2011 11:34:39 -0800 (PST) In-Reply-To: <1298972332.10293.18.camel@acorde.it.uc3m.es> References: <AANLkTi=Fsr15UL7V=y1QovzN0OfgK8CTv3ito0Cz0MKL@mail.gmail.com> <C98C3FCF.DC9B%rkoodli@cisco.com> <D60519DB022FFA48974A25955FFEC08C03A5CAB6@SAM.InterDigital.com> <AANLkTikx7kDG+Ou5rwE1nJH=jo+HamFY=+YH6K4OHN9Z@mail.gmail.com> <1298663501.3608.141.camel@acorde.it.uc3m.es> <AANLkTi=zSij2NLJJWA6WfHRV4eCW2BS=rmQOfZCa7-4W@mail.gmail.com> <1298930405.3785.18.camel@acorde.it.uc3m.es> <AANLkTinrfghpCeK-Dr-OzuFUg0sLOveN=3EH5jtizOkS@mail.gmail.com> <1298972332.10293.18.camel@acorde.it.uc3m.es> Date: Thu, 3 Mar 2011 11:34:39 -0800 Message-ID: <AANLkTikOBeGB0U+2PGL1QWB+O0dMrCGg7TpgbA0PFTCA@mail.gmail.com> From: Julien Laganier <julien.ietf@gmail.com> 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" <JuanCarlos.Zuniga@interdigital.com> 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 03 Mar 2011 19:33:33 -0000 Hi Carlos, 2011/3/1 Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es>: > Hi Julien, > > On Mon, 2011-02-28 at 19:33 -0700, Julien Laganier wrote: >> 2011/2/28 Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es>: >> > Hi Julien, >> > >> > On Fri, 2011-02-25 at 12:59 -0700, Julien Laganier wrote: >> >> 2011/2/25 Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es>: >> >> > 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 signali= ng at >> >> > all. Optionally, I can enable the APs attached to the MAG detect th= e 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 PM= IPv6 >> >> > 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 complet= ely >> >> > 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. > > Well, there is a big difference between using the signalling that is > always there (no matter if is PMIPv6 in place or just a single station > attaching to an AP) and requiring L2 signalling to have additional > semantics to enable PMIPv6 operation. We just use triggers from the AP. If you target a 3GPP system for flow mobility between a PMIPv6-based 3GPP access (S5) and non-3GPP access (S2b), 3GPP " owns" the L2 signaling and can certainly extends it to support flow mobility. On the other hand if you rely upon the *unmodified* L2 signaling of an IEEE 802 media to provide flow mobility across an IEEE 802 media and a non-IEEE 802 media such as 3GPP, I don't understand how the thing would work, including: 1. how does network retrieve knowledge of the MN stack capabilities w.r.t. flow mobility / inter access handoff (e.g. logical interface support) ? 2. how does the network obtains knowledge of the MN-ID based on IEEE 802 L2 signaling? 3. how does the network provides a point-to-point link over a shared IEEE 802 media? ...and there are probably more but these three come to mind first... >> >> 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. > > You can have information about the capabilities of the device in your > database as well. If you rely on unmodified IEEE 802 signaling, should I take it as your solution be only applicable to monolithic devices integrating an IEEE 802.11 chipset? --julien From julien.ietf@gmail.com Thu Mar 3 11:43:26 2011 Return-Path: <julien.ietf@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 514D03A6844 for <netext@core3.amsl.com>; Thu, 3 Mar 2011 11:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.223 X-Spam-Level: X-Spam-Status: No, score=-3.223 tagged_above=-999 required=5 tests=[AWL=0.376, 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 e5Akqy7GrxnS for <netext@core3.amsl.com>; Thu, 3 Mar 2011 11:43:25 -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 37C263A69A4 for <netext@ietf.org>; Thu, 3 Mar 2011 11:43:25 -0800 (PST) Received: by fxm15 with SMTP id 15so1549127fxm.31 for <netext@ietf.org>; Thu, 03 Mar 2011 11:44: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; bh=xsWsHH/9anefGW8VITxqOG/Prb14wAQZxCQOyKY5nsc=; b=fzjVOpgfLCmFq1lhTW7Tzeg7xCQAp0LqnuPO0gmykX0GCGh44oT25ZtlX5rIotgKpc /RgdKw5jDplGCO3Df2OKyjBxmVNI5dL3tRQaOyFOb31CGSQqPBqOPr2OVOGyuzRvYFAz +Mn1p1jzcXQhZzlqe+CQkROICabPr8XlEw6Ww= 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=ZJUZJneD7TjUI7JjdKnC57JhIqHbJ6tRyv3v0/sOaue7CkxyXsOfmU/SCuA5ngSBKu STmeVoZn2ZcP34P43J68bCs5DigmMp0VtEJjWMT25d6WVCITd36P01YcGjxKq4SQMwhM GMynRS7sUkDFHbBl+0TrtEueH2HeVMMVWTQV8= MIME-Version: 1.0 Received: by 10.223.70.193 with SMTP id e1mr1984259faj.91.1299181472740; Thu, 03 Mar 2011 11:44:32 -0800 (PST) Received: by 10.223.93.141 with HTTP; Thu, 3 Mar 2011 11:44:32 -0800 (PST) In-Reply-To: <C993EAEA.E051%rkoodli@cisco.com> References: <4D6E9F44.7060202@piuha.net> <C993EAEA.E051%rkoodli@cisco.com> Date: Thu, 3 Mar 2011 11:44:32 -0800 Message-ID: <AANLkTim25tLfusBFkY35AFi_7fXucQ4etjKxj4y-KLEf@mail.gmail.com> From: Julien Laganier <julien.ietf@gmail.com> To: Rajeev Koodli <rkoodli@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Update on flow mobility following discussion with ADs X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 03 Mar 2011 19:43:26 -0000 Hi Rajeev, On Wed, Mar 2, 2011 at 12:39 PM, Rajeev Koodli <rkoodli@cisco.com> wrote: > > > On 3/2/11 11:49 AM, "Jari Arkko" <jari.arkko@piuha.net> wrote: > >> Sri: >> >> What Basavaraj said. I don't think the number of specifications is a big >> concern either now or later. Split the documents the way you like. Lets >> discuss functionality, robustness, assumptions instead -- those are >> important. > > > I agree that the spec should be robust, and should work under conditions > assuming existing & new L2 signaling, as well as under conditions when new > L2 signaling is unavailable. I have expressed doubts about the feasibility of a robust flow mobility / inter-access handover solution that relies on existing, unmodified L2 signaling (this is discussed in a different thread.) We should not sacrifice correctness and robustness for the sake of working around unmodified L2 signaling. As I've said earlier, one of the potential customer for this (3GPP) owns two L2 that are used to access their system (PMIP based S5 for 3GPP accesses, and PMIP based S2b for no-3GPP accesses.) > It's a question of whether we agree that LMA-MAG signaling could also be > used in addition to relying only on L2 signaling for flow mobility. At this stage the question is rather, is it possible to provide a correct and robust system without modified L2 signaling. If it is, then we can go ahead with the question you laid above. Would you agree? >> (And of course, splitting to different specifications should not be >> misused to hide a technical omission or a problem.) > > I would focus on getting a protocol that works under different cases and not > just under continued reliance on (existing and new) L2 signaling. (I am not > referring to new IP signaling between MN and MAG). See above. The focus you propose is only appropriate insofar we've come up with a positive answer to the question I asked above, and that we' re discussing with Carlos, Hesham, et al. --julien From sgundave@cisco.com Thu Mar 3 14:41:12 2011 Return-Path: <sgundave@cisco.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 720E93A687B for <netext@core3.amsl.com>; Thu, 3 Mar 2011 14:41:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.357 X-Spam-Level: X-Spam-Status: No, score=-9.357 tagged_above=-999 required=5 tests=[AWL=-0.154, 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 NHfI-HGbVgG2 for <netext@core3.amsl.com>; Thu, 3 Mar 2011 14:41:11 -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 1A2273A67D9 for <netext@ietf.org>; Thu, 3 Mar 2011 14:41:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=5266; q=dns/txt; s=iport; t=1299192139; x=1300401739; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=DZ2GLvMhhNpR071KjobOSaOtZt0K45RA5niVBety944=; b=k20cRqN3Wz+FbG+QssiZ7q2CIFDm4qSHJIK7KN/NDlO1vgONFxT6tIQh Dn5GFjvkkPgdBgKtLmD3zKVLA1Y6chPBe1YheCMVnl6Jk7Pn5rvqxIWtM P9mBGszRTKRxMfrQEyW2Lzbb/8IzTUmMPDJgpwj11+BxPVvLGdvQX2FDg 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgAAMunb02rR7H+/2dsb2JhbACYIY1pXXSiapwXhWEEhRqHEoNIgxI X-IronPort-AV: E=Sophos;i="4.62,260,1297036800"; d="scan'208";a="665367045" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 03 Mar 2011 22:42:19 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p23MgG3K021451; Thu, 3 Mar 2011 22:42:19 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 Mar 2011 14:42:18 -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 ; Thu, 3 Mar 2011 22:42:17 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 03 Mar 2011 14:43:47 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: Julien Laganier <julien.ietf@gmail.com> Message-ID: <C99559A3.11E25%sgundave@cisco.com> Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvZ9HUYG5ND0JhDr0SoBNZH5B8Z4A== In-Reply-To: <AANLkTinZUYi3PtGhD3NdORmouwHk-oJVDyLRamkU5JP2@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 03 Mar 2011 22:42:18.0345 (UTC) FILETIME=[40412590:01CBD9F4] Cc: netext@ietf.org, JuanCarlos.Zuniga@interdigital.com, Basavaraj.Patil@nokia.com 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 03 Mar 2011 22:41:12 -0000 Julien: RS message can get lost and in sequence, sure, like any other IP packet. So= , the host using stateless autoconf can never configure an IPv6 address, till it receives a router advertisement message. So, enabling RA suppress is not desirable. It is also unreliable for any IP host on a normal IPv6 link to obtain prefix information, given the probability that RS/RA messages can ge= t lost. I agree, its the same level of unreliability exists in case of PMIPv6= , which is one of the triggers for the protocol operation, not just for flow mobility. Regards Sri On 3/3/11 10:40 AM, "Julien Laganier" <julien.ietf@gmail.com> wrote: > Sri, >=20 > Whether or not a host stack send an RS when a link-up event happens is > irrelevant to the design of the PMIPv6 flow mobility for the two > following reasons: >=20 > 1. Stacks with DNAv6 would send an RS, other stack would not. So it's > not generic and can't be relied upon. > 2. Even if all stacks were sending RS. RS can be lost. So it's not > reliable and can' t be relied upon. >=20 > --julien >=20 > On Wed, Mar 2, 2011 at 9:13 AM, Sri Gundavelli <sgundave@cisco.com> wrote= : >> Yes, it is relevant in the context of the current discussion. If we are = not >> on the same page, as how a simple IP host behaves across L3 roams, we ar= e >> not going to converge on what new events L2 or L3 we need. So, this is >> relevant. >>=20 >>=20 >>=20 >> Thanks >> Sri >>=20 >>=20 >>=20 >> On 3/2/11 8:53 AM, "Basavaraj.Patil@nokia.com" <Basavaraj.Patil@nokia.co= m> >> wrote: >>=20 >>>=20 >>> Folks, >>>=20 >>> Is this discussion about how MIP6 works even relevant in the context of= the >>> flow mobility discussion? >>> There are other questions and concerns that have been raised which I wo= uld >>> advise the authors to focus on. >>>=20 >>> If you need to understand how movement detection in MIP6 works, please = refer >>> to Sec 11.5 of RFC3775. >>>=20 >>> -Raj >>>=20 >>> -----Original Message----- >>> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behal= f Of >>> ext Carlos Jes=FAs Bernardos Cano >>> Sent: Wednesday, March 02, 2011 10:49 AM >>> To: Sri Gundavelli >>> Cc: netext@ietf.org; Zuniga, Juan Carlos >>> Subject: Re: [netext] Flow Mobility discussion - way forward? >>>=20 >>> Hi Sri, >>>=20 >>> On Wed, 2011-03-02 at 08:16 -0800, Sri Gundavelli wrote: >>>>> I'm talking about a legacu IPv6 host. If I install Mobile IPv6 in >>>>> that Linux stack, don't worry, the MIPv6 client takes care of >>>>> configuring a CoA (sending an RS if no RA is received). >>>>>=20 >>>>=20 >>>> Hi Carlos: >>>>=20 >>>> (Still keeping the discussion context to this one comment). >>>>=20 >>>> - I assume MIPv6 stack is on top of IP stack, not the other way around >>>=20 >>> Well, i reality MIPv6 is part of IPv6, not really sits on top. >>>=20 >>>>=20 >>>> - If IP stack does not detect movement detection across L3 links (in >>>> the absence of any other hints about same L3 link, in the forms essid >>>> or other hints), how does the MIPv6 stack which is relying on the >>>> stack/kernel events, decide to force an RA ? What is the hint ? How >>>> come ND/DHCP does not realize the same need to send an RS ? Is MIPv6 s= tack >>>> so >>>> smart ? >>>=20 >>> The implementations that I'm familiar with do the following: >>>=20 >>> - They wait for an unsolicited RA >>> - If no unsolicited RA is received in a time interval equal to 2 times = the >>> frequency of RAs (there is information about that on the RAs), the MN s= ends >>> an >>> RS. >>>=20 >>>>=20 >>>> - Assuming there is no MIPv6 stack on the host, an host moves across >>>> access links, it will never do an RS and will keep using the address >>>> from the previous link. So, the basic IPv6 connectivity is broken. >>>> This is a bug, not a protocol gap. >>>=20 >>> With WLAN and Linux, that's the behavior. I guess developers understood= that >>> two APs with the same ESSID belongs to the same ESS, and therefore the = same >>> IP >>> subnet. That actually is correct and cannot be cataloged as "bug". >>>=20 >>>>=20 >>>> PS: I heard about this RS problems 5 years back, when most WLAN >>>> drivers were not handling IPv6 correctly. I'm pretty sure all the WLAN >>>> drivers have fixed those problems now. You may want to replace your >>>> buggy NIC card driver :) >>>=20 >>> It's not a buggy NIC card driver. You may say a buggy OS, but I honestl= y >>> will >>> not call Linux "buggy" (or at least buggier than many others that are o= ut >>> there). >>>=20 >>> Carlos >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Regards >>>> Sri >>>>=20 >>>>=20 >>>>=20 >>>> On 3/2/11 3:34 AM, "Carlos Jes=FAs Bernardos Cano" <cjbc@it.uc3m.es> wro= te: >>>>=20 >>>>>=20 >>>>> I'm talking about a legacu IPv6 host. If I install Mobile IPv6 in >>>>> that Linux stack, don't worry, the MIPv6 client takes care of >>>>> configuring a CoA (sending an RS if no RA is received). >>>>>=20 >>>>> Carlos >>>>>=20 >>>>>=20 >>>>=20 >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >>=20 From julien.ietf@gmail.com Thu Mar 3 14:58:12 2011 Return-Path: <julien.ietf@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AF973A6889 for <netext@core3.amsl.com>; Thu, 3 Mar 2011 14:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.227 X-Spam-Level: X-Spam-Status: No, score=-3.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 FvBbEiITgVfk for <netext@core3.amsl.com>; Thu, 3 Mar 2011 14:58: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 5F2AB3A67D9 for <netext@ietf.org>; Thu, 3 Mar 2011 14:58:10 -0800 (PST) Received: by fxm15 with SMTP id 15so1733350fxm.31 for <netext@ietf.org>; Thu, 03 Mar 2011 14:59: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 :content-transfer-encoding; bh=RdNI7YYA3iDOg2CQwqNVw7JbA7TpfPkK6D97cAN5LaA=; b=Zheg2F+YalHjO0rgh3oE9Zcie/euNTnOrmhgD4XllL8LrkrfSqJPAmjgIiLH/pi3gi 7Y9Am1DPLq6lL5mAKwAlApPnDjyYgglPlRwBaonKi8a9GhzEMNlWEMOD14D+4OEDW4k5 B1PRkjtxuupiKZWt8kXLtacWPuGO/okjGhJ6Q= 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=IUttpMvlea6x3mpG+u4Qmf7rGnICxf5PzhtiFNp68KVdrswmv9b1gGevYQR1P5Ac8Y t3Mz+PMv8T56rhANCkPgUouV9t6SOifreQyquAF54xZB17Li8nhhbeqjVtySw7Pe7LBl 4jXEfdGKcymeXMoekysyNpxgRmzWfVSPuOD/Y= MIME-Version: 1.0 Received: by 10.223.74.5 with SMTP id s5mr2222333faj.72.1299193157937; Thu, 03 Mar 2011 14:59:17 -0800 (PST) Received: by 10.223.93.141 with HTTP; Thu, 3 Mar 2011 14:59:17 -0800 (PST) In-Reply-To: <C99559A3.11E25%sgundave@cisco.com> References: <AANLkTinZUYi3PtGhD3NdORmouwHk-oJVDyLRamkU5JP2@mail.gmail.com> <C99559A3.11E25%sgundave@cisco.com> Date: Thu, 3 Mar 2011 14:59:17 -0800 Message-ID: <AANLkTikYtWznF75jxre++hExwVXZ+fB6CHpHd=i==pDL@mail.gmail.com> From: Julien Laganier <julien.ietf@gmail.com> To: Sri Gundavelli <sgundave@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org, JuanCarlos.Zuniga@interdigital.com, Basavaraj.Patil@nokia.com 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 03 Mar 2011 22:58:12 -0000 Sri, In the ND case, when RS are lost, an IPv6 host will eventually obtain prefix information via receiving a periodic RA, configure an address with SLAAC, and be connected to the Internet. In contrast, in the PMIPv6 case, relying on RS as a mobility trigger can lead to a failure mode in which the host is never detected by the PMIPv6 fabric and has no connectivity to the Internet. --julien On Thu, Mar 3, 2011 at 2:43 PM, Sri Gundavelli <sgundave@cisco.com> wrote: > Julien: > > RS message can get lost and in sequence, sure, like any other IP packet. = So, > the host using stateless autoconf can never configure an IPv6 address, ti= ll > it receives a router advertisement message. So, enabling RA suppress is n= ot > desirable. It is also unreliable for any IP host on a normal IPv6 link to > obtain prefix information, given the probability that RS/RA messages can = get > lost. I agree, its the same level of unreliability exists in case of PMIP= v6, > which is one of the triggers for the protocol operation, not just for flo= w > mobility. > > > > Regards > Sri > > > > On 3/3/11 10:40 AM, "Julien Laganier" <julien.ietf@gmail.com> wrote: > >> Sri, >> >> Whether or not a host stack send an RS when a link-up event happens is >> irrelevant to the design of the PMIPv6 flow mobility for the two >> following reasons: >> >> 1. Stacks with DNAv6 would send an RS, other stack would not. So it's >> not generic and can't be relied upon. >> 2. Even if all stacks were sending RS. RS can be lost. So it's not >> reliable and can' t be relied upon. >> >> --julien >> >> On Wed, Mar 2, 2011 at 9:13 AM, Sri Gundavelli <sgundave@cisco.com> wrot= e: >>> Yes, it is relevant in the context of the current discussion. If we are= not >>> on the same page, as how a simple IP host behaves across L3 roams, we a= re >>> not going to converge on what new events L2 or L3 we need. So, this is >>> relevant. >>> >>> >>> >>> Thanks >>> Sri >>> >>> >>> >>> On 3/2/11 8:53 AM, "Basavaraj.Patil@nokia.com" <Basavaraj.Patil@nokia.c= om> >>> wrote: >>> >>>> >>>> Folks, >>>> >>>> Is this discussion about how MIP6 works even relevant in the context o= f the >>>> flow mobility discussion? >>>> There are other questions and concerns that have been raised which I w= ould >>>> advise the authors to focus on. >>>> >>>> If you need to understand how movement detection in MIP6 works, please= refer >>>> to Sec 11.5 of RFC3775. >>>> >>>> -Raj >>>> >>>> -----Original Message----- >>>> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Beha= lf Of >>>> ext Carlos Jes=FAs Bernardos Cano >>>> Sent: Wednesday, March 02, 2011 10:49 AM >>>> To: Sri Gundavelli >>>> Cc: netext@ietf.org; Zuniga, Juan Carlos >>>> Subject: Re: [netext] Flow Mobility discussion - way forward? >>>> >>>> Hi Sri, >>>> >>>> On Wed, 2011-03-02 at 08:16 -0800, Sri Gundavelli wrote: >>>>>> I'm talking about a legacu IPv6 host. If I install Mobile IPv6 in >>>>>> that Linux stack, don't worry, the MIPv6 client takes care of >>>>>> configuring a CoA (sending an RS if no RA is received). >>>>>> >>>>> >>>>> Hi Carlos: >>>>> >>>>> (Still keeping the discussion context to this one comment). >>>>> >>>>> - I assume MIPv6 stack is on top of IP stack, not the other way aroun= d >>>> >>>> Well, i reality MIPv6 is part of IPv6, not really sits on top. >>>> >>>>> >>>>> - If IP stack does not detect movement detection across L3 links (in >>>>> the absence of any other hints about same L3 link, in the forms essid >>>>> or other hints), how does the MIPv6 stack which is relying on the >>>>> stack/kernel events, decide to force an RA ? What is the hint ? How >>>>> come ND/DHCP does not realize the same need to send an RS ? Is MIPv6 = stack >>>>> so >>>>> smart ? >>>> >>>> The implementations that I'm familiar with do the following: >>>> >>>> - They wait for an unsolicited RA >>>> - If no unsolicited RA is received in a time interval equal to 2 times= the >>>> frequency of RAs (there is information about that on the RAs), the MN = sends >>>> an >>>> RS. >>>> >>>>> >>>>> - Assuming there is no MIPv6 stack on the host, an host moves across >>>>> access links, it will never do an RS and will keep using the address >>>>> from the previous link. So, the basic IPv6 connectivity is broken. >>>>> This is a bug, not a protocol gap. >>>> >>>> With WLAN and Linux, that's the behavior. I guess developers understoo= d that >>>> two APs with the same ESSID belongs to the same ESS, and therefore the= same >>>> IP >>>> subnet. That actually is correct and cannot be cataloged as "bug". >>>> >>>>> >>>>> PS: I heard about this RS problems 5 years back, when most WLAN >>>>> drivers were not handling IPv6 correctly. I'm pretty sure all the WLA= N >>>>> drivers have fixed those problems now. You may want to replace your >>>>> buggy NIC card driver :) >>>> >>>> It's not a buggy NIC card driver. You may say a buggy OS, but I honest= ly >>>> will >>>> not call Linux "buggy" (or at least buggier than many others that are = out >>>> there). >>>> >>>> Carlos >>>> >>>>> >>>>> >>>>> >>>>> Regards >>>>> Sri >>>>> >>>>> >>>>> >>>>> On 3/2/11 3:34 AM, "Carlos Jes=FAs Bernardos Cano" <cjbc@it.uc3m.es> = wrote: >>>>> >>>>>> >>>>>> I'm talking about a legacu IPv6 host. If I install Mobile IPv6 in >>>>>> that Linux stack, don't worry, the MIPv6 client takes care of >>>>>> configuring a CoA (sending an RS if no RA is received). >>>>>> >>>>>> Carlos >>>>>> >>>>>> >>>>> >>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>> > > From trac+netext@trac.tools.ietf.org Thu Mar 3 15:01:15 2011 Return-Path: <trac+netext@trac.tools.ietf.org> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 358E328C0F6 for <netext@core3.amsl.com>; Thu, 3 Mar 2011 15:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 9ZWQoOSxf9l6 for <netext@core3.amsl.com>; Thu, 3 Mar 2011 15:01:14 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7CAD128C0EF for <netext@ietf.org>; Thu, 3 Mar 2011 15:01:14 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac+netext@trac.tools.ietf.org>) id 1PvHXG-0008Bf-0p; Thu, 03 Mar 2011 15:02:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "netext issue tracker" <trac+netext@trac.tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: telemaco.melia@alcatel-lucent.com, basavaraj.patil@nokia.com X-Trac-Project: netext Date: Thu, 03 Mar 2011 23:02:17 -0000 X-URL: http://tools.ietf.org/netext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/netext/trac/ticket/6 Message-ID: <066.f305ff5de33bd8d607b12a7ab7d8e54b@trac.tools.ietf.org> X-Trac-Ticket-ID: 6 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: telemaco.melia@alcatel-lucent.com, basavaraj.patil@nokia.com, netext@ietf.org X-SA-Exim-Mail-From: trac+netext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: netext@ietf.org Subject: [netext] #6: Logical interface: MTU issues X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 03 Mar 2011 23:01:15 -0000 #6: Logical interface: MTU issues Question about the logical interface MTU: -> what is the logical interface MTU? -> How do handoffs between two underlying interfaces with dissimilar MTU impacts PMTUD, and transport protocols -- ---------------------------------------+------------------------------------ Reporter: basavaraj.patil@… | Owner: telemaco.melia@… Type: defect | Status: new Priority: major | Milestone: Component: logical-interface-support | Version: Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/6> netext <http://tools.ietf.org/netext/> From trac+netext@trac.tools.ietf.org Thu Mar 3 15:02:13 2011 Return-Path: <trac+netext@trac.tools.ietf.org> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEE023A67D9 for <netext@core3.amsl.com>; Thu, 3 Mar 2011 15:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 PX58KlsxZ10N for <netext@core3.amsl.com>; Thu, 3 Mar 2011 15:02:13 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1523A3A68D1 for <netext@ietf.org>; Thu, 3 Mar 2011 15:02:13 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac+netext@trac.tools.ietf.org>) id 1PvHYE-0008KW-HW; Thu, 03 Mar 2011 15:03:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "netext issue tracker" <trac+netext@trac.tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: telemaco.melia@alcatel-lucent.com, basavaraj.patil@nokia.com X-Trac-Project: netext Date: Thu, 03 Mar 2011 23:03:18 -0000 X-URL: http://tools.ietf.org/netext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/netext/trac/ticket/7 Message-ID: <066.0751fc96f72ccc7f3cfc7cb7f3fb948e@trac.tools.ietf.org> X-Trac-Ticket-ID: 7 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: telemaco.melia@alcatel-lucent.com, basavaraj.patil@nokia.com, netext@ietf.org X-SA-Exim-Mail-From: trac+netext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: netext@ietf.org Subject: [netext] #7: Logical interface: UL/DL packet processing X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 03 Mar 2011 23:02:13 -0000 #7: Logical interface: UL/DL packet processing Uplink/downlink packet matching: Draft says the Logical interface should transmit uplink packets on the same physical interface on which the downlink packet was received for the particular prefix/flow. How does the logical interface associates an uplink packet to a downlink packet? -- ---------------------------------------+------------------------------------ Reporter: basavaraj.patil@… | Owner: telemaco.melia@… Type: defect | Status: new Priority: major | Milestone: Component: Localized routing | Version: Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/7> netext <http://tools.ietf.org/netext/> From sgundave@cisco.com Thu Mar 3 15:09:35 2011 Return-Path: <sgundave@cisco.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 958DF3A68D9 for <netext@core3.amsl.com>; Thu, 3 Mar 2011 15:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.348 X-Spam-Level: X-Spam-Status: No, score=-9.348 tagged_above=-999 required=5 tests=[AWL=-0.145, 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 TltqYwRA-Nl8 for <netext@core3.amsl.com>; Thu, 3 Mar 2011 15:09:34 -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 459FF3A68D6 for <netext@ietf.org>; Thu, 3 Mar 2011 15:09:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=6629; q=dns/txt; s=iport; t=1299193842; x=1300403442; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=v0Hzb6AGNfo1lDSHimGjBCPJ0I7OGkfB1IEHfmSnI3c=; b=dz/D/qpeMyvdGGS7cPSIdOvR+M4A8tQm52FeePZNm14tG4Tbeg4HYOTh Q4d3kRDkGSLvHu2EUezWexFpagzK4kbHJ/8rFKeMFtJRDZCqeMkEXrlcZ laeBqc5riaV/bhg5cd+T3CWU1MtSWJxlBbGfLvQw5iqb79YlDzB+sDXtj A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgAAB6ub02rRN+K/2dsb2JhbACYIY1pXXSiNpwXhWEEhRqHEoNIgxI X-IronPort-AV: E=Sophos;i="4.62,260,1297036800"; d="scan'208";a="412040995" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 03 Mar 2011 23:10:42 +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 p23NAgmW018669; Thu, 3 Mar 2011 23:10:42 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 Mar 2011 15:10:41 -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 ; Thu, 3 Mar 2011 23:10:41 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 03 Mar 2011 15:12:10 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: Julien Laganier <julien.ietf@gmail.com> Message-ID: <C995604A.11E3F%sgundave@cisco.com> Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvZ+GwqM3i4vBIYv0S4SSX0HbqFWA== In-Reply-To: <AANLkTikYtWznF75jxre++hExwVXZ+fB6CHpHd=i==pDL@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 03 Mar 2011 23:10:41.0852 (UTC) FILETIME=[379FAFC0:01CBD9F8] Cc: netext@ietf.org, JuanCarlos.Zuniga@interdigital.com, Basavaraj.Patil@nokia.com 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 03 Mar 2011 23:09:35 -0000 Julien, Sure, assuming the router is not provisioned to suppress periodic RA's and based on the RA frequency, an IPv6 host will eventually obtain an address. In case of PMIPv6, the same periodic RA with no PIO's will enable the host to retrigger the RS for PIO's and allow the router to discover the host and present its PIO's. Sri On 3/3/11 2:59 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: > Sri, >=20 > In the ND case, when RS are lost, an IPv6 host will eventually obtain > prefix information via receiving a periodic RA, configure an address > with SLAAC, and be connected to the Internet. >=20 > In contrast, in the PMIPv6 case, relying on RS as a mobility trigger > can lead to a failure mode in which the host is never detected by the > PMIPv6 fabric and has no connectivity to the Internet. >=20 > --julien >=20 > On Thu, Mar 3, 2011 at 2:43 PM, Sri Gundavelli <sgundave@cisco.com> wrote= : >> Julien: >>=20 >> RS message can get lost and in sequence, sure, like any other IP packet.= So, >> the host using stateless autoconf can never configure an IPv6 address, t= ill >> it receives a router advertisement message. So, enabling RA suppress is = not >> desirable. It is also unreliable for any IP host on a normal IPv6 link t= o >> obtain prefix information, given the probability that RS/RA messages can= get >> lost. I agree, its the same level of unreliability exists in case of PMI= Pv6, >> which is one of the triggers for the protocol operation, not just for fl= ow >> mobility. >>=20 >>=20 >>=20 >> Regards >> Sri >>=20 >>=20 >>=20 >> On 3/3/11 10:40 AM, "Julien Laganier" <julien.ietf@gmail.com> wrote: >>=20 >>> Sri, >>>=20 >>> Whether or not a host stack send an RS when a link-up event happens is >>> irrelevant to the design of the PMIPv6 flow mobility for the two >>> following reasons: >>>=20 >>> 1. Stacks with DNAv6 would send an RS, other stack would not. So it's >>> not generic and can't be relied upon. >>> 2. Even if all stacks were sending RS. RS can be lost. So it's not >>> reliable and can' t be relied upon. >>>=20 >>> --julien >>>=20 >>> On Wed, Mar 2, 2011 at 9:13 AM, Sri Gundavelli <sgundave@cisco.com> wro= te: >>>> Yes, it is relevant in the context of the current discussion. If we ar= e not >>>> on the same page, as how a simple IP host behaves across L3 roams, we = are >>>> not going to converge on what new events L2 or L3 we need. So, this is >>>> relevant. >>>>=20 >>>>=20 >>>>=20 >>>> Thanks >>>> Sri >>>>=20 >>>>=20 >>>>=20 >>>> On 3/2/11 8:53 AM, "Basavaraj.Patil@nokia.com" <Basavaraj.Patil@nokia.= com> >>>> wrote: >>>>=20 >>>>>=20 >>>>> Folks, >>>>>=20 >>>>> Is this discussion about how MIP6 works even relevant in the context = of >>>>> the >>>>> flow mobility discussion? >>>>> There are other questions and concerns that have been raised which I = would >>>>> advise the authors to focus on. >>>>>=20 >>>>> If you need to understand how movement detection in MIP6 works, pleas= e >>>>> refer >>>>> to Sec 11.5 of RFC3775. >>>>>=20 >>>>> -Raj >>>>>=20 >>>>> -----Original Message----- >>>>> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Beh= alf >>>>> Of >>>>> ext Carlos Jes=FAs Bernardos Cano >>>>> Sent: Wednesday, March 02, 2011 10:49 AM >>>>> To: Sri Gundavelli >>>>> Cc: netext@ietf.org; Zuniga, Juan Carlos >>>>> Subject: Re: [netext] Flow Mobility discussion - way forward? >>>>>=20 >>>>> Hi Sri, >>>>>=20 >>>>> On Wed, 2011-03-02 at 08:16 -0800, Sri Gundavelli wrote: >>>>>>> I'm talking about a legacu IPv6 host. If I install Mobile IPv6 in >>>>>>> that Linux stack, don't worry, the MIPv6 client takes care of >>>>>>> configuring a CoA (sending an RS if no RA is received). >>>>>>>=20 >>>>>>=20 >>>>>> Hi Carlos: >>>>>>=20 >>>>>> (Still keeping the discussion context to this one comment). >>>>>>=20 >>>>>> - I assume MIPv6 stack is on top of IP stack, not the other way arou= nd >>>>>=20 >>>>> Well, i reality MIPv6 is part of IPv6, not really sits on top. >>>>>=20 >>>>>>=20 >>>>>> - If IP stack does not detect movement detection across L3 links (in >>>>>> the absence of any other hints about same L3 link, in the forms essi= d >>>>>> or other hints), how does the MIPv6 stack which is relying on the >>>>>> stack/kernel events, decide to force an RA ? What is the hint ? How >>>>>> come ND/DHCP does not realize the same need to send an RS ? Is MIPv6 >>>>>> stack >>>>>> so >>>>>> smart ? >>>>>=20 >>>>> The implementations that I'm familiar with do the following: >>>>>=20 >>>>> - They wait for an unsolicited RA >>>>> - If no unsolicited RA is received in a time interval equal to 2 time= s the >>>>> frequency of RAs (there is information about that on the RAs), the MN >>>>> sends >>>>> an >>>>> RS. >>>>>=20 >>>>>>=20 >>>>>> - Assuming there is no MIPv6 stack on the host, an host moves across >>>>>> access links, it will never do an RS and will keep using the address >>>>>> from the previous link. So, the basic IPv6 connectivity is broken. >>>>>> This is a bug, not a protocol gap. >>>>>=20 >>>>> With WLAN and Linux, that's the behavior. I guess developers understo= od >>>>> that >>>>> two APs with the same ESSID belongs to the same ESS, and therefore th= e >>>>> same >>>>> IP >>>>> subnet. That actually is correct and cannot be cataloged as "bug". >>>>>=20 >>>>>>=20 >>>>>> PS: I heard about this RS problems 5 years back, when most WLAN >>>>>> drivers were not handling IPv6 correctly. I'm pretty sure all the WL= AN >>>>>> drivers have fixed those problems now. You may want to replace your >>>>>> buggy NIC card driver :) >>>>>=20 >>>>> It's not a buggy NIC card driver. You may say a buggy OS, but I hones= tly >>>>> will >>>>> not call Linux "buggy" (or at least buggier than many others that are= out >>>>> there). >>>>>=20 >>>>> Carlos >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Regards >>>>>> Sri >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 3/2/11 3:34 AM, "Carlos Jes=FAs Bernardos Cano" <cjbc@it.uc3m.es> w= rote: >>>>>>=20 >>>>>>>=20 >>>>>>> I'm talking about a legacu IPv6 host. If I install Mobile IPv6 in >>>>>>> that Linux stack, don't worry, the MIPv6 client takes care of >>>>>>> configuring a CoA (sending an RS if no RA is received). >>>>>>>=20 >>>>>>> Carlos >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>>=20 >>=20 >>=20 From cjbc@it.uc3m.es Thu Mar 3 15:30:16 2011 Return-Path: <cjbc@it.uc3m.es> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5DDD3A6872 for <netext@core3.amsl.com>; Thu, 3 Mar 2011 15:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[AWL=0.056, 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 S9Cf3nhCXW2I for <netext@core3.amsl.com>; Thu, 3 Mar 2011 15:30:15 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id CED0A3A68D8 for <netext@ietf.org>; Thu, 3 Mar 2011 15:30:14 -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 BB1EB75A3BB; Fri, 4 Mar 2011 00:31:21 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <cjbc@it.uc3m.es> To: Julien Laganier <julien.ietf@gmail.com> In-Reply-To: <AANLkTi=ScUtUfSJLMC-bMbvopwV-fJMroSyvf4hmXsQy@mail.gmail.com> References: <C993D070.182DA%hesham@elevatemobile.com> <1299066222.5356.17.camel@acorde.it.uc3m.es> <AANLkTi=ScUtUfSJLMC-bMbvopwV-fJMroSyvf4hmXsQy@mail.gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-RWML/NqjJNZR1N+bxNCB" Organization: Universidad Carlos III de Madrid Date: Fri, 04 Mar 2011 00:32:47 +0100 Message-ID: <1299195167.3889.30.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-17990.002 Cc: netext@ietf.org, "Zuniga, Juan Carlos" <JuanCarlos.Zuniga@interdigital.com> 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 03 Mar 2011 23:30:16 -0000 --=-RWML/NqjJNZR1N+bxNCB Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Julien, On Thu, 2011-03-03 at 10:49 -0800, Julien Laganier wrote: > Hi Carlos, >=20 > 2011/3/2 Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es>: > > On Wed, 2011-03-02 at 10:46 +1100, Hesham Soliman wrote: > >> > >> > >> On 2/03/11 6:30 AM, "Carlos Jes=FAs Bernardos Cano" <cjbc@it.uc3m.es> = wrote: > >> > >> > Hi Hesham, > >> > > >> > On Tue, 2011-03-01 at 23:18 +1100, Hesham Soliman wrote: > >> >>> > >> >>> Well, I see quite potential for PMIPv6 over WLAN, why do you think= there > >> >>> would not be any serious WLAN deployment with PMIPv6? > >> >> > >> >> =3D> Because of the nature of the links, a router doesn't always kn= ow who's > >> >> attached. As you said earlier you make the MN send an RS, which is = not > >> >> required in IPv6. Also the address allocation is a mess and sharing= the link > >> > > >> > PMIPv6 does not force any specific mechanism on how the MAG detects = the > >> > attachment of a MN. My experience with WLAN is quite OK so far, neve= r > >> > had a problem and it's quite easy to implement the AP trigger and th= e > >> > ptp-to-ptp emulation on WLAN. > >> > >> =3D> Quiet easy? I think you must have a special WLAN in your lab :) > >> I don't think so, if you think it's easy I think you've missed a lot o= f > >> issues. See my points above and please respond specifically. > > > > - MN attachment detection: software on the AP that monitors the > > association table (most drivers provide that feature). >=20 > Ok. >=20 > > - Point-to-point emulation: MAG send the RA to the unicast link-local > > address of the MN or it sends it multicast in IPv6 but addressed to the > > L2 address of the MN only. >=20 > PMIPv6 assumes a point-to-point *link*. You are talking about > unicasting RAs which implements a subnet in which only one MN stands. > This doesn't give you a point-to-point link. Since we do not change > the L3 between MN and MAG, a point-to-point link has to be provided at > L2. How do you do that? I've just described how I make our lab proto work, emulating a point-to-point link over a point-to-multipoint one. >=20 > > - We use L2 address as MN-ID (just for the sake of simplicity) >=20 > If you use IEEE EUI-48 as MN-ID, how do you do flow mobility to a > system that isn't 802 (e.g. 3GPP)? All my previous e-mails about the lab prototype and WLAN refers to basic PMIPv6, I haven't mentioned anything about flow mobility in that context. That's a separate issue. >=20 > If you do not use IEEE EUI-48 as MN-ID, where do you get the MN-ID from? >=20 > > What else do we need? with that I have legacy IPv6 clients (no > > modification at all) roaming happily between MAGs :) >=20 > See above... >=20 > >> >> with MIPv6 nodes is very problematic. I'm not the right person to s= ay why > >> >> PMIPv6 was created in the first place but I only see it used, if ev= er, on > >> >> p2p links whose use is strictly defined in SDOs. It was never inten= ded, even > >> >> by its proponents, to do flow mobility or global mobility and it ca= n't do > >> >> either one. > >> > > >> > I don't know the intention of the proponents of the protocol, but as > >> > mentioned in other e-mail, I don't see any problem using it on WLAN > >> > links. I see it working every day, and even doing flow mobility acro= ss > >> > different technologies. > >> > >> =3D>I notice that you're giving generic responses. You're not addressi= ng > >> specific issues above. > >> > >> > > >> >> The irony is that people wanted something that doesn't involve MN s= ignalling > >> >> and now we'll expect signalling anyway, just not on L3. It's mind b= oggling. > >> > > >> > I don't expect signaling from the MN, that's the point. I see the va= lue > >> > of PMIPv6 on this absence of MN involvement and that's why we are > >> > proposing signaling on the core (MAG-LMA) to enable flow mobility > >> > instead of putting all the requirements on the MN (for that we alrea= dy > >> > have MIPv6). > >> > >> =3D> If you think you can do flow mobility without MN involvement then= good > >> luck with that. I'm starting to think that people on this list are in = denial > >> and it doesn't matter how many arguments are not being responded to, > >> everyone comes back and says "it's doable". I think we're going to hav= e to > >> leave this to the AD's because we're not making any progress. > > > > Well, I've seen prototypes of flow mobility working, with the only > > artifact of the logical interface (or the weak host model) in the > > terminal. So I say "it's doable" because I've done it or I've seen it > > done. >=20 > You can't assume weak host model. Remember the IP layer is unmodified. True, in IETF I cannot assume that. I've just wanted to make the point that the same network signaling used in a prototype worked for terminals with the logical interface artifact and with the weak host model. But I just mentioned that to provide proof that I've seen the concepts we are discussing in a working system. >=20 > You can assume logical interface, but it has loads of unresolved > issues that need to be taken care of, as per my comments during the > meetings. I haven' t seen those resolved yet, so I do not know how > doable or not it is. That's a different draft. Authors are working on addressing unresolved issues and your very right comments. New version will come out soon and then we will be able to discuss about that (separate thread). Carlos >=20 > >> >> =3D> Really? And do you call your operator if you remove your SIM = card and > >> >> put it in another device?. Does you operator also know when you run= new SW > >> >> on your phone/laptop? This is not a serious approach, I'm sorry but= it's > >> >> completely unreliable for any serious deployment > >> > > >> > You talking about serious approaches and operators?? from a pure-use= r > >> > only perspective, I'm sorry to say that most current practices of > >> > operators cannot be considered as "serious" :) > >> > >> =3D> Again, you're backing out of your points mentioned earlier :) Ple= ase > >> respond to how you will make it work. > > > > We have a draft summarizing how solutions that I've seen working > > operate. >=20 > We still have unanswered questions left on the table. The drafts on > the table do not answer those. >=20 > --julien --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-RWML/NqjJNZR1N+bxNCB 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) iEYEABECAAYFAk1wJR8ACgkQNdy6TdFwT2cb5QCfdoYXOUPSSD9E0FuUcnuOB7A8 EasAoLKl4nhYiHr3As9laEDnbOljiAx2 =h1Yx -----END PGP SIGNATURE----- --=-RWML/NqjJNZR1N+bxNCB-- From Basavaraj.Patil@nokia.com Thu Mar 3 15:45:46 2011 Return-Path: <Basavaraj.Patil@nokia.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E51D43A687C for <netext@core3.amsl.com>; Thu, 3 Mar 2011 15:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 QKCdCy1BJi7S for <netext@core3.amsl.com>; Thu, 3 Mar 2011 15:45:46 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id AA04C3A6816 for <netext@ietf.org>; Thu, 3 Mar 2011 15:45:45 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p23Nkq2u028862; Fri, 4 Mar 2011 01:46:52 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Mar 2011 01:46:47 +0200 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 4 Mar 2011 00:46:46 +0100 Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.127]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0270.002; Fri, 4 Mar 2011 00:46:46 +0100 From: <Basavaraj.Patil@nokia.com> To: <cjbc@it.uc3m.es>, <julien.ietf@gmail.com> Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvTH7hRFKVN0Kr67UiTaBIlg8gywgAejl2AAAHvnYAAAaltAAAAevCAAA8x8gAAE1N8AAADW1qAAANRXoAAAMIDgAADjsKAAAfFm4AAHfplgAABZ90AAAgHUYAAAEM0AACbGJiAAAdu4YAAEPkHAAAFGCYAAABJUQAAAC5+AAAPG+WAAAjrAQAAGQ+MAABBK/AAAAniXYAAA+6+UA== Date: Thu, 3 Mar 2011 23:46:45 +0000 Message-ID: <97683F8C138FB243AAC90CEFB48ABF1509268CE9@008-AM1MPN1-004.mgdnok.nokia.com> References: <C993D070.182DA%hesham@elevatemobile.com> <1299066222.5356.17.camel@acorde.it.uc3m.es> <AANLkTi=ScUtUfSJLMC-bMbvopwV-fJMroSyvf4hmXsQy@mail.gmail.com> <1299195167.3889.30.camel@acorde.it.uc3m.es> In-Reply-To: <1299195167.3889.30.camel@acorde.it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.64.197.89] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Mar 2011 23:46:47.0353 (UTC) FILETIME=[425CEA90:01CBD9FD] X-Nokia-AV: Clean Cc: netext@ietf.org, JuanCarlos.Zuniga@interdigital.com 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 03 Mar 2011 23:45:47 -0000 >>=20 >> > - Point-to-point emulation: MAG send the RA to the unicast=20 >> > link-local address of the MN or it sends it multicast in IPv6 but=20 >> > addressed to the >> > L2 address of the MN only. >>=20 >> PMIPv6 assumes a point-to-point *link*. You are talking about=20 >> unicasting RAs which implements a subnet in which only one MN stands. >> This doesn't give you a point-to-point link. Since we do not change=20 >> the L3 between MN and MAG, a point-to-point link has to be provided at=20 >> L2. How do you do that? > >I've just described how I make our lab proto work, emulating a point-to-po= int link over a point-to-multipoint one. I agree with Carlo's comment about how one could emulate a PtP link over wi= fi. You do not have to change the Wifi Mac to emulate a PtP link. -Raj From julien.ietf@gmail.com Thu Mar 3 15:50:30 2011 Return-Path: <julien.ietf@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D0263A687C for <netext@core3.amsl.com>; Thu, 3 Mar 2011 15:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.231 X-Spam-Level: X-Spam-Status: No, score=-3.231 tagged_above=-999 required=5 tests=[AWL=0.368, 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 sbk1MVhrR1iV for <netext@core3.amsl.com>; Thu, 3 Mar 2011 15:50: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 02B253A6816 for <netext@ietf.org>; Thu, 3 Mar 2011 15:50:28 -0800 (PST) Received: by fxm15 with SMTP id 15so1765932fxm.31 for <netext@ietf.org>; Thu, 03 Mar 2011 15:51: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 :content-transfer-encoding; bh=71Jhm1TnPWIYmCMyRWSMdIF+f0aYCu1JC14PWn2qbnA=; b=J60ykZuXwxQ3xaMfQ4EsQ42S+WxTDSNhhu69HN4Tobo2tkENaO8yPnBMUqJWw9OzWM OWsB8vZe0kIo6TAqkqbvXMOXrBC6EDwhQKL0IZEUO2dHc+jt0wEMeCQ/XUiNUCjma7kG 8fa96AtqJHBINNQ5uO4JTGkp2ve3JehdcHD7o= 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=SPeYbCJLknJKcfnTzP6AFJ7/xdC92cPF4I8JfZM5qTaV3w5WEDTZ0iQlP4vCalst8O +GzpJ77CoiBwUVjEr2xZa4UDWRhJlCWWTlA6/T5CT0HjCAgZP9z2awkqGirAscQahmsz cr6F4g5GTSKzEXWbxk1mtek3a3T3ix5BpuzPU= MIME-Version: 1.0 Received: by 10.223.70.142 with SMTP id d14mr2220758faj.110.1299196296512; Thu, 03 Mar 2011 15:51:36 -0800 (PST) Received: by 10.223.93.141 with HTTP; Thu, 3 Mar 2011 15:51:36 -0800 (PST) In-Reply-To: <1299195167.3889.30.camel@acorde.it.uc3m.es> References: <C993D070.182DA%hesham@elevatemobile.com> <1299066222.5356.17.camel@acorde.it.uc3m.es> <AANLkTi=ScUtUfSJLMC-bMbvopwV-fJMroSyvf4hmXsQy@mail.gmail.com> <1299195167.3889.30.camel@acorde.it.uc3m.es> Date: Thu, 3 Mar 2011 15:51:36 -0800 Message-ID: <AANLkTincnC_0MoN4M5CmDK_AL5fssHtZi=VBF4KyPFSL@mail.gmail.com> From: Julien Laganier <julien.ietf@gmail.com> 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" <JuanCarlos.Zuniga@interdigital.com> 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 03 Mar 2011 23:50:30 -0000 Hi Carlos, 2011/3/3 Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es>: > On Thu, 2011-03-03 at 10:49 -0800, Julien Laganier wrote: >> 2011/3/2 Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es>: >> > On Wed, 2011-03-02 at 10:46 +1100, Hesham Soliman wrote: >> >> On 2/03/11 6:30 AM, "Carlos Jes=FAs Bernardos Cano" <cjbc@it.uc3m.es>= wrote: >> >> > On Tue, 2011-03-01 at 23:18 +1100, Hesham Soliman wrote: >> >> >>> >> >> >>> Well, I see quite potential for PMIPv6 over WLAN, why do you thin= k there >> >> >>> would not be any serious WLAN deployment with PMIPv6? >> >> >> >> >> >> =3D> Because of the nature of the links, a router doesn't always k= now who's >> >> >> attached. As you said earlier you make the MN send an RS, which is= not >> >> >> required in IPv6. Also the address allocation is a mess and sharin= g the link >> >> > >> >> > PMIPv6 does not force any specific mechanism on how the MAG detects= the >> >> > attachment of a MN. My experience with WLAN is quite OK so far, nev= er >> >> > had a problem and it's quite easy to implement the AP trigger and t= he >> >> > ptp-to-ptp emulation on WLAN. >> >> >> >> =3D> Quiet easy? I think you must have a special WLAN in your lab :) >> >> I don't think so, if you think it's easy I think you've missed a lot = of >> >> issues. See my points above and please respond specifically. >> > >> > - MN attachment detection: software on the AP that monitors the >> > association table (most drivers provide that feature). >> >> Ok. >> >> > - Point-to-point emulation: MAG send the RA to the unicast link-local >> > address of the MN or it sends it multicast in IPv6 but addressed to th= e >> > L2 address of the MN only. >> >> PMIPv6 assumes a point-to-point *link*. You are talking about >> unicasting RAs which implements a subnet in which only one MN stands. >> This doesn't give you a point-to-point link. Since we do not change >> the L3 between MN and MAG, a point-to-point link has to be provided at >> L2. How do you do that? > > I've just described how I make our lab proto work, emulating a > point-to-point link over a point-to-multipoint one. I've just explained why what you do isn't emulating a point-to-point link. A point-to-point link is a link that has only two endpoints. What you explained creates a per-MN subnet. These are different things... >> > - We use L2 address as MN-ID (just for the sake of simplicity) >> >> If you use IEEE EUI-48 as MN-ID, how do you do flow mobility to a >> system that isn't 802 (e.g. 3GPP)? > > All my previous e-mails about the lab prototype and WLAN refers to basic > PMIPv6, I haven't mentioned anything about flow mobility in that > context. That's a separate issue. So is it fair to say that your basic PMIPv6 system only works with unmodified L2 signaling because you constrain the MNID to be an EUI-48? If so, if the MNID had to be something else (which it will necessarily have to in a multi-radio-technology setup as in flow mobility and inter-tech handoffs), you will need to extend L2 signaling, no? --julien From julien.ietf@gmail.com Thu Mar 3 15:53:27 2011 Return-Path: <julien.ietf@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FB0B3A681D for <netext@core3.amsl.com>; Thu, 3 Mar 2011 15:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.235 X-Spam-Level: X-Spam-Status: No, score=-3.235 tagged_above=-999 required=5 tests=[AWL=0.364, 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 TavJPMwJhLZg for <netext@core3.amsl.com>; Thu, 3 Mar 2011 15:53: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 F25373A6816 for <netext@ietf.org>; Thu, 3 Mar 2011 15:53:25 -0800 (PST) Received: by fxm15 with SMTP id 15so1767406fxm.31 for <netext@ietf.org>; Thu, 03 Mar 2011 15:54: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=2e9Iq4F31jw3j3FE3oDXsHhTBFJfOk3LmsXoEu37Op4=; b=Vegt5XYiJjpaKZ4tA0lwRJQtsvNOTZpt7gxZO3ZT1Zj0sF1/N1iQB117ssxirBqrVv OVapNVOMa8U0q3xLAIwFqK2RhCA1dK1ekLmgTh9k4m8dzDwvemj3Pl3hWUrS+pag0Ker AZm1cCydYPrcFtG3TKh4z+7/G4EfobHipdTqk= 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=vPpzRkAmKcTHvmldZjagZq92Z66CR3crbgbRgnii2j0i/6a2v/AtQoSBOfV4aXaPcP pzYU16lYarrunH35BX56MV8s/ScXv3gj6fT9vt+5SL1OSJoVSantaGC0/c/Y9Q7vG7tc PkmzUdn1KI5PLTQ1T2E7Mo6ppJwevgdYAVsOs= MIME-Version: 1.0 Received: by 10.223.151.12 with SMTP id a12mr17947faw.15.1299196473749; Thu, 03 Mar 2011 15:54:33 -0800 (PST) Received: by 10.223.93.141 with HTTP; Thu, 3 Mar 2011 15:54:33 -0800 (PST) In-Reply-To: <97683F8C138FB243AAC90CEFB48ABF1509268CE9@008-AM1MPN1-004.mgdnok.nokia.com> References: <C993D070.182DA%hesham@elevatemobile.com> <1299066222.5356.17.camel@acorde.it.uc3m.es> <AANLkTi=ScUtUfSJLMC-bMbvopwV-fJMroSyvf4hmXsQy@mail.gmail.com> <1299195167.3889.30.camel@acorde.it.uc3m.es> <97683F8C138FB243AAC90CEFB48ABF1509268CE9@008-AM1MPN1-004.mgdnok.nokia.com> Date: Thu, 3 Mar 2011 15:54:33 -0800 Message-ID: <AANLkTikOdW4RMUvwuFjjoC8xar8FJg7FyBsc_-kU02M+@mail.gmail.com> From: Julien Laganier <julien.ietf@gmail.com> To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org, JuanCarlos.Zuniga@interdigital.com 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 03 Mar 2011 23:53:27 -0000 On Thu, Mar 3, 2011 at 3:46 PM, <Basavaraj.Patil@nokia.com> wrote: >>> >>> > - Point-to-point emulation: MAG send the RA to the unicast >>> > link-local address of the MN or it sends it multicast in IPv6 but >>> > addressed to the >>> > L2 address of the MN only. >>> >>> PMIPv6 assumes a point-to-point *link*. You are talking about >>> unicasting RAs which implements a subnet in which only one MN stands. >>> This doesn't give you a point-to-point link. Since we do not change >>> the L3 between MN and MAG, a point-to-point link has to be provided at >>> L2. How do you do that? >> >>I've just described how I make our lab proto work, emulating a point-to-point link over a point-to-multipoint one. > > I agree with Carlo's comment about how one could emulate a PtP link over wifi. You do not have to change the Wifi Mac to emulate a PtP link. So you disagree with my comment that what Carlos is doing only implements a per-MN subnet model, and does not emulate a point-to-point link? If so, maybe you or Carlos can explain how having a per-MN subnet model can constrain a shared link to have only two endpoints... --julien From julien.ietf@gmail.com Thu Mar 3 15:54:54 2011 Return-Path: <julien.ietf@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98D723A68B7 for <netext@core3.amsl.com>; Thu, 3 Mar 2011 15:54:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.239 X-Spam-Level: X-Spam-Status: No, score=-3.239 tagged_above=-999 required=5 tests=[AWL=0.360, 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 g-rGvLZ-M9Kp for <netext@core3.amsl.com>; Thu, 3 Mar 2011 15:54: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 068973A6816 for <netext@ietf.org>; Thu, 3 Mar 2011 15:54:52 -0800 (PST) Received: by fxm15 with SMTP id 15so1768174fxm.31 for <netext@ietf.org>; Thu, 03 Mar 2011 15:56: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=FSJf7zFIwbKYV8NHgn9KufFjCApHxs2zcMpNxSrPE9A=; b=vZ6+fEBMiGis2h0urPX7UPqRNlN/61fHzkLadXlOghIgrK8iO/uEeIJOQUdwgxUcnW SqA21AQWgzFh5Le6E9KCs7K0wrqUSfQyAQhRR+WM/C0NW8DE8bCMAuXxx5YMFzgms9lU vhw87vMFzGAev1Qd4bKsW1aQ6mhjFedI/X1eQ= 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=nEEQoIrvVTn7AD0hWtfDU+NiWjLnHel5UK9+e4ttqmrH5sMw8mEo/DUF1TBOF5UJll x4rlWm5oC8HmKmlb3W5chBozmimTf3fpXvkpZD4fJgz8jvBImQcDbzCQPJt5fY6g72ii L7EYLdiDBmoVV58kx7N/txK4kjnPtawC8MksU= MIME-Version: 1.0 Received: by 10.223.7.88 with SMTP id c24mr4933fac.72.1299196554569; Thu, 03 Mar 2011 15:55:54 -0800 (PST) Received: by 10.223.93.141 with HTTP; Thu, 3 Mar 2011 15:55:54 -0800 (PST) In-Reply-To: <C995604A.11E3F%sgundave@cisco.com> References: <AANLkTikYtWznF75jxre++hExwVXZ+fB6CHpHd=i==pDL@mail.gmail.com> <C995604A.11E3F%sgundave@cisco.com> Date: Thu, 3 Mar 2011 15:55:54 -0800 Message-ID: <AANLkTim4zabH_DJ4wKMU-qgH3zb_CP-f_qsTCHzV=c1h@mail.gmail.com> From: Julien Laganier <julien.ietf@gmail.com> To: Sri Gundavelli <sgundave@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org, JuanCarlos.Zuniga@interdigital.com, Basavaraj.Patil@nokia.com 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 03 Mar 2011 23:54:54 -0000 Sri, I don't know of a spec that requires a host receiving an RA without PIO to send another RS... --julien On Thu, Mar 3, 2011 at 3:12 PM, Sri Gundavelli <sgundave@cisco.com> wrote: > Julien, > > Sure, assuming the router is not provisioned to suppress periodic RA's an= d > based on the RA frequency, an IPv6 host will eventually obtain an address= . > In case of PMIPv6, the same periodic RA with no PIO's will enable the hos= t > to retrigger the RS for PIO's and allow the router to discover the host a= nd > present its PIO's. > > > Sri > > > > On 3/3/11 2:59 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: > >> Sri, >> >> In the ND case, when RS are lost, an IPv6 host will eventually obtain >> prefix information via receiving a periodic RA, configure an address >> with SLAAC, and be connected to the Internet. >> >> In contrast, in the PMIPv6 case, relying on RS as a mobility trigger >> can lead to a failure mode in which the host is never detected by the >> PMIPv6 fabric and has no connectivity to the Internet. >> >> --julien >> >> On Thu, Mar 3, 2011 at 2:43 PM, Sri Gundavelli <sgundave@cisco.com> wrot= e: >>> Julien: >>> >>> RS message can get lost and in sequence, sure, like any other IP packet= . So, >>> the host using stateless autoconf can never configure an IPv6 address, = till >>> it receives a router advertisement message. So, enabling RA suppress is= not >>> desirable. It is also unreliable for any IP host on a normal IPv6 link = to >>> obtain prefix information, given the probability that RS/RA messages ca= n get >>> lost. I agree, its the same level of unreliability exists in case of PM= IPv6, >>> which is one of the triggers for the protocol operation, not just for f= low >>> mobility. >>> >>> >>> >>> Regards >>> Sri >>> >>> >>> >>> On 3/3/11 10:40 AM, "Julien Laganier" <julien.ietf@gmail.com> wrote: >>> >>>> Sri, >>>> >>>> Whether or not a host stack send an RS when a link-up event happens is >>>> irrelevant to the design of the PMIPv6 flow mobility for the two >>>> following reasons: >>>> >>>> 1. Stacks with DNAv6 would send an RS, other stack would not. So it's >>>> not generic and can't be relied upon. >>>> 2. Even if all stacks were sending RS. RS can be lost. So it's not >>>> reliable and can' t be relied upon. >>>> >>>> --julien >>>> >>>> On Wed, Mar 2, 2011 at 9:13 AM, Sri Gundavelli <sgundave@cisco.com> wr= ote: >>>>> Yes, it is relevant in the context of the current discussion. If we a= re not >>>>> on the same page, as how a simple IP host behaves across L3 roams, we= are >>>>> not going to converge on what new events L2 or L3 we need. So, this i= s >>>>> relevant. >>>>> >>>>> >>>>> >>>>> Thanks >>>>> Sri >>>>> >>>>> >>>>> >>>>> On 3/2/11 8:53 AM, "Basavaraj.Patil@nokia.com" <Basavaraj.Patil@nokia= .com> >>>>> wrote: >>>>> >>>>>> >>>>>> Folks, >>>>>> >>>>>> Is this discussion about how MIP6 works even relevant in the context= of >>>>>> the >>>>>> flow mobility discussion? >>>>>> There are other questions and concerns that have been raised which I= would >>>>>> advise the authors to focus on. >>>>>> >>>>>> If you need to understand how movement detection in MIP6 works, plea= se >>>>>> refer >>>>>> to Sec 11.5 of RFC3775. >>>>>> >>>>>> -Raj >>>>>> >>>>>> -----Original Message----- >>>>>> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Be= half >>>>>> Of >>>>>> ext Carlos Jes=FAs Bernardos Cano >>>>>> Sent: Wednesday, March 02, 2011 10:49 AM >>>>>> To: Sri Gundavelli >>>>>> Cc: netext@ietf.org; Zuniga, Juan Carlos >>>>>> Subject: Re: [netext] Flow Mobility discussion - way forward? >>>>>> >>>>>> Hi Sri, >>>>>> >>>>>> On Wed, 2011-03-02 at 08:16 -0800, Sri Gundavelli wrote: >>>>>>>> I'm talking about a legacu IPv6 host. If I install Mobile IPv6 in >>>>>>>> that Linux stack, don't worry, the MIPv6 client takes care of >>>>>>>> configuring a CoA (sending an RS if no RA is received). >>>>>>>> >>>>>>> >>>>>>> Hi Carlos: >>>>>>> >>>>>>> (Still keeping the discussion context to this one comment). >>>>>>> >>>>>>> - I assume MIPv6 stack is on top of IP stack, not the other way aro= und >>>>>> >>>>>> Well, i reality MIPv6 is part of IPv6, not really sits on top. >>>>>> >>>>>>> >>>>>>> - If IP stack does not detect movement detection across L3 links (i= n >>>>>>> the absence of any other hints about same L3 link, in the forms ess= id >>>>>>> or other hints), how does the MIPv6 stack which is relying on the >>>>>>> stack/kernel events, decide to force an RA ? What is the hint ? How >>>>>>> come ND/DHCP does not realize the same need to send an RS ? Is MIPv= 6 >>>>>>> stack >>>>>>> so >>>>>>> smart ? >>>>>> >>>>>> The implementations that I'm familiar with do the following: >>>>>> >>>>>> - They wait for an unsolicited RA >>>>>> - If no unsolicited RA is received in a time interval equal to 2 tim= es the >>>>>> frequency of RAs (there is information about that on the RAs), the M= N >>>>>> sends >>>>>> an >>>>>> RS. >>>>>> >>>>>>> >>>>>>> - Assuming there is no MIPv6 stack on the host, an host moves acros= s >>>>>>> access links, it will never do an RS and will keep using the addres= s >>>>>>> from the previous link. So, the basic IPv6 connectivity is broken. >>>>>>> This is a bug, not a protocol gap. >>>>>> >>>>>> With WLAN and Linux, that's the behavior. I guess developers underst= ood >>>>>> that >>>>>> two APs with the same ESSID belongs to the same ESS, and therefore t= he >>>>>> same >>>>>> IP >>>>>> subnet. That actually is correct and cannot be cataloged as "bug". >>>>>> >>>>>>> >>>>>>> PS: I heard about this RS problems 5 years back, when most WLAN >>>>>>> drivers were not handling IPv6 correctly. I'm pretty sure all the W= LAN >>>>>>> drivers have fixed those problems now. You may want to replace your >>>>>>> buggy NIC card driver :) >>>>>> >>>>>> It's not a buggy NIC card driver. You may say a buggy OS, but I hone= stly >>>>>> will >>>>>> not call Linux "buggy" (or at least buggier than many others that ar= e out >>>>>> there). >>>>>> >>>>>> Carlos >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards >>>>>>> Sri >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 3/2/11 3:34 AM, "Carlos Jes=FAs Bernardos Cano" <cjbc@it.uc3m.es= > wrote: >>>>>>> >>>>>>>> >>>>>>>> I'm talking about a legacu IPv6 host. If I install Mobile IPv6 in >>>>>>>> that Linux stack, don't worry, the MIPv6 client takes care of >>>>>>>> configuring a CoA (sending an RS if no RA is received). >>>>>>>> >>>>>>>> Carlos >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>>> _______________________________________________ >>>>> netext mailing list >>>>> netext@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netext >>>>> >>> >>> > > From trungtm2909@gmail.com Thu Mar 3 16:14:42 2011 Return-Path: <trungtm2909@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 756F63A68B7 for <netext@core3.amsl.com>; Thu, 3 Mar 2011 16:14:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=-0.152, 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 m-gunm425Dwv for <netext@core3.amsl.com>; Thu, 3 Mar 2011 16:14:41 -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 42CAE3A68B5 for <netext@ietf.org>; Thu, 3 Mar 2011 16:14:41 -0800 (PST) Received: by vws6 with SMTP id 6so1743102vws.31 for <netext@ietf.org>; Thu, 03 Mar 2011 16:15: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=3Y7mf5y2wuXZaNCPYRfhsJCcocrjDnQ7m9BOZzX+8o0=; b=Sw43oq5s3QLH4RxZmjQdE9E4n5yN7biFuePTnuOhB1QaNOFFQTfZ8vkdq5+BIdT2Qq imkEA2tW1sw5/6/M24Ye8xzRaSYypzvrSq0EIb8+8AppEVSRXZ6JjadL2lN9zobJARXb uxkdzYfg+oYYjRqh/uw0IMO553FgbKgy4xuf4= 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=nckSOnqYp3LwoZRBYHXLpRtPIY8jFH6pjs/CCAfLxNr6RGy2TMmgLhW15eamVVw9kp GUS20sRlfs7KQkhvuh350qGTJ0nGqitwhE4lvVwKbb1VGUhQV8nQV/jGkwxdjB3tkjUi 62ha3PbXyVu/UI3SB64wGCRe4fGRQBRWP8IPw= MIME-Version: 1.0 Received: by 10.52.90.208 with SMTP id by16mr2853418vdb.280.1299197748447; Thu, 03 Mar 2011 16:15:48 -0800 (PST) Received: by 10.52.162.1 with HTTP; Thu, 3 Mar 2011 16:15:48 -0800 (PST) In-Reply-To: <AANLkTimZaSe5FAoLh3fzAaOFPe5K676OXXOMw0UctsJn@mail.gmail.com> References: <AANLkTi=Fsr15UL7V=y1QovzN0OfgK8CTv3ito0Cz0MKL@mail.gmail.com> <C98C3FCF.DC9B%rkoodli@cisco.com> <AANLkTinZBDDWsCpkuo9RoWG4f7z5Rp9Ly1=HBdiHGO-F@mail.gmail.com> <AANLkTimiCyWgz8p8H0LRp6+Xds0-m6LVAarU-Fo6-f2E@mail.gmail.com> <AANLkTi=f9c7FhAyO8P1o-9Dt0ny6s816rRr+kHMU2Gxn@mail.gmail.com> <AANLkTimZaSe5FAoLh3fzAaOFPe5K676OXXOMw0UctsJn@mail.gmail.com> Date: Fri, 4 Mar 2011 09:15:48 +0900 Message-ID: <AANLkTikAEOiiz_0n6y7TBNN1BiDM8X=KaKRGazPmcQPr@mail.gmail.com> From: Tran Minh Trung <trungtm2909@gmail.com> To: Julien Laganier <julien.ietf@gmail.com> 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 04 Mar 2011 00:14:42 -0000 Hi Julien, Since I did not receive answer for my questions in previous email, could I understand that LMA-MAG signaling is necessary for the case of adding attached interfaces to a new session. Please check again my questions in quoted text: On Mon, Feb 28, 2011 at 6:08 PM, Tran Minh Trung <trungtm2909@gmail.com> wr= ote: > Hi Julien, > > On Sat, Feb 26, 2011 at 1:06 AM, Julien Laganier <julien.ietf@gmail.com> = wrote: >> 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: > <TrungTM> 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. >> > <TrungTM> I have checked =A0TS 23.402, 401 as well as TR 23.861 =A0(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] =A0(PMIPv6 extension for flow mobility) 3. =A0User 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 connect= ivity 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 =A0"PDN Connectivity Request" or after =A0"RRC Connection Reconfiguration Complete"?. Thank you. Regards, TrungTM > >> Thanks, >> >> --julien >> >> On Thu, Feb 24, 2011 at 8:06 PM, Tran Minh Trung <trungtm2909@gmail.com>= 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 <julien.ietf@gmail.co= m> wrote: >>>> On Thu, Feb 24, 2011 at 6:03 PM, Rajeev Koodli <rkoodli@cisco.com> wro= te: >>>>> >>>>> I do care about the PMIP6 interaction with AAA because the system des= ign >>>>> 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 robu= stness. >>>> >>>> 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 provi= ding a >>>>> prefix which is not in the session, and why should there be any restr= iction >>>>> 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 sign= aling, >>>>> 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. >>>> >>>> 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 m= ove >>>>> 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 >>> >> > > > > -- > 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 cjbc@it.uc3m.es Thu Mar 3 16:51:21 2011 Return-Path: <cjbc@it.uc3m.es> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29B373A68BA for <netext@core3.amsl.com>; Thu, 3 Mar 2011 16:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.003 X-Spam-Level: X-Spam-Status: No, score=-4.003 tagged_above=-999 required=5 tests=[AWL=0.053, 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 R2NKJBfKeVxH for <netext@core3.amsl.com>; Thu, 3 Mar 2011 16:51:19 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 702583A687C for <netext@ietf.org>; Thu, 3 Mar 2011 16:51:19 -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 3D10DB4A0DF; Fri, 4 Mar 2011 01:52:22 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <cjbc@it.uc3m.es> To: Julien Laganier <julien.ietf@gmail.com> In-Reply-To: <AANLkTincnC_0MoN4M5CmDK_AL5fssHtZi=VBF4KyPFSL@mail.gmail.com> References: <C993D070.182DA%hesham@elevatemobile.com> <1299066222.5356.17.camel@acorde.it.uc3m.es> <AANLkTi=ScUtUfSJLMC-bMbvopwV-fJMroSyvf4hmXsQy@mail.gmail.com> <1299195167.3889.30.camel@acorde.it.uc3m.es> <AANLkTincnC_0MoN4M5CmDK_AL5fssHtZi=VBF4KyPFSL@mail.gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-05Uv0/PQufTqGxqEzCPc" Organization: Universidad Carlos III de Madrid Date: Fri, 04 Mar 2011 01:53:47 +0100 Message-ID: <1299200027.3889.43.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-17990.003 Cc: netext@ietf.org, "Zuniga, Juan Carlos" <JuanCarlos.Zuniga@interdigital.com> 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 04 Mar 2011 00:51:21 -0000 --=-05Uv0/PQufTqGxqEzCPc Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Julien, On Thu, 2011-03-03 at 15:51 -0800, Julien Laganier wrote: > Hi Carlos, >=20 > 2011/3/3 Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es>: > > On Thu, 2011-03-03 at 10:49 -0800, Julien Laganier wrote: > >> 2011/3/2 Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es>: > >> > On Wed, 2011-03-02 at 10:46 +1100, Hesham Soliman wrote: > >> >> On 2/03/11 6:30 AM, "Carlos Jes=FAs Bernardos Cano" <cjbc@it.uc3m.e= s> wrote: > >> >> > On Tue, 2011-03-01 at 23:18 +1100, Hesham Soliman wrote: > >> >> >>> > >> >> >>> Well, I see quite potential for PMIPv6 over WLAN, why do you th= ink there > >> >> >>> would not be any serious WLAN deployment with PMIPv6? > >> >> >> > >> >> >> =3D> Because of the nature of the links, a router doesn't always= know who's > >> >> >> attached. As you said earlier you make the MN send an RS, which = is not > >> >> >> required in IPv6. Also the address allocation is a mess and shar= ing the link > >> >> > > >> >> > PMIPv6 does not force any specific mechanism on how the MAG detec= ts the > >> >> > attachment of a MN. My experience with WLAN is quite OK so far, n= ever > >> >> > had a problem and it's quite easy to implement the AP trigger and= the > >> >> > ptp-to-ptp emulation on WLAN. > >> >> > >> >> =3D> Quiet easy? I think you must have a special WLAN in your lab := ) > >> >> I don't think so, if you think it's easy I think you've missed a lo= t of > >> >> issues. See my points above and please respond specifically. > >> > > >> > - MN attachment detection: software on the AP that monitors the > >> > association table (most drivers provide that feature). > >> > >> Ok. > >> > >> > - Point-to-point emulation: MAG send the RA to the unicast link-loca= l > >> > address of the MN or it sends it multicast in IPv6 but addressed to = the > >> > L2 address of the MN only. > >> > >> PMIPv6 assumes a point-to-point *link*. You are talking about > >> unicasting RAs which implements a subnet in which only one MN stands. > >> This doesn't give you a point-to-point link. Since we do not change > >> the L3 between MN and MAG, a point-to-point link has to be provided at > >> L2. How do you do that? > > > > I've just described how I make our lab proto work, emulating a > > point-to-point link over a point-to-multipoint one. >=20 > I've just explained why what you do isn't emulating a point-to-point > link. A point-to-point link is a link that has only two endpoints. > What you explained creates a per-MN subnet. These are different > things... If the MAG always uses the L2 address of the MN as destination address of the frames it sends, I think that is a way of emulating a point-to-point link between the MAG and that MN. Of course is not like a real point-to-point link (we cannot avoid MN X to receive multicast packets sent by MN Y), but this is enough to support PMIPv6. >=20 > >> > - We use L2 address as MN-ID (just for the sake of simplicity) > >> > >> If you use IEEE EUI-48 as MN-ID, how do you do flow mobility to a > >> system that isn't 802 (e.g. 3GPP)? > > > > All my previous e-mails about the lab prototype and WLAN refers to basi= c > > PMIPv6, I haven't mentioned anything about flow mobility in that > > context. That's a separate issue. >=20 > So is it fair to say that your basic PMIPv6 system only works with > unmodified L2 signaling because you constrain the MNID to be an > EUI-48? No, I could also have a pre-configured database with L2 IDs and the mapping to MN-IDs, supporting different L2 technologies. But this is just an example. We are missing the point, the discussion started with an example of one potential lab prototype of plain PMIPv6. Carlos >=20 > If so, if the MNID had to be something else (which it will necessarily > have to in a multi-radio-technology setup as in flow mobility and > inter-tech handoffs), you will need to extend L2 signaling, 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 --=-05Uv0/PQufTqGxqEzCPc 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) iEYEABECAAYFAk1wOBsACgkQNdy6TdFwT2fLdACgsll+4NcUncYr1J36e2b6IVuK 0cEAoLSyuexLCAAIZdRQFykSdGhDyy3+ =/rEq -----END PGP SIGNATURE----- --=-05Uv0/PQufTqGxqEzCPc-- From hesham@elevatemobile.com Thu Mar 3 20:34:25 2011 Return-Path: <hesham@elevatemobile.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE80E3A6930 for <netext@core3.amsl.com>; Thu, 3 Mar 2011 20:34:25 -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 PTS81ErHqI1m for <netext@core3.amsl.com>; Thu, 3 Mar 2011 20:34: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 383893A692C for <netext@ietf.org>; Thu, 3 Mar 2011 20:34:23 -0800 (PST) Received: from [114.75.49.203] (helo=[192.168.0.3]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1PvMjI-00070B-8V; Fri, 04 Mar 2011 15:35:05 +1100 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Fri, 04 Mar 2011 15:34:48 +1100 From: Hesham Soliman <hesham@elevatemobile.com> To: Sri Gundavelli <sgundave@cisco.com>, Julien Laganier <julien.ietf@gmail.com> Message-ID: <C996B718.183C9%hesham@elevatemobile.com> Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvZ+GwqM3i4vBIYv0S4SSX0HbqFWAALRJHm In-Reply-To: <C995604A.11E3F%sgundave@cisco.com> 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, JuanCarlos.Zuniga@interdigital.com, Basavaraj.Patil@nokia.com 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 04 Mar 2011 04:34:25 -0000 > Julien, >=20 > Sure, assuming the router is not provisioned to suppress periodic RA's an= d > based on the RA frequency, an IPv6 host will eventually obtain an address= . > In case of PMIPv6, the same periodic RA with no PIO's will enable the hos= t > to retrigger the RS for PIO's =3D> Why would the host do that? Did I miss something? An empty RA doesn't trigger anything AFAIK. Hesham and allow the router to discover the host and > present its PIO's. >=20 >=20 > Sri >=20 >=20 >=20 > On 3/3/11 2:59 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: >=20 >> Sri, >>=20 >> In the ND case, when RS are lost, an IPv6 host will eventually obtain >> prefix information via receiving a periodic RA, configure an address >> with SLAAC, and be connected to the Internet. >>=20 >> In contrast, in the PMIPv6 case, relying on RS as a mobility trigger >> can lead to a failure mode in which the host is never detected by the >> PMIPv6 fabric and has no connectivity to the Internet. >>=20 >> --julien >>=20 >> On Thu, Mar 3, 2011 at 2:43 PM, Sri Gundavelli <sgundave@cisco.com> wrot= e: >>> Julien: >>>=20 >>> RS message can get lost and in sequence, sure, like any other IP packet= . So, >>> the host using stateless autoconf can never configure an IPv6 address, = till >>> it receives a router advertisement message. So, enabling RA suppress is= not >>> desirable. It is also unreliable for any IP host on a normal IPv6 link = to >>> obtain prefix information, given the probability that RS/RA messages ca= n get >>> lost. I agree, its the same level of unreliability exists in case of PM= IPv6, >>> which is one of the triggers for the protocol operation, not just for f= low >>> mobility. >>>=20 >>>=20 >>>=20 >>> Regards >>> Sri >>>=20 >>>=20 >>>=20 >>> On 3/3/11 10:40 AM, "Julien Laganier" <julien.ietf@gmail.com> wrote: >>>=20 >>>> Sri, >>>>=20 >>>> Whether or not a host stack send an RS when a link-up event happens is >>>> irrelevant to the design of the PMIPv6 flow mobility for the two >>>> following reasons: >>>>=20 >>>> 1. Stacks with DNAv6 would send an RS, other stack would not. So it's >>>> not generic and can't be relied upon. >>>> 2. Even if all stacks were sending RS. RS can be lost. So it's not >>>> reliable and can' t be relied upon. >>>>=20 >>>> --julien >>>>=20 >>>> On Wed, Mar 2, 2011 at 9:13 AM, Sri Gundavelli <sgundave@cisco.com> wr= ote: >>>>> Yes, it is relevant in the context of the current discussion. If we a= re >>>>> not >>>>> on the same page, as how a simple IP host behaves across L3 roams, we= are >>>>> not going to converge on what new events L2 or L3 we need. So, this i= s >>>>> relevant. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Thanks >>>>> Sri >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 3/2/11 8:53 AM, "Basavaraj.Patil@nokia.com" <Basavaraj.Patil@nokia= .com> >>>>> wrote: >>>>>=20 >>>>>>=20 >>>>>> Folks, >>>>>>=20 >>>>>> Is this discussion about how MIP6 works even relevant in the context= of >>>>>> the >>>>>> flow mobility discussion? >>>>>> There are other questions and concerns that have been raised which I >>>>>> would >>>>>> advise the authors to focus on. >>>>>>=20 >>>>>> If you need to understand how movement detection in MIP6 works, plea= se >>>>>> refer >>>>>> to Sec 11.5 of RFC3775. >>>>>>=20 >>>>>> -Raj >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Be= half >>>>>> Of >>>>>> ext Carlos Jes=FAs Bernardos Cano >>>>>> Sent: Wednesday, March 02, 2011 10:49 AM >>>>>> To: Sri Gundavelli >>>>>> Cc: netext@ietf.org; Zuniga, Juan Carlos >>>>>> Subject: Re: [netext] Flow Mobility discussion - way forward? >>>>>>=20 >>>>>> Hi Sri, >>>>>>=20 >>>>>> On Wed, 2011-03-02 at 08:16 -0800, Sri Gundavelli wrote: >>>>>>>> I'm talking about a legacu IPv6 host. If I install Mobile IPv6 in >>>>>>>> that Linux stack, don't worry, the MIPv6 client takes care of >>>>>>>> configuring a CoA (sending an RS if no RA is received). >>>>>>>>=20 >>>>>>>=20 >>>>>>> Hi Carlos: >>>>>>>=20 >>>>>>> (Still keeping the discussion context to this one comment). >>>>>>>=20 >>>>>>> - I assume MIPv6 stack is on top of IP stack, not the other way aro= und >>>>>>=20 >>>>>> Well, i reality MIPv6 is part of IPv6, not really sits on top. >>>>>>=20 >>>>>>>=20 >>>>>>> - If IP stack does not detect movement detection across L3 links (i= n >>>>>>> the absence of any other hints about same L3 link, in the forms ess= id >>>>>>> or other hints), how does the MIPv6 stack which is relying on the >>>>>>> stack/kernel events, decide to force an RA ? What is the hint ? How >>>>>>> come ND/DHCP does not realize the same need to send an RS ? Is MIPv= 6 >>>>>>> stack >>>>>>> so >>>>>>> smart ? >>>>>>=20 >>>>>> The implementations that I'm familiar with do the following: >>>>>>=20 >>>>>> - They wait for an unsolicited RA >>>>>> - If no unsolicited RA is received in a time interval equal to 2 tim= es >>>>>> the >>>>>> frequency of RAs (there is information about that on the RAs), the M= N >>>>>> sends >>>>>> an >>>>>> RS. >>>>>>=20 >>>>>>>=20 >>>>>>> - Assuming there is no MIPv6 stack on the host, an host moves acros= s >>>>>>> access links, it will never do an RS and will keep using the addres= s >>>>>>> from the previous link. So, the basic IPv6 connectivity is broken. >>>>>>> This is a bug, not a protocol gap. >>>>>>=20 >>>>>> With WLAN and Linux, that's the behavior. I guess developers underst= ood >>>>>> that >>>>>> two APs with the same ESSID belongs to the same ESS, and therefore t= he >>>>>> same >>>>>> IP >>>>>> subnet. That actually is correct and cannot be cataloged as "bug". >>>>>>=20 >>>>>>>=20 >>>>>>> PS: I heard about this RS problems 5 years back, when most WLAN >>>>>>> drivers were not handling IPv6 correctly. I'm pretty sure all the W= LAN >>>>>>> drivers have fixed those problems now. You may want to replace your >>>>>>> buggy NIC card driver :) >>>>>>=20 >>>>>> It's not a buggy NIC card driver. You may say a buggy OS, but I hone= stly >>>>>> will >>>>>> not call Linux "buggy" (or at least buggier than many others that ar= e out >>>>>> there). >>>>>>=20 >>>>>> Carlos >>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Regards >>>>>>> Sri >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 3/2/11 3:34 AM, "Carlos Jes=FAs Bernardos Cano" <cjbc@it.uc3m.es> >>>>>>> wrote: >>>>>>>=20 >>>>>>>>=20 >>>>>>>> I'm talking about a legacu IPv6 host. If I install Mobile IPv6 in >>>>>>>> that Linux stack, don't worry, the MIPv6 client takes care of >>>>>>>> configuring a CoA (sending an RS if no RA is received). >>>>>>>>=20 >>>>>>>> Carlos >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> netext mailing list >>>>> netext@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netext >>>>>=20 >>>=20 >>>=20 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From rkoodli@cisco.com Thu Mar 3 21:38:21 2011 Return-Path: <rkoodli@cisco.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39B823A692B for <netext@core3.amsl.com>; Thu, 3 Mar 2011 21:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.077 X-Spam-Level: X-Spam-Status: No, score=-110.077 tagged_above=-999 required=5 tests=[AWL=0.522, 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 qalzHb+1vfIO for <netext@core3.amsl.com>; Thu, 3 Mar 2011 21:38:19 -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 AC58C3A693C for <netext@ietf.org>; Thu, 3 Mar 2011 21:38:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rkoodli@cisco.com; l=3074; q=dns/txt; s=iport; t=1299217168; x=1300426768; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=3EXSDVH2vrpqaeJZ0wyFS2K9vouY/mKaErMKfHs9gXY=; b=SYPsAVo15BSCTkos0mCER5PXaJ7OOuQttEK1Lir7VNXDG1bqtjqNROER 6RC2t6ojtyWXNhNv9YuFluXfEccFa+8G5CMD7YgazaIdXa5/5qHXRtcqg 00erIYssEwdz2/KDy4LEnvvBPhtmT7iJNQgHJNfR4vdJsFO6tHGYb0AXC c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAP4JcE2tJXHA/2dsb2JhbACmb3SiYpwMhWEEhRyHE4NJgxQ X-IronPort-AV: E=Sophos;i="4.62,262,1297036800"; d="scan'208";a="222493322" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rtp-iport-2.cisco.com with ESMTP; 04 Mar 2011 05:39:27 +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 p245dR47024116; Fri, 4 Mar 2011 05:39: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); Thu, 3 Mar 2011 23:39:27 -0600 Received: from 10.21.144.204 ([10.21.144.204]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Fri, 4 Mar 2011 05:39:27 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 03 Mar 2011 21:40:19 -0800 From: Rajeev Koodli <rkoodli@cisco.com> To: Julien Laganier <julien.ietf@gmail.com> Message-ID: <C995BB43.E160%rkoodli@cisco.com> Thread-Topic: [netext] Update on flow mobility following discussion with ADs Thread-Index: AcvaLqV910UT+qCsj0eeBVZTVPFoDQ== In-Reply-To: <AANLkTim25tLfusBFkY35AFi_7fXucQ4etjKxj4y-KLEf@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Mar 2011 05:39:27.0533 (UTC) FILETIME=[86D025D0:01CBDA2E] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Update on flow mobility following discussion with ADs X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 04 Mar 2011 05:38:21 -0000 Hi Julien, I don't believe I suggested sacrificing correctness and robustness; in fact, I suggested robustness of protocol operation to cover all cases. More to the point, I think relying _only_ on extended L2 signaling is one of the cases the protocol needs to cover. We need to include the case when either new L2 signaling is unavailable or is not considered reliable. I am proposing an inclusive approach for providing flow mobility when the desired aspects of L2 signaling are available (HI=Flow Mobility) _and_ consider the case when we they are not available (HI=Unknown). I should be able to move flows across interfaces regardless of whether the LMA maintains a single session or multiple sessions (all created according to the baseline PMIP6 model). Making use of 3GPP as a customer is great, but I do not want to be limited only to it. Thanks, -Rajeev On 3/3/11 11:44 AM, "Julien Laganier" <julien.ietf@gmail.com> wrote: > Hi Rajeev, > > On Wed, Mar 2, 2011 at 12:39 PM, Rajeev Koodli <rkoodli@cisco.com> wrote: >> >> >> On 3/2/11 11:49 AM, "Jari Arkko" <jari.arkko@piuha.net> wrote: >> >>> Sri: >>> >>> What Basavaraj said. I don't think the number of specifications is a big >>> concern either now or later. Split the documents the way you like. Lets >>> discuss functionality, robustness, assumptions instead -- those are >>> important. >> >> >> I agree that the spec should be robust, and should work under conditions >> assuming existing & new L2 signaling, as well as under conditions when new >> L2 signaling is unavailable. > > I have expressed doubts about the feasibility of a robust flow > mobility / inter-access handover solution that relies on existing, > unmodified L2 signaling (this is discussed in a different thread.) We > should not sacrifice correctness and robustness for the sake of > working around unmodified L2 signaling. As I've said earlier, one of > the potential customer for this (3GPP) owns two L2 that are used to > access their system (PMIP based S5 for 3GPP accesses, and PMIP based > S2b for no-3GPP accesses.) > >> It's a question of whether we agree that LMA-MAG signaling could also be >> used in addition to relying only on L2 signaling for flow mobility. > > At this stage the question is rather, is it possible to provide a > correct and robust system without modified L2 signaling. If it is, > then we can go ahead with the question you laid above. Would you > agree? > >>> (And of course, splitting to different specifications should not be >>> misused to hide a technical omission or a problem.) >> >> I would focus on getting a protocol that works under different cases and not >> just under continued reliance on (existing and new) L2 signaling. (I am not >> referring to new IP signaling between MN and MAG). > > See above. The focus you propose is only appropriate insofar we've > come up with a positive answer to the question I asked above, and that > we' re discussing with Carlos, Hesham, et al. > > --julien From Marco.Liebsch@neclab.eu Fri Mar 4 08:03:42 2011 Return-Path: <Marco.Liebsch@neclab.eu> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C7503A68EE for <netext@core3.amsl.com>; Fri, 4 Mar 2011 08:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.307 X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[AWL=-0.058, 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 x2OxdhwHJ0v9 for <netext@core3.amsl.com>; Fri, 4 Mar 2011 08:03:41 -0800 (PST) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id A570F3A6802 for <netext@ietf.org>; Fri, 4 Mar 2011 08:03:40 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 0E61B28000195; Fri, 4 Mar 2011 17:06:06 +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 s+HR8vMgJEr1; Fri, 4 Mar 2011 17:06:05 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id E5EAB28000190; Fri, 4 Mar 2011 17:05:50 +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, 4 Mar 2011 17:04:34 +0100 Message-ID: <4D710D92.8030009@neclab.eu> Date: Fri, 4 Mar 2011 17:04:34 +0100 From: Marco Liebsch <marco.liebsch@neclab.eu> User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Jari Arkko <jari.arkko@piuha.net> References: <4D6C026E.1040508@piuha.net> In-Reply-To: <4D6C026E.1040508@piuha.net> Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.6.62] Cc: "netext@ietf.org" <netext@ietf.org>, draft-ietf-netext-pmip6-lr-ps@tools.ietf.org Subject: Re: [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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 04 Mar 2011 16:03:42 -0000 Jari, thanks for your feedback. All your comments are correct and we should address them in an update. I'll propose and post text for the three sections you point to in hope for an update by e.o. next week. marco Jari Arkko wrote: > 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. > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Basavaraj.Patil@nokia.com Fri Mar 4 09:57:00 2011 Return-Path: <Basavaraj.Patil@nokia.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA61C3A6856 for <netext@core3.amsl.com>; Fri, 4 Mar 2011 09:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.984 X-Spam-Level: X-Spam-Status: No, score=-102.984 tagged_above=-999 required=5 tests=[AWL=0.615, 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 rXYr2gy+MHLr for <netext@core3.amsl.com>; Fri, 4 Mar 2011 09:57:00 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id E6D723A6818 for <netext@ietf.org>; Fri, 4 Mar 2011 09:56:59 -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 p24Hw16q010337; Fri, 4 Mar 2011 19:58:06 +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 Mar 2011 19:57:56 +0200 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 4 Mar 2011 18:57:55 +0100 Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.127]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0270.002; Fri, 4 Mar 2011 18:57:55 +0100 From: <Basavaraj.Patil@nokia.com> To: <julien.ietf@gmail.com> Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvTH7hRFKVN0Kr67UiTaBIlg8gywgAejl2AAAHvnYAAAaltAAAAevCAAA8x8gAAE1N8AAADW1qAAANRXoAAAMIDgAADjsKAAAfFm4AAHfplgAABZ90AAAgHUYAAAEM0AACbGJiAAAdu4YAAEPkHAAAFGCYAAABJUQAAAC5+AAAPG+WAAAjrAQAAGQ+MAABBK/AAAAniXYAAA+6+UP//5p6A//7AnGA= Date: Fri, 4 Mar 2011 17:57:54 +0000 Message-ID: <97683F8C138FB243AAC90CEFB48ABF1509269121@008-AM1MPN1-004.mgdnok.nokia.com> References: <C993D070.182DA%hesham@elevatemobile.com> <1299066222.5356.17.camel@acorde.it.uc3m.es> <AANLkTi=ScUtUfSJLMC-bMbvopwV-fJMroSyvf4hmXsQy@mail.gmail.com> <1299195167.3889.30.camel@acorde.it.uc3m.es> <97683F8C138FB243AAC90CEFB48ABF1509268CE9@008-AM1MPN1-004.mgdnok.nokia.com> <AANLkTikOdW4RMUvwuFjjoC8xar8FJg7FyBsc_-kU02M+@mail.gmail.com> In-Reply-To: <AANLkTikOdW4RMUvwuFjjoC8xar8FJg7FyBsc_-kU02M+@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.59.31] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Mar 2011 17:57:56.0699 (UTC) FILETIME=[B12252B0:01CBDA95] X-Nokia-AV: Clean Cc: netext@ietf.org, JuanCarlos.Zuniga@interdigital.com 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 04 Mar 2011 17:57:00 -0000 >>>> >>>> > - Point-to-point emulation: MAG send the RA to the unicast=20 >>>> > link-local address of the MN or it sends it multicast in IPv6 but=20 >>>> > addressed to the >>>> > L2 address of the MN only. >>>> >>>> PMIPv6 assumes a point-to-point *link*. You are talking about=20 >>>> unicasting RAs which implements a subnet in which only one MN stands. >>>> This doesn't give you a point-to-point link. Since we do not change=20 >>>> the L3 between MN and MAG, a point-to-point link has to be provided=20 >>>> at L2. How do you do that? >>> >>>I've just described how I make our lab proto work, emulating a >>>point-to-point link over a point-to-multipoint one.=20 >> >> I agree with Carlo's comment about how one could emulate a PtP link >> over wifi. You do not have to change the Wifi Mac to emulate a PtP >> link.=20 > >So you disagree with my comment that what Carlos is doing only >implements a per-MN subnet model, and does not emulate a >point-to-point link?=20 Keyword here is emulate... Not really implement a PtP link. For a real PtP link you could run PPP between the MN and the AP. It is definitely not something like PDCP which creates a PtP link.=20 For lab purposes emulating a PtP link is sufficient, especially to verify the protocol operation.=20 > >If so, maybe you or Carlos can explain how having a per-MN subnet >model can constrain a shared link to have only two endpoints...=20 If you have the ability to modify the AP, you could emulate the PtP link quite well. Dont know what kind of an AP Carlos has or the details of his lab setup. But the fact is he has a working model. -Raj=20 > >--julien > From julien.ietf@gmail.com Fri Mar 4 11:28:38 2011 Return-Path: <julien.ietf@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 991553A6A1D for <netext@core3.amsl.com>; Fri, 4 Mar 2011 11:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.242 X-Spam-Level: X-Spam-Status: No, score=-3.242 tagged_above=-999 required=5 tests=[AWL=0.357, 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 c-iG0uq-izVz for <netext@core3.amsl.com>; Fri, 4 Mar 2011 11:28: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 5ED8A3A6A17 for <netext@ietf.org>; Fri, 4 Mar 2011 11:28:37 -0800 (PST) Received: by fxm15 with SMTP id 15so2646830fxm.31 for <netext@ietf.org>; Fri, 04 Mar 2011 11:29:46 -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=0R9rYTVD/QV9jOfPy414kGr0yIICdoeofiHF21eCLpU=; b=szhOL2oiojhqYCgnQqSS8bKGpJtxVJ+FI3Rfx/CaMxXt6ivPGJAzTkOhArmwP0Ad8c eprx5l+jDr9hQ6EGr/UbqVtT2G5VTCP1wxPX+5Te90Tsgq8C93fdBssgScQpMn8lkvTO oos+I4LmUgOqn2D2AF/jhF3KyhzAqZVE458DE= 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=ZfIE/c5BdGYCthlWQcAiPv7FGmAgTEJ1PzsdwhManvefqx9G1BrY8L8UYQB/F4CISH xc8K8b0/yeTWuPXnI4g4t80/tRtGCk2zEpzc1uA803eeCNTwF6Tiq0FZEytyCoh8IycQ ZvyJI4dRgXfqY3JozM75fU0DTYjmsWzKnjCug= MIME-Version: 1.0 Received: by 10.223.15.217 with SMTP id l25mr1287935faa.15.1299266986329; Fri, 04 Mar 2011 11:29:46 -0800 (PST) Received: by 10.223.93.141 with HTTP; Fri, 4 Mar 2011 11:29:46 -0800 (PST) In-Reply-To: <C995BB43.E160%rkoodli@cisco.com> References: <AANLkTim25tLfusBFkY35AFi_7fXucQ4etjKxj4y-KLEf@mail.gmail.com> <C995BB43.E160%rkoodli@cisco.com> Date: Fri, 4 Mar 2011 11:29:46 -0800 Message-ID: <AANLkTimPs4cUwwLEnCvmxDx2g5sSuosie2hif9OjRBgR@mail.gmail.com> From: Julien Laganier <julien.ietf@gmail.com> To: Rajeev Koodli <rkoodli@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Update on flow mobility following discussion with ADs X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 04 Mar 2011 19:28:38 -0000 Hi Rajeev, I've been under the impression that correctness is only achievable to the extent that the network offers flow-mobility / inter-access handoffs only to the MN that indicates their support for the feature (e.g., via the logical interface construct, or any other.) If that holds, since the MN can' t indicate this at layer 3, this has to be done at layer 2, thus you need this extended L2 signaling in all cases. Am I missing something? --julien On Thu, Mar 3, 2011 at 9:40 PM, Rajeev Koodli <rkoodli@cisco.com> wrote: > > Hi Julien, > > I don't believe I suggested sacrificing correctness and robustness; in fact, > I suggested robustness of protocol operation to cover all cases. > > More to the point, I think relying _only_ on extended L2 signaling is one of > the cases the protocol needs to cover. We need to include the case when > either new L2 signaling is unavailable or is not considered reliable. > > I am proposing an inclusive approach for providing flow mobility when the > desired aspects of L2 signaling are available (HI=Flow Mobility) _and_ > consider the case when we they are not available (HI=Unknown). I should be > able to move flows across interfaces regardless of whether the LMA maintains > a single session or multiple sessions (all created according to the baseline > PMIP6 model). > > Making use of 3GPP as a customer is great, but I do not want to be limited > only to it. > > Thanks, > > -Rajeev > > > > On 3/3/11 11:44 AM, "Julien Laganier" <julien.ietf@gmail.com> wrote: > >> Hi Rajeev, >> >> On Wed, Mar 2, 2011 at 12:39 PM, Rajeev Koodli <rkoodli@cisco.com> wrote: >>> >>> >>> On 3/2/11 11:49 AM, "Jari Arkko" <jari.arkko@piuha.net> wrote: >>> >>>> Sri: >>>> >>>> What Basavaraj said. I don't think the number of specifications is a big >>>> concern either now or later. Split the documents the way you like. Lets >>>> discuss functionality, robustness, assumptions instead -- those are >>>> important. >>> >>> >>> I agree that the spec should be robust, and should work under conditions >>> assuming existing & new L2 signaling, as well as under conditions when new >>> L2 signaling is unavailable. >> >> I have expressed doubts about the feasibility of a robust flow >> mobility / inter-access handover solution that relies on existing, >> unmodified L2 signaling (this is discussed in a different thread.) We >> should not sacrifice correctness and robustness for the sake of >> working around unmodified L2 signaling. As I've said earlier, one of >> the potential customer for this (3GPP) owns two L2 that are used to >> access their system (PMIP based S5 for 3GPP accesses, and PMIP based >> S2b for no-3GPP accesses.) >> >>> It's a question of whether we agree that LMA-MAG signaling could also be >>> used in addition to relying only on L2 signaling for flow mobility. >> >> At this stage the question is rather, is it possible to provide a >> correct and robust system without modified L2 signaling. If it is, >> then we can go ahead with the question you laid above. Would you >> agree? >> >>>> (And of course, splitting to different specifications should not be >>>> misused to hide a technical omission or a problem.) >>> >>> I would focus on getting a protocol that works under different cases and not >>> just under continued reliance on (existing and new) L2 signaling. (I am not >>> referring to new IP signaling between MN and MAG). >> >> See above. The focus you propose is only appropriate insofar we've >> come up with a positive answer to the question I asked above, and that >> we' re discussing with Carlos, Hesham, et al. >> >> --julien > > From JuanCarlos.Zuniga@InterDigital.com Fri Mar 4 11:58:03 2011 Return-Path: <JuanCarlos.Zuniga@InterDigital.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43B853A6A1D for <netext@core3.amsl.com>; Fri, 4 Mar 2011 11:58:03 -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=[AWL=0.600, 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 MWq1cmXUih4q for <netext@core3.amsl.com>; Fri, 4 Mar 2011 11:58:02 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 119D93A6830 for <netext@ietf.org>; Fri, 4 Mar 2011 11:58:01 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Mar 2011 14:59:18 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 4 Mar 2011 14:59:10 -0500 Message-ID: <D60519DB022FFA48974A25955FFEC08C03A5D22C@SAM.InterDigital.com> In-Reply-To: <AANLkTimPs4cUwwLEnCvmxDx2g5sSuosie2hif9OjRBgR@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Update on flow mobility following discussion with ADs Thread-Index: Acvaoouto6WBti3eRpa0KgjPNWG1hgAA+QJw References: <AANLkTim25tLfusBFkY35AFi_7fXucQ4etjKxj4y-KLEf@mail.gmail.com><C995BB43.E160%rkoodli@cisco.com> <AANLkTimPs4cUwwLEnCvmxDx2g5sSuosie2hif9OjRBgR@mail.gmail.com> From: "Zuniga, Juan Carlos" <JuanCarlos.Zuniga@InterDigital.com> To: "Julien Laganier" <julien.ietf@gmail.com>, "Rajeev Koodli" <rkoodli@cisco.com> X-OriginalArrivalTime: 04 Mar 2011 19:59:18.0493 (UTC) FILETIME=[A56BE8D0:01CBDAA6] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Update on flow mobility following discussion with ADs X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 04 Mar 2011 19:58:03 -0000 Julien, Capability discovery can be achieved by layer-2, 3 or even 7. The current charter restriction is specifically about no MN-ntwk PMIP signalling, and layer-2 signalling is outside the scope. Hence, I think it is fair to design a PMIP flow mobility solution with the following assumptions: 1) MN capabilities are known, 2) possible existence of layer-2 signalling to provide hints (HI=3DFlow Mobility), 3) and possible non-existence of layer-2 signalling to provide hints (HI=3DUnknown) Cheers, Juan Carlos > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > Behalf Of Julien Laganier > Sent: March 4, 2011 2:30 PM > To: Rajeev Koodli > Cc: netext@ietf.org; Basavaraj.Patil@nokia.com > Subject: Re: [netext] Update on flow mobility following discussion with > ADs >=20 > Hi Rajeev, >=20 > I've been under the impression that correctness is only achievable to > the extent that the network offers flow-mobility / inter-access > handoffs only to the MN that indicates their support for the feature > (e.g., via the logical interface construct, or any other.) If that > holds, since the MN can' t indicate this at layer 3, this has to be > done at layer 2, thus you need this extended L2 signaling in all > cases. >=20 > Am I missing something? >=20 > --julien >=20 > On Thu, Mar 3, 2011 at 9:40 PM, Rajeev Koodli <rkoodli@cisco.com> > wrote: > > > > Hi Julien, > > > > I don't believe I suggested sacrificing correctness and robustness; > in fact, > > I suggested robustness of protocol operation to cover all cases. > > > > More to the point, I think relying _only_ on extended L2 signaling is > one of > > the cases the protocol needs to cover. We need to include the case > when > > either new L2 signaling is unavailable or is not considered reliable. > > > > I am proposing an inclusive approach for providing flow mobility when > the > > desired aspects of L2 signaling are available (HI=3DFlow Mobility) > _and_ > > consider the case when we they are not available (HI=3DUnknown). I > should be > > able to move flows across interfaces regardless of whether the LMA > maintains > > a single session or multiple sessions (all created according to the > baseline > > PMIP6 model). > > > > Making use of 3GPP as a customer is great, but I do not want to be > limited > > only to it. > > > > Thanks, > > > > -Rajeev > > > > > > > > On 3/3/11 11:44 AM, "Julien Laganier" <julien.ietf@gmail.com> wrote: > > > >> Hi Rajeev, > >> > >> On Wed, Mar 2, 2011 at 12:39 PM, Rajeev Koodli <rkoodli@cisco.com> > wrote: > >>> > >>> > >>> On 3/2/11 11:49 AM, "Jari Arkko" <jari.arkko@piuha.net> wrote: > >>> > >>>> Sri: > >>>> > >>>> What Basavaraj said. I don't think the number of specifications is > a big > >>>> concern either now or later. Split the documents the way you like. > Lets > >>>> discuss functionality, robustness, assumptions instead -- those > are > >>>> important. > >>> > >>> > >>> I agree that the spec should be robust, and should work under > conditions > >>> assuming existing & new L2 signaling, as well as under conditions > when new > >>> L2 signaling is unavailable. > >> > >> I have expressed doubts about the feasibility of a robust flow > >> mobility / inter-access handover solution that relies on existing, > >> unmodified L2 signaling (this is discussed in a different thread.) > We > >> should not sacrifice correctness and robustness for the sake of > >> working around unmodified L2 signaling. As I've said earlier, one of > >> the potential customer for this (3GPP) owns two L2 that are used to > >> access their system (PMIP based S5 for 3GPP accesses, and PMIP based > >> S2b for no-3GPP accesses.) > >> > >>> It's a question of whether we agree that LMA-MAG signaling could > also be > >>> used in addition to relying only on L2 signaling for flow mobility. > >> > >> At this stage the question is rather, is it possible to provide a > >> correct and robust system without modified L2 signaling. If it is, > >> then we can go ahead with the question you laid above. Would you > >> agree? > >> > >>>> (And of course, splitting to different specifications should not > be > >>>> misused to hide a technical omission or a problem.) > >>> > >>> I would focus on getting a protocol that works under different > cases and not > >>> just under continued reliance on (existing and new) L2 signaling. > (I am not > >>> referring to new IP signaling between MN and MAG). > >> > >> See above. The focus you propose is only appropriate insofar we've > >> come up with a positive answer to the question I asked above, and > that > >> we' re discussing with Carlos, Hesham, et al. > >> > >> --julien > > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From julien.ietf@gmail.com Fri Mar 4 15:57:23 2011 Return-Path: <julien.ietf@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E0B63A692D for <netext@core3.amsl.com>; Fri, 4 Mar 2011 15:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.946 X-Spam-Level: X-Spam-Status: No, score=-2.946 tagged_above=-999 required=5 tests=[AWL=0.053, 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 a8YQ7ptmgh0J for <netext@core3.amsl.com>; Fri, 4 Mar 2011 15:57: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 575153A6921 for <netext@ietf.org>; Fri, 4 Mar 2011 15:57:22 -0800 (PST) Received: by fxm15 with SMTP id 15so2840308fxm.31 for <netext@ietf.org>; Fri, 04 Mar 2011 15:58: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; bh=y/wschWA2ekpRJtKVl2C37pTfqcEUeYjdbd9wO7syuU=; b=l+GgOyJPZxlRa8A+aRWFD0FRfvDClQor438pu4O2QYoF8defYrAs/2uMYS9U42xc9R wZoWBEJWJYSsbpzXBqzc1rwCpwXcfXhxjGU98s8mVcMwmOo9vgKHnsyizXxPjH9J0BAM DXfXoatJF7a+JMw0dpkZAlYgfYoQTBcZS3mBw= 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=Lb+Cx8ZaJintzMbQ0KjRrkawQkNJpH+VNjiDTaCwS9lF2cU9XFDRnB4f0l3xBk86LZ nNtDhsIvg6mMKLMyZ+rKsXCgFZuM0tI7tE8H0geG3KlikRqsWh4HEXPqDMpAx8tDj1Ov Rbae6EeIqQpah4n1oUtRUS9LpcA0GfapJmHwk= MIME-Version: 1.0 Received: by 10.223.69.131 with SMTP id z3mr1512455fai.91.1299283111375; Fri, 04 Mar 2011 15:58:31 -0800 (PST) Received: by 10.223.93.141 with HTTP; Fri, 4 Mar 2011 15:58:31 -0800 (PST) In-Reply-To: <D60519DB022FFA48974A25955FFEC08C03A5D22C@SAM.InterDigital.com> References: <AANLkTim25tLfusBFkY35AFi_7fXucQ4etjKxj4y-KLEf@mail.gmail.com> <C995BB43.E160%rkoodli@cisco.com> <AANLkTimPs4cUwwLEnCvmxDx2g5sSuosie2hif9OjRBgR@mail.gmail.com> <D60519DB022FFA48974A25955FFEC08C03A5D22C@SAM.InterDigital.com> Date: Fri, 4 Mar 2011 15:58:31 -0800 Message-ID: <AANLkTikmfsfBOFy8je=KFw+FtT8SYhw7yBkZ6mK50mO6@mail.gmail.com> From: Julien Laganier <julien.ietf@gmail.com> To: "Zuniga, Juan Carlos" <JuanCarlos.Zuniga@interdigital.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: Basavaraj.Patil@nokia.com, netext@ietf.org Subject: Re: [netext] Update on flow mobility following discussion with ADs X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 04 Mar 2011 23:57:23 -0000 Juan Carlos, On Fri, Mar 4, 2011 at 11:59 AM, Zuniga, Juan Carlos <JuanCarlos.Zuniga@interdigital.com> wrote: > Julien, > > Capability discovery can be achieved by layer-2, 3 or even 7. The > current charter restriction is specifically about no MN-ntwk PMIP > signalling, and layer-2 signalling is outside the scope. We assume that a L2 construct (logical interface) isolates the unmodified IP stack from the underlying diversity of physical interfaces. From this point of view it seems fair that the L2 signaling is in charge of signaling the capabilities of the MN (and this has been done in 3GPP.) Of course the layer 2 signaling definition is out-of-scope of this group, but as it's been done in 5213 where reasonable assumptions were made on what the L2 signaling has to provide (attach triggers, MNID, and possibly handoff indicator), for this flow mobility work item we're certainly in a position to make the assumption that flow mobility requires capability support indication and intent to do flow mobility vs. inter-access handoff. Actually, we have no choice if we want a working system (see point at the end of this note.) The IP layer is unmodified and the charter forbids this group to define a layer 3 MN-network signaling. I don't know how a layer 7 would know anything about the capability of the network stack to hide to the IP layer the underlying physical interfaces... > Hence, I think it is fair to design a PMIP flow mobility solution with > the following assumptions: > > 1) MN capabilities are known, by magic? > 2) possible existence of layer-2 signalling to provide hints (HI=Flow > Mobility), > 3) and possible non-existence of layer-2 signalling to provide hints > (HI=Unknown) in 5213 HI=unknown leads the network to not provide inter-access handoffs because it could break connectivity at a legacy host. I don' t see how we can depart from that and thus if HI= unknown no flow mobility should be offered to the host, only basic 5213 model where each interface of host has its own PMIPv6 session. If you offer flow mobility when the network does not reliably know the capability of the host you risk breaking that host thus the protocol extension would have no correctness... --julien From julien.ietf@gmail.com Fri Mar 4 17:34:24 2011 Return-Path: <julien.ietf@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B30473A69D7 for <netext@core3.amsl.com>; Fri, 4 Mar 2011 17:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.246 X-Spam-Level: X-Spam-Status: No, score=-3.246 tagged_above=-999 required=5 tests=[AWL=0.353, 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 TxJqq0qRwULf for <netext@core3.amsl.com>; Fri, 4 Mar 2011 17:34: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 5D8B63A68D4 for <netext@ietf.org>; Fri, 4 Mar 2011 17:34:22 -0800 (PST) Received: by fxm15 with SMTP id 15so2881303fxm.31 for <netext@ietf.org>; Fri, 04 Mar 2011 17:35: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=AtEmFum+hyTJAZF9iwmdpYlokWWWCCaAKlGVH1G4cmk=; b=VEVs/AajLhoHWGxEe65cqL/i2L5fY4Zo82uMPrIR7LMSDLUh0txz8GLCeq2wSxoscz eYxAHzHAx3xKhl2XxCBbmG8MD3Dk3VYCzZ4sfwuue4Qy9izlYo0bPCPm3zR5uUYRFzRV YlvNPD9sV4WFunMQiTt2jK7eWSpcYTcVL24vc= 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=t6mM+Tbmnnmb3Db/MyOw8gGcEcp7jBfNm+J95vfHskrI0lcgNaZ+3pVhxPkCWR2Dw5 g50CpDo/OQl9bSrYJ6dC+/H8GNGIlbs/QZncrMLOhSObM242O1fpa5GyW5pFhvAOCNZw 0QMG5eEEyAHQyZiBsuvTMrEEJEmCK1NkaKiPA= MIME-Version: 1.0 Received: by 10.223.160.80 with SMTP id m16mr1625711fax.72.1299288931615; Fri, 04 Mar 2011 17:35:31 -0800 (PST) Received: by 10.223.93.141 with HTTP; Fri, 4 Mar 2011 17:35:31 -0800 (PST) In-Reply-To: <AANLkTimZaSe5FAoLh3fzAaOFPe5K676OXXOMw0UctsJn@mail.gmail.com> References: <AANLkTi=Fsr15UL7V=y1QovzN0OfgK8CTv3ito0Cz0MKL@mail.gmail.com> <C98C3FCF.DC9B%rkoodli@cisco.com> <AANLkTinZBDDWsCpkuo9RoWG4f7z5Rp9Ly1=HBdiHGO-F@mail.gmail.com> <AANLkTimiCyWgz8p8H0LRp6+Xds0-m6LVAarU-Fo6-f2E@mail.gmail.com> <AANLkTi=f9c7FhAyO8P1o-9Dt0ny6s816rRr+kHMU2Gxn@mail.gmail.com> <AANLkTimZaSe5FAoLh3fzAaOFPe5K676OXXOMw0UctsJn@mail.gmail.com> Date: Fri, 4 Mar 2011 17:35:31 -0800 Message-ID: <AANLkTinoq0BxYGjgtsu-niw25sTXJRvCkH037AzVJu_v@mail.gmail.com> From: Julien Laganier <julien.ietf@gmail.com> To: Tran Minh Trung <trungtm2909@gmail.com> 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 05 Mar 2011 01:34:24 -0000 Hi Tran, Sorry for not replying earlier... On Mon, Feb 28, 2011 at 2:08 AM, Tran Minh Trung <trungtm2909@gmail.com> wr= ote: > Hi Julien, > > On Sat, Feb 26, 2011 at 1:06 AM, Julien Laganier <julien.ietf@gmail.com> = wrote: >> 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?. RFC 5213 assumes but does not define L2 signaling. The assumptions are that the L2 signaling carries attach, detach, and optionally intra-access handoff and inter-access handoff. The latter is required to support any type of inter-access handover because without it a legacy MN could end up with no connectivity at all if configured with same prefix/address over two different interfaces. > Can this L2 signaling be sent to all MAGs even though the UE just > activates a PDN connection over a specific PHY interface (MAG)?. If the specific connection is to have flow mobility enabled through a given physical interface, the L2 signaling can certainly be sent to the MAG that serves that physical interface if the specification says so. It doesn't need to happen all at once. It only need to happen when the specific physical interface is to be brought up, or when the session (e.g., PDN connection) is created, whichever happens first. > 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. Why would this be magic. PDN connection creation entails L2 signaling. So you just piggyback on that L2 signaling to attach the physical interfaces to the session / PDN connection. >>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 =A0TS 23.402, 401 as well as TR 23.861 =A0(Multi access PD= N > 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. I think this is the wrong section of 23.402. The initial attach would be in section 7.2.1., and the inter-access handoff in 8.2.3. > 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] =A0(PMIPv6 extension for flow > mobility) > 3. =A0User 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 connec= tivity > > Q1. What is the information in Session 2?. Dose it include the PDN > logical interface ID or just 3GPP Interface ID? 3GPP wise, activation of a PDN connection would be indicated via indicating a distinct APN for the PDN to which to connect the PDN connection. > Q2. When the L2 signaling, that you mentioned, is sent to both MAG1 > and MAG2?. Is it before =A0"PDN Connectivity Request" or after =A0"RRC > Connection Reconfiguration Complete"?. For inter-access hand-off: The L2 signaling on the 3GPP access side is in step 3 of section 8.2.1.1. where the UE uses a Request Type indicating "Handover" Attach that corresponds to a handoff indicator of " inter-access handoff". The L2 signaling on the non-3GPP access side is the signaling of the underlying layer to IP, i.e., IKEv2. The handoff indicator can be set to handoff across interfaces if in the step 4. of section 8.2.3 the UE indicates support for IP address preservation (i.e., the 3GPP term for support of inter-access handoff.) You won't find the steps for flow mobility since it's not supported yet for non-3GPP accesses other than DSMIPv6 based S2c... --julien From sgundave@cisco.com Sat Mar 5 08:45:17 2011 Return-Path: <sgundave@cisco.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2B4F3A6A96 for <netext@core3.amsl.com>; Sat, 5 Mar 2011 08:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.339 X-Spam-Level: X-Spam-Status: No, score=-9.339 tagged_above=-999 required=5 tests=[AWL=-0.136, 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 g1CLASfysjcg for <netext@core3.amsl.com>; Sat, 5 Mar 2011 08:45:15 -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 020B33A6A8C for <netext@ietf.org>; Sat, 5 Mar 2011 08:45:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=8541; q=dns/txt; s=iport; t=1299343585; x=1300553185; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=xVlJhUSO7FhwB3CFskwE+D37HFIZibnym9OGMbDNRVQ=; b=XYc8b+jk27dIM0OzfKlFpJm/mHGrQE8P+4kgPyhR1s6fkESOEL1u6Jlx GRCcPHrUiLFa9L5ch0b3lbZ0Ib2iZIyjbyrRJf99IaeOwSgvzshyiHXNK inhda4oDmiOcQk1sk6s1Z4pc1kOfM+uqk63cUSfC89cbUeOTndWLpnPDv I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgABANP3cU2rR7Ht/2dsb2JhbACYLo1kV3SiAZsVgy0CgjMEhRyHFINJgxQ X-IronPort-AV: E=Sophos;i="4.62,269,1297036800"; d="scan'208";a="274210997" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 05 Mar 2011 16:46:25 +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 p25GkP9M012351; Sat, 5 Mar 2011 16:46:25 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); Sat, 5 Mar 2011 08:46:25 -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 ; Sat, 5 Mar 2011 16:46:25 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Sat, 05 Mar 2011 08:47:55 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: Julien Laganier <julien.ietf@gmail.com> Message-ID: <C997A93B.12134%sgundave@cisco.com> Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvbVRMjnHeASFv0REeZh42tPDHRbg== In-Reply-To: <AANLkTim4zabH_DJ4wKMU-qgH3zb_CP-f_qsTCHzV=c1h@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 05 Mar 2011 16:46:25.0536 (UTC) FILETIME=[DDD09000:01CBDB54] Cc: netext@ietf.org, JuanCarlos.Zuniga@interdigital.com, Basavaraj.Patil@nokia.com 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 05 Mar 2011 16:45:17 -0000 Julien: The current implementation conforming to RFC-2461/4861 do deal with this. The optimizations that are built in ND to handle the case of no IPv6 router(s) presence on the link, clearly factor the lossy nature of the link loosing RS/RA message in sequence and do provide a clear recovery path. The purpose, mission and the sole objective for that ND stack in the IP hos= t is to discover routers, default-router, prefixes on the link and so it can configure an IPv6 address on its interface. The host that is silenced after max RS transmissions does reset its state machine any time it detects the presence of the routers on the link and its back at square-1, discovery *routers* on the link. A RA message with no PIO option is not forcing the node to suspend its router discovery phase. Just as how a simple IP node/CMIP node recovers from this situation in a fixed link, so does the IPv6 node in the PMIP6 access link. You can verify the code in Kame/BSD and Linux open source implementations. You can even try it out with popular IPv6 host stacks. Sri On 3/3/11 3:55 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: > Sri, >=20 > I don't know of a spec that requires a host receiving an RA without > PIO to send another RS... >=20 > --julien >=20 > On Thu, Mar 3, 2011 at 3:12 PM, Sri Gundavelli <sgundave@cisco.com> wrote= : >> Julien, >>=20 >> Sure, assuming the router is not provisioned to suppress periodic RA's a= nd >> based on the RA frequency, an IPv6 host will eventually obtain an addres= s. >> In case of PMIPv6, the same periodic RA with no PIO's will enable the ho= st >> to retrigger the RS for PIO's and allow the router to discover the host = and >> present its PIO's. >>=20 >>=20 >> Sri >>=20 >>=20 >>=20 >> On 3/3/11 2:59 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: >>=20 >>> Sri, >>>=20 >>> In the ND case, when RS are lost, an IPv6 host will eventually obtain >>> prefix information via receiving a periodic RA, configure an address >>> with SLAAC, and be connected to the Internet. >>>=20 >>> In contrast, in the PMIPv6 case, relying on RS as a mobility trigger >>> can lead to a failure mode in which the host is never detected by the >>> PMIPv6 fabric and has no connectivity to the Internet. >>>=20 >>> --julien >>>=20 >>> On Thu, Mar 3, 2011 at 2:43 PM, Sri Gundavelli <sgundave@cisco.com> wro= te: >>>> Julien: >>>>=20 >>>> RS message can get lost and in sequence, sure, like any other IP packe= t. >>>> So, >>>> the host using stateless autoconf can never configure an IPv6 address,= till >>>> it receives a router advertisement message. So, enabling RA suppress i= s not >>>> desirable. It is also unreliable for any IP host on a normal IPv6 link= to >>>> obtain prefix information, given the probability that RS/RA messages c= an >>>> get >>>> lost. I agree, its the same level of unreliability exists in case of >>>> PMIPv6, >>>> which is one of the triggers for the protocol operation, not just for = flow >>>> mobility. >>>>=20 >>>>=20 >>>>=20 >>>> Regards >>>> Sri >>>>=20 >>>>=20 >>>>=20 >>>> On 3/3/11 10:40 AM, "Julien Laganier" <julien.ietf@gmail.com> wrote: >>>>=20 >>>>> Sri, >>>>>=20 >>>>> Whether or not a host stack send an RS when a link-up event happens i= s >>>>> irrelevant to the design of the PMIPv6 flow mobility for the two >>>>> following reasons: >>>>>=20 >>>>> 1. Stacks with DNAv6 would send an RS, other stack would not. So it's >>>>> not generic and can't be relied upon. >>>>> 2. Even if all stacks were sending RS. RS can be lost. So it's not >>>>> reliable and can' t be relied upon. >>>>>=20 >>>>> --julien >>>>>=20 >>>>> On Wed, Mar 2, 2011 at 9:13 AM, Sri Gundavelli <sgundave@cisco.com> w= rote: >>>>>> Yes, it is relevant in the context of the current discussion. If we = are >>>>>> not >>>>>> on the same page, as how a simple IP host behaves across L3 roams, w= e are >>>>>> not going to converge on what new events L2 or L3 we need. So, this = is >>>>>> relevant. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Thanks >>>>>> Sri >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 3/2/11 8:53 AM, "Basavaraj.Patil@nokia.com" >>>>>> <Basavaraj.Patil@nokia.com> >>>>>> wrote: >>>>>>=20 >>>>>>>=20 >>>>>>> Folks, >>>>>>>=20 >>>>>>> Is this discussion about how MIP6 works even relevant in the contex= t of >>>>>>> the >>>>>>> flow mobility discussion? >>>>>>> There are other questions and concerns that have been raised which = I >>>>>>> would >>>>>>> advise the authors to focus on. >>>>>>>=20 >>>>>>> If you need to understand how movement detection in MIP6 works, ple= ase >>>>>>> refer >>>>>>> to Sec 11.5 of RFC3775. >>>>>>>=20 >>>>>>> -Raj >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On B= ehalf >>>>>>> Of >>>>>>> ext Carlos Jes=FAs Bernardos Cano >>>>>>> Sent: Wednesday, March 02, 2011 10:49 AM >>>>>>> To: Sri Gundavelli >>>>>>> Cc: netext@ietf.org; Zuniga, Juan Carlos >>>>>>> Subject: Re: [netext] Flow Mobility discussion - way forward? >>>>>>>=20 >>>>>>> Hi Sri, >>>>>>>=20 >>>>>>> On Wed, 2011-03-02 at 08:16 -0800, Sri Gundavelli wrote: >>>>>>>>> I'm talking about a legacu IPv6 host. If I install Mobile IPv6 in >>>>>>>>> that Linux stack, don't worry, the MIPv6 client takes care of >>>>>>>>> configuring a CoA (sending an RS if no RA is received). >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Hi Carlos: >>>>>>>>=20 >>>>>>>> (Still keeping the discussion context to this one comment). >>>>>>>>=20 >>>>>>>> - I assume MIPv6 stack is on top of IP stack, not the other way ar= ound >>>>>>>=20 >>>>>>> Well, i reality MIPv6 is part of IPv6, not really sits on top. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> - If IP stack does not detect movement detection across L3 links (= in >>>>>>>> the absence of any other hints about same L3 link, in the forms es= sid >>>>>>>> or other hints), how does the MIPv6 stack which is relying on the >>>>>>>> stack/kernel events, decide to force an RA ? What is the hint ? Ho= w >>>>>>>> come ND/DHCP does not realize the same need to send an RS ? Is MIP= v6 >>>>>>>> stack >>>>>>>> so >>>>>>>> smart ? >>>>>>>=20 >>>>>>> The implementations that I'm familiar with do the following: >>>>>>>=20 >>>>>>> - They wait for an unsolicited RA >>>>>>> - If no unsolicited RA is received in a time interval equal to 2 ti= mes >>>>>>> the >>>>>>> frequency of RAs (there is information about that on the RAs), the = MN >>>>>>> sends >>>>>>> an >>>>>>> RS. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> - Assuming there is no MIPv6 stack on the host, an host moves acro= ss >>>>>>>> access links, it will never do an RS and will keep using the addre= ss >>>>>>>> from the previous link. So, the basic IPv6 connectivity is broken. >>>>>>>> This is a bug, not a protocol gap. >>>>>>>=20 >>>>>>> With WLAN and Linux, that's the behavior. I guess developers unders= tood >>>>>>> that >>>>>>> two APs with the same ESSID belongs to the same ESS, and therefore = the >>>>>>> same >>>>>>> IP >>>>>>> subnet. That actually is correct and cannot be cataloged as "bug". >>>>>>>=20 >>>>>>>>=20 >>>>>>>> PS: I heard about this RS problems 5 years back, when most WLAN >>>>>>>> drivers were not handling IPv6 correctly. I'm pretty sure all the = WLAN >>>>>>>> drivers have fixed those problems now. You may want to replace you= r >>>>>>>> buggy NIC card driver :) >>>>>>>=20 >>>>>>> It's not a buggy NIC card driver. You may say a buggy OS, but I hon= estly >>>>>>> will >>>>>>> not call Linux "buggy" (or at least buggier than many others that a= re >>>>>>> out >>>>>>> there). >>>>>>>=20 >>>>>>> Carlos >>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Regards >>>>>>>> Sri >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 3/2/11 3:34 AM, "Carlos Jes=FAs Bernardos Cano" <cjbc@it.uc3m.es> >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I'm talking about a legacu IPv6 host. If I install Mobile IPv6 in >>>>>>>>> that Linux stack, don't worry, the MIPv6 client takes care of >>>>>>>>> configuring a CoA (sending an RS if no RA is received). >>>>>>>>>=20 >>>>>>>>> Carlos >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> netext mailing list >>>>>> netext@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netext >>>>>>=20 >>>>=20 >>>>=20 >>=20 >>=20 From sgundave@cisco.com Sat Mar 5 08:45:36 2011 Return-Path: <sgundave@cisco.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DFCE28C0E7 for <netext@core3.amsl.com>; Sat, 5 Mar 2011 08:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.03 X-Spam-Level: X-Spam-Status: No, score=-10.03 tagged_above=-999 required=5 tests=[AWL=0.569, 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 f8sB3Gl9CxaP for <netext@core3.amsl.com>; Sat, 5 Mar 2011 08:45:35 -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 385AA28C0E6 for <netext@ietf.org>; Sat, 5 Mar 2011 08:45:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=1062; q=dns/txt; s=iport; t=1299343606; x=1300553206; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=gqWf/+FeQPOCT8D8aus6JRUJ3plDsmO9mc08n5ycjts=; b=V8nb/mA+A5h+UdMznUi6Y2P3k/CyKfvrUXizEQRDwdafLsPiA9j1isFK 1q0thSCPxGsSfQ8zAi4zg+7pbSr7wAz9Ku4aDHSxSnoyS75Z/99/2TNPJ dP+UfhX4TtYJe3Z0DJ5oDyXpiJlJu8Z865i6B4L3xwnHwXu19VKXHxQSd k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJf3cU2rR7Hu/2dsb2JhbACmaXShf5sVhWIEhRyHFINJ X-IronPort-AV: E=Sophos;i="4.62,269,1297036800"; d="scan'208";a="339879897" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 05 Mar 2011 16:46:46 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p25GkkRb006310; Sat, 5 Mar 2011 16:46:46 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); Sat, 5 Mar 2011 08:46: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 ; Sat, 5 Mar 2011 16:46:45 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Sat, 05 Mar 2011 08:48:18 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: Hesham Soliman <hesham@elevatemobile.com>, Julien Laganier <julien.ietf@gmail.com> Message-ID: <C997A952.12136%sgundave@cisco.com> Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvZ+GwqM3i4vBIYv0S4SSX0HbqFWAALRJHmAEvomqI= In-Reply-To: <C996B718.183C9%hesham@elevatemobile.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Mar 2011 16:46:45.0990 (UTC) FILETIME=[EA019860:01CBDB54] Cc: netext@ietf.org, JuanCarlos.Zuniga@interdigital.com, Basavaraj.Patil@nokia.com 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 05 Mar 2011 16:45:36 -0000 On 3/3/11 8:34 PM, "Hesham Soliman" <hesham@elevatemobile.com> wrote: > > >> Julien, >> >> Sure, assuming the router is not provisioned to suppress periodic RA's and >> based on the RA frequency, an IPv6 host will eventually obtain an address. >> In case of PMIPv6, the same periodic RA with no PIO's will enable the host >> to retrigger the RS for PIO's > > => Why would the host do that? Did I miss something? An empty RA doesn't > trigger anything AFAIK. > We are talking about the case of RS/RA getting loss in simple IP and PMIP links. The node is not shutdown because there is initial ND message loss and the node is not prevented from sending RS messages on the link, as long as there is some indications about router presence on the link. There is sufficient guidance on 2461/4861 on this. The RA with no PIO need not explicitly trigger RS, but that allows the host to continue to keep the discovery phase on, leading to the exact same recovery path for both a node on a simple IPv6 links, vs PMIPv6 links. Sri From hesham@elevatemobile.com Sun Mar 6 17:17:28 2011 Return-Path: <hesham@elevatemobile.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E6D73A68B1 for <netext@core3.amsl.com>; Sun, 6 Mar 2011 17:17:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 lSf-5tRIyFzr for <netext@core3.amsl.com>; Sun, 6 Mar 2011 17:17:27 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 433543A68AF for <netext@ietf.org>; Sun, 6 Mar 2011 17:17:26 -0800 (PST) Received: from [121.219.52.146] (helo=[10.0.0.23]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1PwP5m-0004DZ-Vo; Mon, 07 Mar 2011 12:18:35 +1100 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Mon, 07 Mar 2011 12:18:28 +1100 From: Hesham Soliman <hesham@elevatemobile.com> To: Sri Gundavelli <sgundave@cisco.com>, Julien Laganier <julien.ietf@gmail.com> Message-ID: <C99A7D94.18468%hesham@elevatemobile.com> Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvZ+GwqM3i4vBIYv0S4SSX0HbqFWAALRJHmAEvomqIARBvahA== In-Reply-To: <C997A952.12136%sgundave@cisco.com> 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, JuanCarlos.Zuniga@interdigital.com, Basavaraj.Patil@nokia.com 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 07 Mar 2011 01:17:28 -0000 On 6/03/11 3:48 AM, "Sri Gundavelli" <sgundave@cisco.com> wrote: > > > > On 3/3/11 8:34 PM, "Hesham Soliman" <hesham@elevatemobile.com> wrote: > >> >> >>> Julien, >>> >>> Sure, assuming the router is not provisioned to suppress periodic RA's and >>> based on the RA frequency, an IPv6 host will eventually obtain an address. >>> In case of PMIPv6, the same periodic RA with no PIO's will enable the host >>> to retrigger the RS for PIO's >> >> => Why would the host do that? Did I miss something? An empty RA doesn't >> trigger anything AFAIK. >> > > We are talking about the case of RS/RA getting loss in simple IP and PMIP > links. The node is not shutdown because there is initial ND message loss and > the node is not prevented from sending RS messages on the link, as long as > there is some indications about router presence on the link. => What you said above is that receiving an RA without a prefix option triggers the host to send an RS. I'm not aware of that behaviour specified anywhere. There is > sufficient guidance on 2461/4861 on this. => That an RA without prefix option triggers and RS? Please cite the section. The RA with no PIO need not > explicitly trigger RS, but that allows the host to continue to keep the > discovery phase on, => It does nothing basically. If a host is doing router discovery receiving the RA without prefix option has no effect. Hesham From sgundave@cisco.com Sun Mar 6 18:18:39 2011 Return-Path: <sgundave@cisco.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 632FE3A6827 for <netext@core3.amsl.com>; Sun, 6 Mar 2011 18:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.059 X-Spam-Level: X-Spam-Status: No, score=-10.059 tagged_above=-999 required=5 tests=[AWL=0.540, 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 CXMsEY7wfNqL for <netext@core3.amsl.com>; Sun, 6 Mar 2011 18:18:38 -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 789713A67B1 for <netext@ietf.org>; Sun, 6 Mar 2011 18:18:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=1691; q=dns/txt; s=iport; t=1299464391; x=1300673991; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=OMFuSdaiq5XfHIpFn+lmCNp9zP62QPpEID41T28llOk=; b=gLi3u5eOWJfWR0KHULDIxt6SXy5Q8eV4NHqt2St8FOJomXzhL5RSfgGZ fnSYgOKkczOiz+PNsc49ej47r5/0FQZ+Pm6r0URQIJyMUIwotwLlkz756 yx5H4rRYbhvtwRPL0ixMYlJtvlyG7FTsFxI+tfNQ8w7BybRickinSwM94 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANvPc02rR7Ht/2dsb2JhbACmTXSjPpp9gwWCXQSFHIcUg0k X-IronPort-AV: E=Sophos;i="4.62,274,1297036800"; d="scan'208";a="340766185" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 07 Mar 2011 02:19:51 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p272JpJk028809; Mon, 7 Mar 2011 02:19:51 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); Sun, 6 Mar 2011 18:19:51 -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 ; Mon, 7 Mar 2011 02:19:50 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Sun, 06 Mar 2011 18:21:22 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: Hesham Soliman <hesham@elevatemobile.com>, Julien Laganier <julien.ietf@gmail.com> Message-ID: <C9998122.121DF%sgundave@cisco.com> Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvZ+GwqM3i4vBIYv0S4SSX0HbqFWAALRJHmAEvomqIARBvahAACMl5y In-Reply-To: <C99A7D94.18468%hesham@elevatemobile.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 07 Mar 2011 02:19:51.0189 (UTC) FILETIME=[23985450:01CBDC6E] Cc: netext@ietf.org, JuanCarlos.Zuniga@interdigital.com, Basavaraj.Patil@nokia.com 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 07 Mar 2011 02:18:39 -0000 On 3/6/11 5:18 PM, "Hesham Soliman" <hesham@elevatemobile.com> wrote: >>> >> >> We are talking about the case of RS/RA getting loss in simple IP and PMIP >> links. The node is not shutdown because there is initial ND message loss and >> the node is not prevented from sending RS messages on the link, as long as >> there is some indications about router presence on the link. > > => What you said above is that receiving an RA without a prefix option > triggers the host to send an RS. I'm not aware of that behaviour specified > anywhere. > > > There is >> sufficient guidance on 2461/4861 on this. > > => That an RA without prefix option triggers and RS? Please cite the > section. > > The RA with no PIO need not >> explicitly trigger RS, but that allows the host to continue to keep the >> discovery phase on, > > => It does nothing basically. If a host is doing router discovery receiving > the RA without prefix option has no effect. > Any RA message, with or without PIO options, serves as a hint on the presence of routers on the link, that allows the host to keep/restart the router discovery phase on and will allow the host to reset its max-rs-retry message counter and send the next RS message. If your comment is that they are not directly tied (the RS message from the host due to receiving an RA with no PIO), fine, but the host that suspended its router solicitations after reaching the max RS count, is able to restart the discovery phase and send the next RS message, just because of that periodic RA that it received, which provides the router presence hint on the link. What is the difference ? Sri From hesham@elevatemobile.com Sun Mar 6 18:57:11 2011 Return-Path: <hesham@elevatemobile.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C74A3A67CC for <netext@core3.amsl.com>; Sun, 6 Mar 2011 18:57:11 -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 D5cLVvALXvvG for <netext@core3.amsl.com>; Sun, 6 Mar 2011 18:57:10 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 64EC53A68BA for <netext@ietf.org>; Sun, 6 Mar 2011 18:57:09 -0800 (PST) Received: from [121.219.52.146] (helo=[10.0.0.23]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1PwQeH-0007nP-UQ; Mon, 07 Mar 2011 13:58:18 +1100 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Mon, 07 Mar 2011 13:29:29 +1100 From: Hesham Soliman <hesham@elevatemobile.com> To: Sri Gundavelli <sgundave@cisco.com>, Julien Laganier <julien.ietf@gmail.com> Message-ID: <C99A8E39.1846E%hesham@elevatemobile.com> Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvZ+GwqM3i4vBIYv0S4SSX0HbqFWAALRJHmAEvomqIARBvahAACMl5yAABIks8= In-Reply-To: <C9998122.121DF%sgundave@cisco.com> 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, JuanCarlos.Zuniga@interdigital.com, Basavaraj.Patil@nokia.com 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 07 Mar 2011 02:57:11 -0000 On 7/03/11 1:21 PM, "Sri Gundavelli" <sgundave@cisco.com> wrote: > > > > On 3/6/11 5:18 PM, "Hesham Soliman" <hesham@elevatemobile.com> wrote: > >>>> >>> >>> We are talking about the case of RS/RA getting loss in simple IP and PMIP >>> links. The node is not shutdown because there is initial ND message loss and >>> the node is not prevented from sending RS messages on the link, as long as >>> there is some indications about router presence on the link. >> >> => What you said above is that receiving an RA without a prefix option >> triggers the host to send an RS. I'm not aware of that behaviour specified >> anywhere. >> >> >> There is >>> sufficient guidance on 2461/4861 on this. >> >> => That an RA without prefix option triggers and RS? Please cite the >> section. >> >> The RA with no PIO need not >>> explicitly trigger RS, but that allows the host to continue to keep the >>> discovery phase on, >> >> => It does nothing basically. If a host is doing router discovery receiving >> the RA without prefix option has no effect. >> > > > Any RA message, with or without PIO options, serves as a hint on the > presence of routers on the link, that allows the host to keep/restart the > router discovery phase on and will allow the host to reset its max-rs-retry > message counter and send the next RS message. If your comment is that they > are not directly tied (the RS message from the host due to receiving an RA > with no PIO), fine, but the host that suspended its router solicitations > after reaching the max RS count, is able to restart the discovery phase and > send the next RS message, just because of that periodic RA that it received, > which provides the router presence hint on the link. What is the difference > ? > => What is the difference between what you say above and what you said before? You were sugesting a reaction that is not specified anywhere. That's the difference. The fact is, an "empty" RA for lack of a better term has no effect on the host's behaviour according to 4861. So whether the host is doing router discovery or not, it makes no difference. The host will continue with its normal behaviour. Of course implementations can choose to do things differently, but I wouldn't state it like an expected behaviour. That's why I responded to your comment because it confuses people to suggest that this is "how things work". Hesham > > > Sri > > > > From sgundave@cisco.com Sun Mar 6 19:01:11 2011 Return-Path: <sgundave@cisco.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E3823A68C7 for <netext@core3.amsl.com>; Sun, 6 Mar 2011 19:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.084 X-Spam-Level: X-Spam-Status: No, score=-10.084 tagged_above=-999 required=5 tests=[AWL=0.515, 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 zn2MslwZvrJG for <netext@core3.amsl.com>; Sun, 6 Mar 2011 19:01:09 -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 CBBEB3A6827 for <netext@ietf.org>; Sun, 6 Mar 2011 19:01:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=1577; q=dns/txt; s=iport; t=1299466942; x=1300676542; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=LjZUmjIVproUgY2q1YgMbsVXgYFvtzAso5X6vJecXAY=; b=TW+GRO1d2Tf+YKBb0h3knlxqBpBvQYeJYHIu8h8LRfVWfvB5nsdpJ8AU cYg1J1Lm/uIIOS8dxYeQSEt20k1Rh9Z/zmO9z7Y612oy9xCIRaWEBkyYY 4xPOkCp6mrVl9mU5vUJNgXpZWtJ3ugY1wB0/SCaZc2RdGrrZ5cswpJrVZ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAETZc02rRN+K/2dsb2JhbACmTnSjF5p9gwWCXQSFHIcUg0k X-IronPort-AV: E=Sophos;i="4.62,274,1297036800"; d="scan'208";a="340791659" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 07 Mar 2011 03:02:22 +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 p2732MIT027610; Mon, 7 Mar 2011 03:02:22 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); Sun, 6 Mar 2011 19:02:22 -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 ; Mon, 7 Mar 2011 03:02:22 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Sun, 06 Mar 2011 19:03:54 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: Hesham Soliman <hesham@elevatemobile.com>, Julien Laganier <julien.ietf@gmail.com> Message-ID: <C9998B1A.121F0%sgundave@cisco.com> Thread-Topic: [netext] Flow Mobility discussion - way forward? Thread-Index: AcvZ+GwqM3i4vBIYv0S4SSX0HbqFWAALRJHmAEvomqIARBvahAACMl5yAABIks8AATO1aw== In-Reply-To: <C99A8E39.1846E%hesham@elevatemobile.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 07 Mar 2011 03:02:22.0755 (UTC) FILETIME=[14726730:01CBDC74] Cc: netext@ietf.org, JuanCarlos.Zuniga@interdigital.com, Basavaraj.Patil@nokia.com 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 07 Mar 2011 03:01:11 -0000 On 3/6/11 6:29 PM, "Hesham Soliman" <hesham@elevatemobile.com> wrote: > >> >> >> Any RA message, with or without PIO options, serves as a hint on the >> presence of routers on the link, that allows the host to keep/restart the >> router discovery phase on and will allow the host to reset its max-rs-retry >> message counter and send the next RS message. If your comment is that they >> are not directly tied (the RS message from the host due to receiving an RA >> with no PIO), fine, but the host that suspended its router solicitations >> after reaching the max RS count, is able to restart the discovery phase and >> send the next RS message, just because of that periodic RA that it received, >> which provides the router presence hint on the link. What is the difference >> ? >> > > => What is the difference between what you say above and what you said > before? You were sugesting a reaction that is not specified anywhere. That's > the difference. The fact is, an "empty" RA for lack of a better term has no > effect on the host's behaviour according to 4861. So whether the host is > doing router discovery or not, it makes no difference. The host will > continue with its normal behaviour. Of course implementations can choose to > do things differently, but I wouldn't state it like an expected behaviour. > That's why I responded to your comment because it confuses people to suggest > that this is "how things work". > Ok. This clarification is fine, if it sounded like a "reactionary tie" of the two messages. Sri From Basavaraj.Patil@nokia.com Mon Mar 7 09:16:31 2011 Return-Path: <Basavaraj.Patil@nokia.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD1FF28C0DD for <netext@core3.amsl.com>; Mon, 7 Mar 2011 09:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 9Boa6z6sBfYz for <netext@core3.amsl.com>; Mon, 7 Mar 2011 09:16:31 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id BA29C28C0DB for <netext@ietf.org>; Mon, 7 Mar 2011 09:16:30 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p27HHaYE009939 for <netext@ietf.org>; Mon, 7 Mar 2011 19:17:40 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Mar 2011 19:17:29 +0200 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 7 Mar 2011 18:17:29 +0100 Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.127]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0270.002; Mon, 7 Mar 2011 18:17:28 +0100 From: <Basavaraj.Patil@nokia.com> To: <netext@ietf.org> Thread-Topic: Requests for slots on the agenda Thread-Index: Acvc64fnDDBaH1+LS++zmqlLaD33OQ== Date: Mon, 7 Mar 2011 17:17:28 +0000 Message-ID: <97683F8C138FB243AAC90CEFB48ABF1509269A05@008-AM1MPN1-004.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.59.31] Content-Type: multipart/alternative; boundary="_000_97683F8C138FB243AAC90CEFB48ABF1509269A05008AM1MPN1004mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 07 Mar 2011 17:17:29.0954 (UTC) FILETIME=[89EBAC20:01CBDCEB] X-Nokia-AV: Clean Subject: [netext] Requests for slots on the agenda X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 07 Mar 2011 17:16:31 -0000 --_000_97683F8C138FB243AAC90CEFB48ABF1509269A05008AM1MPN1004mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, So far I have only one request for a slot at the Netext WG meeting at IETF8= 0. Please send a request ASAP if you need a slot. Include I-D name, amount of time required and, a brief explanation as to wh= y this is relevant to the Netext WG. Please note that WG documents and charter items will have priority over oth= er I-Ds. -Chairs --_000_97683F8C138FB243AAC90CEFB48ABF1509269A05008AM1MPN1004mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)"> <style> <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} .MsoChpDefault {mso-style-type:export-only;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --> </style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Hello,<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">So far I have only one request for a slot at the Net= ext WG meeting at IETF80.<o:p></o:p></p> <p class=3D"MsoNormal">Please send a request ASAP if you need a slot.<o:p><= /o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Include I-D name, amount of time required and, a bri= ef explanation as to why this is relevant to the Netext WG.<o:p></o:p></p> <p class=3D"MsoNormal">Please note that WG documents and charter items will= have priority over other I-Ds.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">-Chairs<o:p></o:p></p> </div> </body> </html> --_000_97683F8C138FB243AAC90CEFB48ABF1509269A05008AM1MPN1004mg_-- From Basavaraj.Patil@nokia.com Tue Mar 8 13:46:47 2011 Return-Path: <Basavaraj.Patil@nokia.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0C6B3A66B4 for <netext@core3.amsl.com>; Tue, 8 Mar 2011 13:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKeGj9r3MzXo for <netext@core3.amsl.com>; Tue, 8 Mar 2011 13:46:47 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id B4A513A63C9 for <netext@ietf.org>; Tue, 8 Mar 2011 13:46:46 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p28Llwam019050 for <netext@ietf.org>; Tue, 8 Mar 2011 23:48:01 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Mar 2011 23:47:00 +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; Tue, 8 Mar 2011 22:46:59 +0100 Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.127]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0270.002; Tue, 8 Mar 2011 22:46:59 +0100 From: <Basavaraj.Patil@nokia.com> To: <netext@ietf.org> Thread-Topic: Draft agenda of Netext meeting at IETF80 Thread-Index: AQHL3dpZxZcI01zYUU+tyzUvSvUC0g== Date: Tue, 8 Mar 2011 21:46:58 +0000 Message-ID: <C99BFFEE.11B05%basavaraj.patil@nokia.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.33] Content-Type: text/plain; charset="us-ascii" Content-ID: <38E3A43406436245A8DE2BFBE0D5AC87@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Mar 2011 21:47:00.0347 (UTC) FILETIME=[5AA394B0:01CBDDDA] X-Nokia-AV: Clean Subject: [netext] Draft agenda of Netext meeting at IETF80 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 08 Mar 2011 21:46:48 -0000 http://www.ietf.org/proceedings/80/agenda/netext.txt Agenda (Rev 1) Network-Based Mobility Extensions WG meeting THURSDAY, March 31, 2011 1300-1500 Afternoon Session I (Grand Ballroom) ----------------------------------------------------------------- 1. Logistics (Bluesheets, minutes takers, jabber, agenda bashing) 5 mins 2. WG Status update Chairs 5 Mins 3. Logical Interface Support for multi-mode IP Hosts 20 Mins I-D: draft-ietf-netext-logical-interface-support-(?) Presenter: Telemaco M. (?) 4. Proxy Mobile IPv6 Extensions to Support Flow Mobility 45 Mins I-D: draft-bernardos-netext-pmipv6-flowmob-02 - Summarize the discussion on the ML Raj - Discussion of issues raised The intent of this discussion is to utilize the F2F meeting to resolve issues that we do not seem to have clear answers for on the ML and hence stuck in deadlock. 5. Bulk re-registration updates 5 Mins I-D: draft-ietf-netext-bulk-re-registration-(?) 6. Access Network Information Option for PMIP6 10 Mins I-D: draft-gundavelli-netext-access-network-option-00.txt Presenter: Sri Gundavelli 7. Policy Signaling for Multi-access Mobility 10 Mins I-D: draft-koodli-policy-multiaccess-mobility-00.txt Presenter: Rajeev Koodli From julien.ietf@gmail.com Tue Mar 8 14:16:16 2011 Return-Path: <julien.ietf@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB1DA3A672F for <netext@core3.amsl.com>; Tue, 8 Mar 2011 14:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[AWL=0.349, 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 lGH9IxqoGvab for <netext@core3.amsl.com>; Tue, 8 Mar 2011 14:16:16 -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 BFF1C3A6767 for <netext@ietf.org>; Tue, 8 Mar 2011 14:16:15 -0800 (PST) Received: by fxm15 with SMTP id 15so6074080fxm.31 for <netext@ietf.org>; Tue, 08 Mar 2011 14:17: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=gLOxaD87rgik3K2yP8GVS3p1ryL5siAW0ruwblby2G0=; b=taEJFbNvswBU2G3WBXRzwtAx5MEgYAz6YGUNEUHJP15ebMuiE7LstT9aIl33rzBWc+ uRKh/qW6p2m8mPiq7pp4zr67PpYDLemUoSi8ZEQqMUadNm1mx1hP9FHF4DBuGD39hTE4 USTQhuCGgNsIQhdXxlhS+/ysXxHk0BAbA1nAw= 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=kJE/0lz96TrmhsvMOm7DhxkWMnx/X2zIqkhNyT1ZJtkQUgtHKALDJ28oB3/GwEi5Lm yaQKULlahj8g4pOQyBXvG/rnYIAD+OqbU5Q+8TTx9a5dW+zZSZ1JSL8NDlAVQfStCpen MnzHl6xglMQ+UE1bnnPkaZ8bVeaCZb8QmMsUw= MIME-Version: 1.0 Received: by 10.223.79.78 with SMTP id o14mr7048495fak.110.1299622650598; Tue, 08 Mar 2011 14:17:30 -0800 (PST) Received: by 10.223.93.138 with HTTP; Tue, 8 Mar 2011 14:17:29 -0800 (PST) In-Reply-To: <C99BFFEE.11B05%basavaraj.patil@nokia.com> References: <C99BFFEE.11B05%basavaraj.patil@nokia.com> Date: Tue, 8 Mar 2011 14:17:29 -0800 Message-ID: <AANLkTimy7jHsdArc=4mhcj5evHn7HfYVHqpJaPJV=rNY@mail.gmail.com> From: Julien Laganier <julien.ietf@gmail.com> 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] Draft agenda of Netext meeting at IETF80 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 08 Mar 2011 22:16:17 -0000 Hello Raj, Given the number of issues that we have with both the logical interface and the PMIP extension for flow mobility work items, wouldn't it make sense that we focus on progressing those and allocate one hour to each? Just my 2 cents, --julien On Tue, Mar 8, 2011 at 1:46 PM, <Basavaraj.Patil@nokia.com> wrote: > http://www.ietf.org/proceedings/80/agenda/netext.txt > > > Agenda (Rev 1) > > Network-Based Mobility Extensions WG meeting > > THURSDAY, March 31, 2011 > 1300-1500 Afternoon Session I (Grand Ballroom) > > ----------------------------------------------------------------- > > 1. Logistics (Bluesheets, minutes takers, jabber, agenda bashing) 5 mins > > 2. WG Status update =A0 Chairs =A0 =A0 5 Mins > > 3. Logical Interface Support for multi-mode IP Hosts =A0 20 Mins > =A0 I-D: draft-ietf-netext-logical-interface-support-(?) > =A0 Presenter: Telemaco M. (?) > > 4. Proxy Mobile IPv6 Extensions to Support Flow Mobility 45 =A0Mins > =A0 I-D: draft-bernardos-netext-pmipv6-flowmob-02 > =A0 - Summarize the discussion on the ML =A0 =A0 Raj > =A0 - Discussion of issues raised > The intent of this discussion is to utilize the F2F meeting to resolve > issues that we do not seem to have clear answers for on the ML and > hence stuck in deadlock. > > > 5. Bulk re-registration updates =A05 Mins > =A0 I-D: draft-ietf-netext-bulk-re-registration-(?) > > 6. Access Network Information Option for PMIP6 =A010 Mins > =A0 I-D: draft-gundavelli-netext-access-network-option-00.txt > =A0 Presenter: Sri Gundavelli > > 7. Policy Signaling for Multi-access Mobility =A010 Mins > =A0 I-D: draft-koodli-policy-multiaccess-mobility-00.txt > =A0 Presenter: Rajeev Koodli > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From Basavaraj.Patil@nokia.com Tue Mar 8 14:23:00 2011 Return-Path: <Basavaraj.Patil@nokia.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 243B13A67B2 for <netext@core3.amsl.com>; Tue, 8 Mar 2011 14:22:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.02 X-Spam-Level: X-Spam-Status: No, score=-103.02 tagged_above=-999 required=5 tests=[AWL=0.579, 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 q0QuZEtrRD7V for <netext@core3.amsl.com>; Tue, 8 Mar 2011 14:21:47 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 515BD3A67A5 for <netext@ietf.org>; Tue, 8 Mar 2011 14:21:44 -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 p28MMSoM019676; Wed, 9 Mar 2011 00:22:33 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Mar 2011 00:22:23 +0200 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 8 Mar 2011 23:22:22 +0100 Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.127]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0270.002; Tue, 8 Mar 2011 23:22:22 +0100 From: <Basavaraj.Patil@nokia.com> To: <julien.ietf@gmail.com> Thread-Topic: [netext] Draft agenda of Netext meeting at IETF80 Thread-Index: AQHL3dpZxZcI01zYUU+tyzUvSvUC0pQj8MCAgAAReyA= Date: Tue, 8 Mar 2011 22:22:21 +0000 Message-ID: <97683F8C138FB243AAC90CEFB48ABF150926ABE9@008-AM1MPN1-004.mgdnok.nokia.com> References: <C99BFFEE.11B05%basavaraj.patil@nokia.com> <AANLkTimy7jHsdArc=4mhcj5evHn7HfYVHqpJaPJV=rNY@mail.gmail.com> In-Reply-To: <AANLkTimy7jHsdArc=4mhcj5evHn7HfYVHqpJaPJV=rNY@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.59.35] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Mar 2011 22:22:23.0364 (UTC) FILETIME=[4C0E4440:01CBDDDF] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] Draft agenda of Netext meeting at IETF80 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 08 Mar 2011 22:23:00 -0000 Hi Julien, That might very well be the case.=20 Non-WG chartered items have lesser priority. And the intent is to use the F= 2F meeting time to resolve issues that obviously have not concluded over em= ail. The Logical interface and flow mobility topics will be the focus at th= e upcoming meeting. -Raj -----Original Message----- From: ext Julien Laganier [mailto:julien.ietf@gmail.com]=20 Sent: Tuesday, March 08, 2011 4:17 PM To: Patil Basavaraj (Nokia-MS/Dallas) Cc: netext@ietf.org Subject: Re: [netext] Draft agenda of Netext meeting at IETF80 Hello Raj, Given the number of issues that we have with both the logical interface and the PMIP extension for flow mobility work items, wouldn't it make sense that we focus on progressing those and allocate one hour to each? Just my 2 cents, --julien On Tue, Mar 8, 2011 at 1:46 PM, <Basavaraj.Patil@nokia.com> wrote: > http://www.ietf.org/proceedings/80/agenda/netext.txt > > > Agenda (Rev 1) > > Network-Based Mobility Extensions WG meeting > > THURSDAY, March 31, 2011 > 1300-1500 Afternoon Session I (Grand Ballroom) > > ----------------------------------------------------------------- > > 1. Logistics (Bluesheets, minutes takers, jabber, agenda bashing) 5 mins > > 2. WG Status update =A0 Chairs =A0 =A0 5 Mins > > 3. Logical Interface Support for multi-mode IP Hosts =A0 20 Mins > =A0 I-D: draft-ietf-netext-logical-interface-support-(?) > =A0 Presenter: Telemaco M. (?) > > 4. Proxy Mobile IPv6 Extensions to Support Flow Mobility 45 =A0Mins > =A0 I-D: draft-bernardos-netext-pmipv6-flowmob-02 > =A0 - Summarize the discussion on the ML =A0 =A0 Raj > =A0 - Discussion of issues raised > The intent of this discussion is to utilize the F2F meeting to resolve > issues that we do not seem to have clear answers for on the ML and > hence stuck in deadlock. > > > 5. Bulk re-registration updates =A05 Mins > =A0 I-D: draft-ietf-netext-bulk-re-registration-(?) > > 6. Access Network Information Option for PMIP6 =A010 Mins > =A0 I-D: draft-gundavelli-netext-access-network-option-00.txt > =A0 Presenter: Sri Gundavelli > > 7. Policy Signaling for Multi-access Mobility =A010 Mins > =A0 I-D: draft-koodli-policy-multiaccess-mobility-00.txt > =A0 Presenter: Rajeev Koodli > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From Marco.Liebsch@neclab.eu Wed Mar 9 06:58:34 2011 Return-Path: <Marco.Liebsch@neclab.eu> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF76B3A696D for <netext@core3.amsl.com>; Wed, 9 Mar 2011 06:58:34 -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.044, 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 BJNnQghHxDY0 for <netext@core3.amsl.com>; Wed, 9 Mar 2011 06:58:33 -0800 (PST) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id 37B843A6855 for <netext@ietf.org>; Wed, 9 Mar 2011 06:58:33 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 7D6412800018E for <netext@ietf.org>; Wed, 9 Mar 2011 16:01:05 +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 We0oPdWPN8Ad for <netext@ietf.org>; Wed, 9 Mar 2011 16:01:05 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 5C48E28000189 for <netext@ietf.org>; Wed, 9 Mar 2011 16:01:00 +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; Wed, 9 Mar 2011 15:59:44 +0100 Message-ID: <4D7795DF.7090108@neclab.eu> Date: Wed, 9 Mar 2011 15:59:43 +0100 From: Marco Liebsch <marco.liebsch@neclab.eu> User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: "netext@ietf.org" <netext@ietf.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.6.62] Subject: [netext] Localized Routing PS - AD comment section 3.1 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 09 Mar 2011 14:58:34 -0000 Please find revised text for the following paragraph in section 3.1: /- removed text -/.../+ added text +/ Localized routing is understood in [RFC5213] as optimization of traffic between an MN and a CN that are attached to an access link connected to a same MAG. In such case, the MAG forwards traffic directly between the MN and the CN, assuming the MAG is enabled to support this feature (setting of the EnableMAGLocalRouting flag on the MAG) and the MN's LMA enforces this optimization. [RFC5213] does not specify how an LMA can enforce optimization for such local communication. 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.-/ /+ This document focuses on use cases, where both nodes, the MN and the CN, are within a PMIPv6 network and served by an LMA. +/ Please comment during this week if you do not agree with this revision and propose alternative text in such case. I plan to post version 6 on Monday. marco From Marco.Liebsch@neclab.eu Wed Mar 9 07:23:18 2011 Return-Path: <Marco.Liebsch@neclab.eu> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25A923A6A13 for <netext@core3.amsl.com>; Wed, 9 Mar 2011 07:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 iNqoZNPxfJDR for <netext@core3.amsl.com>; Wed, 9 Mar 2011 07:23:17 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 2A5513A6821 for <netext@ietf.org>; Wed, 9 Mar 2011 07:23:17 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 583C42C000203; Wed, 9 Mar 2011 16:26:06 +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 ZiXrYuHdAHF1; Wed, 9 Mar 2011 16:26:06 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.neclab.eu (Postfix) with ESMTP id 3C6EA2C0001DE; Wed, 9 Mar 2011 16:25:56 +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; Wed, 9 Mar 2011 16:24:23 +0100 Message-ID: <4D779BA7.8040203@neclab.eu> Date: Wed, 9 Mar 2011 16:24:23 +0100 From: Marco Liebsch <marco.liebsch@neclab.eu> User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: "netext@ietf.org" <netext@ietf.org>, Jari Arkko <jari.arkko@piuha.net> References: <4D7795DF.7090108@neclab.eu> In-Reply-To: <4D7795DF.7090108@neclab.eu> Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.6.62] Subject: [netext] Localized Routing PS - AD comment section 3.1 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 09 Mar 2011 15:23:18 -0000 Sorry for re-sending this, I cc:'ed Jari. Marco Liebsch wrote: > Please find revised text for the following paragraph in section 3.1: > > /- removed text -/.../+ added text +/ > > Localized routing is understood in [RFC5213] as optimization of > traffic between an MN and a CN that are attached to an access link > connected to a same MAG. In such case, the MAG forwards traffic > directly between the MN and the CN, assuming the MAG is enabled to > support this feature (setting of the EnableMAGLocalRouting flag on > the MAG) and the MN's LMA enforces this optimization. [RFC5213] does > not specify how an LMA can enforce optimization for such local > communication. 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.-/ > /+ This document focuses on use cases, where both nodes, the MN and the > CN, are within a PMIPv6 network and served by an LMA. +/ > > Please comment during this week if you do not agree with this revision > and propose > alternative text in such case. I plan to post version 6 on Monday. > > marco > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Marco.Liebsch@neclab.eu Wed Mar 9 07:24:58 2011 Return-Path: <Marco.Liebsch@neclab.eu> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B5323A6866 for <netext@core3.amsl.com>; Wed, 9 Mar 2011 07:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 x8wY66ZEeXeQ for <netext@core3.amsl.com>; Wed, 9 Mar 2011 07:24:57 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 21CD93A6821 for <netext@ietf.org>; Wed, 9 Mar 2011 07:24:57 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 528A12C000200 for <netext@ietf.org>; Wed, 9 Mar 2011 16:27:46 +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 PDh8FNyfs+r4 for <netext@ietf.org>; Wed, 9 Mar 2011 16:27:46 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.neclab.eu (Postfix) with ESMTP id 37CA22C0001DE for <netext@ietf.org>; Wed, 9 Mar 2011 16:27:41 +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; Wed, 9 Mar 2011 16:26:08 +0100 Message-ID: <4D779C10.503@neclab.eu> Date: Wed, 9 Mar 2011 16:26:08 +0100 From: Marco Liebsch <marco.liebsch@neclab.eu> User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: "netext@ietf.org" <netext@ietf.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.6.62] Subject: [netext] Localized Routing PS - AD comment on section 4 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 09 Mar 2011 15:24:58 -0000 Please find revised text for the following paragraph in section 4: /+ added text +/ 4. Functional Requirements for Localized Routing Several tasks need to be performed by the network infrastructure components before relevant information for such direct communication is discovered and associated states for localized routing can be set up. The following list summarizes some key functions, which need to be performed by the PMIPv6 enabled network infrastructure to substitute mobile nodes in setting up a direct route. o Detection of the possibility to perform localized routing. This function includes looking at data packets' source and destination address. o Initiation of a procedure, which sets up a localized routing path. o Discovery of stateful entities (i.e. the LMA(s) and/or the MAG(s)), which maintain and can provide relevant information needed to set up a localized routing path. Such information may include the routable address of an LMA or MAG, where one or both mobile nodes are connected to and registered with. o Control in setting up and maintaining (e.g. during handover) the localized routing path. Control is also needed to terminate the use of a localized routing path and to delete associated states, whereas a trigger for the termination may come from a non-PMIPv6 related component. /+ o Enforcement of administrative policy rules to localized routing. Such policies allow operators having further control on the set up of a localized route and enable the possibility to disallow localized routing, for example to ensure that traffic traverses charging related functions on the LMA. +/ Please comment during this week if you do not agree with this revision and propose alternative text in such case. I plan to post version 6 on Monday. marco From Basavaraj.Patil@nokia.com Thu Mar 10 21:08:59 2011 Return-Path: <Basavaraj.Patil@nokia.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1726F3A680D for <netext@core3.amsl.com>; Thu, 10 Mar 2011 21:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.049 X-Spam-Level: X-Spam-Status: No, score=-103.049 tagged_above=-999 required=5 tests=[AWL=0.550, 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 DlC2Rlo5nhiG for <netext@core3.amsl.com>; Thu, 10 Mar 2011 21:08:58 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 5486A3A6823 for <netext@ietf.org>; Thu, 10 Mar 2011 21:08:58 -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 p2B5AAOx011436 for <netext@ietf.org>; Fri, 11 Mar 2011 07:10:15 +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); Fri, 11 Mar 2011 07:10:04 +0200 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 11 Mar 2011 06:10:03 +0100 Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.127]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0270.002; Fri, 11 Mar 2011 06:10:03 +0100 From: <Basavaraj.Patil@nokia.com> To: <netext@ietf.org> Thread-Topic: Charter and milestones.. Thread-Index: AQHL36qTwt6LFJx/oE6mo+nKQVWTxA== Date: Fri, 11 Mar 2011 05:10:02 +0000 Message-ID: <C99F0AC9.11D18%basavaraj.patil@nokia.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: [173.64.197.89] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8328804C5FD3864F9FBD40456F236175@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Mar 2011 05:10:04.0689 (UTC) FILETIME=[94F7C010:01CBDFAA] X-Nokia-AV: Clean Subject: [netext] Charter and milestones.. X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Mar 2011 05:08:59 -0000 Hello, We have the following milestones as part of the Netext charter: " 1. Jul 2010 WG decision on what Proxy Mobile IPv6 mechanisms are needed to support flow mobility and inter-access handovers on a logical interface over multiple physical interfaces 2. Dec 2010 Submit Applicability Statement on Logical Interface over Multiple Physical Interfaces to IESG for publication as Informational RFC " I am considering closing the 1st one since I do believe we have an understanding of what extensions are needed for enabling FM and ITHO using the logical interface. I don=B9t really see a need for the second one. We do not need such an applicability statement IMO. Please express your views regarding the above two milestones. I would like to deprecate these from the charter and update the milestones with dates that reflect the current state of the WG. -Basavaraj From Internet-Drafts@ietf.org Fri Mar 11 10:15:02 2011 Return-Path: <Internet-Drafts@ietf.org> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38B683A6992; Fri, 11 Mar 2011 10:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 Dl+WhaS-dIsv; Fri, 11 Mar 2011 10:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 868FF3A6949; Fri, 11 Mar 2011 10: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: <20110311181501.13620.54538.idtracker@localhost> Date: Fri, 11 Mar 2011 10:15:01 -0800 Cc: netext@ietf.org Subject: [netext] I-D Action:draft-ietf-netext-redirect-06.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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Mar 2011 18: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 : Runtime LMA Assignment Support for Proxy Mobile IPv6 Author(s) : J. Korhonen, et al. Filename : draft-ietf-netext-redirect-06.txt Pages : 19 Date : 2011-03-11 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-06.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-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-11101327.I-D@ietf.org> --NextPart-- From julien.ietf@gmail.com Fri Mar 11 10:39:24 2011 Return-Path: <julien.ietf@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C02163A6C69 for <netext@core3.amsl.com>; Fri, 11 Mar 2011 10:39:24 -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 9ClJZdVoIbXD for <netext@core3.amsl.com>; Fri, 11 Mar 2011 10:39:24 -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 B8B603A6B3B for <netext@ietf.org>; Fri, 11 Mar 2011 10:39:23 -0800 (PST) Received: by fxm15 with SMTP id 15so1393055fxm.31 for <netext@ietf.org>; Fri, 11 Mar 2011 10:40: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=hMIK1umZBlx0yv99JDgdS2Fy8hIdbCOOGoI10p2KBdQ=; b=kC+8lMW9BV40ZmlVAyAHpDNVRO8Ml05acNT1vZTydNfv4Mbyb9ocLqb2UJYlMhZccu JuhBuF31EC2MJwvg5UYlV1ijR2kTD7+ZAS2s9PVcxIZ0u59lcBJ1GpWYcsw/9ztQD+eJ Sed9IX6d5tyjsKoMsJIIPQf9k96Q35qAMWqqo= 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=ZiU8z0DyUsZeSAllmeJ6qlW0fURot352En6M8zRSEhVrY/iWUoKhmNInyozkwwXip1 kuZXLrFcmWkUDV9XM1wvAsGWCf5IFEm5ebb7WqcA7aIVR7tAPnCJuguUIYFMKmMbo46O G4Qi8L5zr+kj7HE5Sa+QoOnn+LSsQzOzgYykQ= MIME-Version: 1.0 Received: by 10.223.99.213 with SMTP id v21mr5387836fan.129.1299868831776; Fri, 11 Mar 2011 10:40:31 -0800 (PST) Received: by 10.223.93.138 with HTTP; Fri, 11 Mar 2011 10:40:31 -0800 (PST) In-Reply-To: <C99F0AC9.11D18%basavaraj.patil@nokia.com> References: <C99F0AC9.11D18%basavaraj.patil@nokia.com> Date: Fri, 11 Mar 2011 10:40:31 -0800 Message-ID: <AANLkTimV-74Y9GANi4LEPfMw-yp+8RLfVFEjCrerQgwd@mail.gmail.com> From: Julien Laganier <julien.ietf@gmail.com> 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] Charter and milestones.. X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Mar 2011 18:39:24 -0000 Hello Raj, Pls. see inline. On Thu, Mar 10, 2011 at 9:10 PM, <Basavaraj.Patil@nokia.com> wrote: > > Hello, > > We have the following milestones as part of the Netext charter: > > " > 1. Jul =A02010 =A0 WG decision on what Proxy Mobile IPv6 mechanisms are n= eeded > to support > =A0 =A0flow mobility and inter-access handovers on a logical interface ov= er > =A0 =A0multiple physical interfaces > > > 2. Dec =A02010 =A0 =A0Submit Applicability Statement on Logical Interface= over > Multiple Physical > =A0 =A0Interfaces to IESG for publication as Informational RFC > > > " > > I am considering closing the 1st one since I do believe we have an > understanding of what extensions are needed for enabling FM and ITHO usin= g > the logical interface. Although most of us do have an understanding on what extensions are required on our own, I believe that fact that the lengthy discussion we've been having on what types of extensions are required (e.g., MAG initiated vs. LMA initiated) did not converge demonstrates that at the WG level we do not have a common understanding. Thus is still work in progress from perspective and the milestone can't be closed. Hopefully we are able to close this after the Prague meeting. > I don=B9t really see a need for the second one. We do not need such an > applicability statement IMO. The second one has been carefully crafted so that the WG does document what are the requirements placed by the concept of logical interface on other parts of the system where the PMIPv6 extension is to be used, e.g., underlying link layers. This hasn't been done so far, so I am opposing removal of this milestone. --julien From Basavaraj.Patil@nokia.com Fri Mar 11 10:54:42 2011 Return-Path: <Basavaraj.Patil@nokia.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A57673A6C6F for <netext@core3.amsl.com>; Fri, 11 Mar 2011 10:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.186 X-Spam-Level: X-Spam-Status: No, score=-102.186 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 GJVZy6fxSnRO for <netext@core3.amsl.com>; Fri, 11 Mar 2011 10:54:41 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id A70823A6B57 for <netext@ietf.org>; Fri, 11 Mar 2011 10:54:41 -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 p2BItuLG023622; Fri, 11 Mar 2011 20:55:56 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Mar 2011 20:55:48 +0200 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 11 Mar 2011 19:55:48 +0100 Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.127]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0270.002; Fri, 11 Mar 2011 19:55:47 +0100 From: <Basavaraj.Patil@nokia.com> To: <julien.ietf@gmail.com> Thread-Topic: [netext] Charter and milestones.. Thread-Index: AQHL36qTwt6LFJx/oE6mo+nKQVWTxJQoZ4CA//+frIA= Date: Fri, 11 Mar 2011 18:55:46 +0000 Message-ID: <C99FCBDF.11DC1%basavaraj.patil@nokia.com> In-Reply-To: <AANLkTimV-74Y9GANi4LEPfMw-yp+8RLfVFEjCrerQgwd@mail.gmail.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: [173.64.197.89] Content-Type: text/plain; charset="euc-kr" Content-ID: <CC2D5C78A98CE8479AF147225D99C296@nokia.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 11 Mar 2011 18:55:48.0696 (UTC) FILETIME=[EF7F4580:01CBE01D] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] Charter and milestones.. X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Mar 2011 18:54:42 -0000 DQpPa2F5LiBMZXRzIGRpc2N1c3MgdGhlc2UgYXQgdGhlIFdHIG1lZXRpbmcgaW4gUHJhZ3VlLiBO byBjaGFuZ2VzIChvdGhlcg0KdGhhbiBkYXRlcykgd2lsbCBiZSByZXF1ZXN0ZWQgZnJvbSBvdXIg QURzLg0KDQotUmFqDQoNCk9uIDMvMTEvMTEgMTI6NDAgUE0sICJleHQgSnVsaWVuIExhZ2FuaWVy IiA8anVsaWVuLmlldGZAZ21haWwuY29tPiB3cm90ZToNCg0KPkhlbGxvIFJhaiwNCj4NCj5QbHMu IHNlZSBpbmxpbmUuDQo+DQo+T24gVGh1LCBNYXIgMTAsIDIwMTEgYXQgOToxMCBQTSwgIDxCYXNh dmFyYWouUGF0aWxAbm9raWEuY29tPiB3cm90ZToNCj4+DQo+PiBIZWxsbywNCj4+DQo+PiBXZSBo YXZlIHRoZSBmb2xsb3dpbmcgbWlsZXN0b25lcyBhcyBwYXJ0IG9mIHRoZSBOZXRleHQgY2hhcnRl cjoNCj4+DQo+PiAiDQo+PiAxLiBKdWwgIDIwMTAgICBXRyBkZWNpc2lvbiBvbiB3aGF0IFByb3h5 IE1vYmlsZSBJUHY2IG1lY2hhbmlzbXMgYXJlDQo+Pm5lZWRlZA0KPj4gdG8gc3VwcG9ydA0KPj4g ICAgZmxvdyBtb2JpbGl0eSBhbmQgaW50ZXItYWNjZXNzIGhhbmRvdmVycyBvbiBhIGxvZ2ljYWwg aW50ZXJmYWNlIG92ZXINCj4+ICAgIG11bHRpcGxlIHBoeXNpY2FsIGludGVyZmFjZXMNCj4+DQo+ Pg0KPj4gMi4gRGVjICAyMDEwICAgIFN1Ym1pdCBBcHBsaWNhYmlsaXR5IFN0YXRlbWVudCBvbiBM b2dpY2FsIEludGVyZmFjZSBvdmVyDQo+PiBNdWx0aXBsZSBQaHlzaWNhbA0KPj4gICAgSW50ZXJm YWNlcyB0byBJRVNHIGZvciBwdWJsaWNhdGlvbiBhcyBJbmZvcm1hdGlvbmFsIFJGQw0KPj4NCj4+ DQo+PiAiDQo+Pg0KPj4gSSBhbSBjb25zaWRlcmluZyBjbG9zaW5nIHRoZSAxc3Qgb25lIHNpbmNl IEkgZG8gYmVsaWV2ZSB3ZSBoYXZlIGFuDQo+PiB1bmRlcnN0YW5kaW5nIG9mIHdoYXQgZXh0ZW5z aW9ucyBhcmUgbmVlZGVkIGZvciBlbmFibGluZyBGTSBhbmQgSVRITw0KPj51c2luZw0KPj4gdGhl IGxvZ2ljYWwgaW50ZXJmYWNlLg0KPg0KPkFsdGhvdWdoIG1vc3Qgb2YgdXMgZG8gaGF2ZSBhbiB1 bmRlcnN0YW5kaW5nIG9uIHdoYXQgZXh0ZW5zaW9ucyBhcmUNCj5yZXF1aXJlZCBvbiBvdXIgb3du LCBJIGJlbGlldmUgdGhhdCBmYWN0IHRoYXQgdGhlIGxlbmd0aHkgZGlzY3Vzc2lvbg0KPndlJ3Zl IGJlZW4gaGF2aW5nIG9uIHdoYXQgdHlwZXMgb2YgZXh0ZW5zaW9ucyBhcmUgcmVxdWlyZWQgKGUu Zy4sIE1BRw0KPmluaXRpYXRlZCB2cy4gTE1BIGluaXRpYXRlZCkgZGlkIG5vdCBjb252ZXJnZSBk ZW1vbnN0cmF0ZXMgdGhhdCBhdCB0aGUNCj5XRyBsZXZlbCB3ZSBkbyBub3QgaGF2ZSBhIGNvbW1v biB1bmRlcnN0YW5kaW5nLg0KPg0KPlRodXMgaXMgc3RpbGwgd29yayBpbiBwcm9ncmVzcyBmcm9t IHBlcnNwZWN0aXZlIGFuZCB0aGUgbWlsZXN0b25lDQo+Y2FuJ3QgYmUgY2xvc2VkLiBIb3BlZnVs bHkgd2UgYXJlIGFibGUgdG8gY2xvc2UgdGhpcyBhZnRlciB0aGUgUHJhZ3VlDQo+bWVldGluZy4N Cj4NCj4+IEkgZG9uqfZ0IHJlYWxseSBzZWUgYSBuZWVkIGZvciB0aGUgc2Vjb25kIG9uZS4gV2Ug ZG8gbm90IG5lZWQgc3VjaCBhbg0KPj4gYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgSU1PLg0KPg0K PlRoZSBzZWNvbmQgb25lIGhhcyBiZWVuIGNhcmVmdWxseSBjcmFmdGVkIHNvIHRoYXQgdGhlIFdH IGRvZXMgZG9jdW1lbnQNCj53aGF0IGFyZSB0aGUgcmVxdWlyZW1lbnRzIHBsYWNlZCBieSB0aGUg Y29uY2VwdCBvZiBsb2dpY2FsIGludGVyZmFjZQ0KPm9uIG90aGVyIHBhcnRzIG9mIHRoZSBzeXN0 ZW0gd2hlcmUgdGhlIFBNSVB2NiBleHRlbnNpb24gaXMgdG8gYmUgdXNlZCwNCj5lLmcuLCB1bmRl cmx5aW5nICBsaW5rIGxheWVycy4gVGhpcyBoYXNuJ3QgYmVlbiBkb25lIHNvIGZhciwgc28gSSBh bQ0KPm9wcG9zaW5nIHJlbW92YWwgb2YgdGhpcyBtaWxlc3RvbmUuDQo+DQo+LS1qdWxpZW4NCg0K From Internet-Drafts@ietf.org Fri Mar 11 11:00:03 2011 Return-Path: <Internet-Drafts@ietf.org> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44AA53A6C6F; Fri, 11 Mar 2011 11:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 R+Y4pyZF+MQN; Fri, 11 Mar 2011 11:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 848193A68F5; Fri, 11 Mar 2011 11: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: <20110311190002.28168.80017.idtracker@localhost> Date: Fri, 11 Mar 2011 11:00:02 -0800 Cc: netext@ietf.org Subject: [netext] I-D Action:draft-ietf-netext-redirect-07.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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Mar 2011 19: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-07.txt Pages : 19 Date : 2011-03-11 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-07.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-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-11104533.I-D@ietf.org> --NextPart-- From rkoodli@cisco.com Fri Mar 11 14:04:50 2011 Return-Path: <rkoodli@cisco.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE59C3A6943; Fri, 11 Mar 2011 14:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.403 X-Spam-Level: X-Spam-Status: No, score=-109.403 tagged_above=-999 required=5 tests=[AWL=-0.201, 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 8VyJmy5fE2vm; Fri, 11 Mar 2011 14:04: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 112EA3A6814; Fri, 11 Mar 2011 14:04:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rkoodli@cisco.com; l=18057; q=dns/txt; s=iport; t=1299881161; x=1301090761; h=date:subject:from:to:cc:message-id:mime-version; bh=RTgadLulpdbmtorP7tpPdRpe5ouZ61QE+rjfLsUzJkY=; b=ai09mNU3+muYbv9WY+sTSTIj+KstkkKKTeSGem9ZLQJ6Ztv5H63zYSOo y7fU1rIIpbeEseISAIUupHUU5dOuNl9whz4UecmeLnB/+79v9S6SOVli7 dzsQSBgUTYKW7AUb5WyxSZPifdEh7wJ5vxaExMbDjoNK+5N9Uq9oBYIce A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAN0rek2tJV2Z/2dsb2JhbACCW5ZOhgkBhipZd6ZHnBqFYgSBdIM1hyaDUA X-IronPort-AV: E=Sophos;i="4.62,305,1297036800"; d="scan'208,217";a="344836658" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-5.cisco.com with ESMTP; 11 Mar 2011 22:06:00 +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 p2BM5xgk027999; Fri, 11 Mar 2011 22:05:59 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); Fri, 11 Mar 2011 16:05:59 -0600 Received: from 10.21.87.41 ([10.21.87.41]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Fri, 11 Mar 2011 22:05:59 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Fri, 11 Mar 2011 14:07:18 -0800 From: Rajeev Koodli <rkoodli@cisco.com> To: The IESG <iesg-secretary@ietf.org>, Jari Arkko <jari.arkko@piuha.net> Message-ID: <C99FDD16.E5DA%rkoodli@cisco.com> Thread-Topic: Request to progress Netext WG ID: draft-ietf-netext-redirect-07.txt Thread-Index: AcvgOK+nadoyLM9S70mAxgFYu0QHKw== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3382697238_17618785" X-OriginalArrivalTime: 11 Mar 2011 22:05:59.0785 (UTC) FILETIME=[81094590:01CBE038] Cc: "netext@ietf.org" <netext@ietf.org> Subject: [netext] Request to progress Netext WG ID: draft-ietf-netext-redirect-07.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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Mar 2011 22:04:50 -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_3382697238_17618785 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable The Netext WG I-D mentioned below is ready for IESG review and approval. Please find below the document shepherd writeup. I-D: Runtime LMA Assignment Support for Proxy Mobile IPv6 <draft-ietf-netext-redirect-07.txt> -Rajeev (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: Rajeev Koodli Yes, I have reviewed this version of the document and I 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. (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? I do not have concerns, but the document can benefit from a security review= , especially of one of the features =B3Runtime Redirection with Binding Creation=B2. (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 document has been presented and discussed adequately in previous WG meetings and on the mailing list. I am aware of an IPR disclosures related to this I-D: =B3Huawei Technologies Cp. Ltd=B9s Statement about IPR related to draft-ietf-netext-redirect-03=B2, dated September 18, 2010. URL:=20 http://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id_document_= t ag=3D19240 =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 strong concurrence among active participants on the subject. I believe the majority of the WG understands the ID and do not object. (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. The normative references are published RFCs. (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? Yes, I have verified the IANA Considerations Section. The documents require= s IANA allocations for two new Mobility Options and two new Status Codes. The respective registries are identified. (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 (LMA), while connected to a Mobility Anchor Gateway (MAG). There may be some deployments in which the LMA may wish to redirect a MAG t= o an alternate LMA for session establishment. For such deployments, this document specifies a new protocol between the MAG and the LMA to assist wit= h runtime LMA assignment (as opposed to LMA selection via DNS or AAA). In a deployment where the MAG does not support the necessary extensions, the behavior defaults to that specified in RFC 5213. There is support in the WG to advance this work. There has not been any major controversy.=20 No known public implementations. --B_3382697238_17618785 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable <HTML> <HEAD> <TITLE>Request to progress Netext WG ID: draft-ietf-netext-redirect-07.txt<= /TITLE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt= '><BR> </SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Consolas, Courier New, Courier"><S= PAN STYLE=3D'font-size:10pt'><BR> The Netext WG I-D mentioned below is ready for IESG review and approval. <B= R> Please find below the document shepherd writeup.<BR> <BR> I-D: Runtime LMA Assignment Support for Proxy Mobile IPv6<BR>      <draft-ietf-netext-redirect-07.txt><BR> <BR> -Rajeev<BR> <BR> <BR>   (1.a) Who is the Document Shepherd for this document? Has the<B= R>         Document Shepherd personall= y reviewed this version of the<BR>         document and, in particular= , does he or she believe this<BR>         version is ready for forwar= ding to the IESG for publication?<BR> <BR> Document shepherd: Rajeev Koodli<BR> Yes, I have reviewed this version of the document and I believe it is<BR> ready for IESG review and publication.<BR> <BR>   (1.b) Has the document had adequate review both from key WG mem= bers<BR>         and from key non-WG members= ? Does the Document Shepherd have<BR>         any concerns about the dept= h or breadth of the reviews that<BR>         have been performed?<BR> <BR> The document has had adequate reviews by key WG members.<BR> I do not have any concerns regarding the depth or breadth of the<BR> reviews.<BR> <BR>   (1.c) Does the Document Shepherd have concerns that the documen= t<BR>         needs more review from a pa= rticular or broader perspective,<BR>         e.g., security, operational= complexity, someone familiar with<BR>         AAA, internationalization o= r XML?<BR> <BR> I do not have concerns, but the document can benefit from a security review= , especially of one of the features “Runtime Redirection with Binding = Creation”.<BR> <BR> <BR>   (1.d) Does the Document Shepherd have any specific concerns or<= BR>         issues with this document t= hat the Responsible Area Director<BR>         and/or the IESG should be a= ware of? For example, perhaps he<BR>         or she is uncomfortable wit= h certain parts of the document, or<BR>         has concerns whether there = really is a need for it. In any<BR>         event, if the WG has discus= sed those issues and has indicated<BR>         that it still wishes to adv= ance the document, detail those<BR>         concerns here. Has an IPR d= isclosure related to this document<BR>         been filed? If so, please i= nclude a reference to the<BR>         disclosure and summarize th= e WG discussion and conclusion on<BR>         this issue.<BR> <BR> I do not have any specific concerns at this time regarding this<BR> document. The document has been presented and discussed adequately in previ= ous WG meetings and on the mailing list. <BR> <BR> I am aware of an IPR disclosures related to this I-D: “Huawei Technol= ogies Cp. Ltd’s Statement about IPR related to draft-ietf-netext-redir= ect-03”, dated September 18, 2010.<BR> URL: <a href=3D"http://datatracker.ietf.org/ipr/search/?option=3Ddocument_searc= h&id_document_tag=3D19240">http://datatracker.ietf.org/ipr/search/?option=3D= document_search&id_document_tag=3D19240</a><BR> <BR>  <BR> <BR>   (1.e) How solid is the WG consensus behind this document? Does = it<BR>         represent the strong concur= rence of a few individuals, with<BR>         others being silent, or doe= s the WG as a whole understand and<BR>         agree with it?<BR> <BR> There is strong concurrence among active participants on the subject. I bel= ieve the majority of the WG understands the ID and do not object.<BR> <BR> <BR>   (1.f) Has anyone threatened an appeal or otherwise indicated ex= treme<BR>         discontent? If so, please s= ummarise the areas of conflict in<BR>         separate email messages to = the Responsible Area Director. (It<BR>         should be in a separate ema= il because this questionnaire is<BR>         entered into the ID Tracker= .)<BR> <BR> No threats of appeal or extreme discontent have been expressed<BR> regarding this I-D.<BR> <BR> <BR>   (1.g) Has the Document Shepherd personally verified that the<BR= >         document satisfies all ID n= its? (See the Internet-Drafts Checklist<BR>         and <FONT COLOR=3D"#0000FF"><= U><a href=3D"http://tools.ietf.org/tools/idnits/">http://tools.ietf.org/tools/= idnits/</a></U></FONT>). Boilerplate checks are<BR>         not enough; this check need= s to be thorough. Has the document<BR>         met all formal review crite= ria it needs to, such as the MIB<BR>         Doctor, media type and URI = type reviews?<BR> <BR> Yes. I have run the I-D through the ID nits tool and found no issues.<BR> <BR>   (1.h) Has the document split its references into normative and<= BR>         informative? Are there norm= ative references to documents that<BR>         are not ready for advanceme= nt or are otherwise in an unclear<BR>         state? If such normative re= ferences exist, what is the<BR>         strategy for their completi= on? Are there normative references<BR>         that are downward reference= s, as described in [RFC3967]? If<BR>         so, list these downward ref= erences to support the Area<BR>         Director in the Last Call p= rocedure for them [RFC3967].<BR> <BR> References are split into normative and informative sections.<BR> The normative references are published RFCs.<BR> <BR>   (1.i) Has the Document Shepherd verified that the document IANA= <BR>         consideration section exist= s and is consistent with the body<BR>         of the document? If the doc= ument specifies protocol<BR>         extensions, are reservation= s requested in appropriate IANA<BR>         registries? Are the IANA re= gistries clearly identified? If<BR>         the document creates a new = registry, does it define the<BR>         proposed initial contents o= f the registry and an allocation<BR>         procedure for future regist= rations? Does it suggest a<BR>         reasonable name for the new= registry? See [RFC5226]. If the<BR>         document describes an Exper= t Review process has Shepherd<BR>         conferred with the Responsi= ble Area Director so that the IESG<BR>         can appoint the needed Expe= rt during the IESG Evaluation?<BR> <BR> Yes, I have verified the IANA Considerations Section. The documents require= s IANA allocations for two new Mobility Options and two new Status Codes. Th= e respective registries are identified.<BR> <BR> <BR>   (1.j) Has the Document Shepherd verified that sections of the<B= R>         document that are written i= n a formal language, such as XML<BR>         code, BNF rules, MIB defini= tions, etc., validate correctly in<BR>         an automated checker?<BR> <BR> Not applicable.<BR> <BR> <BR>   (1.k) The IESG approval announcement includes a Document<BR>         Announcement Write-Up. Plea= se provide such a Document<BR>         Announcement Write-Up? Rece= nt examples can be found in the<BR>         "Action" announce= ments for approved documents. The approval<BR>         announcement contains the f= ollowing sections:<BR> <BR> Proxy Mobile IPv6 is the IETF standard for network-based mobility<BR> management.  In Proxy Mobile IPv6, mobile nodes are topologically<BR> anchored at a Local Mobility Anchor (LMA), while connected to a Mobility An= chor Gateway (MAG).<BR> There may be some deployments in which the LMA may wish to redirect a MAG t= o an alternate LMA for session establishment. For such deployments, this doc= ument specifies a new protocol between the MAG and the LMA to assist with ru= ntime LMA assignment (as opposed to LMA selection via DNS or AAA). In a depl= oyment where the MAG does not support the necessary extensions, the behavior= defaults to that specified in RFC 5213. <BR> <BR> There is support in the WG to advance this work. There has not been any maj= or controversy. <BR> No known public implementations.  </SPAN></FONT></FONT> </BODY> </HTML> --B_3382697238_17618785-- From Internet-Drafts@ietf.org Mon Mar 14 11:15:02 2011 Return-Path: <Internet-Drafts@ietf.org> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6FDA3A6E4D; Mon, 14 Mar 2011 11:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 Um24ddatibih; Mon, 14 Mar 2011 11:15:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41DFD3A6A31; Mon, 14 Mar 2011 11:15:02 -0700 (PDT) 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: <20110314181502.31818.93593.idtracker@localhost> Date: Mon, 14 Mar 2011 11:15:02 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action:draft-ietf-netext-radius-pmip6-02.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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Mar 2011 18:15: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 : RADIUS Support for Proxy Mobile IPv6 Author(s) : F. Xia, et al. Filename : draft-ietf-netext-radius-pmip6-02.txt Pages : 34 Date : 2011-03-14 This document defines new attributes to facilitate Proxy Mobile IPv6 operations using the RADIUS infrastructure. The RADIUS interactions between the Mobile Access Gateway and the AAA RADIUS server take place when the Mobile Node attaches, authenticates and authorizes to a Proxy Mobile IPv6 domain. Furthermore, this document defines the RADIUS-based interface between the Local Mobility Anchor and the AAA RADIUS server for authorizing received Proxy Binding Update messages for the MN's mobility session. In addition to the mobility session setup related interactions, this document defines the baseline for the Mobile Access Gateway and the Local Mobility Anchor generated accounting. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-radius-pmip6-02.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-radius-pmip6-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14110248.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Mon Mar 14 14:45:15 2011 Return-Path: <Internet-Drafts@ietf.org> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36FA93A6F8D; Mon, 14 Mar 2011 14:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 d+hYxwgFwOVm; Mon, 14 Mar 2011 14:45:13 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 906383A6F9D; Mon, 14 Mar 2011 14:45:09 -0700 (PDT) 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: <20110314214509.28151.58855.idtracker@localhost> Date: Mon, 14 Mar 2011 14:45:09 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action:draft-ietf-netext-logical-interface-support-02.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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Mar 2011 21:45:15 -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 : Logical Interface Support for multi-mode IP Hosts Author(s) : T. Melia, S. Gundavelli Filename : draft-ietf-netext-logical-interface-support-02.txt Pages : 26 Date : 2011-03-14 A Logical Interface is a software semantic internal to the host operating system. This semantic is available in all popular operating systems and is used in various protocol implementations. The Logical Interface support is required on the mobile node operating in a Proxy Mobile IPv6 domain, for leveraging various network-based mobility management features such as inter-technology handoffs, multihoming and flow mobility support. This document explains the operational details of Logical Interface construct and the specifics on how the link-layer implementations hide the physical interfaces from the IP stack and from the network nodes on the attached access networks. Furthermore, this document identifies the applicability of this approach to various link-layer technologies and analyzes the issues around it when used in context with various mobility management features. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-logical-interface-support-02.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-logical-interface-support-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14144024.I-D@ietf.org> --NextPart-- From sgundave@cisco.com Mon Mar 14 15:11:48 2011 Return-Path: <sgundave@cisco.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5E243A6BC2 for <netext@core3.amsl.com>; Mon, 14 Mar 2011 15:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.108 X-Spam-Level: X-Spam-Status: No, score=-10.108 tagged_above=-999 required=5 tests=[AWL=0.491, 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 mbrtVTIyUb1h for <netext@core3.amsl.com>; Mon, 14 Mar 2011 15:11:45 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 82BEF3A6978 for <netext@ietf.org>; Mon, 14 Mar 2011 15:11:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=2769; q=dns/txt; s=iport; t=1300140788; x=1301350388; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=J7rSrxWHWzvfiravVHVvxNknLroQjiCuH8A67RlkD2g=; b=OaQYddd5Qc8WqjeP4NrNf4egeSKl/T7ZG2JgEnQn6nsEhVjnxV6JuCpm il3JErdHKMsbVG1ZPbQNOpPLeyFoTgKNYrpVZV39mbMo4y/3qdBoJzpSI 9Jnj9iQh2YYIPw/GJwrhodRklH05Jru9BJ26BQhpYIueHRniKYANjJuE0 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcGAI4vfk2tJV2d/2dsb2JhbACZBo0Hd6R2nDiFYgSFK4cng1Q X-IronPort-AV: E=Sophos;i="4.62,318,1297036800"; d="scan'208";a="225185654" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-1.cisco.com with ESMTP; 14 Mar 2011 22:13:08 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2EMBqOe014864 for <netext@ietf.org>; Mon, 14 Mar 2011 22:13:08 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); Mon, 14 Mar 2011 15:12:18 -0700 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 ; Mon, 14 Mar 2011 22:12:16 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Mon, 14 Mar 2011 15:13:58 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: <netext@ietf.org> Message-ID: <C9A3E136.135A2%sgundave@cisco.com> Thread-Topic: [netext] #6: Logical interface: MTU issues Thread-Index: AcvilR1Q2mmJwjE73kOGbvmIYrILsw== In-Reply-To: <066.f305ff5de33bd8d607b12a7ab7d8e54b@trac.tools.ietf.org> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 14 Mar 2011 22:12:18.0585 (UTC) FILETIME=[E20ED090:01CBE294] Subject: Re: [netext] #6: Logical interface: MTU issues X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Mar 2011 22:11:48 -0000 > #6: Logical interface: MTU issues Question about the logical interface MTU: > -> what is the logical interface MTU? -> How do handoffs between two > underlying interfaces with dissimilar MTU impacts PMTUD, and transport > protocols --=20 Folks: The authors of this document have discussed this and resolve it with the following text. Please comment, if you see any open issues. This should handle all the cases. 6.2. MTU considerations The link MTU (maximum transmission unit) value configured on a logical interface should be the lowest of the MTU values supported across any of the physical interfaces that are part of that logical interface construct. The MTU value should be configured as part of the logical interface creation on the host. Furthermore, this value must be updated any time there is a change to the logical interface construct, such as when interfaces are added or deleted from the logical interface setup. Any time there is an inter-technology handover between two access technologies, the applications on the host bound to the IP address configuration on the logical interface will not detect the change and will continue to use the MTU value of the logical interface for the outbound packets, which is never greater than the MTU value on that supported access network. However, the access network may continue to deliver the packets conforming to the MTU value supported on that access technology and the logical interface should be able to receive those packets from the physical interface attached to that network. Regards Sri On 3/3/11 3:02 PM, "netext issue tracker" <trac+netext@trac.tools.ietf.org> wrote: > #6: Logical interface: MTU issues Question about the logical interface MTU: > -> what is the logical interface MTU? -> How do handoffs between two > underlying interfaces with dissimilar MTU impacts PMTUD, and transport > protocols --=20 > ---------------------------------------+-----------------------------------= - > Reporter: basavaraj.patil@=8A | Owner: telemaco.melia@=8A > Type: defect | Status: new > Priority: major | Milestone: > Component: logical-interface-support | Version: > Severity: Active WG Document | Keywords: > ---------------------------------------+-----------------------------------= - > Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/6> netext > <http://tools.ietf.org/netext/> _____________________________________________ > __ netext mailing > list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From sgundave@cisco.com Mon Mar 14 15:14:35 2011 Return-Path: <sgundave@cisco.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C8B73A6B24 for <netext@core3.amsl.com>; Mon, 14 Mar 2011 15:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.129 X-Spam-Level: X-Spam-Status: No, score=-10.129 tagged_above=-999 required=5 tests=[AWL=0.470, 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 XwOwl+yr5USH for <netext@core3.amsl.com>; Mon, 14 Mar 2011 15:14:34 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 93E0A3A6978 for <netext@ietf.org>; Mon, 14 Mar 2011 15:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=2746; q=dns/txt; s=iport; t=1300140959; x=1301350559; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=cNIJpQnhHT5rEOhaUlWxWTg0ztfaW4CfpuYLwog+MiY=; b=eUPQ8Q0WUfGl2M3D4IHGz0rBQMG9A9QzI6m2UBHjG6GN65FPS9VGqZ9T 5amOqZJlr6aDhzQqpwVX7ZP5Ylmehg6BVhjYykasdSwg6KlUK1h7UCt5S AFZ+wla4HKa1Q3MNpNenL5Z4P0WWJQfz12akeId0NowW99M7Bc2J3XzA7 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkINAAcwfk2tJXG8/2dsb2JhbACZBoYxhlZ3pHacOYViBIUrhyeDVA X-IronPort-AV: E=Sophos;i="4.62,319,1297036800"; d="scan'208";a="277900279" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-3.cisco.com with ESMTP; 14 Mar 2011 22:15:58 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2EMFwum025022; Mon, 14 Mar 2011 22:15:58 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, 14 Mar 2011 15:15:57 -0700 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 ; Mon, 14 Mar 2011 22:15:56 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Mon, 14 Mar 2011 15:17:42 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: <netext@ietf.org> Message-ID: <C9A3E216.135A6%sgundave@cisco.com> Thread-Topic: [netext] #1: Behavior of ND Thread-Index: AcvilaLUZBtBd0KjkkiHnmqKMBVjiw== In-Reply-To: <066.e9f936f62456f0a0d9c6a916f3c93be2@trac.tools.ietf.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 14 Mar 2011 22:15:57.0808 (UTC) FILETIME=[64B99700:01CBE295] Cc: draft-ietf-netext-logical-interface-support@tools.ietf.org Subject: Re: [netext] #1: Behavior of ND X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Mar 2011 22:14:35 -0000 > #1: Behavior of ND > Folks: The authors of this document have discussed this and resolve it with the following text. Please comment, if you see any open issues. This captures the ND interactions around logical interface, for various message types. Might be missing one or two other details, we can capture them. 6.5. ND Considerations for Logical Interface The following are the Neighbor Discovery related considerations for the logical interface. o Any Neighbor Discovery messages, such as Router Solicitation, Neighbor Solicitation messages that the host sends to a multicast destination address of link-local scope such as, all-nodes, all- routers, solicited-node multicast group addresses, using either an unspecified (::) source address, or a link-local address configured on the logical interface will be replicated and forwarded on each of the sub-interfaces under that logical interface. However, if the destination address is a unicast address and if that target is known to exist on a specific sub- interface, the message will be forwarded only on that specific sub-interface. o Any Neighbor Discovery messages, such as Router Advertisement, that the host receives from any of its sub-interfaces, will be associated with the logical interface, i.e., in some implementations the message will appear on the input interface of the logical interface. o When using Stateless Address Autoconfiguraion [RFC4862] for generating IPv6 address configuration on the logical interface, the host may use any of the IPv6 prefixes receieved from the Router Advertisement messages that it received from any of its sub-interfaces. Melia & Gundavelli Expires September 15, 2011 [Page 15] Internet-Draft Logical Interface Support March 2011 o The response to a Neighbor Discovery message received for a unicast, link-specific multicast group address, will be sent on the same sub-interface path where the packet was received. o When using DHCPv4 for obtaining address configuration for the logical interface, the value in the chaddr field in the DHCP messages will be based on the link-layer identfier scheme chosen by the logical interface. . On 3/2/11 2:05 PM, "netext issue tracker" <trac+netext@trac.tools.ietf.org> wrote: > #1: Behavior of ND > > At IETF79 there was a concern identified that the I-D did not clearly > explain the behavior of ND in the case of the logical interface on a host. > Please propose text that addresses this concern. From Internet-Drafts@ietf.org Mon Mar 14 15:15:07 2011 Return-Path: <Internet-Drafts@ietf.org> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 597823A6F7B; Mon, 14 Mar 2011 15:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 Gd31IfKmrvO8; Mon, 14 Mar 2011 15:15:06 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BC6C3A6E80; Mon, 14 Mar 2011 15:15:03 -0700 (PDT) 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: <20110314221503.9641.63216.idtracker@localhost> Date: Mon, 14 Mar 2011 15:15:03 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action:draft-ietf-netext-pmip6-lr-ps-06.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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Mar 2011 22:15:07 -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-06.txt Pages : 19 Date : 2011-03-14 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-06.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-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14151450.I-D@ietf.org> --NextPart-- From sgundave@cisco.com Mon Mar 14 15:22:03 2011 Return-Path: <sgundave@cisco.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76FA53A6D74 for <netext@core3.amsl.com>; Mon, 14 Mar 2011 15:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=0.450, 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 aXIoleZrC0cl for <netext@core3.amsl.com>; Mon, 14 Mar 2011 15:22:01 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id A23A63A6978 for <netext@ietf.org>; Mon, 14 Mar 2011 15:21:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=2950; q=dns/txt; s=iport; t=1300141394; x=1301350994; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=ejz/uQh6lWqrlq0ag2WzRyFKxRyiPczX5W8fdW+Zr58=; b=UOmz3oQFSCyQe4tvnfLZZLCd7KalheWpAraQ80kYQyL8ge/qiJhvfhj1 2qKT3EF8tSNJW4wYg68zcohn/ckBDx7QdvImAIlf3u+okZM4kdOnX2IIB GZWE/hPas+uZE5SdrlLXlxBBgZ0lSutBx1NlbP8zzB5jKm5A9JksZ/jb9 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcGAF8yfk2tJV2a/2dsb2JhbACZBo0Hd6RtnDiFYgSFK4cng1Q X-IronPort-AV: E=Sophos;i="4.62,319,1297036800"; d="scan'208";a="225576672" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 14 Mar 2011 22:23:13 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2EMN7kJ002589 for <netext@ietf.org>; Mon, 14 Mar 2011 22:23:13 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, 14 Mar 2011 15:22:41 -0700 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 ; Mon, 14 Mar 2011 22:22:40 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Mon, 14 Mar 2011 15:24:29 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: <netext@ietf.org> Message-ID: <C9A3E3AD.135AF%sgundave@cisco.com> Thread-Topic: [netext] #4: Logical interface support: Point to point links Thread-Index: AcvilpVrmDU4NCZvYkyaf3ogiAFeBA== In-Reply-To: <066.44c02c04592a11d868774e78f7db352d@trac.tools.ietf.org> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 14 Mar 2011 22:22:41.0243 (UTC) FILETIME=[5530E2B0:01CBE296] Subject: Re: [netext] #4: Logical interface support: Point to point links X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Mar 2011 22:22:03 -0000 > #4: Logical interface support: Point to point links Clarify the use and > behavior of the logical interface on PtP links. Folks: Again, reflecting the team's contributions on this topic, the author= s of this document have discussed this and resolve it with the following text= . The key points we tried to reflect are around that the logical interface appears to the application as a shared link. There were thoughts around making it appear like a p2p link, given that there are multiple neighbors o= n each sub interface, this choice appears reasonable. With respect to how a packet is transmitted, is still based on the chosen link model at each sub interface level. Let us know, if you see any issues with it. This is proven based on the multiple implementations from some of the co-authors of this doc. --- 6.3. Supported Link models for a logical interface The sub-interfaces of a logical interface can be bound to a point-to- point or a shared link (Example: LTE and WLAN). The logical interface appears as a shared-link to the applications, and adapts to the link model of the sub-interface for packet communication. For example, when transmitting a packet on a sub-interface which is attached to a p2p link, the transmission conforms to the p2p link model and when transmitting on a sub-interface attached to a shared link, the transmission conforms to the shared link model. Based on the link to which the sub-interface is attached to, the layer-2 resolutions may or may not be needed. If the interface is bound to a P2P link with PPP running, there will not be any link- layer resolutions in the form of ARP/ND messages. However, if the interface is bound to a shared link such as Ethernet, there will be ND resolutions. The logical interface implementation has to maintain the required link model and the associated state for each sub- interface. -- On 3/3/11 9:17 AM, "netext issue tracker" <trac+netext@trac.tools.ietf.org> wrote: > #4: Logical interface support: Point to point links Clarify the use and > behavior of the logical interface on PtP links. -- > ---------------------------------------+-----------------------------------= - > Reporter: basavaraj.patil@=8A | Owner: telemaco.melia@=8A > Type: defect | Status: new > Priority: major | Milestone: > Component: logical-interface-support | Version: > Severity: - | Keywords: > ---------------------------------------+-----------------------------------= - > Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/4> netext > <http://tools.ietf.org/netext/> _____________________________________________ > __ netext mailing > list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From sgundave@cisco.com Mon Mar 14 15:24:44 2011 Return-Path: <sgundave@cisco.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 456333A6978 for <netext@core3.amsl.com>; Mon, 14 Mar 2011 15:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.167 X-Spam-Level: X-Spam-Status: No, score=-10.167 tagged_above=-999 required=5 tests=[AWL=0.432, 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 9RK+XWlw8l7D for <netext@core3.amsl.com>; Mon, 14 Mar 2011 15:24:43 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2FCA53A6944 for <netext@ietf.org>; Mon, 14 Mar 2011 15:24:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=1552; q=dns/txt; s=iport; t=1300141567; x=1301351167; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=cO9ahDCT601D5/Z0kBCQz1LZJmqoWmHXXOpS/GjzKhQ=; b=dmPWEzMHxY/fXUg0QQfODB7Xed8I4G4M8LSAy0kRFimPka3KZs5CXr6z BnE2ONPNJr75F8ytZlb4rE7ukBLHodoEcTIib6rxnTZqsNNXXwvN/8y+T IVMvipsPlNUw95e6blhmw9pF5EC0rkaGIEHh39iz0jbX/AKiOhU+PtAD0 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcGAF8yfk2tJV2d/2dsb2JhbACZBo0Hd6RtnDiFYgSFK4cng1Q X-IronPort-AV: E=Sophos;i="4.62,319,1297036800"; d="scan'208";a="225577109" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-2.cisco.com with ESMTP; 14 Mar 2011 22:26:06 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2EMQ6xo023003 for <netext@ietf.org>; Mon, 14 Mar 2011 22:26:06 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); Mon, 14 Mar 2011 15:26:06 -0700 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 ; Mon, 14 Mar 2011 22:26:05 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Mon, 14 Mar 2011 15:27:53 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: <netext@ietf.org> Message-ID: <C9A3E479.135B3%sgundave@cisco.com> Thread-Topic: [netext] #5: Logical interface support: Multicast traffic Thread-Index: Acvilw8Du9peX2QLA0qqr8d/IZW4NQ== In-Reply-To: <066.d15938dc10856d20b122b59428c9c5bc@trac.tools.ietf.org> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 14 Mar 2011 22:26:06.0379 (UTC) FILETIME=[CF7627B0:01CBE296] Subject: Re: [netext] #5: Logical interface support: Multicast traffic X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Mar 2011 22:24:44 -0000 > #5: Logical interface support: Multicast traffic Clarify how the logical > interface deals with multicast traffic. We believe we have resolve this issue, this is captured in the ND interactions section. The general considerations around dealing with link-specific multicast traffic, all-nodes, solicited node multicast traffic, or others have common considerations. It is possible we might be missing few cases, we can add that in, but the base handling of things at the logical interface level, or sub-interface level is captured. Comments welcome. Sri On 3/3/11 9:19 AM, "netext issue tracker" <trac+netext@trac.tools.ietf.org> wrote: > #5: Logical interface support: Multicast traffic Clarify how the logical > interface deals with multicast traffic. -- > ---------------------------------------+-----------------------------------= - > Reporter: basavaraj.patil@=8A | Owner: telemaco.melia@=8A > Type: defect | Status: new > Priority: critical | Milestone: > Component: logical-interface-support | Version: > Severity: - | Keywords: > ---------------------------------------+-----------------------------------= - > Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/5> netext > <http://tools.ietf.org/netext/> _____________________________________________ > __ netext mailing > list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From sgundave@cisco.com Mon Mar 14 15:32:28 2011 Return-Path: <sgundave@cisco.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CDE73A6D75 for <netext@core3.amsl.com>; Mon, 14 Mar 2011 15:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.183 X-Spam-Level: X-Spam-Status: No, score=-10.183 tagged_above=-999 required=5 tests=[AWL=0.416, 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 1oGxHWiu2wJd for <netext@core3.amsl.com>; Mon, 14 Mar 2011 15:32:27 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 5F2943A6FD3 for <netext@ietf.org>; Mon, 14 Mar 2011 15:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=2012; q=dns/txt; s=iport; t=1300142017; x=1301351617; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=xClPEXKYQ49pF6H4eFX9lIfVxUsCadvf27BZyvk5pec=; b=YbqpSACczjfRmw+zn7G9NoNfokG7UYv9K3CDhoE0co9UaiklH3LDfzSq 66/TIu3BkSw4lhuAum22taod2GPjxjs73952HvxYaA/DpoIL0CfWMfxfg 6mEl/1XIG7cdFzr2Yg7Z1Xacswnkw+PaP1loHYe+qmPFgkqbcydpGlu/h c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcGAAI0fk2tJV2Z/2dsb2JhbACZBo0Hd6RpnDiFYgSFK4cng1Q X-IronPort-AV: E=Sophos;i="4.62,319,1297036800"; d="scan'208";a="320225087" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-2.cisco.com with ESMTP; 14 Mar 2011 22:33:37 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2EMXbrs028354; Mon, 14 Mar 2011 22:33:37 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); Mon, 14 Mar 2011 15:33:36 -0700 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 ; Mon, 14 Mar 2011 22:33:35 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Mon, 14 Mar 2011 15:35:23 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: <netext@ietf.org> Message-ID: <C9A3E63B.135B7%sgundave@cisco.com> Thread-Topic: [netext] #3: Logical Interface: Use of the Virtual LLID Thread-Index: AcvimBs7blf7gtIPJ0uMTj78sxo6Uw== In-Reply-To: <066.d2b1a47b864e8340579c7215fdc00464@trac.tools.ietf.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 14 Mar 2011 22:33:36.0805 (UTC) FILETIME=[DBEFB550:01CBE297] Cc: draft-ietf-netext-logical-interface-support@tools.ietf.org Subject: Re: [netext] #3: Logical Interface: Use of the Virtual LLID X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Mar 2011 22:32:28 -0000 > #3: Logical Interface: Use of the Virtual LLID There were quite a few discussion on this among the authors. Looking things are done WiMAX, CDMA and LTE. It appeared logical to allow both the use of a neutral link-layer identifier, or adopt one of the link-layer identifier from its sub-interfaces. We may have to add some text around SEND considerations. This section can go through some updates. Few need to reflect few comments from Yokota-san and others ... Its not complete. It shows where we are heading. -- 6.4. Link-layer Identifier of a Logical Interface The logical Interface may or may not use the link-layer identifier from one of its sub-interfaces. Following are the considerations. o In access architectures where it is possible to adopt a virtual link-layer identfier and use it for layer-2 communications in any of the access networks, a virtual identifier (VLL-Id) may be used. The specifics on how that identifier is chosen is out side the scope of this document. This identifier may be used for all link- layer communications. This identifier may also be used for generating IPv6 global or link-local addresses on that interface. o In access architectures, where the link-layer identifier is associated with a specific access technology, it will not be possible for the logical interface to adopt a virtual identifier and it use it across different access networks. In such networks, the logical interface must adopt the identifier of the respective sub-interface through which a packet is being transmitted. -- On 3/3/11 9:16 AM, "netext issue tracker" <trac+netext@trac.tools.ietf.org> wrote: > #3: Logical Interface: Use of the Virtual LLID > > Clarify the use of virtual LLID and how this is used in the scope of > PMIP6. > Discuss the solution and propose text and ensure there is clear consensus > before you can close this issue. From julien.ietf@gmail.com Mon Mar 14 15:57:33 2011 Return-Path: <julien.ietf@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96CB73A6D34 for <netext@core3.amsl.com>; Mon, 14 Mar 2011 15:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.263 X-Spam-Level: X-Spam-Status: No, score=-3.263 tagged_above=-999 required=5 tests=[AWL=0.336, 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 qgDSxeX+lTxk for <netext@core3.amsl.com>; Mon, 14 Mar 2011 15:57:32 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 016F53A6BCB for <netext@ietf.org>; Mon, 14 Mar 2011 15:57:31 -0700 (PDT) Received: by fxm15 with SMTP id 15so18858fxm.31 for <netext@ietf.org>; Mon, 14 Mar 2011 15:58:55 -0700 (PDT) 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:content-transfer-encoding; bh=uiO9cicvzQbEHUHLzLBTsBdrUhoSwo0wGeLba6RkEdc=; b=nH86gPLnTaUM46otJq+3PgVUhaVJ5aIm9xyWxA3G434a0i5PDXpAjTPpvReZIPb28S oDNnf2R1ORZGsuarug30tMpMwLr8oR6YlC5D4HO3gGHQz+JXwWbwAcBCOqy2VqPLXD/a 8mjp9i65tCeAM6rhrl9EzNnLdTbbtdf+UkcAI= 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:content-transfer-encoding; b=KvcxCRWvoMyPqgpqonqLp/329LEZCLcr8mcJ9F1zMMdkbOHPrRbmW7aYuxuP2gShiZ gCj4MKlH2fSlm5kbyb2diA1sinXhmL7AHnAfKYD8LxSJSwQH+2NRvUGcIRJ/7oC9uOZW hyNwhFZh0fSgfBWj3OEF+sBLqIRvmuHRRhHT0= MIME-Version: 1.0 Received: by 10.223.14.137 with SMTP id g9mr7612721faa.1.1300143535587; Mon, 14 Mar 2011 15:58:55 -0700 (PDT) Received: by 10.223.78.135 with HTTP; Mon, 14 Mar 2011 15:58:55 -0700 (PDT) In-Reply-To: <20110314214509.28151.58855.idtracker@localhost> References: <20110314214509.28151.58855.idtracker@localhost> Date: Mon, 14 Mar 2011 15:58:55 -0700 Message-ID: <AANLkTinRUGJodg5JJuZ=8YQOEG4YuAXeqzwRTJ1JG8MP@mail.gmail.com> From: Julien Laganier <julien.ietf@gmail.com> To: netext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [netext] I-D Action:draft-ietf-netext-logical-interface-support-02.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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Mar 2011 22:57:33 -0000 I am surprised that this document was revised without any mailing discussions of the changes that were carried on... --julien On Mon, Mar 14, 2011 at 2:45 PM, <Internet-Drafts@ietf.org> wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Network-Based Mobility Extensions Workin= g Group of the IETF. > > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Logical Interface Support for = multi-mode IP Hosts > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : T. Melia, S. Gundavelli > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-netext-logical-interf= ace-support-02.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 26 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-03-14 > > A Logical Interface is a software semantic internal to the host > operating system. =A0This semantic is available in all popular > operating systems and is used in various protocol implementations. > The Logical Interface support is required on the mobile node > operating in a Proxy Mobile IPv6 domain, for leveraging various > network-based mobility management features such as inter-technology > handoffs, multihoming and flow mobility support. =A0This document > explains the operational details of Logical Interface construct and > the specifics on how the link-layer implementations hide the physical > interfaces from the IP stack and from the network nodes on the > attached access networks. =A0Furthermore, this document identifies the > applicability of this approach to various link-layer technologies and > analyzes the issues around it when used in context with various > mobility management features. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netext-logical-interface-s= upport-02.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. > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > From sgundave@cisco.com Mon Mar 14 16:05:30 2011 Return-Path: <sgundave@cisco.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDA283A6BED for <netext@core3.amsl.com>; Mon, 14 Mar 2011 16:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.501 X-Spam-Level: X-Spam-Status: No, score=-9.501 tagged_above=-999 required=5 tests=[AWL=-0.298, 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 I8f5SQ4kG1aZ for <netext@core3.amsl.com>; Mon, 14 Mar 2011 16:05:30 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 81A403A6B8B for <netext@ietf.org>; Mon, 14 Mar 2011 16:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=2862; q=dns/txt; s=iport; t=1300144012; x=1301353612; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=2jbDa5r1T4jW0JvMDkEpM4qLTwaIYCGUwtyBaBme3+8=; b=BBP17vm4HDOLkPXILK8xOiQDnahZBMJ4Md6soDEeTPYHvR+qetUUP3Wj lko2fe9wYZedfxP1EE1fHdWYSyLBLJ2auuiHZgpnlH7YoY/8tkCOJY/1e ukMKeThXDjty8UNuAPUkY/PxsXQMP6t37yY0lcCIWrWOMFd97VZrN5VZp 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAK48fk2tJXHB/2dsb2JhbAClOlN3pROcP4ViBIUrhyeDVIMc X-IronPort-AV: E=Sophos;i="4.62,319,1297036800"; d="scan'208";a="346452247" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-5.cisco.com with ESMTP; 14 Mar 2011 23:06:52 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2EN6pPN006786; Mon, 14 Mar 2011 23:06:52 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, 14 Mar 2011 16:06:51 -0700 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 ; Mon, 14 Mar 2011 23:06:51 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Mon, 14 Mar 2011 16:08:35 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: Julien Laganier <julien.ietf@gmail.com>, <netext@ietf.org> Message-ID: <C9A3EE03.135D4%sgundave@cisco.com> Thread-Topic: [netext] I-D Action:draft-ietf-netext-logical-interface-support-02.txt Thread-Index: AcvinL6OqIYXUbvBZ0mp9aoJ18c5oQ== In-Reply-To: <AANLkTinRUGJodg5JJuZ=8YQOEG4YuAXeqzwRTJ1JG8MP@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 14 Mar 2011 23:06:51.0772 (UTC) FILETIME=[810783C0:01CBE29C] Subject: Re: [netext] I-D Action:draft-ietf-netext-logical-interface-support-02.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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Mar 2011 23:05:31 -0000 Hi Julien: We were hoping to post the text before, but we could not as we did not have the text till late. Any ways, we can use it as a starting point text for th= e discussions. We can update the text as needed. If you can please review and comment that will be great. Regards Sri On 3/14/11 2:58 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: > I am surprised that this document was revised without any mailing > discussions of the changes that were carried on... >=20 > --julien >=20 > On Mon, Mar 14, 2011 at 2:45 PM, <Internet-Drafts@ietf.org> wrote: >> 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 Worki= ng >> Group of the IETF. >>=20 >>=20 >> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Logical Interface Support for multi-mode IP Hos= ts >> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : T. Melia, S. Gundavelli >> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-netext-logical-interface-support-02.= txt >> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 26 >> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-03-14 >>=20 >> A Logical Interface is a software semantic internal to the host >> operating system. =A0This semantic is available in all popular >> operating systems and is used in various protocol implementations. >> The Logical Interface support is required on the mobile node >> operating in a Proxy Mobile IPv6 domain, for leveraging various >> network-based mobility management features such as inter-technology >> handoffs, multihoming and flow mobility support. =A0This document >> explains the operational details of Logical Interface construct and >> the specifics on how the link-layer implementations hide the physical >> interfaces from the IP stack and from the network nodes on the >> attached access networks. =A0Furthermore, this document identifies the >> applicability of this approach to various link-layer technologies and >> analyzes the issues around it when used in context with various >> mobility management features. >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-netext-logical-interface-= suppo >> rt-02.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >>=20 >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >>=20 >>=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From julien.ietf@gmail.com Mon Mar 14 16:09:33 2011 Return-Path: <julien.ietf@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6A753A6BE6 for <netext@core3.amsl.com>; Mon, 14 Mar 2011 16:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=0.333, 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 sHaLu4u0LZFb for <netext@core3.amsl.com>; Mon, 14 Mar 2011 16:09:32 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 8DFA53A6B8B for <netext@ietf.org>; Mon, 14 Mar 2011 16:09:32 -0700 (PDT) Received: by fxm15 with SMTP id 15so26927fxm.31 for <netext@ietf.org>; Mon, 14 Mar 2011 16:10:56 -0700 (PDT) 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=zcMYxJ+9rySZyNoEu3washZcfJO8HHwz76X0bzQ0+kA=; b=xSLtMC4eOc9xfZp26sZNk8EX8SGUXAJuZURi5JYTtZOpGgmQPlCePPYl29e10FRI31 ygwzoMAI0zTPyjvbHQVckRaJ+M39Mtyo2LmPvPfKZiAJUEhuRO1xRWdRSNyXH8Ta9oho NdWXuuxmJEW3xPiqwnpqdItzGEH5x+o6VeqwU= 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=hPT6DFJIojKCBpwX2KUWYu8aLXbFVaKiK6R3ROrI1omRS5H8Inrpfwe4S5S7JE5iP/ i7bSLg0LnrfmGTM3FGzdW/O1FI3Wl3y6Y3sohQ55NCugkOe/hkKIzjYgVLeOsnQIjq79 t+Tj1WiFhWM6f7mvxt/m/b/RK+sY/Yi7OGe2E= MIME-Version: 1.0 Received: by 10.223.14.137 with SMTP id g9mr7625170faa.1.1300144254533; Mon, 14 Mar 2011 16:10:54 -0700 (PDT) Received: by 10.223.78.135 with HTTP; Mon, 14 Mar 2011 16:10:54 -0700 (PDT) In-Reply-To: <C9A3EE03.135D4%sgundave@cisco.com> References: <AANLkTinRUGJodg5JJuZ=8YQOEG4YuAXeqzwRTJ1JG8MP@mail.gmail.com> <C9A3EE03.135D4%sgundave@cisco.com> Date: Mon, 14 Mar 2011 16:10:54 -0700 Message-ID: <AANLkTimd-nM8CveeWmFfw+dGQrQeN9GSPJGGSxKo839v@mail.gmail.com> From: Julien Laganier <julien.ietf@gmail.com> To: Sri Gundavelli <sgundave@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] I-D Action:draft-ietf-netext-logical-interface-support-02.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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Mar 2011 23:09:33 -0000 Hi Sri, I think the new text fragments should be posted on this mailing list and discussed first. If and when agreement is reached, then the text fragments can be included in a revision of the draft. Otherwise I do not see how the draft can reflect the WG consensus... --julien On Mon, Mar 14, 2011 at 5:08 PM, Sri Gundavelli <sgundave@cisco.com> wrote: > Hi Julien: > > We were hoping to post the text before, but we could not as we did not ha= ve > the text till late. Any ways, we can use it as a starting point text for = the > discussions. We can update the text as needed. If you can please review a= nd > comment that will be great. > > > > Regards > Sri > > > > > On 3/14/11 2:58 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: > >> I am surprised that this document was revised without any mailing >> discussions of the changes that were carried on... >> >> --julien >> >> On Mon, Mar 14, 2011 at 2:45 PM, =A0<Internet-Drafts@ietf.org> wrote: >>> 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 Work= ing >>> Group of the IETF. >>> >>> >>> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Logical Interface Support fo= r multi-mode IP Hosts >>> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : T. Melia, S. Gundavelli >>> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-netext-logical-inte= rface-support-02.txt >>> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 26 >>> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-03-14 >>> >>> A Logical Interface is a software semantic internal to the host >>> operating system. =A0This semantic is available in all popular >>> operating systems and is used in various protocol implementations. >>> The Logical Interface support is required on the mobile node >>> operating in a Proxy Mobile IPv6 domain, for leveraging various >>> network-based mobility management features such as inter-technology >>> handoffs, multihoming and flow mobility support. =A0This document >>> explains the operational details of Logical Interface construct and >>> the specifics on how the link-layer implementations hide the physical >>> interfaces from the IP stack and from the network nodes on the >>> attached access networks. =A0Furthermore, this document identifies the >>> applicability of this approach to various link-layer technologies and >>> analyzes the issues around it when used in context with various >>> mobility management features. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-netext-logical-interface= -suppo >>> rt-02.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. >>> >>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>> >>> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > > From sgundave@cisco.com Mon Mar 14 17:16:09 2011 Return-Path: <sgundave@cisco.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 004A63A6BFB for <netext@core3.amsl.com>; Mon, 14 Mar 2011 17:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.49 X-Spam-Level: X-Spam-Status: No, score=-9.49 tagged_above=-999 required=5 tests=[AWL=-0.287, 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 HdOcXehpincH for <netext@core3.amsl.com>; Mon, 14 Mar 2011 17:16:08 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id F20713A6F8D for <netext@ietf.org>; Mon, 14 Mar 2011 17:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=3875; q=dns/txt; s=iport; t=1300148252; x=1301357852; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=elKLpb7aCEGdsIBLFqzGQ/YvKBv69g/In6yIIr7Y2gA=; b=ixtbWqLWI2DYnjHbJrNyYfzzl+1Ob97Zviq234y7fy0TtzeNLGNaSKA4 J3oVoBEQyLjkY9Uv/mCVt9WtLymvYHnD16D0hU2589BXQfeuaEAlRT7M3 KZPKs99tsFDz4MfiS7xpKlE2RHlmfMqeU45GmKv2qjiKGosBk2ePtjN21 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFNNfk2tJXHA/2dsb2JhbAClOlN3pVicS4ViBIUrhyeDVIMc X-IronPort-AV: E=Sophos;i="4.62,319,1297036800"; d="scan'208";a="277934439" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by sj-iport-3.cisco.com with ESMTP; 15 Mar 2011 00:17:32 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2F0HJSA003241; Tue, 15 Mar 2011 00:17:31 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); Mon, 14 Mar 2011 17:17:16 -0700 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, 15 Mar 2011 00:17:15 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Mon, 14 Mar 2011 17:19:02 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: Julien Laganier <julien.ietf@gmail.com> Message-ID: <C9A3FE86.135F0%sgundave@cisco.com> Thread-Topic: [netext] I-D Action:draft-ietf-netext-logical-interface-support-02.txt Thread-Index: AcvippYL1ROwEzOs70CQ3r61W7KrbQ== In-Reply-To: <AANLkTimd-nM8CveeWmFfw+dGQrQeN9GSPJGGSxKo839v@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 15 Mar 2011 00:17:16.0214 (UTC) FILETIME=[56FE3560:01CBE2A6] Cc: netext@ietf.org Subject: Re: [netext] I-D Action:draft-ietf-netext-logical-interface-support-02.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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Mar 2011 00:16:09 -0000 Hi Julien, We are not at a last call, still getting the draft to a shape to enable serious reviews, you can challenge any sections of the draft. As we move forward, I agree, we should be careful to post the text before. We have posted the text for each of the issues separately, lets start with them. =20 Regards Sri On 3/14/11 3:10 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: > Hi Sri, >=20 > I think the new text fragments should be posted on this mailing list > and discussed first. If and when agreement is reached, then the text > fragments can be included in a revision of the draft. Otherwise I do > not see how the draft can reflect the WG consensus... >=20 > --julien >=20 > On Mon, Mar 14, 2011 at 5:08 PM, Sri Gundavelli <sgundave@cisco.com> wrot= e: >> Hi Julien: >>=20 >> We were hoping to post the text before, but we could not as we did not h= ave >> the text till late. Any ways, we can use it as a starting point text for= the >> discussions. We can update the text as needed. If you can please review = and >> comment that will be great. >>=20 >>=20 >>=20 >> Regards >> Sri >>=20 >>=20 >>=20 >>=20 >> On 3/14/11 2:58 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: >>=20 >>> I am surprised that this document was revised without any mailing >>> discussions of the changes that were carried on... >>>=20 >>> --julien >>>=20 >>> On Mon, Mar 14, 2011 at 2:45 PM, =A0<Internet-Drafts@ietf.org> wrote: >>>> 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 Wor= king >>>> Group of the IETF. >>>>=20 >>>>=20 >>>> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Logical Interface Support for multi-mode IP H= osts >>>> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : T. Melia, S. Gundavelli >>>> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-netext-logical-interface-support-0= 2.txt >>>> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 26 >>>> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-03-14 >>>>=20 >>>> A Logical Interface is a software semantic internal to the host >>>> operating system. =A0This semantic is available in all popular >>>> operating systems and is used in various protocol implementations. >>>> The Logical Interface support is required on the mobile node >>>> operating in a Proxy Mobile IPv6 domain, for leveraging various >>>> network-based mobility management features such as inter-technology >>>> handoffs, multihoming and flow mobility support. =A0This document >>>> explains the operational details of Logical Interface construct and >>>> the specifics on how the link-layer implementations hide the physical >>>> interfaces from the IP stack and from the network nodes on the >>>> attached access networks. =A0Furthermore, this document identifies the >>>> applicability of this approach to various link-layer technologies and >>>> analyzes the issues around it when used in context with various >>>> mobility management features. >>>>=20 >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-netext-logical-interfac= e-sup >>>> po >>>> rt-02.txt >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>>=20 >>>>=20 >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>=20 >>=20 From julien.ietf@gmail.com Mon Mar 14 18:18:40 2011 Return-Path: <julien.ietf@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50C0C3A6B98 for <netext@core3.amsl.com>; Mon, 14 Mar 2011 18:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.269 X-Spam-Level: X-Spam-Status: No, score=-3.269 tagged_above=-999 required=5 tests=[AWL=0.330, 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 Q5+fvL7bOlR2 for <netext@core3.amsl.com>; Mon, 14 Mar 2011 18:18:39 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id CA0623A68AC for <netext@ietf.org>; Mon, 14 Mar 2011 18:18:38 -0700 (PDT) Received: by fxm15 with SMTP id 15so104268fxm.31 for <netext@ietf.org>; Mon, 14 Mar 2011 18:20:02 -0700 (PDT) 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=sImIZDpjUsvpBVWwLkWptoxPnLDWWtY4DeY/hKYBG/U=; b=hZrP25wg5Vd6aDVhc05Qg0h6c1/LZgJRkAEi0SPgrDzlhwodfNBPUCzXFt5K8oXfcG bIc71waxmgPPUINsitOytK/DGW3lGhj3masM9TJtai+Q00z9pO9jK9AuCeAtZG86ShpI CnZJCmkAKM97ALF8sU4XElShxMBbxCOUAbqdM= 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=QrFPmEurbOXLZGt3LJuImjjXIv0AYsy+Ti8s1+FQZcr5OZwjXGkB9jbKJVhSs7In4O 7BonFb7kzllWCN5tx5865D04qx12kkW2WcXt1FS8t3EA5+6Ix6VEJk82t/VIYsjzJ95Y ZUh7u9MEbqGmuSPg+vtT7R7qxL2J4GuCLxG3s= MIME-Version: 1.0 Received: by 10.223.126.130 with SMTP id c2mr603314fas.39.1300152002244; Mon, 14 Mar 2011 18:20:02 -0700 (PDT) Received: by 10.223.78.135 with HTTP; Mon, 14 Mar 2011 18:20:02 -0700 (PDT) In-Reply-To: <C9A3E3AD.135AF%sgundave@cisco.com> References: <066.44c02c04592a11d868774e78f7db352d@trac.tools.ietf.org> <C9A3E3AD.135AF%sgundave@cisco.com> Date: Mon, 14 Mar 2011 18:20:02 -0700 Message-ID: <AANLkTin_ZbJmkbS3d2U0RGcSp4nCFD0H_VjeUQzQdB6H@mail.gmail.com> From: Julien Laganier <julien.ietf@gmail.com> To: Sri Gundavelli <sgundave@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] #4: Logical interface support: Point to point links X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Mar 2011 01:18:40 -0000 Sri - 5213 supports only PtP links thus I do not understand how the following resolution resolves anything. Please clarify what is the issue you' re addressing and how this is addressing it. --julien On Mon, Mar 14, 2011 at 4:24 PM, Sri Gundavelli <sgundave@cisco.com> wrote: >> #4: Logical interface support: Point to point links > > =C2=A0Clarify the use and >> behavior of the logical interface on PtP links. > > > Folks: Again, reflecting the team's contributions on this topic, the auth= ors > of this document have discussed this and resolve it with the following te= xt. > The key points we tried to reflect are around that the logical interface > appears to the application as a shared link. There were thoughts around > making it appear like a p2p link, given that there are multiple neighbors= on > each sub interface, this choice appears reasonable. With respect to how a > packet is transmitted, is still based on the chosen link model at each su= b > interface level. Let us know, if you see any issues with it. This is prov= en > based on the multiple implementations from some of the co-authors of this > doc. > > > > > --- > 6.3. =C2=A0Supported Link models for a logical interface > > =C2=A0The sub-interfaces of a logical interface can be bound to a point-t= o- > =C2=A0 point or a shared link (Example: LTE and WLAN). =C2=A0The logical > =C2=A0 interface appears as a shared-link to the applications, and adapts= to > =C2=A0 the link model of the sub-interface for packet communication. =C2= =A0For > =C2=A0 example, when transmitting a packet on a sub-interface which is > =C2=A0 attached to a p2p link, the transmission conforms to the p2p link > =C2=A0 model and when transmitting on a sub-interface attached to a share= d > =C2=A0 link, the transmission conforms to the shared link model. > > =C2=A0 Based on the link to which the sub-interface is attached to, the > =C2=A0 layer-2 resolutions may or may not be needed. =C2=A0If the interfa= ce is > =C2=A0 bound to a P2P link with PPP running, there will not be any link- > =C2=A0 layer resolutions in the form of ARP/ND messages. =C2=A0However, i= f the > =C2=A0 interface is bound to a shared link such as Ethernet, there will b= e > =C2=A0 ND resolutions. =C2=A0The logical interface implementation has to = maintain > =C2=A0 the required link model and the associated state for each sub- > =C2=A0 interface. > -- > > > > > On 3/3/11 9:17 AM, "netext issue tracker" <trac+netext@trac.tools.ietf.or= g> > wrote: > >> #4: Logical interface support: Point to point links > > =C2=A0Clarify the use and >> behavior of the logical interface on PtP links. > > -- >> > ---------------------------------------+---------------------------------= --- > >> Reporter: =C2=A0basavaraj.patil@=C5=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| =C2=A0 =C2=A0 =C2=A0 Owner: =C2=A0telemaco.melia@=C5=A0 >> > =C2=A0 =C2=A0 Type: =C2=A0defect =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0Status: =C2=A0new >> > =C2=A0Priority: =C2=A0major =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 Milestone: >> > Component: =C2=A0logical-interface-support =C2=A0| =C2=A0 =C2=A0 Version: >> > =C2=A0Severity: =C2=A0- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0Keywords: >> > ---------------------------------------+---------------------------------= --- > >> > Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/4> > netext >> <http://tools.ietf.org/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 Mon Mar 14 18:21:53 2011 Return-Path: <julien.ietf@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 596743A68AC for <netext@core3.amsl.com>; Mon, 14 Mar 2011 18:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.272 X-Spam-Level: X-Spam-Status: No, score=-3.272 tagged_above=-999 required=5 tests=[AWL=0.327, 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 khiz8VYzBr9b for <netext@core3.amsl.com>; Mon, 14 Mar 2011 18:21:51 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 799353A6BCA for <netext@ietf.org>; Mon, 14 Mar 2011 18:21:50 -0700 (PDT) Received: by fxm15 with SMTP id 15so106140fxm.31 for <netext@ietf.org>; Mon, 14 Mar 2011 18:23:14 -0700 (PDT) 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=7fHa0INP7dqxrkl3mEBIg3Zu12vv0tSou/OgKDhcuio=; b=lBuxhr8BTx/MNjpySi8UugCEk/IZ7vMWxU5Ycx0qQyTZvgcEw6ACnYlejJqyEoDe+3 wYo//+PsD045HyeCQwHZu5ywe8kyqR7kazKtOfGluVCLef5i6t/qLvt2i35RUBTIgXIG LYNYeGJARR9A+chrKyH26iv4w1VxS3bXW9iqg= 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=w9LYocb0gaQzqL81v3LWLT55A+UUXujkhgItsbfR+wXJTeZWFn+Ej3sWupyi2uiA+h CuAzr3YsmhiDwff67tw63g3j2W190j0P5xob5vEH+qRor2HUSzUFvFLzpZR1z4SGKQg9 egscGe4BqlAF94TE5Kyyupp3SmXB/l7xbP4nY= MIME-Version: 1.0 Received: by 10.223.78.201 with SMTP id m9mr3834595fak.20.1300152194131; Mon, 14 Mar 2011 18:23:14 -0700 (PDT) Received: by 10.223.78.135 with HTTP; Mon, 14 Mar 2011 18:23:14 -0700 (PDT) In-Reply-To: <C9A3E63B.135B7%sgundave@cisco.com> References: <066.d2b1a47b864e8340579c7215fdc00464@trac.tools.ietf.org> <C9A3E63B.135B7%sgundave@cisco.com> Date: Mon, 14 Mar 2011 18:23:14 -0700 Message-ID: <AANLkTim6CY-H49YhHcq1RdHp+MHLRfQaRKqpQFk5+-8F@mail.gmail.com> From: Julien Laganier <julien.ietf@gmail.com> To: Sri Gundavelli <sgundave@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org, draft-ietf-netext-logical-interface-support@tools.ietf.org Subject: Re: [netext] #3: Logical Interface: Use of the Virtual LLID X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Mar 2011 01:21:53 -0000 Sri - I don't understand how this resolves the issue we discussed last time. If an underlying link layer does not let you use an arbitrary link layer identifier, what is the link layer identifier exposed by the logical interface to the IP layer? --julien On Mon, Mar 14, 2011 at 4:35 PM, Sri Gundavelli <sgundave@cisco.com> wrote: >> #3: Logical Interface: Use of the Virtual LLID > > > There were quite a few discussion on this among the authors. Looking thin= gs > are done WiMAX, CDMA and LTE. It appeared logical to allow both the use o= f a > neutral link-layer identifier, or adopt one of the link-layer identifier > from its sub-interfaces. =A0We may have to add some text around SEND > considerations. This section can go through some updates. Few need to > reflect few comments from Yokota-san and others ... Its not complete. It > shows where we are heading. > > > > -- > 6.4. =A0Link-layer Identifier of a Logical Interface > > =A0 The logical Interface may or may not use the link-layer identifier > =A0 from one of its sub-interfaces. =A0Following are the considerations. > > =A0 o =A0In access architectures where it is possible to adopt a virtual > =A0 =A0 =A0link-layer identfier and use it for layer-2 communications in = any > =A0 =A0 =A0of the access networks, a virtual identifier (VLL-Id) may be u= sed. > =A0 =A0 =A0The specifics on how that identifier is chosen is out side the > =A0 =A0 =A0scope of this document. =A0This identifier may be used for all= link- > =A0 =A0 =A0layer communications. =A0This identifier may also be used for > =A0 =A0 =A0generating IPv6 global or link-local addresses on that interfa= ce. > > =A0 o =A0In access architectures, where the link-layer identifier is > =A0 =A0 =A0associated with a specific access technology, it will not be > =A0 =A0 =A0possible for the logical interface to adopt a virtual identifi= er > =A0 =A0 =A0and it use it across different access networks. =A0In such net= works, > =A0 =A0 =A0the logical interface must adopt the identifier of the respect= ive > =A0 =A0 =A0sub-interface through which a packet is being transmitted. > -- > > > > > > On 3/3/11 9:16 AM, "netext issue tracker" <trac+netext@trac.tools.ietf.or= g> > wrote: > >> #3: Logical Interface: Use of the Virtual LLID >> >> =A0Clarify the use of virtual LLID and how this is used in the scope of >> =A0PMIP6. >> =A0Discuss the solution and propose text and ensure there is clear conse= nsus >> =A0before you can close this issue. > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From julien.ietf@gmail.com Mon Mar 14 18:23:47 2011 Return-Path: <julien.ietf@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA2F33A68AC for <netext@core3.amsl.com>; Mon, 14 Mar 2011 18:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.275 X-Spam-Level: X-Spam-Status: No, score=-3.275 tagged_above=-999 required=5 tests=[AWL=0.324, 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 suqAMzywCeoM for <netext@core3.amsl.com>; Mon, 14 Mar 2011 18:23:44 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 0B2103A6BB2 for <netext@ietf.org>; Mon, 14 Mar 2011 18:23:43 -0700 (PDT) Received: by fxm15 with SMTP id 15so107093fxm.31 for <netext@ietf.org>; Mon, 14 Mar 2011 18:25:07 -0700 (PDT) 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=oAnkUcF1lPsFEExDmDybOz12Mk3L2BWzgq3RhnQXC7c=; b=s4i6UVjBCO/33jD8btV9il5w35Za8QOp+zWvZObOpEzUx7IocR4AFB3lccL5Mfxdv3 ZqDj62lezZishHL0Yl6ZYHCVAy9dc0/QNpANi3ODBwRIHPoSF/omcy3HgBk+m+7AZLOI 0agmDxbtZAwl5vxer/YmlvAig+LUK8sxd0JBo= 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=Ju+Hq1QWptL8vR3re0kBYGIHElXVGqkSxz5GorRKJMw8VjyyAfopoPEW4HYQp+DIX7 h+2gDL3oEv/JYA7gEGNcjt2XbmZgFcjFMJkgxBuue7B/cdUCfIhXRfcowFsVq1U9oJxI CNh6gMGeEhvs5+QZ222MCIzOCZ5MBadw6CpkY= MIME-Version: 1.0 Received: by 10.223.126.130 with SMTP id c2mr607264fas.39.1300152307840; Mon, 14 Mar 2011 18:25:07 -0700 (PDT) Received: by 10.223.78.135 with HTTP; Mon, 14 Mar 2011 18:25:07 -0700 (PDT) In-Reply-To: <C9A3E479.135B3%sgundave@cisco.com> References: <066.d15938dc10856d20b122b59428c9c5bc@trac.tools.ietf.org> <C9A3E479.135B3%sgundave@cisco.com> Date: Mon, 14 Mar 2011 18:25:07 -0700 Message-ID: <AANLkTi=0rTWWrc-MX0anmKpKvfU67QGXsJf9Ww+ifpwq@mail.gmail.com> From: Julien Laganier <julien.ietf@gmail.com> To: Sri Gundavelli <sgundave@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] #5: Logical interface support: Multicast traffic X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Mar 2011 01:23:47 -0000 Sri - Multicast traffic isn' t limited to ND, thus I don' t think it is appropriate to consider this issue as closed because you crafter some text on ND considerations elsewhere in this document. Please clarify how tranmission on multicast traffic is handled over a logical interface. --julien On Mon, Mar 14, 2011 at 4:27 PM, Sri Gundavelli <sgundave@cisco.com> wrote: >> #5: Logical interface support: Multicast traffic > > =C2=A0Clarify how the logical >> interface deals with multicast traffic. > > > We believe we have resolve this issue, this is captured in the ND > interactions section. The general considerations around dealing with > link-specific multicast traffic, all-nodes, solicited node multicast > traffic, or others have common considerations. It is possible we might be > missing few cases, we can add that in, but the base handling of things at > the logical interface level, or sub-interface level is captured. Comments > welcome. > > > Sri > > > > > > On 3/3/11 9:19 AM, "netext issue tracker" <trac+netext@trac.tools.ietf.or= g> > wrote: > >> #5: Logical interface support: Multicast traffic > > =C2=A0Clarify how the logical >> interface deals with multicast traffic. > > -- >> > ---------------------------------------+---------------------------------= --- > >> Reporter: =C2=A0basavaraj.patil@=C5=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| =C2=A0 =C2=A0 =C2=A0 Owner: =C2=A0telemaco.melia@=C5=A0 >> > =C2=A0 =C2=A0 Type: =C2=A0defect =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0Status: =C2=A0new >> > =C2=A0Priority: =C2=A0critical =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | =C2=A0 Milestone: >> > Component: =C2=A0logical-interface-support =C2=A0| =C2=A0 =C2=A0 Version: >> > =C2=A0Severity: =C2=A0- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0Keywords: >> > ---------------------------------------+---------------------------------= --- > >> > Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/5> > netext >> <http://tools.ietf.org/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 sgundave@cisco.com Mon Mar 14 18:40:18 2011 Return-Path: <sgundave@cisco.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAAD83A68AC for <netext@core3.amsl.com>; Mon, 14 Mar 2011 18:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.48 X-Spam-Level: X-Spam-Status: No, score=-9.48 tagged_above=-999 required=5 tests=[AWL=-0.277, 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 1X04kJSljefk for <netext@core3.amsl.com>; Mon, 14 Mar 2011 18:40:17 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 8B4DF3A68AB for <netext@ietf.org>; Mon, 14 Mar 2011 18:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=2978; q=dns/txt; s=iport; t=1300153302; x=1301362902; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=tb0xqb6zoh/g7PPHoECwn8htndk3KdojjLC1t8l5rA4=; b=S7znikUbqWwjlQrByiuxYMKlkuoxG9dBzGp9cDpeSwq/imtFNJ/Vd/Bq s3ptnnu7eHPXhKJtqerEJkbvoT4tAAdphdaO48q6/eJS/G5mtsf6B59LW WK6uL6GBlbqBS9wbr4WWfwcikEXtFW+W3BZRvJ3EvMQ27Y4rzjMfea10b U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAA5hfk2tJV2c/2dsb2JhbAClO1N3pX+cUYViBIUrhyeDVIMc X-IronPort-AV: E=Sophos;i="4.62,319,1297036800"; d="scan'208";a="346544961" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by sj-iport-5.cisco.com with ESMTP; 15 Mar 2011 01:41:41 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2F1feWV001049; Tue, 15 Mar 2011 01:41:41 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, 14 Mar 2011 18:41:41 -0700 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, 15 Mar 2011 01:41:40 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Mon, 14 Mar 2011 18:43:25 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: Julien Laganier <julien.ietf@gmail.com> Message-ID: <C9A4124D.1361E%sgundave@cisco.com> Thread-Topic: [netext] #5: Logical interface support: Multicast traffic Thread-Index: Acvisl/U9Ad2mCDymkKFiD2tkDVNag== In-Reply-To: <AANLkTi=0rTWWrc-MX0anmKpKvfU67QGXsJf9Ww+ifpwq@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-2" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 15 Mar 2011 01:41:41.0090 (UTC) FILETIME=[21E4F420:01CBE2B2] Cc: netext@ietf.org Subject: Re: [netext] #5: Logical interface support: Multicast traffic X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Mar 2011 01:40:18 -0000 Julien: Agree. I did put that note below that we should add any additional cases. The text around handling link-specific multicast traffic with different destination scopes covers most of the common multicast cases, ALL-NODES, SOLICTED-NODE... We can add any missing cases and resolve it. Any specific case you are thinking about ? We can generalize the case and make it apply for ND and non-ND cases. Regards Sri On 3/14/11 5:25 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: > Sri - >=20 > Multicast traffic isn' t limited to ND, thus I don' t think it is > appropriate to consider this issue as closed because you crafter some > text on ND considerations elsewhere in this document. Please clarify > how tranmission on multicast traffic is handled over a logical > interface. >=20 > --julien >=20 > On Mon, Mar 14, 2011 at 4:27 PM, Sri Gundavelli <sgundave@cisco.com> wrot= e: >>> #5: Logical interface support: Multicast traffic >>=20 >> =A0Clarify how the logical >>> interface deals with multicast traffic. >>=20 >>=20 >> We believe we have resolve this issue, this is captured in the ND >> interactions section. The general considerations around dealing with >> link-specific multicast traffic, all-nodes, solicited node multicast >> traffic, or others have common considerations. It is possible we might b= e >> missing few cases, we can add that in, but the base handling of things a= t >> the logical interface level, or sub-interface level is captured. Comment= s >> welcome. >>=20 >>=20 >> Sri >>=20 >>=20 >>=20 >>=20 >>=20 >> On 3/3/11 9:19 AM, "netext issue tracker" <trac+netext@trac.tools.ietf.o= rg> >> wrote: >>=20 >>> #5: Logical interface support: Multicast traffic >>=20 >> =A0Clarify how the logical >>> interface deals with multicast traffic. >>=20 >> -- >>>=20 >> ---------------------------------------+--------------------------------= ---- >>=20 >>> Reporter: =A0basavaraj.patil@=A9 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Owner: =A0telemaco.melia@=A9 >>>=20 >> =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status: =A0new >>>=20 >> =A0Priority: =A0critical =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone: >>>=20 >> Component: =A0logical-interface-support =A0| =A0 =A0 Version: >>>=20 >> =A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0Keywords: >>>=20 >> ---------------------------------------+--------------------------------= ---- >>=20 >>>=20 >> Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/5> >> netext >>> <http://tools.ietf.org/netext/> >>=20 >> _____________________________________________ >>> __ >> netext mailing >>> list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >>=20 >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >>=20 From julien.ietf@gmail.com Mon Mar 14 18:51:24 2011 Return-Path: <julien.ietf@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 814B03A6E04 for <netext@core3.amsl.com>; Mon, 14 Mar 2011 18:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.278 X-Spam-Level: X-Spam-Status: No, score=-3.278 tagged_above=-999 required=5 tests=[AWL=0.321, 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 UzGuAiAojtny for <netext@core3.amsl.com>; Mon, 14 Mar 2011 18:51:23 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 023B63A6BD5 for <netext@ietf.org>; Mon, 14 Mar 2011 18:51:22 -0700 (PDT) Received: by fxm15 with SMTP id 15so124195fxm.31 for <netext@ietf.org>; Mon, 14 Mar 2011 18:52:46 -0700 (PDT) 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=r4vVdc5rI3HYDagI9vCYxeO4FocMm+LNRUKXkhCt6XE=; b=YcqHlULZZR+Tu0c1aVbZzf3U2iwXcXxAt7qbK+TUHNI1SFk9oTcdqnOyTjvdv75hyY elAFdoBCMmia/V5wz4Ljfgmmza+/dhIN6CRQoYsBsItZbYb06evsPRcfvTLfv30/Eo+b gTykhOhsSjiZKePEtnIlYv8J8gbaEdE4oa5+s= 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=h8fR2c8+52SY2Mjbmnbt2Mn78OCDcMnrSvHTnqakXcCO8pU2GAlW5nJojnRmHHgZtD sznqa0SXgxBeB5U5nAD+dQ1sfKhnDd2QU1xJ5p0bo3J7ywwkGWcuBoqQv6WGh8ypN930 LUwlMS2W2aSyKbrP+2OjOc3JLVyUl/KLYGuJQ= MIME-Version: 1.0 Received: by 10.223.151.14 with SMTP id a14mr1433158faw.134.1300153966549; Mon, 14 Mar 2011 18:52:46 -0700 (PDT) Received: by 10.223.78.135 with HTTP; Mon, 14 Mar 2011 18:52:46 -0700 (PDT) In-Reply-To: <C9A4124D.1361E%sgundave@cisco.com> References: <AANLkTi=0rTWWrc-MX0anmKpKvfU67QGXsJf9Ww+ifpwq@mail.gmail.com> <C9A4124D.1361E%sgundave@cisco.com> Date: Mon, 14 Mar 2011 18:52:46 -0700 Message-ID: <AANLkTim4aeCmtWgdXvMFTu=mJC9HmEoZTnYhJBE8Tj7L@mail.gmail.com> From: Julien Laganier <julien.ietf@gmail.com> To: Sri Gundavelli <sgundave@cisco.com> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] #5: Logical interface support: Multicast traffic X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Mar 2011 01:51:24 -0000 The case I have in mind is: IP stack wants to send a packet to multicast address M; How is it transmitted? --julien 2011/3/14 Sri Gundavelli <sgundave@cisco.com>: > Julien: > > Agree. I did put that note below that we should add any additional cases. > The text around handling link-specific multicast traffic with different > destination scopes covers most of the common multicast cases, ALL-NODES, > SOLICTED-NODE... We can add any missing cases and resolve it. Any specifi= c > case you are thinking about ? We can generalize the case and make it appl= y > for ND and non-ND cases. > > > > Regards > Sri > > > > > On 3/14/11 5:25 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: > >> Sri - >> >> Multicast traffic isn' t limited to ND, thus I don' t think it is >> appropriate to consider this issue as closed because you crafter some >> text on ND considerations elsewhere in this document. Please clarify >> how tranmission on multicast traffic is handled over a logical >> interface. >> >> --julien >> >> On Mon, Mar 14, 2011 at 4:27 PM, Sri Gundavelli <sgundave@cisco.com> wro= te: >>>> #5: Logical interface support: Multicast traffic >>> >>> =A0Clarify how the logical >>>> interface deals with multicast traffic. >>> >>> >>> We believe we have resolve this issue, this is captured in the ND >>> interactions section. The general considerations around dealing with >>> link-specific multicast traffic, all-nodes, solicited node multicast >>> traffic, or others have common considerations. It is possible we might = be >>> missing few cases, we can add that in, but the base handling of things = at >>> the logical interface level, or sub-interface level is captured. Commen= ts >>> welcome. >>> >>> >>> Sri >>> >>> >>> >>> >>> >>> On 3/3/11 9:19 AM, "netext issue tracker" <trac+netext@trac.tools.ietf.= org> >>> wrote: >>> >>>> #5: Logical interface support: Multicast traffic >>> >>> =A0Clarify how the logical >>>> interface deals with multicast traffic. >>> >>> -- >>>> >>> ---------------------------------------+-------------------------------= ----- >>> >>>> Reporter: =A0basavaraj.patil@=A9 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Owne= r: =A0telemaco.melia@=A9 >>>> >>> =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 = =A0 =A0Status: =A0new >>>> >>> =A0Priority: =A0critical =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Mile= stone: >>>> >>> Component: =A0logical-interface-support =A0| =A0 =A0 Version: >>>> >>> =A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0Keywords: >>>> >>> ---------------------------------------+-------------------------------= ----- >>> >>>> >>> Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/5> >>> netext >>>> <http://tools.ietf.org/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 sgundave@cisco.com Mon Mar 14 18:57:15 2011 Return-Path: <sgundave@cisco.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A39033A6BBA for <netext@core3.amsl.com>; Mon, 14 Mar 2011 18:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.471 X-Spam-Level: X-Spam-Status: No, score=-9.471 tagged_above=-999 required=5 tests=[AWL=-0.268, 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 aau2fH9SBZ50 for <netext@core3.amsl.com>; Mon, 14 Mar 2011 18:57:13 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id EE20C3A68AB for <netext@ietf.org>; Mon, 14 Mar 2011 18:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=3804; q=dns/txt; s=iport; t=1300154317; x=1301363917; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=dxLW9WcvpPul82BDncNSxWnzYICgg9h9pKPKcrqCvSI=; b=i+SUvR/5hTJjiXgVLZ8qKnQKognIbsJBP1YcF0VEbmiANVbpnCeM8TIW J+nT5Ig/Shf+I8LpDStrBFfj8Pj2YPPlnSRTRJoZRhEXgtZ+xlbGM8aEY 2m2sewjVkpV1Cz18XAi6QDi7MqZUM5CDuMm9TX2YoZn5nQRcZwQkjZFuB M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIdkfk2tJXHB/2dsb2JhbAClO1N3pXqcUYViBIUrhyeDVIMc X-IronPort-AV: E=Sophos;i="4.62,319,1297036800"; d="scan'208";a="346552118" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-5.cisco.com with ESMTP; 15 Mar 2011 01:58:37 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2F1waiF025127; Tue, 15 Mar 2011 01:58:36 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, 14 Mar 2011 18:58:36 -0700 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, 15 Mar 2011 01:58:35 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Mon, 14 Mar 2011 19:00:21 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: Julien Laganier <julien.ietf@gmail.com> Message-ID: <C9A41645.13626%sgundave@cisco.com> Thread-Topic: [netext] #5: Logical interface support: Multicast traffic Thread-Index: AcvitL1pk/SlWp5N1kqZTFBp+1zpPQ== In-Reply-To: <AANLkTim4aeCmtWgdXvMFTu=mJC9HmEoZTnYhJBE8Tj7L@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-2" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 15 Mar 2011 01:58:36.0427 (UTC) FILETIME=[7F1515B0:01CBE2B4] Cc: netext@ietf.org Subject: Re: [netext] #5: Logical interface support: Multicast traffic X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Mar 2011 01:57:15 -0000 If you can define the destination scope, link-specific non-link-specific ? We have covered link-specific cases in the ND context (which can be generalized), non-link specific ? May be if you can reflect the issue that you are thinking, that will help resolve the issue. Sri On 3/14/11 5:52 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: > The case I have in mind is: IP stack wants to send a packet to > multicast address M; How is it transmitted? >=20 > --julien >=20 > 2011/3/14 Sri Gundavelli <sgundave@cisco.com>: >> Julien: >>=20 >> Agree. I did put that note below that we should add any additional cases= . >> The text around handling link-specific multicast traffic with different >> destination scopes covers most of the common multicast cases, ALL-NODES, >> SOLICTED-NODE... We can add any missing cases and resolve it. Any specif= ic >> case you are thinking about ? We can generalize the case and make it app= ly >> for ND and non-ND cases. >>=20 >>=20 >>=20 >> Regards >> Sri >>=20 >>=20 >>=20 >>=20 >> On 3/14/11 5:25 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: >>=20 >>> Sri - >>>=20 >>> Multicast traffic isn' t limited to ND, thus I don' t think it is >>> appropriate to consider this issue as closed because you crafter some >>> text on ND considerations elsewhere in this document. Please clarify >>> how tranmission on multicast traffic is handled over a logical >>> interface. >>>=20 >>> --julien >>>=20 >>> On Mon, Mar 14, 2011 at 4:27 PM, Sri Gundavelli <sgundave@cisco.com> wr= ote: >>>>> #5: Logical interface support: Multicast traffic >>>>=20 >>>> =A0Clarify how the logical >>>>> interface deals with multicast traffic. >>>>=20 >>>>=20 >>>> We believe we have resolve this issue, this is captured in the ND >>>> interactions section. The general considerations around dealing with >>>> link-specific multicast traffic, all-nodes, solicited node multicast >>>> traffic, or others have common considerations. It is possible we might= be >>>> missing few cases, we can add that in, but the base handling of things= at >>>> the logical interface level, or sub-interface level is captured. Comme= nts >>>> welcome. >>>>=20 >>>>=20 >>>> Sri >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 3/3/11 9:19 AM, "netext issue tracker" <trac+netext@trac.tools.ietf= .org> >>>> wrote: >>>>=20 >>>>> #5: Logical interface support: Multicast traffic >>>>=20 >>>> =A0Clarify how the logical >>>>> interface deals with multicast traffic. >>>>=20 >>>> -- >>>>>=20 >>>>=20 ---------------------------------------+-----------------------------------= >>>> - >>>>=20 >>>>> Reporter: =A0basavaraj.patil@=A9 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Owner: =A0telemaco.melia@= =A9 >>>>>=20 >>>> =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status: =A0new >>>>>=20 >>>> =A0Priority: =A0critical =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone: >>>>>=20 >>>> Component: =A0logical-interface-support =A0| =A0 =A0 Version: >>>>>=20 >>>> =A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0Keywords: >>>>>=20 >>>>=20 ---------------------------------------+-----------------------------------= >>>> - >>>>=20 >>>>>=20 >>>> Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/5> >>>> netext >>>>> <http://tools.ietf.org/netext/> >>>>=20 >>>> _____________________________________________ >>>>> __ >>>> netext mailing >>>>> list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>>=20 >>=20 >>=20 From sgundave@cisco.com Mon Mar 14 19:00:48 2011 Return-Path: <sgundave@cisco.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 335C73A6A3A for <netext@core3.amsl.com>; Mon, 14 Mar 2011 19:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.462 X-Spam-Level: X-Spam-Status: No, score=-9.462 tagged_above=-999 required=5 tests=[AWL=-0.259, 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 M6KNBVCbWtea for <netext@core3.amsl.com>; Mon, 14 Mar 2011 19:00:46 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 55EA53A68AB for <netext@ietf.org>; Mon, 14 Mar 2011 19:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=5118; q=dns/txt; s=iport; t=1300154531; x=1301364131; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=uVwLFcmj22SiBOibl3KcKVyNhOGZxYye3VhXyE7Twog=; b=bNkbQ407sdU8ONXKg0rJydNT4vy+27tsHFtR7MqQfWSMSjX24yDqDWFK f4cDkUas9PK9lVNGPGJ8cbraPziHc3shwyIMwK541yrnLxMneGMd7OXWp f3G7Djx8s3lRLBThI45D7WN7zpFzuqoiuK73Y1EKi3C6Fh/tdjmn/+2pI o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHZlfk2tJV2c/2dsb2JhbAClO1N3pXScUYViBIUrhyeDVIMc X-IronPort-AV: E=Sophos;i="4.62,319,1297036800"; d="scan'208";a="225229201" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 15 Mar 2011 02:02:09 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2F229F5009037; Tue, 15 Mar 2011 02:02:09 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, 14 Mar 2011 19:02:09 -0700 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, 15 Mar 2011 02:02:08 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Mon, 14 Mar 2011 19:03:54 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: Julien Laganier <julien.ietf@gmail.com> Message-ID: <C9A4171A.13628%sgundave@cisco.com> Thread-Topic: [netext] #4: Logical interface support: Point to point links Thread-Index: AcvitTxenbMujdRwpUe3xtq+9Nb7nQ== In-Reply-To: <AANLkTin_ZbJmkbS3d2U0RGcSp4nCFD0H_VjeUQzQdB6H@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-2" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 15 Mar 2011 02:02:09.0269 (UTC) FILETIME=[FDF23250:01CBE2B4] Cc: netext@ietf.org Subject: Re: [netext] #4: Logical interface support: Point to point links X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Mar 2011 02:00:48 -0000 Julien: Lets see, what is the violation here ? - We are stating the logical interface appears to the applications as an interface attached to a shared link. For the simple reason, that we have multiple neighbors on different network segments attached through different sub-interface of that logical interface. We don't have a single neighbor/MAG.=20 - "Underneath the logical interface ...", there are sub-interfaces which ma= y be very well attached to different p2p links. As long as the network has th= e semantics to send a RA with PIO, exclusively to this node, no other node on that access link can receive that Prefix set, we are confirming to 5213 lin= k model. From any of the MAG's perspective, attached to any of the access links, it can still be kept as a p2p link - Exposing the logical interface as a shared link to the applications on th= e *mobile node*, is not violating 5213 principles. The path chosen for a packet through a sub-interface can be still a p2p link and the rules of link-layer resolution of the peer, or adding l2 headers skipping l2 resolution, is still the approach in use. Sri On 3/14/11 5:20 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: > Sri - >=20 > 5213 supports only PtP links thus I do not understand how the > following resolution resolves anything. Please clarify what is the > issue you' re addressing and how this is addressing it. >=20 > --julien >=20 > On Mon, Mar 14, 2011 at 4:24 PM, Sri Gundavelli <sgundave@cisco.com> wrot= e: >>> #4: Logical interface support: Point to point links >>=20 >> =A0Clarify the use and >>> behavior of the logical interface on PtP links. >>=20 >>=20 >> Folks: Again, reflecting the team's contributions on this topic, the aut= hors >> of this document have discussed this and resolve it with the following t= ext. >> The key points we tried to reflect are around that the logical interface >> appears to the application as a shared link. There were thoughts around >> making it appear like a p2p link, given that there are multiple neighbor= s on >> each sub interface, this choice appears reasonable. With respect to how = a >> packet is transmitted, is still based on the chosen link model at each s= ub >> interface level. Let us know, if you see any issues with it. This is pro= ven >> based on the multiple implementations from some of the co-authors of thi= s >> doc. >>=20 >>=20 >>=20 >>=20 >> --- >> 6.3. =A0Supported Link models for a logical interface >>=20 >> =A0The sub-interfaces of a logical interface can be bound to a point-to- >> =A0 point or a shared link (Example: LTE and WLAN). =A0The logical >> =A0 interface appears as a shared-link to the applications, and adapts to >> =A0 the link model of the sub-interface for packet communication. =A0For >> =A0 example, when transmitting a packet on a sub-interface which is >> =A0 attached to a p2p link, the transmission conforms to the p2p link >> =A0 model and when transmitting on a sub-interface attached to a shared >> =A0 link, the transmission conforms to the shared link model. >>=20 >> =A0 Based on the link to which the sub-interface is attached to, the >> =A0 layer-2 resolutions may or may not be needed. =A0If the interface is >> =A0 bound to a P2P link with PPP running, there will not be any link- >> =A0 layer resolutions in the form of ARP/ND messages. =A0However, if the >> =A0 interface is bound to a shared link such as Ethernet, there will be >> =A0 ND resolutions. =A0The logical interface implementation has to maintain >> =A0 the required link model and the associated state for each sub- >> =A0 interface. >> -- >>=20 >>=20 >>=20 >>=20 >> On 3/3/11 9:17 AM, "netext issue tracker" <trac+netext@trac.tools.ietf.o= rg> >> wrote: >>=20 >>> #4: Logical interface support: Point to point links >>=20 >> =A0Clarify the use and >>> behavior of the logical interface on PtP links. >>=20 >> -- >>>=20 >> ---------------------------------------+--------------------------------= ---- >>=20 >>> Reporter: =A0basavaraj.patil@=A9 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Owner: =A0telemaco.melia@=A9 >>>=20 >> =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status: =A0new >>>=20 >> =A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 Milestone: >>>=20 >> Component: =A0logical-interface-support =A0| =A0 =A0 Version: >>>=20 >> =A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0Keywords: >>>=20 >> ---------------------------------------+--------------------------------= ---- >>=20 >>>=20 >> Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/4> >> netext >>> <http://tools.ietf.org/netext/> >>=20 >> _____________________________________________ >>> __ >> netext mailing >>> list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >>=20 >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >>=20 From damjan.damic@siemens.com Tue Mar 15 02:15:36 2011 Return-Path: <damjan.damic@siemens.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BA8B3A693D for <netext@core3.amsl.com>; Tue, 15 Mar 2011 02:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 EvX-a-ThPj5e for <netext@core3.amsl.com>; Tue, 15 Mar 2011 02:15:35 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by core3.amsl.com (Postfix) with ESMTP id 818803A6ADD for <netext@ietf.org>; Tue, 15 Mar 2011 02:15:34 -0700 (PDT) Received: from mail2.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.13.6/8.13.6) with ESMTP id p2F9GwbD020510 for <netext@ietf.org>; Tue, 15 Mar 2011 10:16:58 +0100 Received: from nets138a.ww300.siemens.net (nets138a.ww300.siemens.net [158.226.250.81]) by mail2.siemens.de (8.13.6/8.13.6) with ESMTP id p2F9GvKS030298 for <netext@ietf.org>; Tue, 15 Mar 2011 10:16:58 +0100 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Mar 2011 10:16:57 +0100 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: Tue, 15 Mar 2011 10:16:56 +0100 Message-ID: <3C31CDD06342EA4A8137716247B1CD68073E014B@zagh223a.ww300.siemens.net> In-Reply-To: <mailman.38.1300129216.16375.netext@ietf.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Soliciting support for the draft-ietf-netext-radius-pmip6-02.txt Thread-Index: Acvien9z6LGMEPRPToKKm5uDlE82cQAdIlDA References: <mailman.38.1300129216.16375.netext@ietf.org> From: "Damic, Damjan" <damjan.damic@siemens.com> To: <netext@ietf.org> X-OriginalArrivalTime: 15 Mar 2011 09:16:57.0676 (UTC) FILETIME=[BBD930C0:01CBE2F1] Subject: [netext] Soliciting support for the draft-ietf-netext-radius-pmip6-02.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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Mar 2011 09:15:36 -0000 Hello netext community, We have posted a new revision of the WG I-D: http://www.ietf.org/internet-drafts/draft-ietf-netext-radius-pmip6-02.tx t This document focuses on signaling and attributes needed to facilitate Proxy Mobile IPv6 operations with the RADIUS AAA infrastructure. For those interested... We kindly ask to dedicate some time to this document, if not done so far, and provide feedback before or at the upcoming IETF meeting. We hope to get sufficient WG support to move this item forward immediately past the Prague Meeting. Thank you, Damjan, on behalf of the author group From pierrick.seite@orange-ftgroup.com Tue Mar 15 02:19:52 2011 Return-Path: <pierrick.seite@orange-ftgroup.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A11613A6C1A for <netext@core3.amsl.com>; Tue, 15 Mar 2011 02:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.946 X-Spam-Level: X-Spam-Status: No, score=-2.946 tagged_above=-999 required=5 tests=[AWL=0.303, 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 a9Jmal3957-X for <netext@core3.amsl.com>; Tue, 15 Mar 2011 02:19:51 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id B488C3A6BDA for <netext@ietf.org>; Tue, 15 Mar 2011 02:19:50 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 121878B8002; Tue, 15 Mar 2011 10:21:44 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 073C58B8001; Tue, 15 Mar 2011 10:21:44 +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 Mar 2011 10:21:15 +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 Mar 2011 10:21:13 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C4620190B524@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <C9A4171A.13628%sgundave@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] #4: Logical interface support: Point to point links Thread-Index: AcvitTxenbMujdRwpUe3xtq+9Nb7nQAOp6rw References: <AANLkTin_ZbJmkbS3d2U0RGcSp4nCFD0H_VjeUQzQdB6H@mail.gmail.com> <C9A4171A.13628%sgundave@cisco.com> From: <pierrick.seite@orange-ftgroup.com> To: <sgundave@cisco.com>, <julien.ietf@gmail.com> X-OriginalArrivalTime: 15 Mar 2011 09:21:15.0128 (UTC) FILETIME=[554D3F80:01CBE2F2] Cc: netext@ietf.org Subject: Re: [netext] #4: Logical interface support: Point to point links X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Mar 2011 09:19:52 -0000 DQpIaSBTcmksDQoNCklmIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHksIHRoZXJlIGlzIG5vIHZpb2xh dGlvbiBvZiBSRkM1MjEzIGlmIGFsbCBwaHlzaWNhbCBsaW5rcyBhcmUgcDJwLiBIb3dldmVyIHRo ZSBwcm9wb3NlZCB0ZXh0IGFsbG93cyB0aGUgdmlydHVhbCBpbnRlcmZhY2UgdG8gYm91bmQgcGh5 c2ljYWwgc2hhcmVkIGxpbmtzLiBJZiBzbywgSSB0aGluayB3ZSBtYXkgaGF2ZSB0aGUgaXNzdWUg ZGVzY3JpYmVkIGluIHNlY3Rpb24gNC4yIG9mIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtbmV0bG1tLW1uLWFyLWlmLTAzLiBNYXliZSwgdGhlIHRleHQgc2hvdWxkIGJlIGNs YXJpZmllZCB0byByZXN0cmljdCB0byBwaHlzaWNhbCBwMnAgbGlua3MuICANCg0KQlIsDQpQaWVy cmljayANCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogbmV0ZXh0LWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuZXRleHQtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFy dA0KPiBkZSBTcmkgR3VuZGF2ZWxsaQ0KPiBFbnZvecOpwqA6IG1hcmRpIDE1IG1hcnMgMjAxMSAw NDowNA0KPiDDgMKgOiBKdWxpZW4gTGFnYW5pZXINCj4gQ2PCoDogbmV0ZXh0QGlldGYub3JnDQo+ IE9iamV0wqA6IFJlOiBbbmV0ZXh0XSAjNDogTG9naWNhbCBpbnRlcmZhY2Ugc3VwcG9ydDogUG9p bnQgdG8gcG9pbnQgbGlua3MNCj4gDQo+IEp1bGllbjoNCj4gDQo+IExldHMgc2VlLCB3aGF0IGlz IHRoZSB2aW9sYXRpb24gaGVyZSA/DQo+IA0KPiAtIFdlIGFyZSBzdGF0aW5nIHRoZSBsb2dpY2Fs IGludGVyZmFjZSBhcHBlYXJzIHRvIHRoZSBhcHBsaWNhdGlvbnMgYXMgYW4NCj4gaW50ZXJmYWNl IGF0dGFjaGVkIHRvIGEgc2hhcmVkIGxpbmsuIEZvciB0aGUgc2ltcGxlIHJlYXNvbiwgdGhhdCB3 ZSBoYXZlDQo+IG11bHRpcGxlIG5laWdoYm9ycyBvbiBkaWZmZXJlbnQgbmV0d29yayBzZWdtZW50 cyBhdHRhY2hlZCB0aHJvdWdoDQo+IGRpZmZlcmVudA0KPiBzdWItaW50ZXJmYWNlIG9mIHRoYXQg bG9naWNhbCBpbnRlcmZhY2UuIFdlIGRvbid0IGhhdmUgYSBzaW5nbGUNCj4gbmVpZ2hib3IvTUFH Lg0KPiANCj4gLSAiVW5kZXJuZWF0aCB0aGUgbG9naWNhbCBpbnRlcmZhY2UgLi4uIiwgdGhlcmUg YXJlIHN1Yi1pbnRlcmZhY2VzIHdoaWNoDQo+IG1heQ0KPiBiZSB2ZXJ5IHdlbGwgYXR0YWNoZWQg dG8gZGlmZmVyZW50IHAycCBsaW5rcy4gQXMgbG9uZyBhcyB0aGUgbmV0d29yayBoYXMNCj4gdGhl DQo+IHNlbWFudGljcyB0byBzZW5kIGEgUkEgd2l0aCBQSU8sIGV4Y2x1c2l2ZWx5IHRvIHRoaXMg bm9kZSwgbm8gb3RoZXIgbm9kZQ0KPiBvbg0KPiB0aGF0IGFjY2VzcyBsaW5rIGNhbiByZWNlaXZl IHRoYXQgUHJlZml4IHNldCwgd2UgYXJlIGNvbmZpcm1pbmcgdG8gNTIxMw0KPiBsaW5rDQo+IG1v ZGVsLiBGcm9tIGFueSBvZiB0aGUgTUFHJ3MgcGVyc3BlY3RpdmUsIGF0dGFjaGVkIHRvIGFueSBv ZiB0aGUgYWNjZXNzDQo+IGxpbmtzLCBpdCBjYW4gc3RpbGwgYmUga2VwdCBhcyBhIHAycCBsaW5r DQo+IA0KPiAtIEV4cG9zaW5nIHRoZSBsb2dpY2FsIGludGVyZmFjZSBhcyBhIHNoYXJlZCBsaW5r IHRvIHRoZSBhcHBsaWNhdGlvbnMgb24NCj4gdGhlDQo+ICptb2JpbGUgbm9kZSosIGlzIG5vdCB2 aW9sYXRpbmcgNTIxMyBwcmluY2lwbGVzLiBUaGUgcGF0aCBjaG9zZW4gZm9yIGENCj4gcGFja2V0 IHRocm91Z2ggYSBzdWItaW50ZXJmYWNlIGNhbiBiZSBzdGlsbCBhIHAycCBsaW5rIGFuZCB0aGUg cnVsZXMgb2YNCj4gbGluay1sYXllciByZXNvbHV0aW9uIG9mIHRoZSBwZWVyLCBvciBhZGRpbmcg bDIgaGVhZGVycyBza2lwcGluZyBsMg0KPiByZXNvbHV0aW9uLCBpcyBzdGlsbCB0aGUgYXBwcm9h Y2ggaW4gdXNlLg0KPiANCj4gDQo+IA0KPiANCj4gU3JpDQo+IA0KPiANCj4gDQo+IA0KPiANCj4g DQo+IA0KPiANCj4gT24gMy8xNC8xMSA1OjIwIFBNLCAiSnVsaWVuIExhZ2FuaWVyIiA8anVsaWVu LmlldGZAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+ID4gU3JpIC0NCj4gPg0KPiA+IDUyMTMgc3Vw cG9ydHMgb25seSBQdFAgbGlua3MgdGh1cyBJIGRvIG5vdCB1bmRlcnN0YW5kIGhvdyB0aGUNCj4g PiBmb2xsb3dpbmcgcmVzb2x1dGlvbiByZXNvbHZlcyBhbnl0aGluZy4gUGxlYXNlIGNsYXJpZnkg d2hhdCBpcyB0aGUNCj4gPiBpc3N1ZSB5b3UnIHJlIGFkZHJlc3NpbmcgYW5kIGhvdyB0aGlzIGlz IGFkZHJlc3NpbmcgaXQuDQo+ID4NCj4gPiAtLWp1bGllbg0KPiA+DQo+ID4gT24gTW9uLCBNYXIg MTQsIDIwMTEgYXQgNDoyNCBQTSwgU3JpIEd1bmRhdmVsbGkgPHNndW5kYXZlQGNpc2NvLmNvbT4N Cj4gd3JvdGU6DQo+ID4+PiAjNDogTG9naWNhbCBpbnRlcmZhY2Ugc3VwcG9ydDogUG9pbnQgdG8g cG9pbnQgbGlua3MNCj4gPj4NCj4gPj4gwqBDbGFyaWZ5IHRoZSB1c2UgYW5kDQo+ID4+PiBiZWhh dmlvciBvZiB0aGUgbG9naWNhbCBpbnRlcmZhY2Ugb24gUHRQIGxpbmtzLg0KPiA+Pg0KPiA+Pg0K PiA+PiBGb2xrczogQWdhaW4sIHJlZmxlY3RpbmcgdGhlIHRlYW0ncyBjb250cmlidXRpb25zIG9u IHRoaXMgdG9waWMsIHRoZQ0KPiBhdXRob3JzDQo+ID4+IG9mIHRoaXMgZG9jdW1lbnQgaGF2ZSBk aXNjdXNzZWQgdGhpcyBhbmQgcmVzb2x2ZSBpdCB3aXRoIHRoZSBmb2xsb3dpbmcNCj4gdGV4dC4N Cj4gPj4gVGhlIGtleSBwb2ludHMgd2UgdHJpZWQgdG8gcmVmbGVjdCBhcmUgYXJvdW5kIHRoYXQg dGhlIGxvZ2ljYWwNCj4gaW50ZXJmYWNlDQo+ID4+IGFwcGVhcnMgdG8gdGhlIGFwcGxpY2F0aW9u IGFzIGEgc2hhcmVkIGxpbmsuIFRoZXJlIHdlcmUgdGhvdWdodHMgYXJvdW5kDQo+ID4+IG1ha2lu ZyBpdCBhcHBlYXIgbGlrZSBhIHAycCBsaW5rLCBnaXZlbiB0aGF0IHRoZXJlIGFyZSBtdWx0aXBs ZQ0KPiBuZWlnaGJvcnMgb24NCj4gPj4gZWFjaCBzdWIgaW50ZXJmYWNlLCB0aGlzIGNob2ljZSBh cHBlYXJzIHJlYXNvbmFibGUuIFdpdGggcmVzcGVjdCB0byBob3cNCj4gYQ0KPiA+PiBwYWNrZXQg aXMgdHJhbnNtaXR0ZWQsIGlzIHN0aWxsIGJhc2VkIG9uIHRoZSBjaG9zZW4gbGluayBtb2RlbCBh dCBlYWNoDQo+IHN1Yg0KPiA+PiBpbnRlcmZhY2UgbGV2ZWwuIExldCB1cyBrbm93LCBpZiB5b3Ug c2VlIGFueSBpc3N1ZXMgd2l0aCBpdC4gVGhpcyBpcw0KPiBwcm92ZW4NCj4gPj4gYmFzZWQgb24g dGhlIG11bHRpcGxlIGltcGxlbWVudGF0aW9ucyBmcm9tIHNvbWUgb2YgdGhlIGNvLWF1dGhvcnMg b2YNCj4gdGhpcw0KPiA+PiBkb2MuDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IC0tLQ0K PiA+PiA2LjMuIMKgU3VwcG9ydGVkIExpbmsgbW9kZWxzIGZvciBhIGxvZ2ljYWwgaW50ZXJmYWNl DQo+ID4+DQo+ID4+IMKgVGhlIHN1Yi1pbnRlcmZhY2VzIG9mIGEgbG9naWNhbCBpbnRlcmZhY2Ug Y2FuIGJlIGJvdW5kIHRvIGEgcG9pbnQtdG8tDQo+ID4+IMKgIHBvaW50IG9yIGEgc2hhcmVkIGxp bmsgKEV4YW1wbGU6IExURSBhbmQgV0xBTikuIMKgVGhlIGxvZ2ljYWwNCj4gPj4gwqAgaW50ZXJm YWNlIGFwcGVhcnMgYXMgYSBzaGFyZWQtbGluayB0byB0aGUgYXBwbGljYXRpb25zLCBhbmQgYWRh cHRzIHRvDQo+ID4+IMKgIHRoZSBsaW5rIG1vZGVsIG9mIHRoZSBzdWItaW50ZXJmYWNlIGZvciBw YWNrZXQgY29tbXVuaWNhdGlvbi4gwqBGb3INCj4gPj4gwqAgZXhhbXBsZSwgd2hlbiB0cmFuc21p dHRpbmcgYSBwYWNrZXQgb24gYSBzdWItaW50ZXJmYWNlIHdoaWNoIGlzDQo+ID4+IMKgIGF0dGFj aGVkIHRvIGEgcDJwIGxpbmssIHRoZSB0cmFuc21pc3Npb24gY29uZm9ybXMgdG8gdGhlIHAycCBs aW5rDQo+ID4+IMKgIG1vZGVsIGFuZCB3aGVuIHRyYW5zbWl0dGluZyBvbiBhIHN1Yi1pbnRlcmZh Y2UgYXR0YWNoZWQgdG8gYSBzaGFyZWQNCj4gPj4gwqAgbGluaywgdGhlIHRyYW5zbWlzc2lvbiBj b25mb3JtcyB0byB0aGUgc2hhcmVkIGxpbmsgbW9kZWwuDQo+ID4+DQo+ID4+IMKgIEJhc2VkIG9u IHRoZSBsaW5rIHRvIHdoaWNoIHRoZSBzdWItaW50ZXJmYWNlIGlzIGF0dGFjaGVkIHRvLCB0aGUN Cj4gPj4gwqAgbGF5ZXItMiByZXNvbHV0aW9ucyBtYXkgb3IgbWF5IG5vdCBiZSBuZWVkZWQuIMKg SWYgdGhlIGludGVyZmFjZSBpcw0KPiA+PiDCoCBib3VuZCB0byBhIFAyUCBsaW5rIHdpdGggUFBQ IHJ1bm5pbmcsIHRoZXJlIHdpbGwgbm90IGJlIGFueSBsaW5rLQ0KPiA+PiDCoCBsYXllciByZXNv bHV0aW9ucyBpbiB0aGUgZm9ybSBvZiBBUlAvTkQgbWVzc2FnZXMuIMKgSG93ZXZlciwgaWYgdGhl DQo+ID4+IMKgIGludGVyZmFjZSBpcyBib3VuZCB0byBhIHNoYXJlZCBsaW5rIHN1Y2ggYXMgRXRo ZXJuZXQsIHRoZXJlIHdpbGwgYmUNCj4gPj4gwqAgTkQgcmVzb2x1dGlvbnMuIMKgVGhlIGxvZ2lj YWwgaW50ZXJmYWNlIGltcGxlbWVudGF0aW9uIGhhcyB0byBtYWludGFpbg0KPiA+PiDCoCB0aGUg cmVxdWlyZWQgbGluayBtb2RlbCBhbmQgdGhlIGFzc29jaWF0ZWQgc3RhdGUgZm9yIGVhY2ggc3Vi LQ0KPiA+PiDCoCBpbnRlcmZhY2UuDQo+ID4+IC0tDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ ID4+IE9uIDMvMy8xMSA5OjE3IEFNLCAibmV0ZXh0IGlzc3VlIHRyYWNrZXIiDQo+IDx0cmFjK25l dGV4dEB0cmFjLnRvb2xzLmlldGYub3JnPg0KPiA+PiB3cm90ZToNCj4gPj4NCj4gPj4+ICM0OiBM b2dpY2FsIGludGVyZmFjZSBzdXBwb3J0OiBQb2ludCB0byBwb2ludCBsaW5rcw0KPiA+Pg0KPiA+ PiDCoENsYXJpZnkgdGhlIHVzZSBhbmQNCj4gPj4+IGJlaGF2aW9yIG9mIHRoZSBsb2dpY2FsIGlu dGVyZmFjZSBvbiBQdFAgbGlua3MuDQo+ID4+DQo+ID4+IC0tDQo+ID4+Pg0KPiA+PiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiAtLS0tLQ0KPiA+Pg0KPiA+Pj4gUmVwb3J0ZXI6IMKgYmFzYXZhcmFqLnBhdGls QMWgIMKgIMKgIMKgIMKgIMKgfCDCoCDCoCDCoCBPd25lcjogwqB0ZWxlbWFjby5tZWxpYUDFoA0K PiA+Pj4NCj4gPj4gwqAgwqAgVHlwZTogwqBkZWZlY3QgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgfCDCoCDCoCDCoFN0YXR1czogwqBuZXcNCj4gPj4+DQo+ID4+IMKgUHJpb3JpdHk6IMKg bWFqb3IgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8IMKgIE1pbGVzdG9uZToNCj4g Pj4+DQo+ID4+IENvbXBvbmVudDogwqBsb2dpY2FsLWludGVyZmFjZS1zdXBwb3J0IMKgfCDCoCDC oCBWZXJzaW9uOg0KPiA+Pj4NCj4gPj4gwqBTZXZlcml0eTogwqAtIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgfCDCoCDCoEtleXdvcmRzOg0KPiA+Pj4NCj4gPj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gLS0tLS0NCj4gPj4NCj4gPj4+DQo+ID4+IFRpY2tldCBVUkw6IDxodHRwOi8v dHJhYy50b29scy5pZXRmLm9yZy93Zy9uZXRleHQvdHJhYy90aWNrZXQvND4NCj4gPj4gbmV0ZXh0 DQo+ID4+PiA8aHR0cDovL3Rvb2xzLmlldGYub3JnL25ldGV4dC8+DQo+ID4+DQo+ID4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4gX18NCj4gPj4g bmV0ZXh0IG1haWxpbmcNCj4gPj4+IGxpc3QNCj4gPj4gbmV0ZXh0QGlldGYub3JnDQo+ID4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0DQo+ID4+DQo+ID4+DQo+ ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ IG5ldGV4dCBtYWlsaW5nIGxpc3QNCj4gPj4gbmV0ZXh0QGlldGYub3JnDQo+ID4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0DQo+ID4+DQo+IA0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRleHQgbWFpbGlu ZyBsaXN0DQo+IG5ldGV4dEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldGV4dA0K From telemaco.melia@alcatel-lucent.com Tue Mar 15 02:54:09 2011 Return-Path: <telemaco.melia@alcatel-lucent.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BF143A6B9F for <netext@core3.amsl.com>; Tue, 15 Mar 2011 02:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.707 X-Spam-Level: X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[AWL=0.542, 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 2Q4j1Zk+oXt4 for <netext@core3.amsl.com>; Tue, 15 Mar 2011 02:54:08 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 431143A69E3 for <netext@ietf.org>; Tue, 15 Mar 2011 02:54:08 -0700 (PDT) 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 p2F9gL5S020137 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 15 Mar 2011 10:55:27 +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, 15 Mar 2011 10:54:48 +0100 From: "MELIA, TELEMACO (TELEMACO)" <telemaco.melia@alcatel-lucent.com> To: Sri Gundavelli <sgundave@cisco.com>, Julien Laganier <julien.ietf@gmail.com>, "netext@ietf.org" <netext@ietf.org> Date: Tue, 15 Mar 2011 10:54:48 +0100 Thread-Topic: [netext] I-D Action:draft-ietf-netext-logical-interface-support-02.txt Thread-Index: AcvinL6OqIYXUbvBZ0mp9aoJ18c5oQAWgZGA Message-ID: <3D6C64F2D792B540BAAEBCEF6509363B0EE6E5A41D@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> References: <AANLkTinRUGJodg5JJuZ=8YQOEG4YuAXeqzwRTJ1JG8MP@mail.gmail.com> <C9A3EE03.135D4%sgundave@cisco.com> In-Reply-To: <C9A3EE03.135D4%sgundave@cisco.com> 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.80 Subject: Re: [netext] I-D Action:draft-ietf-netext-logical-interface-support-02.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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Mar 2011 09:54:09 -0000 Julien,=20 As Sri commented below this is the basis we would like to use for discussio= ns. We submitted a revised version to keep track of the changes. telemaco=20 -----Message d'origine----- De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part de= Sri Gundavelli Envoy=E9 : mardi 15 mars 2011 01:09 =C0 : Julien Laganier; netext@ietf.org Objet : Re: [netext] I-D Action:draft-ietf-netext-logical-interface-support= -02.txt Hi Julien: We were hoping to post the text before, but we could not as we did not have= the text till late. Any ways, we can use it as a starting point text for t= he discussions. We can update the text as needed. If you can please review = and comment that will be great. Regards Sri On 3/14/11 2:58 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: > I am surprised that this document was revised without any mailing=20 > discussions of the changes that were carried on... >=20 > --julien >=20 > On Mon, Mar 14, 2011 at 2:45 PM, <Internet-Drafts@ietf.org> wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts=20 >> directories. >> This draft is a work item of the Network-Based Mobility Extensions=20 >> Working Group of the IETF. >>=20 >>=20 >> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Logical Interface Support for= multi-mode IP=20 >> Hosts >> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : T. Melia, S. Gundavelli >> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0:=20 >> draft-ietf-netext-logical-interface-support-02.txt >> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 26 >> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-03-14 >>=20 >> A Logical Interface is a software semantic internal to the host=20 >> operating system. =A0This semantic is available in all popular=20 >> operating systems and is used in various protocol implementations. >> The Logical Interface support is required on the mobile node=20 >> operating in a Proxy Mobile IPv6 domain, for leveraging various=20 >> network-based mobility management features such as inter-technology=20 >> handoffs, multihoming and flow mobility support. =A0This document=20 >> explains the operational details of Logical Interface construct and=20 >> the specifics on how the link-layer implementations hide the physical=20 >> interfaces from the IP stack and from the network nodes on the=20 >> attached access networks. =A0Furthermore, this document identifies the=20 >> applicability of this approach to various link-layer technologies and=20 >> analyzes the issues around it when used in context with various=20 >> mobility management features. >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-netext-logical-interfa >> ce-suppo >> rt-02.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> Below is the data which will enable a MIME compliant mail reader=20 >> implementation to automatically retrieve the ASCII version of the=20 >> Internet-Draft. >>=20 >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >>=20 >>=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From damjan.damic@siemens.com Tue Mar 15 02:59:36 2011 Return-Path: <damjan.damic@siemens.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15EB83A6C99 for <netext@core3.amsl.com>; Tue, 15 Mar 2011 02:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 YWQ-jThLX3uR for <netext@core3.amsl.com>; Tue, 15 Mar 2011 02:59:35 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id A810A3A6C42 for <netext@ietf.org>; Tue, 15 Mar 2011 02:59:34 -0700 (PDT) Received: from mail3.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.13.6/8.13.6) with ESMTP id p2FA0wBL013288; Tue, 15 Mar 2011 11:00:58 +0100 Received: from nets139a.ww300.siemens.net (nets139a.ww300.siemens.net [158.226.250.82]) by mail3.siemens.de (8.13.6/8.13.6) with ESMTP id p2FA0sRj031443; Tue, 15 Mar 2011 11:00:57 +0100 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Mar 2011 11:00:56 +0100 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: Tue, 15 Mar 2011 11:00:53 +0100 Message-ID: <3C31CDD06342EA4A8137716247B1CD68073E0206@zagh223a.ww300.siemens.net> In-Reply-To: <mailman.1.1293998406.4778.netext@ietf.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Review of draft-ietf-netext-radius-pmip6-01 Thread-Index: Acuqt/ZTGDkyE03QQZ+yNvlzDUkY+AjBjjAw References: <mailman.1.1293998406.4778.netext@ietf.org> From: "Damic, Damjan" <damjan.damic@siemens.com> To: <gwz@net-zen.net> X-OriginalArrivalTime: 15 Mar 2011 10:00:56.0047 (UTC) FILETIME=[E070A7F0:01CBE2F7] Cc: netext@ietf.org Subject: Re: [netext] Review of draft-ietf-netext-radius-pmip6-01 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Mar 2011 09:59:36 -0000 Hello Glen, Please accept sincere appologies for a long, long overdue response, but this work was on hold for a while. A new I-D revision has just been published, and your valuable comments have been taken into account. - Please mark this I-D is the RADIUS counterpart and a follow-up of the RFC5779 that deals with Diameter support for PMIPv6. The AAA concept and fundamentals are pretty much inherited or slightly redefined for the RADIUS use case. - Terminology issues, grammar nits and other consistency flaws are hopefully corrected. Everything however spins around the mobility protocol Proxy Mobile IPv6 and we have to retain this focus including use of the rather explicit jargon. - A point was raised on suspected ambiguity in the functional split definitions. Some real world deployments that actually drive this publication do allow such variations in the architecture. We are trying not to rule them out by this general purpose I-D write up. - Remark to the scope is valid. Obviously the aim is to provide more then just attribute listing, and I agree there may be room for further improvements. Thank you. Damjan -----Original Message----- Date: Sun, 2 Jan 2011 13:08:09 +0700 From: "Glen Zorn" <gwz@net-zen.net> Subject: [netext] Review of draft-ietf-netext-radius-pmip6-01 To: <netext@ietf.org> Message-ID: <000001cbaa43$705b1820$51114860$@net> Content-Type: text/plain; charset=3D"us-ascii" There are many grammatical errors. For example, in the very first sentence of section 1 Proxy Mobile IPv6 (PMIPv6) [RFC5213] is network based mobility management protocol which allows IP mobility session continuity for a Mobile Node (MN) without its involvement in mobility management signaling. =20 This should read something like Proxy Mobile IPv6 (PMIPv6) [RFC5213] is a network-based mobility management protocol which allows IP mobility session continuity for a Mobile Node (MN) without its involvement in mobility management signaling. =20 However, this still reads pretty clumsily; in particular, it's difficult for me to tell which entity "its" refers to and the usage of "network-based" is jargon that only has meaning if one is already familiar with PMIP; since this draft is presumably aimed at RADIUS implanters, I think it would be good to avoid as much PMIP-specific jargon as possible. Similarly, the terms "download" and "interface" are used repeatedly. "Download" has AFAIK no meaning WRT to RADIUS and "interface", while "real 3G" is also not particularly useful in this context. For example, Section 1 says: This document defines the RADIUS [RFC2865] based profile and the corresponding attributes to be used on the AAA interface between the MAG and the RADIUS server. This interface is used to download the per MN Policy Profile from the remote Policy Store to the MAG, at the point when MN attaches to a PMIPv6 Domain.=20 I suspect that what this means that the per-MN profile is returned in a RADIUS Access-Accept message encapsulated in the Attributes defined by this draft (and I shouldn't need to guess). The same section continues: Furthermore, this document also defines a RADIUS-based interface between the LMA and=20 the RADIUS server for authorization of the received Proxy Binding Update (PBU) messages for the mobility service session. =20 Actually, it doesn't: some Attributes are defined, but how they are used is left almost completely unspecified. The statement that "The terminology in this document is based on the definitions found in [RFC5213] and [I-D.ietf-netlmm-pmip6-ipv4-support]" in Section 2 strongly suggests that the reader must have read and understood draft-ietf-netlmm-pmip6-ipv4-support and that, therefore, that draft would be a normative reference but it's not. In Section 2, the definition of "Network Access Server (NAS)" says A device that provides the access service for a user to a network. In the context of this document the NAS may be integrated into or co-located with the MAG. The NAS device contains the RADIUS Client function. What happens in the context of this document if the NAS is _not_ integrated or co-located with the MAG? Since the statement is that the NAS "contains the RADIUS Client (sic) functionality", my guess is nothing ;-). Similarly, even if the MAG and NAS are co-located, unless they communicate nothing will happen. Furthermore, Section 3 says that the MAG 'acts as a NAS', which seems more accurate but isn't the same as 'integrated with' or 'co-located with'. I _think_ that what is really meant is that the MAG acts as a RADIUS client, but it's really hard to tell... I could go on at (much) greater length, but basically this draft either a) says too much (i.e., claims to provide a "solution" while just doing a lot of hand-waving) or b) says way too little for the same reason. My suggestion would be to either a) get rid of the "solution" stuff and _only_ define the needed Attributes or b) actually describe how these Attributes are to be used in detail. From telemaco.melia@alcatel-lucent.com Tue Mar 15 03:03:28 2011 Return-Path: <telemaco.melia@alcatel-lucent.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FF523A6C42 for <netext@core3.amsl.com>; Tue, 15 Mar 2011 03:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.784 X-Spam-Level: X-Spam-Status: No, score=-5.784 tagged_above=-999 required=5 tests=[AWL=0.465, 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 jEjrnPxk4uYC for <netext@core3.amsl.com>; Tue, 15 Mar 2011 03:03:27 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 229AC3A69E3 for <netext@ietf.org>; Tue, 15 Mar 2011 03:03:26 -0700 (PDT) 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 p2FA2qO4002560 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 15 Mar 2011 11:04: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; Tue, 15 Mar 2011 11:04:43 +0100 From: "MELIA, TELEMACO (TELEMACO)" <telemaco.melia@alcatel-lucent.com> To: Sri Gundavelli <sgundave@cisco.com>, Julien Laganier <julien.ietf@gmail.com> Date: Tue, 15 Mar 2011 11:04:41 +0100 Thread-Topic: [netext] #5: Logical interface support: Multicast traffic Thread-Index: AcvitL1pk/SlWp5N1kqZTFBp+1zpPQAQ3dzg Message-ID: <3D6C64F2D792B540BAAEBCEF6509363B0EE6E5A424@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> References: <AANLkTim4aeCmtWgdXvMFTu=mJC9HmEoZTnYhJBE8Tj7L@mail.gmail.com> <C9A41645.13626%sgundave@cisco.com> In-Reply-To: <C9A41645.13626%sgundave@cisco.com> 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" <netext@ietf.org> Subject: Re: [netext] #5: Logical interface support: Multicast traffic X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Mar 2011 10:03:28 -0000 SnVsaWVuLCBpcyB0aGUgcXVlc3Rpb24gYWJvdXQgZ2xvYmFsIG11bHRpY2FzdCB0cmFmZmljPw0K DQp0ZWxlbWFjbyANCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZSA6IG5ldGV4dC1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86bmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBh cnQgZGUgU3JpIEd1bmRhdmVsbGkNCkVudm95w6kgOiBtYXJkaSAxNSBtYXJzIDIwMTEgMDQ6MDAN CsOAIDogSnVsaWVuIExhZ2FuaWVyDQpDYyA6IG5ldGV4dEBpZXRmLm9yZw0KT2JqZXQgOiBSZTog W25ldGV4dF0gIzU6IExvZ2ljYWwgaW50ZXJmYWNlIHN1cHBvcnQ6IE11bHRpY2FzdCB0cmFmZmlj DQoNCklmIHlvdSBjYW4gZGVmaW5lIHRoZSBkZXN0aW5hdGlvbiBzY29wZSwgbGluay1zcGVjaWZp YyBub24tbGluay1zcGVjaWZpYyA/DQpXZSBoYXZlIGNvdmVyZWQgbGluay1zcGVjaWZpYyBjYXNl cyBpbiB0aGUgTkQgY29udGV4dCAod2hpY2ggY2FuIGJlIGdlbmVyYWxpemVkKSwgbm9uLWxpbmsg c3BlY2lmaWMgPyBNYXkgYmUgaWYgeW91IGNhbiByZWZsZWN0IHRoZSBpc3N1ZSB0aGF0IHlvdSBh cmUgdGhpbmtpbmcsIHRoYXQgd2lsbCBoZWxwIHJlc29sdmUgdGhlIGlzc3VlLg0KDQoNCg0KU3Jp DQoNCg0KDQoNCg0KDQpPbiAzLzE0LzExIDU6NTIgUE0sICJKdWxpZW4gTGFnYW5pZXIiIDxqdWxp ZW4uaWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KDQo+IFRoZSBjYXNlIEkgaGF2ZSBpbiBtaW5kIGlz OiBJUCBzdGFjayB3YW50cyB0byBzZW5kIGEgcGFja2V0IHRvIA0KPiBtdWx0aWNhc3QgYWRkcmVz cyBNOyAgSG93IGlzIGl0IHRyYW5zbWl0dGVkPw0KPiANCj4gLS1qdWxpZW4NCj4gDQo+IDIwMTEv My8xNCBTcmkgR3VuZGF2ZWxsaSA8c2d1bmRhdmVAY2lzY28uY29tPjoNCj4+IEp1bGllbjoNCj4+ IA0KPj4gQWdyZWUuIEkgZGlkIHB1dCB0aGF0IG5vdGUgYmVsb3cgdGhhdCB3ZSBzaG91bGQgYWRk IGFueSBhZGRpdGlvbmFsIGNhc2VzLg0KPj4gVGhlIHRleHQgYXJvdW5kIGhhbmRsaW5nIGxpbmst c3BlY2lmaWMgbXVsdGljYXN0IHRyYWZmaWMgd2l0aCANCj4+IGRpZmZlcmVudCBkZXN0aW5hdGlv biBzY29wZXMgY292ZXJzIG1vc3Qgb2YgdGhlIGNvbW1vbiBtdWx0aWNhc3QgDQo+PiBjYXNlcywg QUxMLU5PREVTLCBTT0xJQ1RFRC1OT0RFLi4uIFdlIGNhbiBhZGQgYW55IG1pc3NpbmcgY2FzZXMg YW5kIA0KPj4gcmVzb2x2ZSBpdC4gQW55IHNwZWNpZmljIGNhc2UgeW91IGFyZSB0aGlua2luZyBh Ym91dCA/IFdlIGNhbiANCj4+IGdlbmVyYWxpemUgdGhlIGNhc2UgYW5kIG1ha2UgaXQgYXBwbHkg Zm9yIE5EIGFuZCBub24tTkQgY2FzZXMuDQo+PiANCj4+IA0KPj4gDQo+PiBSZWdhcmRzDQo+PiBT cmkNCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gT24gMy8xNC8xMSA1OjI1IFBNLCAiSnVsaWVuIExh Z2FuaWVyIiA8anVsaWVuLmlldGZAZ21haWwuY29tPiB3cm90ZToNCj4+IA0KPj4+IFNyaSAtDQo+ Pj4gDQo+Pj4gTXVsdGljYXN0IHRyYWZmaWMgaXNuJyB0IGxpbWl0ZWQgdG8gTkQsIHRodXMgSSBk b24nIHQgdGhpbmsgaXQgaXMgDQo+Pj4gYXBwcm9wcmlhdGUgdG8gY29uc2lkZXIgdGhpcyBpc3N1 ZSBhcyBjbG9zZWQgYmVjYXVzZSB5b3UgY3JhZnRlciANCj4+PiBzb21lIHRleHQgb24gTkQgY29u c2lkZXJhdGlvbnMgZWxzZXdoZXJlIGluIHRoaXMgZG9jdW1lbnQuIFBsZWFzZSANCj4+PiBjbGFy aWZ5IGhvdyB0cmFubWlzc2lvbiBvbiBtdWx0aWNhc3QgdHJhZmZpYyBpcyBoYW5kbGVkIG92ZXIg YSANCj4+PiBsb2dpY2FsIGludGVyZmFjZS4NCj4+PiANCj4+PiAtLWp1bGllbg0KPj4+IA0KPj4+ IE9uIE1vbiwgTWFyIDE0LCAyMDExIGF0IDQ6MjcgUE0sIFNyaSBHdW5kYXZlbGxpIDxzZ3VuZGF2 ZUBjaXNjby5jb20+IHdyb3RlOg0KPj4+Pj4gIzU6IExvZ2ljYWwgaW50ZXJmYWNlIHN1cHBvcnQ6 IE11bHRpY2FzdCB0cmFmZmljDQo+Pj4+IA0KPj4+PiDCoENsYXJpZnkgaG93IHRoZSBsb2dpY2Fs DQo+Pj4+PiBpbnRlcmZhY2UgZGVhbHMgd2l0aCBtdWx0aWNhc3QgdHJhZmZpYy4NCj4+Pj4gDQo+ Pj4+IA0KPj4+PiBXZSBiZWxpZXZlIHdlIGhhdmUgcmVzb2x2ZSB0aGlzIGlzc3VlLCB0aGlzIGlz IGNhcHR1cmVkIGluIHRoZSBORCANCj4+Pj4gaW50ZXJhY3Rpb25zIHNlY3Rpb24uIFRoZSBnZW5l cmFsIGNvbnNpZGVyYXRpb25zIGFyb3VuZCBkZWFsaW5nIA0KPj4+PiB3aXRoIGxpbmstc3BlY2lm aWMgbXVsdGljYXN0IHRyYWZmaWMsIGFsbC1ub2Rlcywgc29saWNpdGVkIG5vZGUgDQo+Pj4+IG11 bHRpY2FzdCB0cmFmZmljLCBvciBvdGhlcnMgaGF2ZSBjb21tb24gY29uc2lkZXJhdGlvbnMuIEl0 IGlzIA0KPj4+PiBwb3NzaWJsZSB3ZSBtaWdodCBiZSBtaXNzaW5nIGZldyBjYXNlcywgd2UgY2Fu IGFkZCB0aGF0IGluLCBidXQgdGhlIA0KPj4+PiBiYXNlIGhhbmRsaW5nIG9mIHRoaW5ncyBhdCB0 aGUgbG9naWNhbCBpbnRlcmZhY2UgbGV2ZWwsIG9yIA0KPj4+PiBzdWItaW50ZXJmYWNlIGxldmVs IGlzIGNhcHR1cmVkLiBDb21tZW50cyB3ZWxjb21lLg0KPj4+PiANCj4+Pj4gDQo+Pj4+IFNyaQ0K Pj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IE9uIDMvMy8xMSA5OjE5IEFN LCAibmV0ZXh0IGlzc3VlIHRyYWNrZXIiIA0KPj4+PiA8dHJhYytuZXRleHRAdHJhYy50b29scy5p ZXRmLm9yZz4NCj4+Pj4gd3JvdGU6DQo+Pj4+IA0KPj4+Pj4gIzU6IExvZ2ljYWwgaW50ZXJmYWNl IHN1cHBvcnQ6IE11bHRpY2FzdCB0cmFmZmljDQo+Pj4+IA0KPj4+PiDCoENsYXJpZnkgaG93IHRo ZSBsb2dpY2FsDQo+Pj4+PiBpbnRlcmZhY2UgZGVhbHMgd2l0aCBtdWx0aWNhc3QgdHJhZmZpYy4N Cj4+Pj4gDQo+Pj4+IC0tDQo+Pj4+PiANCj4+Pj4gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+Pj4+DQot DQo+Pj4+IA0KPj4+Pj4gUmVwb3J0ZXI6IMKgYmFzYXZhcmFqLnBhdGlsQMWgIMKgIMKgIMKgIMKg IMKgfCDCoCDCoCDCoCBPd25lcjogwqANCj4+Pj4+IHRlbGVtYWNvLm1lbGlhQMWgDQo+Pj4+PiAN Cj4+Pj4gwqAgwqAgVHlwZTogwqBkZWZlY3QgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg fCDCoCDCoCDCoFN0YXR1czogwqBuZXcNCj4+Pj4+IA0KPj4+PiDCoFByaW9yaXR5OiDCoGNyaXRp Y2FsIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqAgTWlsZXN0b25lOg0KPj4+Pj4gDQo+ Pj4+IENvbXBvbmVudDogwqBsb2dpY2FsLWludGVyZmFjZS1zdXBwb3J0IMKgfCDCoCDCoCBWZXJz aW9uOg0KPj4+Pj4gDQo+Pj4+IMKgU2V2ZXJpdHk6IMKgLSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoHwgwqAgwqBLZXl3b3JkczoNCj4+Pj4+IA0KPj4+PiANCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLT4+Pj4NCi0NCj4+Pj4gDQo+Pj4+PiANCj4+Pj4gVGlja2V0IFVSTDogPGh0dHA6 Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL25ldGV4dC90cmFjL3RpY2tldC81Pg0KPj4+PiBuZXRl eHQNCj4+Pj4+IDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvbmV0ZXh0Lz4NCj4+Pj4gDQo+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gX18NCj4+ Pj4gbmV0ZXh0IG1haWxpbmcNCj4+Pj4+IGxpc3QNCj4+Pj4gbmV0ZXh0QGlldGYub3JnDQo+Pj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0DQo+Pj4+IA0KPj4+ PiANCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+Pj4gbmV0ZXh0IG1haWxpbmcgbGlzdA0KPj4+PiBuZXRleHRAaWV0Zi5vcmcNCj4+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRleHQNCj4+Pj4gDQo+PiANCj4+ IA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0 ZXh0IG1haWxpbmcgbGlzdA0KbmV0ZXh0QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldGV4dA0K From telemaco.melia@alcatel-lucent.com Tue Mar 15 08:55:51 2011 Return-Path: <telemaco.melia@alcatel-lucent.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE82E3A6D2A for <netext@core3.amsl.com>; Tue, 15 Mar 2011 08:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.842 X-Spam-Level: X-Spam-Status: No, score=-5.842 tagged_above=-999 required=5 tests=[AWL=0.407, 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 WMRjK38ezVH5 for <netext@core3.amsl.com>; Tue, 15 Mar 2011 08:55:49 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id CD24F3A6E27 for <netext@ietf.org>; Tue, 15 Mar 2011 08:55:48 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p2FFuiIm010484 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 15 Mar 2011 16:57:11 +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, 15 Mar 2011 16:57:03 +0100 From: "MELIA, TELEMACO (TELEMACO)" <telemaco.melia@alcatel-lucent.com> To: netext issue tracker <trac+netext@zinfandel.tools.ietf.org>, "basavaraj.patil@nokia.com" <basavaraj.patil@nokia.com> Date: Tue, 15 Mar 2011 16:57:02 +0100 Thread-Topic: [netext] #7: Logical interface: UL/DL packet processing Thread-Index: AcvZ9zLqaCiqXPtjQvqFSNx7xNb4BQJMWIEw Message-ID: <3D6C64F2D792B540BAAEBCEF6509363B0EE6E5A4EB@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> References: <066.0751fc96f72ccc7f3cfc7cb7f3fb948e@trac.tools.ietf.org> In-Reply-To: <066.0751fc96f72ccc7f3cfc7cb7f3fb948e@trac.tools.ietf.org> 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" <netext@ietf.org> Subject: Re: [netext] #7: Logical interface: UL/DL packet processing X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Mar 2011 15:55:51 -0000 Folks, reflecting the discussions in the team here is the proposed text to = solve this issue. Let us know any problem you see with the proposed text. =3D=3D=3D=3D=3D 6.6. Logical Interface Forwarding Conceptual Data Structures The LIF should maintain the LIF and FLOW table data structures depicted in Figure 4 LIF TABLE FLOW table +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+ +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | PIF_ID | FLOW RoutingPolicies | | FLOW ID | PIF_ID | | | Home Network Prefix | +-------------------------------+ | | Link Layer Address | | FLOW_ID | PIF_ID | | | Status | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ +-------------------------------| | PIF_ID | FLOW RoutingPolicies | | | Home Network Prefix | | | Link Layer Address | | | Status | +-------------------------------+ | .... | .... | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+ Figure 4 The LIF table maintains the mapping between the LIF and each PIF associated to the LIF (see P3). For each PIF entry the table should store the associated Routing Policies, the Home Network Prefix received during the SLAAC procedure, the configured Link Layer Address (as described above) and the Status of the PIF (e.g. active, not active). The method by which the Routing Policies are configured in the UE is out of scope of this document. It is however assumed that this method is in place and that these policies are configured in the LIF TABLE. The FLOW table allows a LIF to properly route each IP flow to the right interface (see P7). The LIF can identify flows arriving on its PIFs and can map them accordingly for transmitting the corresponding packets. For locally generated traffic (e.g. unidirectional outgoing flows, mobile initiated traffic, etc.), the LIF should perform interface selection based on the Flow Routing Policies. In case traffic of an existing flow is suddenly received from the network on a different PIF than the one locally stored, the LIF should interpret the event as an explicit flow mobility trigger from the network and it should update the PIF_ID parameter in the FLOW table. Similarly, locally generated events from the PIFs or configuration updates to the local policy rules can cause updates to the table and hence trigger flow mobility. -----Message d'origine----- De : netext issue tracker [mailto:trac+netext@zinfandel.tools.ietf.org]=20 Envoy=E9 : vendredi 4 mars 2011 00:03 =C0 : MELIA, TELEMACO (TELEMACO); basavaraj.patil@nokia.com Cc : netext@ietf.org Objet : [netext] #7: Logical interface: UL/DL packet processing #7: Logical interface: UL/DL packet processing Uplink/downlink packet matching: Draft says the Logical interface should = transmit uplink packets on the same physical interface on which the downli= nk packet was received for the particular prefix/flow. How does the logica= l interface associates an uplink packet to a downlink packet? --=20 ---------------------------------------+-------------------------------- ---------------------------------------+---- Reporter: basavaraj.patil@. | Owner: telemaco.melia@. = =20 Type: defect | Status: new = =20 Priority: major | Milestone: = =20 Component: Localized routing | Version: = =20 Severity: Active WG Document | Keywords: = =20 ---------------------------------------+-------------------------------- ---------------------------------------+---- Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/7> netext <http://tools.ietf.org/netext/> From julien.ietf@gmail.com Tue Mar 15 09:10:40 2011 Return-Path: <julien.ietf@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2E5F3A6D1F for <netext@core3.amsl.com>; Tue, 15 Mar 2011 09:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.281 X-Spam-Level: X-Spam-Status: No, score=-3.281 tagged_above=-999 required=5 tests=[AWL=0.318, 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 s7Ns1RNQfOUD for <netext@core3.amsl.com>; Tue, 15 Mar 2011 09:10:37 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id E14EA3A6BDD for <netext@ietf.org>; Tue, 15 Mar 2011 09:10:36 -0700 (PDT) Received: by fxm15 with SMTP id 15so785120fxm.31 for <netext@ietf.org>; Tue, 15 Mar 2011 09:12:01 -0700 (PDT) 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=ro+tSKDlghIBfuPRS/BHQpVQ0HVL5zjadOCfzqCwyVU=; b=mJm6NR1u1K35NWdc5d9USZxpSgBZ+EEDDpLFIiJnlg5vU93gykvj5zXewIlAFEY7GQ IaUTjmF2URiGt42UwWAlVXIz2lOy5gMoQW3bZ9tA75b4o3MUJ++9jJqUjv6zUZPd1Xm2 UBauWC1MzDYy/k7qCzh5lVIBfUC3n0JPE/nk4= 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=YCXgLcnAfcqC3scKkgUUUI5tAR78KZ9idrsSb09aM57pl9Ks8gTwVjx9cugfWcTIvg 3O40eAgOZq/QzIwWBexRZmQzTxpUzaHgfDvLqDSNW0nUoZ18vn1L57dbNCkJ5JmHb2zC qd11jkDlS5TEFFsV/KMGcBOhCMojHlpB1geeQ= MIME-Version: 1.0 Received: by 10.223.59.146 with SMTP id l18mr11583021fah.58.1300205516015; Tue, 15 Mar 2011 09:11:56 -0700 (PDT) Received: by 10.223.78.135 with HTTP; Tue, 15 Mar 2011 09:11:55 -0700 (PDT) In-Reply-To: <3D6C64F2D792B540BAAEBCEF6509363B0EE6E5A41D@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> References: <AANLkTinRUGJodg5JJuZ=8YQOEG4YuAXeqzwRTJ1JG8MP@mail.gmail.com> <C9A3EE03.135D4%sgundave@cisco.com> <3D6C64F2D792B540BAAEBCEF6509363B0EE6E5A41D@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> Date: Tue, 15 Mar 2011 09:11:55 -0700 Message-ID: <AANLkTimDAOyYrU68MNKccNLkuAp_U2jVS_-2nWLsT9WQ@mail.gmail.com> From: Julien Laganier <julien.ietf@gmail.com> To: "MELIA, TELEMACO (TELEMACO)" <telemaco.melia@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "netext@ietf.org" <netext@ietf.org> Subject: Re: [netext] I-D Action:draft-ietf-netext-logical-interface-support-02.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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Mar 2011 16:10:40 -0000 And as I commented, we should discuss first and put it in the draft next. Otherwise when I look at the draft I have no idea what we have an agreement upon and what we have not. Do you disagree with this? --julien On Tue, Mar 15, 2011 at 2:54 AM, MELIA, TELEMACO (TELEMACO) <telemaco.melia@alcatel-lucent.com> wrote: > Julien, > > As Sri commented below this is the basis we would like to use for discuss= ions. We submitted a revised version to keep track of the changes. > > telemaco > > -----Message d'origine----- > De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part = de Sri Gundavelli > Envoy=E9 : mardi 15 mars 2011 01:09 > =C0 : Julien Laganier; netext@ietf.org > Objet : Re: [netext] I-D Action:draft-ietf-netext-logical-interface-suppo= rt-02.txt > > Hi Julien: > > We were hoping to post the text before, but we could not as we did not ha= ve the text till late. Any ways, we can use it as a starting point text for= the discussions. We can update the text as needed. If you can please revie= w and comment that will be great. > > > > Regards > Sri > > > > > On 3/14/11 2:58 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: > >> I am surprised that this document was revised without any mailing >> discussions of the changes that were carried on... >> >> --julien >> >> On Mon, Mar 14, 2011 at 2:45 PM, =A0<Internet-Drafts@ietf.org> wrote: >>> 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. >>> >>> >>> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Logical Interface Support fo= r multi-mode IP >>> Hosts >>> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : T. Melia, S. Gundavelli >>> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: >>> draft-ietf-netext-logical-interface-support-02.txt >>> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 26 >>> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-03-14 >>> >>> A Logical Interface is a software semantic internal to the host >>> operating system. =A0This semantic is available in all popular >>> operating systems and is used in various protocol implementations. >>> The Logical Interface support is required on the mobile node >>> operating in a Proxy Mobile IPv6 domain, for leveraging various >>> network-based mobility management features such as inter-technology >>> handoffs, multihoming and flow mobility support. =A0This document >>> explains the operational details of Logical Interface construct and >>> the specifics on how the link-layer implementations hide the physical >>> interfaces from the IP stack and from the network nodes on the >>> attached access networks. =A0Furthermore, this document identifies the >>> applicability of this approach to various link-layer technologies and >>> analyzes the issues around it when used in context with various >>> mobility management features. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-netext-logical-interfa >>> ce-suppo >>> rt-02.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. >>> >>> >>> _______________________________________________ >>> 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 Tue Mar 15 09:14:31 2011 Return-Path: <julien.ietf@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B1DE3A6C5B for <netext@core3.amsl.com>; Tue, 15 Mar 2011 09:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.284 X-Spam-Level: X-Spam-Status: No, score=-3.284 tagged_above=-999 required=5 tests=[AWL=0.315, 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 1beD-Yetvk8q for <netext@core3.amsl.com>; Tue, 15 Mar 2011 09:14:30 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 02ACF3A6E20 for <netext@ietf.org>; Tue, 15 Mar 2011 09:14:29 -0700 (PDT) Received: by fxm15 with SMTP id 15so789261fxm.31 for <netext@ietf.org>; Tue, 15 Mar 2011 09:15:54 -0700 (PDT) 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=zaT4DQmUQJkzVYIlGJJ/3H+nEMnK40ISHjCcSnqsmaQ=; b=JfpsUCDiaVY98/62idBsswRJ7tLy94O2cLXrzWREWN6vnlYAKUbGGIrfSAtSYrg8hB BYQwKdS3fJefBApSoC/ChXa4f/gXH252sJCZXL2xLDA2cspARsTzvqhmRj4AUqDorETC 6MkniIocipeBlyI3oQaXyge6m5RfVZCn+nbx4= 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=UhLhD8UwTCwswOveDK8MAbDZC/QukX/7o1ux1WWNlraqIpJlL31u6HV2MorjFFmCPD H+HCNwBTSruRbviZe+ep4hLix/ceo+7TKilk/FW8DYCUzR6QsdGvklP5SiAATJNwkB7X MqqAuBs4Q0bPmQ85VMVcHKV7cxpC8khjEm3VA= MIME-Version: 1.0 Received: by 10.223.151.14 with SMTP id a14mr2381544faw.134.1300205710591; Tue, 15 Mar 2011 09:15:10 -0700 (PDT) Received: by 10.223.78.135 with HTTP; Tue, 15 Mar 2011 09:15:10 -0700 (PDT) In-Reply-To: <C9A41645.13626%sgundave@cisco.com> References: <AANLkTim4aeCmtWgdXvMFTu=mJC9HmEoZTnYhJBE8Tj7L@mail.gmail.com> <C9A41645.13626%sgundave@cisco.com> Date: Tue, 15 Mar 2011 09:15:10 -0700 Message-ID: <AANLkTikxyJvbgV3AfzD0WsTx6GbWaLvtpAYMTrKsq2+2@mail.gmail.com> From: Julien Laganier <julien.ietf@gmail.com> To: Sri Gundavelli <sgundave@cisco.com> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] #5: Logical interface support: Multicast traffic X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Mar 2011 16:14:31 -0000 We have to deal with the general problem. If there are subcases, let's deal with all of the subcases, sure. As to link-local, as I said in my other note multicast traffic isn' t limited to ND thus I don't believe you have covered them. --julien 2011/3/14 Sri Gundavelli <sgundave@cisco.com>: > If you can define the destination scope, link-specific non-link-specific = ? > We have covered link-specific cases in the ND context (which can be > generalized), non-link specific ? May be if you can reflect the issue tha= t > you are thinking, that will help resolve the issue. > > > > Sri > > > > > > > On 3/14/11 5:52 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: > >> The case I have in mind is: IP stack wants to send a packet to >> multicast address M; =A0How is it transmitted? >> >> --julien >> >> 2011/3/14 Sri Gundavelli <sgundave@cisco.com>: >>> Julien: >>> >>> Agree. I did put that note below that we should add any additional case= s. >>> The text around handling link-specific multicast traffic with different >>> destination scopes covers most of the common multicast cases, ALL-NODES= , >>> SOLICTED-NODE... We can add any missing cases and resolve it. Any speci= fic >>> case you are thinking about ? We can generalize the case and make it ap= ply >>> for ND and non-ND cases. >>> >>> >>> >>> Regards >>> Sri >>> >>> >>> >>> >>> On 3/14/11 5:25 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: >>> >>>> Sri - >>>> >>>> Multicast traffic isn' t limited to ND, thus I don' t think it is >>>> appropriate to consider this issue as closed because you crafter some >>>> text on ND considerations elsewhere in this document. Please clarify >>>> how tranmission on multicast traffic is handled over a logical >>>> interface. >>>> >>>> --julien >>>> >>>> On Mon, Mar 14, 2011 at 4:27 PM, Sri Gundavelli <sgundave@cisco.com> w= rote: >>>>>> #5: Logical interface support: Multicast traffic >>>>> >>>>> =A0Clarify how the logical >>>>>> interface deals with multicast traffic. >>>>> >>>>> >>>>> We believe we have resolve this issue, this is captured in the ND >>>>> interactions section. The general considerations around dealing with >>>>> link-specific multicast traffic, all-nodes, solicited node multicast >>>>> traffic, or others have common considerations. It is possible we migh= t be >>>>> missing few cases, we can add that in, but the base handling of thing= s at >>>>> the logical interface level, or sub-interface level is captured. Comm= ents >>>>> welcome. >>>>> >>>>> >>>>> Sri >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 3/3/11 9:19 AM, "netext issue tracker" <trac+netext@trac.tools.iet= f.org> >>>>> wrote: >>>>> >>>>>> #5: Logical interface support: Multicast traffic >>>>> >>>>> =A0Clarify how the logical >>>>>> interface deals with multicast traffic. >>>>> >>>>> -- >>>>>> >>>>> > ---------------------------------------+---------------------------------= -->>>> > - >>>>> >>>>>> Reporter: =A0basavaraj.patil@=A9 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Ow= ner: =A0telemaco.melia@=A9 >>>>>> >>>>> =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0= =A0 =A0Status: =A0new >>>>>> >>>>> =A0Priority: =A0critical =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Mi= lestone: >>>>>> >>>>> Component: =A0logical-interface-support =A0| =A0 =A0 Version: >>>>>> >>>>> =A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= | =A0 =A0Keywords: >>>>>> >>>>> > ---------------------------------------+---------------------------------= -->>>> > - >>>>> >>>>>> >>>>> Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/5> >>>>> netext >>>>>> <http://tools.ietf.org/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 Tue Mar 15 16:50:38 2011 Return-Path: <julien.ietf@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AC703A6E48 for <netext@core3.amsl.com>; Tue, 15 Mar 2011 16:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.287 X-Spam-Level: X-Spam-Status: No, score=-3.287 tagged_above=-999 required=5 tests=[AWL=0.312, 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 BoP-yX-XXdZd for <netext@core3.amsl.com>; Tue, 15 Mar 2011 16:50:36 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 1F1833A6F1B for <netext@ietf.org>; Tue, 15 Mar 2011 16:50:35 -0700 (PDT) Received: by fxm15 with SMTP id 15so1210707fxm.31 for <netext@ietf.org>; Tue, 15 Mar 2011 16:52:01 -0700 (PDT) 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=LzAulSSZ6Dp6GLZzvjQcbqqvFGbiN2bVk/GYR5OTkPc=; b=tJnxLA9b4wxPy9x9w+wbX4SuM0eo8SQnWxDeneHmtFig64Zf0DwaIaomsbLewxAseL O/JqICkTtwyQamq3O7zCTpeQMyanbXbdSb+kIqvq4Nc1yXw0iG1pSvJXiwna44ehbwI6 Q0iIzN+haw/yvp2LFmoY/xgYsAP+YDV8uQsqg= 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=KmOMpqFu01r1apS3qs6YWTkZTDaBA/ikVS9LVm/ty1Owz+kezv88RWV8vMK2jwrCk6 8QkteP9ZwF9YNW+TvSpAjsm0dgd12PG3KuWyu+tn23KvLUkPL/aeZeIEsnizeVbXxsUa Nfgwm/yxEfURlL0d21/0PA2FPn61DEpCnR3b4= MIME-Version: 1.0 Received: by 10.223.127.210 with SMTP id h18mr140102fas.77.1300233091216; Tue, 15 Mar 2011 16:51:31 -0700 (PDT) Received: by 10.223.78.135 with HTTP; Tue, 15 Mar 2011 16:51:31 -0700 (PDT) In-Reply-To: <C9A4171A.13628%sgundave@cisco.com> References: <AANLkTin_ZbJmkbS3d2U0RGcSp4nCFD0H_VjeUQzQdB6H@mail.gmail.com> <C9A4171A.13628%sgundave@cisco.com> Date: Tue, 15 Mar 2011 16:51:31 -0700 Message-ID: <AANLkTi=QuJKcKFRALjCKmyVy81Fiu=snQsk9dJ+6P6tE@mail.gmail.com> From: Julien Laganier <julien.ietf@gmail.com> To: Sri Gundavelli <sgundave@cisco.com> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] #4: Logical interface support: Point to point links X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Mar 2011 23:50:38 -0000 Sri: I am going to repeat it once again: you are equating advertizing or per-MN subnet prefix to a point-to-point link, but these are two different things, thus I am saying that we have a problem as 5213 is limited to support of point-to-point links. --julien 2011/3/14 Sri Gundavelli <sgundave@cisco.com>: > Julien: > > Lets see, what is the violation here ? > > - We are stating the logical interface appears to the applications as an > interface attached to a shared link. For the simple reason, that we have > multiple neighbors on different network segments attached through differe= nt > sub-interface of that logical interface. We don't have a single > neighbor/MAG. > > - "Underneath the logical interface ...", there are sub-interfaces which = may > be very well attached to different p2p links. As long as the network has = the > semantics to send a RA with PIO, exclusively to this node, no other node = on > that access link can receive that Prefix set, we are confirming to 5213 l= ink > model. From any of the MAG's perspective, attached to any of the access > links, it can still be kept as a p2p link > > - Exposing the logical interface as a shared link to the applications on = the > *mobile node*, is not violating 5213 principles. The path chosen for a > packet through a sub-interface can be still a p2p link and the rules of > link-layer resolution of the peer, or adding l2 headers skipping l2 > resolution, is still the approach in use. > > > > > Sri > > > > > > > > > On 3/14/11 5:20 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: > >> Sri - >> >> 5213 supports only PtP links thus I do not understand how the >> following resolution resolves anything. Please clarify what is the >> issue you' re addressing and how this is addressing it. >> >> --julien >> >> On Mon, Mar 14, 2011 at 4:24 PM, Sri Gundavelli <sgundave@cisco.com> wro= te: >>>> #4: Logical interface support: Point to point links >>> >>> =A0Clarify the use and >>>> behavior of the logical interface on PtP links. >>> >>> >>> Folks: Again, reflecting the team's contributions on this topic, the au= thors >>> of this document have discussed this and resolve it with the following = text. >>> The key points we tried to reflect are around that the logical interfac= e >>> appears to the application as a shared link. There were thoughts around >>> making it appear like a p2p link, given that there are multiple neighbo= rs on >>> each sub interface, this choice appears reasonable. With respect to how= a >>> packet is transmitted, is still based on the chosen link model at each = sub >>> interface level. Let us know, if you see any issues with it. This is pr= oven >>> based on the multiple implementations from some of the co-authors of th= is >>> doc. >>> >>> >>> >>> >>> --- >>> 6.3. =A0Supported Link models for a logical interface >>> >>> =A0The sub-interfaces of a logical interface can be bound to a point-to= - >>> =A0 point or a shared link (Example: LTE and WLAN). =A0The logical >>> =A0 interface appears as a shared-link to the applications, and adapts = to >>> =A0 the link model of the sub-interface for packet communication. =A0Fo= r >>> =A0 example, when transmitting a packet on a sub-interface which is >>> =A0 attached to a p2p link, the transmission conforms to the p2p link >>> =A0 model and when transmitting on a sub-interface attached to a shared >>> =A0 link, the transmission conforms to the shared link model. >>> >>> =A0 Based on the link to which the sub-interface is attached to, the >>> =A0 layer-2 resolutions may or may not be needed. =A0If the interface i= s >>> =A0 bound to a P2P link with PPP running, there will not be any link- >>> =A0 layer resolutions in the form of ARP/ND messages. =A0However, if th= e >>> =A0 interface is bound to a shared link such as Ethernet, there will be >>> =A0 ND resolutions. =A0The logical interface implementation has to main= tain >>> =A0 the required link model and the associated state for each sub- >>> =A0 interface. >>> -- >>> >>> >>> >>> >>> On 3/3/11 9:17 AM, "netext issue tracker" <trac+netext@trac.tools.ietf.= org> >>> wrote: >>> >>>> #4: Logical interface support: Point to point links >>> >>> =A0Clarify the use and >>>> behavior of the logical interface on PtP links. >>> >>> -- >>>> >>> ---------------------------------------+-------------------------------= ----- >>> >>>> Reporter: =A0basavaraj.patil@=A9 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Owne= r: =A0telemaco.melia@=A9 >>>> >>> =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 = =A0 =A0Status: =A0new >>>> >>> =A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 = Milestone: >>>> >>> Component: =A0logical-interface-support =A0| =A0 =A0 Version: >>>> >>> =A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0Keywords: >>>> >>> ---------------------------------------+-------------------------------= ----- >>> >>>> >>> Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/4> >>> netext >>>> <http://tools.ietf.org/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 sgundave@cisco.com Tue Mar 15 17:15:47 2011 Return-Path: <sgundave@cisco.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 597FD3A6A55 for <netext@core3.amsl.com>; Tue, 15 Mar 2011 17:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.454 X-Spam-Level: X-Spam-Status: No, score=-9.454 tagged_above=-999 required=5 tests=[AWL=-0.251, 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 r2lQbtONUGd1 for <netext@core3.amsl.com>; Tue, 15 Mar 2011 17:15:46 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 3B12E3A6A4E for <netext@ietf.org>; Tue, 15 Mar 2011 17:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=7279; q=dns/txt; s=iport; t=1300234632; x=1301444232; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=jJs5pEPyZZvEPr7zl+z5hYJJsZ6qjGHUcLQISvKFBFQ=; b=G5d57y81Tzw8sBYp6gDERJa3wafEqs4/rHUpD4iZmAe2tTLoM0NtkInQ nGMl0talVDI4pLGu99lLrZL6lXEDX1EfK8LqmT8x4aRM8sImAU01zSuL7 CFWu77NH6uI8ht1s/8VZIOI2Lml2hMK5nLu/C7kDW9h1O+RJ47y0yhTgN k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJeef02tJXG+/2dsb2JhbACEPqB6VXekcYsjkT6BJ4NFdgSFMIctg1WDHw X-IronPort-AV: E=Sophos;i="4.63,191,1299456000"; d="scan'208";a="667518888" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-6.cisco.com with ESMTP; 16 Mar 2011 00:17:11 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2G0H9AN006814; Wed, 16 Mar 2011 00:17:11 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, 15 Mar 2011 17:17:10 -0700 Received: from 10.32.243.120 ([10.32.243.120]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Wed, 16 Mar 2011 00:17:10 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 15 Mar 2011 17:17:05 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: <pierrick.seite@orange-ftgroup.com>, <julien.ietf@gmail.com> Message-ID: <C9A54F91.138B8%sgundave@cisco.com> Thread-Topic: [netext] #4: Logical interface support: Point to point links Thread-Index: AcvitTxenbMujdRwpUe3xtq+9Nb7nQAOp6rwAB/n7CU= In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C4620190B524@ftrdmel0.rd.francetelecom.fr> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 16 Mar 2011 00:17:10.0713 (UTC) FILETIME=[7E209290:01CBE36F] Cc: netext@ietf.org Subject: Re: [netext] #4: Logical interface support: Point to point links X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Mar 2011 00:15:47 -0000 Hi Pierrick, The sentence can be reworded. Agree, the link model between the MAG and the MN is still a point-to-point link. From 5213 perspective, as long as the point-to-point communication semantics are there between the MN and MAG, we meet the requirement and there is no protocol violation. How that P2P link model is achieved, based a tunnel interface, putting the access point in a unicast mode, are all the possible options. Sri On 3/15/11 1:21 AM, "pierrick.seite@orange-ftgroup.com" <pierrick.seite@orange-ftgroup.com> wrote: >=20 > Hi Sri, >=20 > If I understand correctly, there is no violation of RFC5213 if all physic= al > links are p2p. However the proposed text allows the virtual interface to = bound > physical shared links. If so, I think we may have the issue described in > section 4.2 of http://tools.ietf.org/html/draft-ietf-netlmm-mn-ar-if-03. > Maybe, the text should be clarified to restrict to physical p2p links. >=20 > BR, > Pierrick=20 >=20 >> -----Message d'origine----- >> De=C2=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la par= t >> de Sri Gundavelli >> Envoy=C3=A9=C2=A0: mardi 15 mars 2011 04:04 >> =C3=80=C2=A0: Julien Laganier >> Cc=C2=A0: netext@ietf.org >> Objet=C2=A0: Re: [netext] #4: Logical interface support: Point to point link= s >>=20 >> Julien: >>=20 >> Lets see, what is the violation here ? >>=20 >> - We are stating the logical interface appears to the applications as an >> interface attached to a shared link. For the simple reason, that we have >> multiple neighbors on different network segments attached through >> different >> sub-interface of that logical interface. We don't have a single >> neighbor/MAG. >>=20 >> - "Underneath the logical interface ...", there are sub-interfaces which >> may >> be very well attached to different p2p links. As long as the network has >> the >> semantics to send a RA with PIO, exclusively to this node, no other node >> on >> that access link can receive that Prefix set, we are confirming to 5213 >> link >> model. From any of the MAG's perspective, attached to any of the access >> links, it can still be kept as a p2p link >>=20 >> - Exposing the logical interface as a shared link to the applications on >> the >> *mobile node*, is not violating 5213 principles. The path chosen for a >> packet through a sub-interface can be still a p2p link and the rules of >> link-layer resolution of the peer, or adding l2 headers skipping l2 >> resolution, is still the approach in use. >>=20 >>=20 >>=20 >>=20 >> Sri >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 3/14/11 5:20 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: >>=20 >>> Sri - >>>=20 >>> 5213 supports only PtP links thus I do not understand how the >>> following resolution resolves anything. Please clarify what is the >>> issue you' re addressing and how this is addressing it. >>>=20 >>> --julien >>>=20 >>> On Mon, Mar 14, 2011 at 4:24 PM, Sri Gundavelli <sgundave@cisco.com> >> wrote: >>>>> #4: Logical interface support: Point to point links >>>>=20 >>>> =C2=A0Clarify the use and >>>>> behavior of the logical interface on PtP links. >>>>=20 >>>>=20 >>>> Folks: Again, reflecting the team's contributions on this topic, the >> authors >>>> of this document have discussed this and resolve it with the following >> text. >>>> The key points we tried to reflect are around that the logical >> interface >>>> appears to the application as a shared link. There were thoughts aroun= d >>>> making it appear like a p2p link, given that there are multiple >> neighbors on >>>> each sub interface, this choice appears reasonable. With respect to ho= w >> a >>>> packet is transmitted, is still based on the chosen link model at each >> sub >>>> interface level. Let us know, if you see any issues with it. This is >> proven >>>> based on the multiple implementations from some of the co-authors of >> this >>>> doc. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> --- >>>> 6.3. =C2=A0Supported Link models for a logical interface >>>>=20 >>>> =C2=A0The sub-interfaces of a logical interface can be bound to a point-to= - >>>> =C2=A0 point or a shared link (Example: LTE and WLAN). =C2=A0The logical >>>> =C2=A0 interface appears as a shared-link to the applications, and adapts = to >>>> =C2=A0 the link model of the sub-interface for packet communication. =C2=A0For >>>> =C2=A0 example, when transmitting a packet on a sub-interface which is >>>> =C2=A0 attached to a p2p link, the transmission conforms to the p2p link >>>> =C2=A0 model and when transmitting on a sub-interface attached to a shared >>>> =C2=A0 link, the transmission conforms to the shared link model. >>>>=20 >>>> =C2=A0 Based on the link to which the sub-interface is attached to, the >>>> =C2=A0 layer-2 resolutions may or may not be needed. =C2=A0If the interface is >>>> =C2=A0 bound to a P2P link with PPP running, there will not be any link- >>>> =C2=A0 layer resolutions in the form of ARP/ND messages. =C2=A0However, if the >>>> =C2=A0 interface is bound to a shared link such as Ethernet, there will be >>>> =C2=A0 ND resolutions. =C2=A0The logical interface implementation has to maint= ain >>>> =C2=A0 the required link model and the associated state for each sub- >>>> =C2=A0 interface. >>>> -- >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 3/3/11 9:17 AM, "netext issue tracker" >> <trac+netext@trac.tools.ietf.org> >>>> wrote: >>>>=20 >>>>> #4: Logical interface support: Point to point links >>>>=20 >>>> =C2=A0Clarify the use and >>>>> behavior of the logical interface on PtP links. >>>>=20 >>>> -- >>>>>=20 >>>> ---------------------------------------+------------------------------= - >> ----- >>>>=20 >>>>> Reporter: =C2=A0basavaraj.patil@=C5=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 Owner: =C2=A0tele= maco.melia@=C5=A0 >>>>>=20 >>>> =C2=A0 =C2=A0 Type: =C2=A0defect =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0Status: =C2= =A0new >>>>>=20 >>>> =C2=A0Priority: =C2=A0major =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 Milestone: >>>>>=20 >>>> Component: =C2=A0logical-interface-support =C2=A0| =C2=A0 =C2=A0 Version: >>>>>=20 >>>> =C2=A0Severity: =C2=A0- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0Keywords: >>>>>=20 >>>> ---------------------------------------+------------------------------= - >> ----- >>>>=20 >>>>>=20 >>>> Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/4> >>>> netext >>>>> <http://tools.ietf.org/netext/> >>>>=20 >>>> _____________________________________________ >>>>> __ >>>> netext mailing >>>>> list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>>=20 >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext From sgundave@cisco.com Tue Mar 15 17:15:55 2011 Return-Path: <sgundave@cisco.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2674F3A6EAA for <netext@core3.amsl.com>; Tue, 15 Mar 2011 17:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.447 X-Spam-Level: X-Spam-Status: No, score=-9.447 tagged_above=-999 required=5 tests=[AWL=-0.244, 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 weBEIyNrT-lI for <netext@core3.amsl.com>; Tue, 15 Mar 2011 17:15:54 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 2AD773A6A4E for <netext@ietf.org>; Tue, 15 Mar 2011 17:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=4802; q=dns/txt; s=iport; t=1300234640; x=1301444240; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=WJlTqaJuYQG59ZMIqV2NibSdMVFjGWnKsYzJizmDRzk=; b=aTaYZG6ZvwJX+SAJc4FeQBkCAB4c2n0E2BKyikuA2uhRjNSAg3lwVkPo ywfuNNgeoa152vtLnrozZYLAGSSueoJOJT6/+Ii9QUk54M7Qzu51RepyL orkXk1h8mGQ7+9ZMqL00xBZgPgolYdd75HyIqUp+g5WZW1VvhNNwC1mYP E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFqef02tJXG8/2dsb2JhbAClOFV3pG6cYYViBIUwhy2DVYMf X-IronPort-AV: E=Sophos;i="4.63,191,1299456000"; d="scan'208";a="320712097" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-2.cisco.com with ESMTP; 16 Mar 2011 00:17:19 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2G0HGEi019476; Wed, 16 Mar 2011 00:17:19 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, 15 Mar 2011 17:17:18 -0700 Received: from 10.32.243.120 ([10.32.243.120]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Wed, 16 Mar 2011 00:17:17 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 15 Mar 2011 17:17:15 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: Julien Laganier <julien.ietf@gmail.com> Message-ID: <C9A54F9B.138B8%sgundave@cisco.com> Thread-Topic: [netext] #5: Logical interface support: Multicast traffic Thread-Index: Acvjb4Cuze2UQTqf2UO9miCVkCpsWQ== In-Reply-To: <AANLkTikxyJvbgV3AfzD0WsTx6GbWaLvtpAYMTrKsq2+2@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-2" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 16 Mar 2011 00:17:18.0180 (UTC) FILETIME=[8293F240:01CBE36F] Cc: netext@ietf.org Subject: Re: [netext] #5: Logical interface support: Multicast traffic X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Mar 2011 00:15:55 -0000 We have captured this under ND. Its a valid point, that ND is just one sub-case of multicast usage. We should have sub section specific to multicast and we can present this in a generic way. That's fine, we will write up some text for this and resolve it. Sri On 3/15/11 8:15 AM, "Julien Laganier" <julien.ietf@gmail.com> wrote: > We have to deal with the general problem. If there are subcases, let's > deal with all of the subcases, sure. As to link-local, as I said in my > other note multicast traffic isn' t limited to ND thus I don't believe > you have covered them. >=20 > --julien >=20 > 2011/3/14 Sri Gundavelli <sgundave@cisco.com>: >> If you can define the destination scope, link-specific non-link-specific= ? >> We have covered link-specific cases in the ND context (which can be >> generalized), non-link specific ? May be if you can reflect the issue th= at >> you are thinking, that will help resolve the issue. >>=20 >>=20 >>=20 >> Sri >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 3/14/11 5:52 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: >>=20 >>> The case I have in mind is: IP stack wants to send a packet to >>> multicast address M; =A0How is it transmitted? >>>=20 >>> --julien >>>=20 >>> 2011/3/14 Sri Gundavelli <sgundave@cisco.com>: >>>> Julien: >>>>=20 >>>> Agree. I did put that note below that we should add any additional cas= es. >>>> The text around handling link-specific multicast traffic with differen= t >>>> destination scopes covers most of the common multicast cases, ALL-NODE= S, >>>> SOLICTED-NODE... We can add any missing cases and resolve it. Any spec= ific >>>> case you are thinking about ? We can generalize the case and make it a= pply >>>> for ND and non-ND cases. >>>>=20 >>>>=20 >>>>=20 >>>> Regards >>>> Sri >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 3/14/11 5:25 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: >>>>=20 >>>>> Sri - >>>>>=20 >>>>> Multicast traffic isn' t limited to ND, thus I don' t think it is >>>>> appropriate to consider this issue as closed because you crafter some >>>>> text on ND considerations elsewhere in this document. Please clarify >>>>> how tranmission on multicast traffic is handled over a logical >>>>> interface. >>>>>=20 >>>>> --julien >>>>>=20 >>>>> On Mon, Mar 14, 2011 at 4:27 PM, Sri Gundavelli <sgundave@cisco.com> >>>>> wrote: >>>>>>> #5: Logical interface support: Multicast traffic >>>>>>=20 >>>>>> =A0Clarify how the logical >>>>>>> interface deals with multicast traffic. >>>>>>=20 >>>>>>=20 >>>>>> We believe we have resolve this issue, this is captured in the ND >>>>>> interactions section. The general considerations around dealing with >>>>>> link-specific multicast traffic, all-nodes, solicited node multicast >>>>>> traffic, or others have common considerations. It is possible we mig= ht be >>>>>> missing few cases, we can add that in, but the base handling of thin= gs at >>>>>> the logical interface level, or sub-interface level is captured. Com= ments >>>>>> welcome. >>>>>>=20 >>>>>>=20 >>>>>> Sri >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 3/3/11 9:19 AM, "netext issue tracker" >>>>>> <trac+netext@trac.tools.ietf.org> >>>>>> wrote: >>>>>>=20 >>>>>>> #5: Logical interface support: Multicast traffic >>>>>>=20 >>>>>> =A0Clarify how the logical >>>>>>> interface deals with multicast traffic. >>>>>>=20 >>>>>> -- >>>>>>>=20 >>>>>>=20 >> ---------------------------------------+--------------------------------= --->> >> >> >> - >>>>>>=20 >>>>>>> Reporter: =A0basavaraj.patil@=A9 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Owner: =A0telemaco.meli= a@=A9 >>>>>>>=20 >>>>>> =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status: =A0new >>>>>>>=20 >>>>>> =A0Priority: =A0critical =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone: >>>>>>>=20 >>>>>> Component: =A0logical-interface-support =A0| =A0 =A0 Version: >>>>>>>=20 >>>>>> =A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0Keywords: >>>>>>>=20 >>>>>>=20 >> ---------------------------------------+--------------------------------= --->> >> >> >> - >>>>>>=20 >>>>>>>=20 >>>>>> Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/5> >>>>>> netext >>>>>>> <http://tools.ietf.org/netext/> >>>>>>=20 >>>>>> _____________________________________________ >>>>>>> __ >>>>>> netext mailing >>>>>>> list >>>>>> netext@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netext >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> netext mailing list >>>>>> netext@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netext >>>>>>=20 >>>>=20 >>>>=20 >>=20 >>=20 From sgundave@cisco.com Tue Mar 15 17:16:39 2011 Return-Path: <sgundave@cisco.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDA863A6A4E for <netext@core3.amsl.com>; Tue, 15 Mar 2011 17:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.439 X-Spam-Level: X-Spam-Status: No, score=-9.439 tagged_above=-999 required=5 tests=[AWL=-0.236, 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 2ptXL2hys6u5 for <netext@core3.amsl.com>; Tue, 15 Mar 2011 17:16:38 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id BD2D03A6A55 for <netext@ietf.org>; Tue, 15 Mar 2011 17:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=6321; q=dns/txt; s=iport; t=1300234684; x=1301444284; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=3uJK8s8B1cBI7Fix0M+6IwYEBBn4UHj4UePmLneuMOQ=; b=YT0IB1Y3tEok+47785+25JMRXp+9kvR/VlEBXy4Q24DRymxOcEX4LfOf Rk0Y0NWS24k+Bno+Xyqraw8BlECC2JSb1sRqo00GbQxFP7co5U16D2Mn0 GqdJOfckLjPi2F8Mp6w9qtd5Ts1hEl6gBqSTiSgg5I4J1TNgdrS/iEA2b Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJeef02tJV2d/2dsb2JhbAClOFV3pHGcYYViBIUwhy2DVYMf X-IronPort-AV: E=Sophos;i="4.63,191,1299456000"; d="scan'208";a="347477980" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by sj-iport-5.cisco.com with ESMTP; 16 Mar 2011 00:18:04 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2G0I3Jp013234; Wed, 16 Mar 2011 00:18: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); Tue, 15 Mar 2011 17:18:03 -0700 Received: from 10.32.243.120 ([10.32.243.120]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Wed, 16 Mar 2011 00:18:03 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 15 Mar 2011 17:18:00 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: Julien Laganier <julien.ietf@gmail.com> Message-ID: <C9A54FC8.138B8%sgundave@cisco.com> Thread-Topic: [netext] #4: Logical interface support: Point to point links Thread-Index: Acvjb5uBzMME2bizR0CJREdnEGNofg== In-Reply-To: <AANLkTi=QuJKcKFRALjCKmyVy81Fiu=snQsk9dJ+6P6tE@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-2" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 16 Mar 2011 00:18:03.0647 (UTC) FILETIME=[9DADA8F0:01CBE36F] Cc: netext@ietf.org Subject: Re: [netext] #4: Logical interface support: Point to point links X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Mar 2011 00:16:39 -0000 Julien: We all agree, the link model is still P2P. All I'm saying, we should not classify P2P vs Non-P2P, based on the access technology type. I can build P2P link on an IPsec tunnel, 802.11 access, or a GRE tunnel. We just requir= e P2P communication semantics, if we specify more that this, it will be an over specification. Lets work out the text for this. Sri On 3/15/11 3:51 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: > Sri: >=20 > I am going to repeat it once again: you are equating advertizing or > per-MN subnet prefix to a point-to-point link, but these are two > different things, thus I am saying that we have a problem as 5213 is > limited to support of point-to-point links. >=20 > --julien >=20 > 2011/3/14 Sri Gundavelli <sgundave@cisco.com>: >> Julien: >>=20 >> Lets see, what is the violation here ? >>=20 >> - We are stating the logical interface appears to the applications as an >> interface attached to a shared link. For the simple reason, that we have >> multiple neighbors on different network segments attached through differ= ent >> sub-interface of that logical interface. We don't have a single >> neighbor/MAG. >>=20 >> - "Underneath the logical interface ...", there are sub-interfaces which= may >> be very well attached to different p2p links. As long as the network has= the >> semantics to send a RA with PIO, exclusively to this node, no other node= on >> that access link can receive that Prefix set, we are confirming to 5213 = link >> model. From any of the MAG's perspective, attached to any of the access >> links, it can still be kept as a p2p link >>=20 >> - Exposing the logical interface as a shared link to the applications on= the >> *mobile node*, is not violating 5213 principles. The path chosen for a >> packet through a sub-interface can be still a p2p link and the rules of >> link-layer resolution of the peer, or adding l2 headers skipping l2 >> resolution, is still the approach in use. >>=20 >>=20 >>=20 >>=20 >> Sri >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 3/14/11 5:20 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: >>=20 >>> Sri - >>>=20 >>> 5213 supports only PtP links thus I do not understand how the >>> following resolution resolves anything. Please clarify what is the >>> issue you' re addressing and how this is addressing it. >>>=20 >>> --julien >>>=20 >>> On Mon, Mar 14, 2011 at 4:24 PM, Sri Gundavelli <sgundave@cisco.com> wr= ote: >>>>> #4: Logical interface support: Point to point links >>>>=20 >>>> =A0Clarify the use and >>>>> behavior of the logical interface on PtP links. >>>>=20 >>>>=20 >>>> Folks: Again, reflecting the team's contributions on this topic, the >>>> authors >>>> of this document have discussed this and resolve it with the following >>>> text. >>>> The key points we tried to reflect are around that the logical interfa= ce >>>> appears to the application as a shared link. There were thoughts aroun= d >>>> making it appear like a p2p link, given that there are multiple neighb= ors >>>> on >>>> each sub interface, this choice appears reasonable. With respect to ho= w a >>>> packet is transmitted, is still based on the chosen link model at each= sub >>>> interface level. Let us know, if you see any issues with it. This is p= roven >>>> based on the multiple implementations from some of the co-authors of t= his >>>> doc. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> --- >>>> 6.3. =A0Supported Link models for a logical interface >>>>=20 >>>> =A0The sub-interfaces of a logical interface can be bound to a point-to- >>>> =A0 point or a shared link (Example: LTE and WLAN). =A0The logical >>>> =A0 interface appears as a shared-link to the applications, and adapts t= o >>>> =A0 the link model of the sub-interface for packet communication. =A0For >>>> =A0 example, when transmitting a packet on a sub-interface which is >>>> =A0 attached to a p2p link, the transmission conforms to the p2p link >>>> =A0 model and when transmitting on a sub-interface attached to a shared >>>> =A0 link, the transmission conforms to the shared link model. >>>>=20 >>>> =A0 Based on the link to which the sub-interface is attached to, the >>>> =A0 layer-2 resolutions may or may not be needed. =A0If the interface is >>>> =A0 bound to a P2P link with PPP running, there will not be any link- >>>> =A0 layer resolutions in the form of ARP/ND messages. =A0However, if the >>>> =A0 interface is bound to a shared link such as Ethernet, there will be >>>> =A0 ND resolutions. =A0The logical interface implementation has to maintai= n >>>> =A0 the required link model and the associated state for each sub- >>>> =A0 interface. >>>> -- >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 3/3/11 9:17 AM, "netext issue tracker" <trac+netext@trac.tools.ietf= .org> >>>> wrote: >>>>=20 >>>>> #4: Logical interface support: Point to point links >>>>=20 >>>> =A0Clarify the use and >>>>> behavior of the logical interface on PtP links. >>>>=20 >>>> -- >>>>>=20 >>>>=20 ---------------------------------------+-----------------------------------= >>>> - >>>>=20 >>>>> Reporter: =A0basavaraj.patil@=A9 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Owner: =A0telemaco.melia@= =A9 >>>>>=20 >>>> =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status: =A0new >>>>>=20 >>>> =A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 Milestone: >>>>>=20 >>>> Component: =A0logical-interface-support =A0| =A0 =A0 Version: >>>>>=20 >>>> =A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0Keywords: >>>>>=20 >>>>=20 ---------------------------------------+-----------------------------------= >>>> - >>>>=20 >>>>>=20 >>>> Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/4> >>>> netext >>>>> <http://tools.ietf.org/netext/> >>>>=20 >>>> _____________________________________________ >>>>> __ >>>> netext mailing >>>>> list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>>=20 >>=20 >>=20 From julien.ietf@gmail.com Tue Mar 15 17:35:33 2011 Return-Path: <julien.ietf@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C79BB3A6F31 for <netext@core3.amsl.com>; Tue, 15 Mar 2011 17:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.29 X-Spam-Level: X-Spam-Status: No, score=-3.29 tagged_above=-999 required=5 tests=[AWL=0.309, 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 EzevPqZSmfCc for <netext@core3.amsl.com>; Tue, 15 Mar 2011 17:35:32 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 2BBAE3A68CE for <netext@ietf.org>; Tue, 15 Mar 2011 17:35:32 -0700 (PDT) Received: by fxm15 with SMTP id 15so1238606fxm.31 for <netext@ietf.org>; Tue, 15 Mar 2011 17:36:57 -0700 (PDT) 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=bLjW74JH2yV/tL/ljmWarCWFt1zB4pYLnmUpLXRGXMk=; b=IHPkNPmG0jWsyT0I5YCer32OiS9FBmRwrNwM9sJlPQjz4U9854w86LV5daWdTWnzcy Ev2m1DBx9M183VpN30K4DnScIT3a+AZHpR0j738RNNsJzKgId17e0VUVrfx+FhtTGnFJ L7YPJ45AGlZivoh7XJsHufI/WFnrFYO8UXIlQ= 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=iequVnGLNxhe2nZfrd7Egp7TrkAlx3+mMp+HKri7N01+WIscXer3UmRHj91H/c0h5J g53SOGO97Kvx2LWZSCE3ZG0YrdfGFWH7rPHQRvjIUXOwT+htMD33mbqHqc05IWR1GK0/ pz00izi0JimtTWXpwzi7wD8iViBRQY/4LcDnk= MIME-Version: 1.0 Received: by 10.223.20.216 with SMTP id g24mr161111fab.115.1300235817210; Tue, 15 Mar 2011 17:36:57 -0700 (PDT) Received: by 10.223.78.135 with HTTP; Tue, 15 Mar 2011 17:36:57 -0700 (PDT) In-Reply-To: <C9A54FC8.138B8%sgundave@cisco.com> References: <AANLkTi=QuJKcKFRALjCKmyVy81Fiu=snQsk9dJ+6P6tE@mail.gmail.com> <C9A54FC8.138B8%sgundave@cisco.com> Date: Tue, 15 Mar 2011 17:36:57 -0700 Message-ID: <AANLkTi=2CoE5G5M5GuRKBd7mcty9eCCEmuVYdtb=S3va@mail.gmail.com> From: Julien Laganier <julien.ietf@gmail.com> To: Sri Gundavelli <sgundave@cisco.com> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] #4: Logical interface support: Point to point links X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Mar 2011 00:35:34 -0000 Actually, the point to point link depends on access type. Tunnels are point to point by nature so there is nothing to do. 802.11 is a shared media thus unless you can enforce that only two IP nodes are attached to the link it doesn' t qualify as a point-to-point link and thus 5213 doesn' t work. This is the stuff that i supposed to go in the applicability statement for the logical interface that this WG is chartered to produce thus I do not understand what you mean by overspecification. It would atcually be underspecification in terms of the deliverable we have. --julien 2011/3/15 Sri Gundavelli <sgundave@cisco.com>: > Julien: > > We all agree, the link model is still P2P. All I'm saying, we should not > classify P2P vs Non-P2P, based on the access technology type. I can build > P2P link on an IPsec tunnel, 802.11 access, or a GRE tunnel. We just requ= ire > P2P communication semantics, if we specify more that this, it will be an > over specification. Lets work out the text for this. > > > Sri > > > > On 3/15/11 3:51 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: > >> Sri: >> >> I am going to repeat it once again: you are equating advertizing or >> per-MN subnet prefix to a point-to-point link, but these are two >> different things, thus I am saying that we have a problem as 5213 is >> limited to support of point-to-point links. >> >> --julien >> >> 2011/3/14 Sri Gundavelli <sgundave@cisco.com>: >>> Julien: >>> >>> Lets see, what is the violation here ? >>> >>> - We are stating the logical interface appears to the applications as a= n >>> interface attached to a shared link. For the simple reason, that we hav= e >>> multiple neighbors on different network segments attached through diffe= rent >>> sub-interface of that logical interface. We don't have a single >>> neighbor/MAG. >>> >>> - "Underneath the logical interface ...", there are sub-interfaces whic= h may >>> be very well attached to different p2p links. As long as the network ha= s the >>> semantics to send a RA with PIO, exclusively to this node, no other nod= e on >>> that access link can receive that Prefix set, we are confirming to 5213= link >>> model. From any of the MAG's perspective, attached to any of the access >>> links, it can still be kept as a p2p link >>> >>> - Exposing the logical interface as a shared link to the applications o= n the >>> *mobile node*, is not violating 5213 principles. The path chosen for a >>> packet through a sub-interface can be still a p2p link and the rules of >>> link-layer resolution of the peer, or adding l2 headers skipping l2 >>> resolution, is still the approach in use. >>> >>> >>> >>> >>> Sri >>> >>> >>> >>> >>> >>> >>> >>> >>> On 3/14/11 5:20 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: >>> >>>> Sri - >>>> >>>> 5213 supports only PtP links thus I do not understand how the >>>> following resolution resolves anything. Please clarify what is the >>>> issue you' re addressing and how this is addressing it. >>>> >>>> --julien >>>> >>>> On Mon, Mar 14, 2011 at 4:24 PM, Sri Gundavelli <sgundave@cisco.com> w= rote: >>>>>> #4: Logical interface support: Point to point links >>>>> >>>>> =A0Clarify the use and >>>>>> behavior of the logical interface on PtP links. >>>>> >>>>> >>>>> Folks: Again, reflecting the team's contributions on this topic, the >>>>> authors >>>>> of this document have discussed this and resolve it with the followin= g >>>>> text. >>>>> The key points we tried to reflect are around that the logical interf= ace >>>>> appears to the application as a shared link. There were thoughts arou= nd >>>>> making it appear like a p2p link, given that there are multiple neigh= bors >>>>> on >>>>> each sub interface, this choice appears reasonable. With respect to h= ow a >>>>> packet is transmitted, is still based on the chosen link model at eac= h sub >>>>> interface level. Let us know, if you see any issues with it. This is = proven >>>>> based on the multiple implementations from some of the co-authors of = this >>>>> doc. >>>>> >>>>> >>>>> >>>>> >>>>> --- >>>>> 6.3. =A0Supported Link models for a logical interface >>>>> >>>>> =A0The sub-interfaces of a logical interface can be bound to a point-= to- >>>>> =A0 point or a shared link (Example: LTE and WLAN). =A0The logical >>>>> =A0 interface appears as a shared-link to the applications, and adapt= s to >>>>> =A0 the link model of the sub-interface for packet communication. =A0= For >>>>> =A0 example, when transmitting a packet on a sub-interface which is >>>>> =A0 attached to a p2p link, the transmission conforms to the p2p link >>>>> =A0 model and when transmitting on a sub-interface attached to a shar= ed >>>>> =A0 link, the transmission conforms to the shared link model. >>>>> >>>>> =A0 Based on the link to which the sub-interface is attached to, the >>>>> =A0 layer-2 resolutions may or may not be needed. =A0If the interface= is >>>>> =A0 bound to a P2P link with PPP running, there will not be any link- >>>>> =A0 layer resolutions in the form of ARP/ND messages. =A0However, if = the >>>>> =A0 interface is bound to a shared link such as Ethernet, there will = be >>>>> =A0 ND resolutions. =A0The logical interface implementation has to ma= intain >>>>> =A0 the required link model and the associated state for each sub- >>>>> =A0 interface. >>>>> -- >>>>> >>>>> >>>>> >>>>> >>>>> On 3/3/11 9:17 AM, "netext issue tracker" <trac+netext@trac.tools.iet= f.org> >>>>> wrote: >>>>> >>>>>> #4: Logical interface support: Point to point links >>>>> >>>>> =A0Clarify the use and >>>>>> behavior of the logical interface on PtP links. >>>>> >>>>> -- >>>>>> >>>>> > ---------------------------------------+---------------------------------= -->>>> > - >>>>> >>>>>> Reporter: =A0basavaraj.patil@=A9 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Ow= ner: =A0telemaco.melia@=A9 >>>>>> >>>>> =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0= =A0 =A0Status: =A0new >>>>>> >>>>> =A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 Milestone: >>>>>> >>>>> Component: =A0logical-interface-support =A0| =A0 =A0 Version: >>>>>> >>>>> =A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= | =A0 =A0Keywords: >>>>>> >>>>> > ---------------------------------------+---------------------------------= -->>>> > - >>>>> >>>>>> >>>>> Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/4> >>>>> netext >>>>>> <http://tools.ietf.org/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 sgundave@cisco.com Tue Mar 15 17:45:41 2011 Return-Path: <sgundave@cisco.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED3973A6F2B for <netext@core3.amsl.com>; Tue, 15 Mar 2011 17:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.433 X-Spam-Level: X-Spam-Status: No, score=-9.433 tagged_above=-999 required=5 tests=[AWL=-0.230, 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 xjBlgSE-03qy for <netext@core3.amsl.com>; Tue, 15 Mar 2011 17:45:40 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 976983A6BA0 for <netext@ietf.org>; Tue, 15 Mar 2011 17:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=8130; q=dns/txt; s=iport; t=1300236426; x=1301446026; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=UfT1yl/ny24pe1UVmj4XDh+K39qX80cpU02HrCvjz0w=; b=mKtopE28TV5Zzdqu3cNxEEFNhNAU4p63UagdJPVLTUT92I82rH4x3AzF fsA4XAvNGqDI0OwvegqV/xnsGI6utePigrDypaaRecq4G70pAIIZ1O8ek y9B92Jt7wio9Gg9sBA5Om0inSIX7JW3g/0SuekPbvjXnPxL3UPc6oWkJU U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACalf02tJXHA/2dsb2JhbAClOVV3pG2cZoViBIUwhy2DVYMf X-IronPort-AV: E=Sophos;i="4.63,191,1299456000"; d="scan'208";a="320718254" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by sj-iport-2.cisco.com with ESMTP; 16 Mar 2011 00:47:06 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2G0l5On012606; Wed, 16 Mar 2011 00:47:05 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, 15 Mar 2011 17:47:05 -0700 Received: from 10.32.243.120 ([10.32.243.120]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Wed, 16 Mar 2011 00:47:05 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 15 Mar 2011 17:47:04 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: Julien Laganier <julien.ietf@gmail.com> Message-ID: <C9A55698.138D6%sgundave@cisco.com> Thread-Topic: [netext] #4: Logical interface support: Point to point links Thread-Index: Acvjc6sCQ2vmTEqYAUSUEoSXJ4wG9A== In-Reply-To: <AANLkTi=2CoE5G5M5GuRKBd7mcty9eCCEmuVYdtb=S3va@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-2" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 16 Mar 2011 00:47:05.0540 (UTC) FILETIME=[ABED7040:01CBE373] Cc: netext@ietf.org Subject: Re: [netext] #4: Logical interface support: Point to point links X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Mar 2011 00:45:42 -0000 Looks like I prompted you to say this :), when you were not exactly thinkin= g about that. Surely an over specification in my email text. I'm not sure I agree. There is no 1:1 relation between a link model and an Access Technology. Even in 802.11, every frame goes back the AP, its the AP's choice on what gets blocked. So, that P2P link model is there even in 802.11 shared media. If my memory serves right, I know some one who posted few emails 3 years back in netlmm, as how to achieve this P2P links in 802.11 and use it as PMIPv6 access links. Is that you ? :) Sri On 3/15/11 4:36 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: > Actually, the point to point link depends on access type. Tunnels are > point to point by nature so there is nothing to do. 802.11 is a shared > media thus unless you can enforce that only two IP nodes are attached > to the link it doesn' t qualify as a point-to-point link and thus 5213 > doesn' t work. This is the stuff that i supposed to go in the > applicability statement for the logical interface that this WG is > chartered to produce thus I do not understand what you mean by > overspecification. It would atcually be underspecification in terms of > the deliverable we have. >=20 > --julien >=20 > 2011/3/15 Sri Gundavelli <sgundave@cisco.com>: >> Julien: >>=20 >> We all agree, the link model is still P2P. All I'm saying, we should not >> classify P2P vs Non-P2P, based on the access technology type. I can buil= d >> P2P link on an IPsec tunnel, 802.11 access, or a GRE tunnel. We just req= uire >> P2P communication semantics, if we specify more that this, it will be an >> over specification. Lets work out the text for this. >>=20 >>=20 >> Sri >>=20 >>=20 >>=20 >> On 3/15/11 3:51 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: >>=20 >>> Sri: >>>=20 >>> I am going to repeat it once again: you are equating advertizing or >>> per-MN subnet prefix to a point-to-point link, but these are two >>> different things, thus I am saying that we have a problem as 5213 is >>> limited to support of point-to-point links. >>>=20 >>> --julien >>>=20 >>> 2011/3/14 Sri Gundavelli <sgundave@cisco.com>: >>>> Julien: >>>>=20 >>>> Lets see, what is the violation here ? >>>>=20 >>>> - We are stating the logical interface appears to the applications as = an >>>> interface attached to a shared link. For the simple reason, that we ha= ve >>>> multiple neighbors on different network segments attached through diff= erent >>>> sub-interface of that logical interface. We don't have a single >>>> neighbor/MAG. >>>>=20 >>>> - "Underneath the logical interface ...", there are sub-interfaces whi= ch >>>> may >>>> be very well attached to different p2p links. As long as the network h= as >>>> the >>>> semantics to send a RA with PIO, exclusively to this node, no other no= de on >>>> that access link can receive that Prefix set, we are confirming to 521= 3 >>>> link >>>> model. From any of the MAG's perspective, attached to any of the acces= s >>>> links, it can still be kept as a p2p link >>>>=20 >>>> - Exposing the logical interface as a shared link to the applications = on >>>> the >>>> *mobile node*, is not violating 5213 principles. The path chosen for a >>>> packet through a sub-interface can be still a p2p link and the rules o= f >>>> link-layer resolution of the peer, or adding l2 headers skipping l2 >>>> resolution, is still the approach in use. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Sri >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 3/14/11 5:20 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: >>>>=20 >>>>> Sri - >>>>>=20 >>>>> 5213 supports only PtP links thus I do not understand how the >>>>> following resolution resolves anything. Please clarify what is the >>>>> issue you' re addressing and how this is addressing it. >>>>>=20 >>>>> --julien >>>>>=20 >>>>> On Mon, Mar 14, 2011 at 4:24 PM, Sri Gundavelli <sgundave@cisco.com> >>>>> wrote: >>>>>>> #4: Logical interface support: Point to point links >>>>>>=20 >>>>>> =A0Clarify the use and >>>>>>> behavior of the logical interface on PtP links. >>>>>>=20 >>>>>>=20 >>>>>> Folks: Again, reflecting the team's contributions on this topic, the >>>>>> authors >>>>>> of this document have discussed this and resolve it with the followi= ng >>>>>> text. >>>>>> The key points we tried to reflect are around that the logical inter= face >>>>>> appears to the application as a shared link. There were thoughts aro= und >>>>>> making it appear like a p2p link, given that there are multiple neig= hbors >>>>>> on >>>>>> each sub interface, this choice appears reasonable. With respect to = how a >>>>>> packet is transmitted, is still based on the chosen link model at ea= ch >>>>>> sub >>>>>> interface level. Let us know, if you see any issues with it. This is >>>>>> proven >>>>>> based on the multiple implementations from some of the co-authors of= this >>>>>> doc. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> --- >>>>>> 6.3. =A0Supported Link models for a logical interface >>>>>>=20 >>>>>> =A0The sub-interfaces of a logical interface can be bound to a point-t= o- >>>>>> =A0 point or a shared link (Example: LTE and WLAN). =A0The logical >>>>>> =A0 interface appears as a shared-link to the applications, and adapts= to >>>>>> =A0 the link model of the sub-interface for packet communication. =A0For >>>>>> =A0 example, when transmitting a packet on a sub-interface which is >>>>>> =A0 attached to a p2p link, the transmission conforms to the p2p link >>>>>> =A0 model and when transmitting on a sub-interface attached to a share= d >>>>>> =A0 link, the transmission conforms to the shared link model. >>>>>>=20 >>>>>> =A0 Based on the link to which the sub-interface is attached to, the >>>>>> =A0 layer-2 resolutions may or may not be needed. =A0If the interface is >>>>>> =A0 bound to a P2P link with PPP running, there will not be any link- >>>>>> =A0 layer resolutions in the form of ARP/ND messages. =A0However, if the >>>>>> =A0 interface is bound to a shared link such as Ethernet, there will b= e >>>>>> =A0 ND resolutions. =A0The logical interface implementation has to maint= ain >>>>>> =A0 the required link model and the associated state for each sub- >>>>>> =A0 interface. >>>>>> -- >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 3/3/11 9:17 AM, "netext issue tracker" >>>>>> <trac+netext@trac.tools.ietf.org> >>>>>> wrote: >>>>>>=20 >>>>>>> #4: Logical interface support: Point to point links >>>>>>=20 >>>>>> =A0Clarify the use and >>>>>>> behavior of the logical interface on PtP links. >>>>>>=20 >>>>>> -- >>>>>>>=20 >>>>>>=20 >> ---------------------------------------+--------------------------------= --->> >> >> >> - >>>>>>=20 >>>>>>> Reporter: =A0basavaraj.patil@=A9 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Owner: =A0telemaco.meli= a@=A9 >>>>>>>=20 >>>>>> =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status: =A0new >>>>>>>=20 >>>>>> =A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 Milestone: >>>>>>>=20 >>>>>> Component: =A0logical-interface-support =A0| =A0 =A0 Version: >>>>>>>=20 >>>>>> =A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0Keywords: >>>>>>>=20 >>>>>>=20 >> ---------------------------------------+--------------------------------= --->> >> >> >> - >>>>>>=20 >>>>>>>=20 >>>>>> Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/4> >>>>>> netext >>>>>>> <http://tools.ietf.org/netext/> >>>>>>=20 >>>>>> _____________________________________________ >>>>>>> __ >>>>>> netext mailing >>>>>>> list >>>>>> netext@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netext >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> netext mailing list >>>>>> netext@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netext >>>>>>=20 >>>>=20 >>>>=20 >>=20 >>=20 From julien.ietf@gmail.com Tue Mar 15 18:43:17 2011 Return-Path: <julien.ietf@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0CB73A6B1F for <netext@core3.amsl.com>; Tue, 15 Mar 2011 18:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.292 X-Spam-Level: X-Spam-Status: No, score=-3.292 tagged_above=-999 required=5 tests=[AWL=0.307, 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 PGFMghmMAL3o for <netext@core3.amsl.com>; Tue, 15 Mar 2011 18:43:15 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 5298F3A6B10 for <netext@ietf.org>; Tue, 15 Mar 2011 18:43:14 -0700 (PDT) Received: by fxm15 with SMTP id 15so1275347fxm.31 for <netext@ietf.org>; Tue, 15 Mar 2011 18:44:40 -0700 (PDT) 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=TNwlxB6dCvURZHfyClpdmL6ToU+yblXT99PxYo3JLVw=; b=uwXu9/m8HGX9aQGnc+JgcVPP/r48r2AUgArjvnpsCU4mixyirtkcj4BR90qNMKd84z EYPTlNHGY2mnsag+nktA1R1aauO7a3jswsrlqLl2KLzmNRc9rBpeSNpB1fAZhnON4Enl GtSgkIdzYl9anqRivV0oHLwu7td/1JcYN17Pk= 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=Hs/Xy7jOrBzz2Mv0NVlv2Ez3wG2SIlRXKlAz4H2Byycr42gj7UztR7ZBmUOA7sO9Uh lZKzsI2Wke94NCyLGPdSce+OTzqB615hYeMTvvYawr1N2HpLiGCOpVUC+Uap0lB/34BF uVCXVcv0CoJ/qeg6bm9u/a9Ye0spt5q6LJ+Og= MIME-Version: 1.0 Received: by 10.223.98.141 with SMTP id q13mr221897fan.96.1300239879932; Tue, 15 Mar 2011 18:44:39 -0700 (PDT) Received: by 10.223.78.135 with HTTP; Tue, 15 Mar 2011 18:44:39 -0700 (PDT) In-Reply-To: <C9A55698.138D6%sgundave@cisco.com> References: <AANLkTi=2CoE5G5M5GuRKBd7mcty9eCCEmuVYdtb=S3va@mail.gmail.com> <C9A55698.138D6%sgundave@cisco.com> Date: Tue, 15 Mar 2011 18:44:39 -0700 Message-ID: <AANLkTimuik=quvGJ0-b8=ptxqNH_TqoAGYJaP0e01Y4b@mail.gmail.com> From: Julien Laganier <julien.ietf@gmail.com> To: Sri Gundavelli <sgundave@cisco.com> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] #4: Logical interface support: Point to point links X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Mar 2011 01:43:17 -0000 2011/3/15 Sri Gundavelli <sgundave@cisco.com>: > Looks like I prompted you to say this :), when you were not exactly think= ing > about that. Surely an over specification in my email text. I've been thinking about this for a long time, trust me. > I'm not sure I agree. There is no 1:1 relation between a link model and a= n > Access Technology. Even in 802.11, every frame goes back the AP, its the > AP's choice on what gets blocked. So, that P2P link model is there even i= n > 802.11 shared media. In 802.11 the MAC exposes a shared link to the IP layer. Now I am not saying the technology can't construed into giving you a point to point link, but that is something that a vanilla 802.11 will not give you thus this has to be explained in the applicability statement. That is exactly the raison d' etre of such a statement... > If my memory serves right, I know some one who posted few emails 3 years > back in netlmm, as how to achieve this P2P links in 802.11 and use it as > PMIPv6 access links. Is that you ? :) I think your memory is mixing up things. Some years ago I've been trying to get NETLMM to work on shared link, as it wouldn't work on them "as is" without additional mechanism in place. At this time however the WG decided to not work on these mechanism and restrict the applicability of NETLMM to point-to-point links. That's what happened. Now we have to live with the limited scope that was decided upon, and I didn' t make that decision. --julien > On 3/15/11 4:36 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: > >> Actually, the point to point link depends on access type. Tunnels are >> point to point by nature so there is nothing to do. 802.11 is a shared >> media thus unless you can enforce that only two IP nodes are attached >> to the link it doesn' t qualify as a point-to-point link and thus 5213 >> doesn' t work. This is the stuff that i supposed to go in the >> applicability statement for the logical interface that this WG is >> chartered to produce thus I do not understand what you mean by >> overspecification. It would atcually be underspecification in terms of >> the deliverable we have. >> >> --julien >> >> 2011/3/15 Sri Gundavelli <sgundave@cisco.com>: >>> Julien: >>> >>> We all agree, the link model is still P2P. All I'm saying, we should no= t >>> classify P2P vs Non-P2P, based on the access technology type. I can bui= ld >>> P2P link on an IPsec tunnel, 802.11 access, or a GRE tunnel. We just re= quire >>> P2P communication semantics, if we specify more that this, it will be a= n >>> over specification. Lets work out the text for this. >>> >>> >>> Sri >>> >>> >>> >>> On 3/15/11 3:51 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: >>> >>>> Sri: >>>> >>>> I am going to repeat it once again: you are equating advertizing or >>>> per-MN subnet prefix to a point-to-point link, but these are two >>>> different things, thus I am saying that we have a problem as 5213 is >>>> limited to support of point-to-point links. >>>> >>>> --julien >>>> >>>> 2011/3/14 Sri Gundavelli <sgundave@cisco.com>: >>>>> Julien: >>>>> >>>>> Lets see, what is the violation here ? >>>>> >>>>> - We are stating the logical interface appears to the applications as= an >>>>> interface attached to a shared link. For the simple reason, that we h= ave >>>>> multiple neighbors on different network segments attached through dif= ferent >>>>> sub-interface of that logical interface. We don't have a single >>>>> neighbor/MAG. >>>>> >>>>> - "Underneath the logical interface ...", there are sub-interfaces wh= ich >>>>> may >>>>> be very well attached to different p2p links. As long as the network = has >>>>> the >>>>> semantics to send a RA with PIO, exclusively to this node, no other n= ode on >>>>> that access link can receive that Prefix set, we are confirming to 52= 13 >>>>> link >>>>> model. From any of the MAG's perspective, attached to any of the acce= ss >>>>> links, it can still be kept as a p2p link >>>>> >>>>> - Exposing the logical interface as a shared link to the applications= on >>>>> the >>>>> *mobile node*, is not violating 5213 principles. The path chosen for = a >>>>> packet through a sub-interface can be still a p2p link and the rules = of >>>>> link-layer resolution of the peer, or adding l2 headers skipping l2 >>>>> resolution, is still the approach in use. >>>>> >>>>> >>>>> >>>>> >>>>> Sri >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 3/14/11 5:20 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: >>>>> >>>>>> Sri - >>>>>> >>>>>> 5213 supports only PtP links thus I do not understand how the >>>>>> following resolution resolves anything. Please clarify what is the >>>>>> issue you' re addressing and how this is addressing it. >>>>>> >>>>>> --julien >>>>>> >>>>>> On Mon, Mar 14, 2011 at 4:24 PM, Sri Gundavelli <sgundave@cisco.com> >>>>>> wrote: >>>>>>>> #4: Logical interface support: Point to point links >>>>>>> >>>>>>> =A0Clarify the use and >>>>>>>> behavior of the logical interface on PtP links. >>>>>>> >>>>>>> >>>>>>> Folks: Again, reflecting the team's contributions on this topic, th= e >>>>>>> authors >>>>>>> of this document have discussed this and resolve it with the follow= ing >>>>>>> text. >>>>>>> The key points we tried to reflect are around that the logical inte= rface >>>>>>> appears to the application as a shared link. There were thoughts ar= ound >>>>>>> making it appear like a p2p link, given that there are multiple nei= ghbors >>>>>>> on >>>>>>> each sub interface, this choice appears reasonable. With respect to= how a >>>>>>> packet is transmitted, is still based on the chosen link model at e= ach >>>>>>> sub >>>>>>> interface level. Let us know, if you see any issues with it. This i= s >>>>>>> proven >>>>>>> based on the multiple implementations from some of the co-authors o= f this >>>>>>> doc. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> --- >>>>>>> 6.3. =A0Supported Link models for a logical interface >>>>>>> >>>>>>> =A0The sub-interfaces of a logical interface can be bound to a poin= t-to- >>>>>>> =A0 point or a shared link (Example: LTE and WLAN). =A0The logical >>>>>>> =A0 interface appears as a shared-link to the applications, and ada= pts to >>>>>>> =A0 the link model of the sub-interface for packet communication. = =A0For >>>>>>> =A0 example, when transmitting a packet on a sub-interface which is >>>>>>> =A0 attached to a p2p link, the transmission conforms to the p2p li= nk >>>>>>> =A0 model and when transmitting on a sub-interface attached to a sh= ared >>>>>>> =A0 link, the transmission conforms to the shared link model. >>>>>>> >>>>>>> =A0 Based on the link to which the sub-interface is attached to, th= e >>>>>>> =A0 layer-2 resolutions may or may not be needed. =A0If the interfa= ce is >>>>>>> =A0 bound to a P2P link with PPP running, there will not be any lin= k- >>>>>>> =A0 layer resolutions in the form of ARP/ND messages. =A0However, i= f the >>>>>>> =A0 interface is bound to a shared link such as Ethernet, there wil= l be >>>>>>> =A0 ND resolutions. =A0The logical interface implementation has to = maintain >>>>>>> =A0 the required link model and the associated state for each sub- >>>>>>> =A0 interface. >>>>>>> -- >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 3/3/11 9:17 AM, "netext issue tracker" >>>>>>> <trac+netext@trac.tools.ietf.org> >>>>>>> wrote: >>>>>>> >>>>>>>> #4: Logical interface support: Point to point links >>>>>>> >>>>>>> =A0Clarify the use and >>>>>>>> behavior of the logical interface on PtP links. >>>>>>> >>>>>>> -- >>>>>>>> >>>>>>> >>> ---------------------------------------+-------------------------------= ---->> >>> >> >>> - >>>>>>> >>>>>>>> Reporter: =A0basavaraj.patil@=A9 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 = Owner: =A0telemaco.melia@=A9 >>>>>>>> >>>>>>> =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | = =A0 =A0 =A0Status: =A0new >>>>>>>> >>>>>>> =A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 Milestone: >>>>>>>> >>>>>>> Component: =A0logical-interface-support =A0| =A0 =A0 Version: >>>>>>>> >>>>>>> =A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| =A0 =A0Keywords: >>>>>>>> >>>>>>> >>> ---------------------------------------+-------------------------------= ---->> >>> >> >>> - >>>>>>> >>>>>>>> >>>>>>> Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/4> >>>>>>> netext >>>>>>>> <http://tools.ietf.org/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 pierrick.seite@orange-ftgroup.com Wed Mar 16 00:20:49 2011 Return-Path: <pierrick.seite@orange-ftgroup.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C0863A681E for <netext@core3.amsl.com>; Wed, 16 Mar 2011 00:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=0.248, 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 iqc+MHcUd+gk for <netext@core3.amsl.com>; Wed, 16 Mar 2011 00:20:46 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 4D2203A681C for <netext@ietf.org>; Wed, 16 Mar 2011 00:20:46 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A0B70FC4003; Wed, 16 Mar 2011 08:22:17 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 92C02FC4001; Wed, 16 Mar 2011 08:22:17 +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 Mar 2011 08:22:11 +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: Wed, 16 Mar 2011 08:22:10 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C4620190B829@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <C9A54F91.138B8%sgundave@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] #4: Logical interface support: Point to point links Thread-Index: AcvitTxenbMujdRwpUe3xtq+9Nb7nQAOp6rwAB/n7CUADtVwIA== References: <843DA8228A1BA74CA31FB4E111A5C4620190B524@ftrdmel0.rd.francetelecom.fr> <C9A54F91.138B8%sgundave@cisco.com> From: <pierrick.seite@orange-ftgroup.com> To: <sgundave@cisco.com>, <julien.ietf@gmail.com> X-OriginalArrivalTime: 16 Mar 2011 07:22:11.0033 (UTC) FILETIME=[DD809C90:01CBE3AA] Cc: netext@ietf.org Subject: Re: [netext] #4: Logical interface support: Point to point links X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Mar 2011 07:20:49 -0000 DQphZ3JlZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogU3JpIEd1 bmRhdmVsbGkgW21haWx0bzpzZ3VuZGF2ZUBjaXNjby5jb21dDQo+IEVudm95w6nCoDogbWVyY3Jl ZGkgMTYgbWFycyAyMDExIDAyOjE3DQo+IMOAwqA6IFNFSVRFIFBpZXJyaWNrIFJELVJFU0EtUkVO OyBqdWxpZW4uaWV0ZkBnbWFpbC5jb20NCj4gQ2PCoDogbmV0ZXh0QGlldGYub3JnDQo+IE9iamV0 wqA6IFJlOiBbbmV0ZXh0XSAjNDogTG9naWNhbCBpbnRlcmZhY2Ugc3VwcG9ydDogUG9pbnQgdG8g cG9pbnQgbGlua3MNCj4gDQo+IEhpIFBpZXJyaWNrLA0KPiANCj4gVGhlIHNlbnRlbmNlIGNhbiBi ZSByZXdvcmRlZC4gQWdyZWUsIHRoZSBsaW5rIG1vZGVsIGJldHdlZW4gdGhlIE1BRyBhbmQNCj4g dGhlDQo+IE1OIGlzIHN0aWxsIGEgcG9pbnQtdG8tcG9pbnQgbGluay4gRnJvbSA1MjEzIHBlcnNw ZWN0aXZlLCBhcyBsb25nIGFzIHRoZQ0KPiBwb2ludC10by1wb2ludCBjb21tdW5pY2F0aW9uIHNl bWFudGljcyBhcmUgdGhlcmUgYmV0d2VlbiB0aGUgTU4gYW5kIE1BRywNCj4gd2UNCj4gbWVldCB0 aGUgcmVxdWlyZW1lbnQgYW5kIHRoZXJlIGlzIG5vIHByb3RvY29sIHZpb2xhdGlvbi4gIEhvdyB0 aGF0IFAyUA0KPiBsaW5rDQo+IG1vZGVsIGlzIGFjaGlldmVkLCBiYXNlZCBhIHR1bm5lbCBpbnRl cmZhY2UsIHB1dHRpbmcgdGhlIGFjY2VzcyBwb2ludCBpbiBhDQo+IHVuaWNhc3QgbW9kZSwgYXJl IGFsbCB0aGUgcG9zc2libGUgb3B0aW9ucy4NCj4gDQo+IA0KPiANCj4gU3JpDQo+IA0KPiANCj4g DQo+IE9uIDMvMTUvMTEgMToyMSBBTSwgInBpZXJyaWNrLnNlaXRlQG9yYW5nZS1mdGdyb3VwLmNv bSINCj4gPHBpZXJyaWNrLnNlaXRlQG9yYW5nZS1mdGdyb3VwLmNvbT4gd3JvdGU6DQo+IA0KPiA+ DQo+ID4gSGkgU3JpLA0KPiA+DQo+ID4gSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgdGhlcmUg aXMgbm8gdmlvbGF0aW9uIG9mIFJGQzUyMTMgaWYgYWxsDQo+IHBoeXNpY2FsDQo+ID4gbGlua3Mg YXJlIHAycC4gSG93ZXZlciB0aGUgcHJvcG9zZWQgdGV4dCBhbGxvd3MgdGhlIHZpcnR1YWwgaW50 ZXJmYWNlIHRvDQo+IGJvdW5kDQo+ID4gcGh5c2ljYWwgc2hhcmVkIGxpbmtzLiBJZiBzbywgSSB0 aGluayB3ZSBtYXkgaGF2ZSB0aGUgaXNzdWUgZGVzY3JpYmVkIGluDQo+ID4gc2VjdGlvbiA0LjIg b2YgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRsbW0tbW4tYXItaWYt MDMuDQo+ID4gTWF5YmUsIHRoZSB0ZXh0IHNob3VsZCBiZSBjbGFyaWZpZWQgdG8gcmVzdHJpY3Qg dG8gcGh5c2ljYWwgcDJwIGxpbmtzLg0KPiA+DQo+ID4gQlIsDQo+ID4gUGllcnJpY2sNCj4gPg0K PiA+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPj4gRGXCoDogbmV0ZXh0LWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpuZXRleHQtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGENCj4gcGFy dA0KPiA+PiBkZSBTcmkgR3VuZGF2ZWxsaQ0KPiA+PiBFbnZvecOpwqA6IG1hcmRpIDE1IG1hcnMg MjAxMSAwNDowNA0KPiA+PiDDgMKgOiBKdWxpZW4gTGFnYW5pZXINCj4gPj4gQ2PCoDogbmV0ZXh0 QGlldGYub3JnDQo+ID4+IE9iamV0wqA6IFJlOiBbbmV0ZXh0XSAjNDogTG9naWNhbCBpbnRlcmZh Y2Ugc3VwcG9ydDogUG9pbnQgdG8gcG9pbnQNCj4gbGlua3MNCj4gPj4NCj4gPj4gSnVsaWVuOg0K PiA+Pg0KPiA+PiBMZXRzIHNlZSwgd2hhdCBpcyB0aGUgdmlvbGF0aW9uIGhlcmUgPw0KPiA+Pg0K PiA+PiAtIFdlIGFyZSBzdGF0aW5nIHRoZSBsb2dpY2FsIGludGVyZmFjZSBhcHBlYXJzIHRvIHRo ZSBhcHBsaWNhdGlvbnMgYXMNCj4gYW4NCj4gPj4gaW50ZXJmYWNlIGF0dGFjaGVkIHRvIGEgc2hh cmVkIGxpbmsuIEZvciB0aGUgc2ltcGxlIHJlYXNvbiwgdGhhdCB3ZQ0KPiBoYXZlDQo+ID4+IG11 bHRpcGxlIG5laWdoYm9ycyBvbiBkaWZmZXJlbnQgbmV0d29yayBzZWdtZW50cyBhdHRhY2hlZCB0 aHJvdWdoDQo+ID4+IGRpZmZlcmVudA0KPiA+PiBzdWItaW50ZXJmYWNlIG9mIHRoYXQgbG9naWNh bCBpbnRlcmZhY2UuIFdlIGRvbid0IGhhdmUgYSBzaW5nbGUNCj4gPj4gbmVpZ2hib3IvTUFHLg0K PiA+Pg0KPiA+PiAtICJVbmRlcm5lYXRoIHRoZSBsb2dpY2FsIGludGVyZmFjZSAuLi4iLCB0aGVy ZSBhcmUgc3ViLWludGVyZmFjZXMNCj4gd2hpY2gNCj4gPj4gbWF5DQo+ID4+IGJlIHZlcnkgd2Vs bCBhdHRhY2hlZCB0byBkaWZmZXJlbnQgcDJwIGxpbmtzLiBBcyBsb25nIGFzIHRoZSBuZXR3b3Jr DQo+IGhhcw0KPiA+PiB0aGUNCj4gPj4gc2VtYW50aWNzIHRvIHNlbmQgYSBSQSB3aXRoIFBJTywg ZXhjbHVzaXZlbHkgdG8gdGhpcyBub2RlLCBubyBvdGhlcg0KPiBub2RlDQo+ID4+IG9uDQo+ID4+ IHRoYXQgYWNjZXNzIGxpbmsgY2FuIHJlY2VpdmUgdGhhdCBQcmVmaXggc2V0LCB3ZSBhcmUgY29u ZmlybWluZyB0byA1MjEzDQo+ID4+IGxpbmsNCj4gPj4gbW9kZWwuIEZyb20gYW55IG9mIHRoZSBN QUcncyBwZXJzcGVjdGl2ZSwgYXR0YWNoZWQgdG8gYW55IG9mIHRoZSBhY2Nlc3MNCj4gPj4gbGlu a3MsIGl0IGNhbiBzdGlsbCBiZSBrZXB0IGFzIGEgcDJwIGxpbmsNCj4gPj4NCj4gPj4gLSBFeHBv c2luZyB0aGUgbG9naWNhbCBpbnRlcmZhY2UgYXMgYSBzaGFyZWQgbGluayB0byB0aGUgYXBwbGlj YXRpb25zDQo+IG9uDQo+ID4+IHRoZQ0KPiA+PiAqbW9iaWxlIG5vZGUqLCBpcyBub3QgdmlvbGF0 aW5nIDUyMTMgcHJpbmNpcGxlcy4gVGhlIHBhdGggY2hvc2VuIGZvciBhDQo+ID4+IHBhY2tldCB0 aHJvdWdoIGEgc3ViLWludGVyZmFjZSBjYW4gYmUgc3RpbGwgYSBwMnAgbGluayBhbmQgdGhlIHJ1 bGVzIG9mDQo+ID4+IGxpbmstbGF5ZXIgcmVzb2x1dGlvbiBvZiB0aGUgcGVlciwgb3IgYWRkaW5n IGwyIGhlYWRlcnMgc2tpcHBpbmcgbDINCj4gPj4gcmVzb2x1dGlvbiwgaXMgc3RpbGwgdGhlIGFw cHJvYWNoIGluIHVzZS4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gU3JpDQo+ID4+DQo+ ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IE9uIDMvMTQvMTEg NToyMCBQTSwgIkp1bGllbiBMYWdhbmllciIgPGp1bGllbi5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6 DQo+ID4+DQo+ID4+PiBTcmkgLQ0KPiA+Pj4NCj4gPj4+IDUyMTMgc3VwcG9ydHMgb25seSBQdFAg bGlua3MgdGh1cyBJIGRvIG5vdCB1bmRlcnN0YW5kIGhvdyB0aGUNCj4gPj4+IGZvbGxvd2luZyBy ZXNvbHV0aW9uIHJlc29sdmVzIGFueXRoaW5nLiBQbGVhc2UgY2xhcmlmeSB3aGF0IGlzIHRoZQ0K PiA+Pj4gaXNzdWUgeW91JyByZSBhZGRyZXNzaW5nIGFuZCBob3cgdGhpcyBpcyBhZGRyZXNzaW5n IGl0Lg0KPiA+Pj4NCj4gPj4+IC0tanVsaWVuDQo+ID4+Pg0KPiA+Pj4gT24gTW9uLCBNYXIgMTQs IDIwMTEgYXQgNDoyNCBQTSwgU3JpIEd1bmRhdmVsbGkgPHNndW5kYXZlQGNpc2NvLmNvbT4NCj4g Pj4gd3JvdGU6DQo+ID4+Pj4+ICM0OiBMb2dpY2FsIGludGVyZmFjZSBzdXBwb3J0OiBQb2ludCB0 byBwb2ludCBsaW5rcw0KPiA+Pj4+DQo+ID4+Pj4gwqBDbGFyaWZ5IHRoZSB1c2UgYW5kDQo+ID4+ Pj4+IGJlaGF2aW9yIG9mIHRoZSBsb2dpY2FsIGludGVyZmFjZSBvbiBQdFAgbGlua3MuDQo+ID4+ Pj4NCj4gPj4+Pg0KPiA+Pj4+IEZvbGtzOiBBZ2FpbiwgcmVmbGVjdGluZyB0aGUgdGVhbSdzIGNv bnRyaWJ1dGlvbnMgb24gdGhpcyB0b3BpYywgdGhlDQo+ID4+IGF1dGhvcnMNCj4gPj4+PiBvZiB0 aGlzIGRvY3VtZW50IGhhdmUgZGlzY3Vzc2VkIHRoaXMgYW5kIHJlc29sdmUgaXQgd2l0aCB0aGUN Cj4gZm9sbG93aW5nDQo+ID4+IHRleHQuDQo+ID4+Pj4gVGhlIGtleSBwb2ludHMgd2UgdHJpZWQg dG8gcmVmbGVjdCBhcmUgYXJvdW5kIHRoYXQgdGhlIGxvZ2ljYWwNCj4gPj4gaW50ZXJmYWNlDQo+ ID4+Pj4gYXBwZWFycyB0byB0aGUgYXBwbGljYXRpb24gYXMgYSBzaGFyZWQgbGluay4gVGhlcmUg d2VyZSB0aG91Z2h0cw0KPiBhcm91bmQNCj4gPj4+PiBtYWtpbmcgaXQgYXBwZWFyIGxpa2UgYSBw MnAgbGluaywgZ2l2ZW4gdGhhdCB0aGVyZSBhcmUgbXVsdGlwbGUNCj4gPj4gbmVpZ2hib3JzIG9u DQo+ID4+Pj4gZWFjaCBzdWIgaW50ZXJmYWNlLCB0aGlzIGNob2ljZSBhcHBlYXJzIHJlYXNvbmFi bGUuIFdpdGggcmVzcGVjdCB0bw0KPiBob3cNCj4gPj4gYQ0KPiA+Pj4+IHBhY2tldCBpcyB0cmFu c21pdHRlZCwgaXMgc3RpbGwgYmFzZWQgb24gdGhlIGNob3NlbiBsaW5rIG1vZGVsIGF0DQo+IGVh Y2gNCj4gPj4gc3ViDQo+ID4+Pj4gaW50ZXJmYWNlIGxldmVsLiBMZXQgdXMga25vdywgaWYgeW91 IHNlZSBhbnkgaXNzdWVzIHdpdGggaXQuIFRoaXMgaXMNCj4gPj4gcHJvdmVuDQo+ID4+Pj4gYmFz ZWQgb24gdGhlIG11bHRpcGxlIGltcGxlbWVudGF0aW9ucyBmcm9tIHNvbWUgb2YgdGhlIGNvLWF1 dGhvcnMgb2YNCj4gPj4gdGhpcw0KPiA+Pj4+IGRvYy4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4N Cj4gPj4+Pg0KPiA+Pj4+IC0tLQ0KPiA+Pj4+IDYuMy4gwqBTdXBwb3J0ZWQgTGluayBtb2RlbHMg Zm9yIGEgbG9naWNhbCBpbnRlcmZhY2UNCj4gPj4+Pg0KPiA+Pj4+IMKgVGhlIHN1Yi1pbnRlcmZh Y2VzIG9mIGEgbG9naWNhbCBpbnRlcmZhY2UgY2FuIGJlIGJvdW5kIHRvIGEgcG9pbnQtDQo+IHRv LQ0KPiA+Pj4+IMKgIHBvaW50IG9yIGEgc2hhcmVkIGxpbmsgKEV4YW1wbGU6IExURSBhbmQgV0xB TikuIMKgVGhlIGxvZ2ljYWwNCj4gPj4+PiDCoCBpbnRlcmZhY2UgYXBwZWFycyBhcyBhIHNoYXJl ZC1saW5rIHRvIHRoZSBhcHBsaWNhdGlvbnMsIGFuZCBhZGFwdHMNCj4gdG8NCj4gPj4+PiDCoCB0 aGUgbGluayBtb2RlbCBvZiB0aGUgc3ViLWludGVyZmFjZSBmb3IgcGFja2V0IGNvbW11bmljYXRp b24uIMKgRm9yDQo+ID4+Pj4gwqAgZXhhbXBsZSwgd2hlbiB0cmFuc21pdHRpbmcgYSBwYWNrZXQg b24gYSBzdWItaW50ZXJmYWNlIHdoaWNoIGlzDQo+ID4+Pj4gwqAgYXR0YWNoZWQgdG8gYSBwMnAg bGluaywgdGhlIHRyYW5zbWlzc2lvbiBjb25mb3JtcyB0byB0aGUgcDJwIGxpbmsNCj4gPj4+PiDC oCBtb2RlbCBhbmQgd2hlbiB0cmFuc21pdHRpbmcgb24gYSBzdWItaW50ZXJmYWNlIGF0dGFjaGVk IHRvIGEgc2hhcmVkDQo+ID4+Pj4gwqAgbGluaywgdGhlIHRyYW5zbWlzc2lvbiBjb25mb3JtcyB0 byB0aGUgc2hhcmVkIGxpbmsgbW9kZWwuDQo+ID4+Pj4NCj4gPj4+PiDCoCBCYXNlZCBvbiB0aGUg bGluayB0byB3aGljaCB0aGUgc3ViLWludGVyZmFjZSBpcyBhdHRhY2hlZCB0bywgdGhlDQo+ID4+ Pj4gwqAgbGF5ZXItMiByZXNvbHV0aW9ucyBtYXkgb3IgbWF5IG5vdCBiZSBuZWVkZWQuIMKgSWYg dGhlIGludGVyZmFjZSBpcw0KPiA+Pj4+IMKgIGJvdW5kIHRvIGEgUDJQIGxpbmsgd2l0aCBQUFAg cnVubmluZywgdGhlcmUgd2lsbCBub3QgYmUgYW55IGxpbmstDQo+ID4+Pj4gwqAgbGF5ZXIgcmVz b2x1dGlvbnMgaW4gdGhlIGZvcm0gb2YgQVJQL05EIG1lc3NhZ2VzLiDCoEhvd2V2ZXIsIGlmIHRo ZQ0KPiA+Pj4+IMKgIGludGVyZmFjZSBpcyBib3VuZCB0byBhIHNoYXJlZCBsaW5rIHN1Y2ggYXMg RXRoZXJuZXQsIHRoZXJlIHdpbGwgYmUNCj4gPj4+PiDCoCBORCByZXNvbHV0aW9ucy4gwqBUaGUg bG9naWNhbCBpbnRlcmZhY2UgaW1wbGVtZW50YXRpb24gaGFzIHRvDQo+IG1haW50YWluDQo+ID4+ Pj4gwqAgdGhlIHJlcXVpcmVkIGxpbmsgbW9kZWwgYW5kIHRoZSBhc3NvY2lhdGVkIHN0YXRlIGZv ciBlYWNoIHN1Yi0NCj4gPj4+PiDCoCBpbnRlcmZhY2UuDQo+ID4+Pj4gLS0NCj4gPj4+Pg0KPiA+ Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+IE9uIDMvMy8xMSA5OjE3IEFNLCAibmV0ZXh0IGlz c3VlIHRyYWNrZXIiDQo+ID4+IDx0cmFjK25ldGV4dEB0cmFjLnRvb2xzLmlldGYub3JnPg0KPiA+ Pj4+IHdyb3RlOg0KPiA+Pj4+DQo+ID4+Pj4+ICM0OiBMb2dpY2FsIGludGVyZmFjZSBzdXBwb3J0 OiBQb2ludCB0byBwb2ludCBsaW5rcw0KPiA+Pj4+DQo+ID4+Pj4gwqBDbGFyaWZ5IHRoZSB1c2Ug YW5kDQo+ID4+Pj4+IGJlaGF2aW9yIG9mIHRoZSBsb2dpY2FsIGludGVyZmFjZSBvbiBQdFAgbGlu a3MuDQo+ID4+Pj4NCj4gPj4+PiAtLQ0KPiA+Pj4+Pg0KPiA+Pj4+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAt LQ0KPiA+PiAtLS0tLQ0KPiA+Pj4+DQo+ID4+Pj4+DQo+IFJlcG9ydGVyOiDCoGJhc2F2YXJhai5w YXRpbEDFoCDCoCDCoCDCoCDCoCDCoHwgwqAgwqAgwqAgT3duZXI6IMKgdGVsZW1hY28ubWVsaWFA xaANCj4gPj4+Pj4NCj4gPj4+PiDCoCDCoCBUeXBlOiDCoGRlZmVjdCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKgU3RhdHVzOiDCoG5ldw0KPiA+Pj4+Pg0KPiA+Pj4+IMKg UHJpb3JpdHk6IMKgbWFqb3IgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8IMKgIE1p bGVzdG9uZToNCj4gPj4+Pj4NCj4gPj4+PiBDb21wb25lbnQ6IMKgbG9naWNhbC1pbnRlcmZhY2Ut c3VwcG9ydCDCoHwgwqAgwqAgVmVyc2lvbjoNCj4gPj4+Pj4NCj4gPj4+PiDCoFNldmVyaXR5OiDC oC0gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8IMKgIMKgS2V5d29yZHM6 DQo+ID4+Pj4+DQo+ID4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tDQo+ID4+IC0tLS0tDQo+ID4+Pj4N Cj4gPj4+Pj4NCj4gPj4+PiBUaWNrZXQgVVJMOiA8aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcv d2cvbmV0ZXh0L3RyYWMvdGlja2V0LzQ+DQo+ID4+Pj4gbmV0ZXh0DQo+ID4+Pj4+IDxodHRwOi8v dG9vbHMuaWV0Zi5vcmcvbmV0ZXh0Lz4NCj4gPj4+Pg0KPiA+Pj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+PiBfXw0KPiA+Pj4+IG5ldGV4dCBt YWlsaW5nDQo+ID4+Pj4+IGxpc3QNCj4gPj4+PiBuZXRleHRAaWV0Zi5vcmcNCj4gPj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGV4dA0KPiA+Pj4+DQo+ID4+Pj4N Cj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+Pj4+IG5ldGV4dCBtYWlsaW5nIGxpc3QNCj4gPj4+PiBuZXRleHRAaWV0Zi5vcmcNCj4gPj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGV4dA0KPiA+Pj4+DQo+ ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4+IG5ldGV4dCBtYWlsaW5nIGxpc3QNCj4gPj4gbmV0ZXh0QGlldGYub3JnDQo+ID4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0DQoNCg== From pierrick.seite@orange-ftgroup.com Wed Mar 16 00:32:55 2011 Return-Path: <pierrick.seite@orange-ftgroup.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C40103A6821 for <netext@core3.amsl.com>; Wed, 16 Mar 2011 00:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=0.229, 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 17mC1+zSfI0P for <netext@core3.amsl.com>; Wed, 16 Mar 2011 00:32:54 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 8EB7C3A6820 for <netext@ietf.org>; Wed, 16 Mar 2011 00:32:53 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9E0D56D8010; Wed, 16 Mar 2011 08:34:51 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 903B56C0002; Wed, 16 Mar 2011 08:34: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); Wed, 16 Mar 2011 08:34:19 +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 Mar 2011 08:34:18 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C4620190B82F@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <3D6C64F2D792B540BAAEBCEF6509363B0EE6E5A4EB@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] #7: Logical interface: UL/DL packet processing Thread-Index: AcvZ9zLqaCiqXPtjQvqFSNx7xNb4BQJMWIEwACCXFbA= References: <066.0751fc96f72ccc7f3cfc7cb7f3fb948e@trac.tools.ietf.org> <3D6C64F2D792B540BAAEBCEF6509363B0EE6E5A4EB@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> From: <pierrick.seite@orange-ftgroup.com> To: <telemaco.melia@alcatel-lucent.com>, <trac+netext@zinfandel.tools.ietf.org>, <basavaraj.patil@nokia.com> X-OriginalArrivalTime: 16 Mar 2011 07:34:19.0351 (UTC) FILETIME=[8F9D1E70:01CBE3AC] Cc: netext@ietf.org Subject: Re: [netext] #7: Logical interface: UL/DL packet processing X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Mar 2011 07:32:55 -0000 Hi Tele, What is the reason for the flow routing policies entry in the LIF table? = IMHO, this entry is useless. I mean, routing policies should be = node-scoped and only allow to select the interface, i.e configure the = flow table; that's it.=20 BTW, when a flow handover is performed, policies should also be updated = (In order to select the correct interface for new flow).=20 BR, Pierrick > -----Message d'origine----- > De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la = part > de MELIA, TELEMACO (TELEMACO) > Envoy=E9=A0: mardi 15 mars 2011 16:57 > =C0=A0: netext issue tracker; basavaraj.patil@nokia.com > Cc=A0: netext@ietf.org > Objet=A0: Re: [netext] #7: Logical interface: UL/DL packet processing >=20 > Folks, reflecting the discussions in the team here is the proposed = text to > solve this issue. Let us know any problem you see with the proposed = text. >=20 > =3D=3D=3D=3D=3D > 6.6. Logical Interface Forwarding Conceptual Data Structures >=20 >=20 > The LIF should maintain the LIF and FLOW table data structures > depicted in Figure 4 >=20 > LIF TABLE FLOW table > = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D+ = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D+ > | PIF_ID | FLOW RoutingPolicies | | FLOW ID | PIF_ID = | > | | Home Network Prefix | = +-------------------------------+ > | | Link Layer Address | | FLOW_ID | PIF_ID = | > | | Status | = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D+ > +-------------------------------| > | PIF_ID | FLOW RoutingPolicies | > | | Home Network Prefix | > | | Link Layer Address | > | | Status | > +-------------------------------+ > | .... | .... | > = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D+ >=20 >=20 > Figure 4 >=20 > The LIF table maintains the mapping between the LIF and each PIF > associated to the LIF (see P3). For each PIF entry the table = should > store the associated Routing Policies, the Home Network Prefix > received during the SLAAC procedure, the configured Link Layer > Address (as described above) and the Status of the PIF (e.g. = active, > not active). >=20 > The method by which the Routing Policies are configured in the UE = is > out of scope of this document. It is however assumed that this > method is in place and that these policies are configured in the = LIF > TABLE. >=20 > The FLOW table allows a LIF to properly route each IP flow to the > right interface (see P7). The LIF can identify flows arriving on = its > PIFs and can map them accordingly for transmitting the = corresponding > packets. For locally generated traffic (e.g. unidirectional = outgoing > flows, mobile initiated traffic, etc.), the LIF should perform > interface selection based on the Flow Routing Policies. In case > traffic of an existing flow is suddenly received from the network = on > a different PIF than the one locally stored, the LIF should = interpret > the event as an explicit flow mobility trigger from the network and > it should update the PIF_ID parameter in the FLOW table. = Similarly, > locally generated events from the PIFs or configuration updates to > the local policy rules can cause updates to the table and hence > trigger flow mobility. >=20 >=20 > -----Message d'origine----- > De : netext issue tracker = [mailto:trac+netext@zinfandel.tools.ietf.org] > Envoy=E9 : vendredi 4 mars 2011 00:03 > =C0 : MELIA, TELEMACO (TELEMACO); basavaraj.patil@nokia.com > Cc : netext@ietf.org > Objet : [netext] #7: Logical interface: UL/DL packet processing >=20 > #7: Logical interface: UL/DL packet processing >=20 > Uplink/downlink packet matching: Draft says the Logical interface = should > transmit uplink packets on the same physical interface on which the > downlink packet was received for the particular prefix/flow. How does = the > logical interface associates an uplink packet to a downlink packet? >=20 > -- > = ---------------------------------------+-------------------------------- > ---------------------------------------+---- > Reporter: basavaraj.patil@. | Owner: = telemaco.melia@. > Type: defect | Status: new > Priority: major | Milestone: > Component: Localized routing | Version: > Severity: Active WG Document | Keywords: > = ---------------------------------------+-------------------------------- > ---------------------------------------+---- >=20 > Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/7> > netext <http://tools.ietf.org/netext/> >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Marco.Liebsch@neclab.eu Wed Mar 16 04:59:47 2011 Return-Path: <Marco.Liebsch@neclab.eu> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA5B83A6972 for <netext@core3.amsl.com>; Wed, 16 Mar 2011 04:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=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 bCw+kPwIg+-4 for <netext@core3.amsl.com>; Wed, 16 Mar 2011 04:59:46 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id 97A813A6920 for <netext@ietf.org>; Wed, 16 Mar 2011 04:59:46 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 916E928000192 for <netext@ietf.org>; Wed, 16 Mar 2011 13:02:28 +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 frMMSY200ymA for <netext@ietf.org>; Wed, 16 Mar 2011 13:02:28 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 6F3F628000171 for <netext@ietf.org>; Wed, 16 Mar 2011 13:02:23 +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, 16 Mar 2011 13:01:06 +0100 Message-ID: <4D80A682.8020906@neclab.eu> Date: Wed, 16 Mar 2011 13:01:06 +0100 From: Marco Liebsch <marco.liebsch@neclab.eu> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: <netext@ietf.org> Content-Type: multipart/mixed; boundary="------------030005070907080205030301" X-Originating-IP: [10.1.6.32] Subject: [netext] Fwd: I-D Action:draft-ietf-netext-pmip6-lr-ps-06.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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Mar 2011 11:59:48 -0000 --------------030005070907080205030301 Content-Type: multipart/alternative; boundary="------------020608060603090206040305" --------------020608060603090206040305 Content-Type: text/plain; charset="ISO-8859-15"; format=flowed Content-Transfer-Encoding: 7bit We updated the localized routing PS draft to cover comments from AD review and to meet the deadline. We will submit a further revision to address remaining comments from IESG when the submission tool has opened its doors again. marco -------- Original-Nachricht -------- Betreff: [netext] I-D Action:draft-ietf-netext-pmip6-lr-ps-06.txt Datum: Mon, 14 Mar 2011 15:15:03 -0700 Von: <Internet-Drafts@ietf.org> An: <i-d-announce@ietf.org> CC: <netext@ietf.org> 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-06.txt Pages : 19 Date : 2011-03-14 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-06.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. --------------020608060603090206040305 Content-Type: text/html; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-15"> </head> <body bgcolor="#ffffff" text="#000000"> We updated the localized routing PS draft to cover comments from AD review<br> and to meet the deadline. We will submit a further revision to address remaining<br> comments from IESG when the submission tool has opened its doors again.<br> <br> marco<br> <br> -------- Original-Nachricht -------- <table class="moz-email-headers-table" border="0" cellpadding="0" cellspacing="0"> <tbody> <tr> <th align="RIGHT" valign="BASELINE" nowrap="nowrap">Betreff: </th> <td>[netext] I-D Action:draft-ietf-netext-pmip6-lr-ps-06.txt</td> </tr> <tr> <th align="RIGHT" valign="BASELINE" nowrap="nowrap">Datum: </th> <td>Mon, 14 Mar 2011 15:15:03 -0700</td> </tr> <tr> <th align="RIGHT" valign="BASELINE" nowrap="nowrap">Von: </th> <td><a class="moz-txt-link-rfc2396E" href="mailto:Internet-Drafts@ietf.org"><Internet-Drafts@ietf.org></a></td> </tr> <tr> <th align="RIGHT" valign="BASELINE" nowrap="nowrap">An: </th> <td><a class="moz-txt-link-rfc2396E" href="mailto:i-d-announce@ietf.org"><i-d-announce@ietf.org></a></td> </tr> <tr> <th align="RIGHT" valign="BASELINE" nowrap="nowrap">CC: </th> <td><a class="moz-txt-link-rfc2396E" href="mailto:netext@ietf.org"><netext@ietf.org></a></td> </tr> </tbody> </table> <br> <br> <pre>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-06.txt Pages : 19 Date : 2011-03-14 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: <a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-ietf-netext-pmip6-lr-ps-06.txt">http://www.ietf.org/internet-drafts/draft-ietf-netext-pmip6-lr-ps-06.txt</a> Internet-Drafts are also available by anonymous FTP at: <a class="moz-txt-link-freetext" href="ftp://ftp.ietf.org/internet-drafts/">ftp://ftp.ietf.org/internet-drafts/</a> Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. </pre> </body> </html> --------------020608060603090206040305-- --------------030005070907080205030301 Content-Type: message/external-body; name="draft-ietf-netext-pmip6-lr-ps-06.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-netext-pmip6-lr-ps-06.txt" Content-Type: text/plain Content-ID: <2011-03-14151450.I-D@ietf.org> --------------030005070907080205030301 Content-Type: text/plain; name="Nachrichtenteil als Anhang" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Nachrichtenteil als Anhang" _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext --------------030005070907080205030301-- From telemaco.melia@alcatel-lucent.com Wed Mar 16 07:23:37 2011 Return-Path: <telemaco.melia@alcatel-lucent.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5E653A6957 for <netext@core3.amsl.com>; Wed, 16 Mar 2011 07:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.887 X-Spam-Level: X-Spam-Status: No, score=-3.887 tagged_above=-999 required=5 tests=[AWL=-1.638, 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 j3vBwZ63dtB2 for <netext@core3.amsl.com>; Wed, 16 Mar 2011 07:23:36 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by core3.amsl.com (Postfix) with ESMTP id 5261A3A68EA for <netext@ietf.org>; Wed, 16 Mar 2011 07:23:31 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p2GEOff9005245 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 16 Mar 2011 15:24:44 +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, 16 Mar 2011 15:24:17 +0100 From: "MELIA, TELEMACO (TELEMACO)" <telemaco.melia@alcatel-lucent.com> To: Julien Laganier <julien.ietf@gmail.com> Date: Wed, 16 Mar 2011 15:24:16 +0100 Thread-Topic: [netext] I-D Action:draft-ietf-netext-logical-interface-support-02.txt Thread-Index: AcvjK82duYM1Rp6XTdWPjURoYkVBzQAuXI0A Message-ID: <3D6C64F2D792B540BAAEBCEF6509363B0EE6E5A60E@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> References: <AANLkTinRUGJodg5JJuZ=8YQOEG4YuAXeqzwRTJ1JG8MP@mail.gmail.com> <C9A3EE03.135D4%sgundave@cisco.com> <3D6C64F2D792B540BAAEBCEF6509363B0EE6E5A41D@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> <AANLkTimDAOyYrU68MNKccNLkuAp_U2jVS_-2nWLsT9WQ@mail.gmail.com> In-Reply-To: <AANLkTimDAOyYrU68MNKccNLkuAp_U2jVS_-2nWLsT9WQ@mail.gmail.com> 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.84 Cc: "netext@ietf.org" <netext@ietf.org> Subject: Re: [netext] I-D Action:draft-ietf-netext-logical-interface-support-02.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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Mar 2011 14:23:37 -0000 No disagreement Julien. Can we assume -02 version is the starting point? >From now on only agreed text will be added to the ID. This is fine? telemaco =20 -----Message d'origine----- De : Julien Laganier [mailto:julien.ietf@gmail.com]=20 Envoy=E9 : mardi 15 mars 2011 17:12 =C0 : MELIA, TELEMACO (TELEMACO) Cc : Sri Gundavelli; netext@ietf.org Objet : Re: [netext] I-D Action:draft-ietf-netext-logical-interface-support= -02.txt And as I commented, we should discuss first and put it in the draft next. O= therwise when I look at the draft I have no idea what we have an agreement = upon and what we have not. Do you disagree with this? --julien On Tue, Mar 15, 2011 at 2:54 AM, MELIA, TELEMACO (TELEMACO) <telemaco.melia= @alcatel-lucent.com> wrote: > Julien, > > As Sri commented below this is the basis we would like to use for discuss= ions. We submitted a revised version to keep track of the changes. > > telemaco > > -----Message d'origine----- > De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la=20 > part de Sri Gundavelli Envoy=E9 : mardi 15 mars 2011 01:09 =C0 : Julien=20 > Laganier; netext@ietf.org Objet : Re: [netext] I-D=20 > Action:draft-ietf-netext-logical-interface-support-02.txt > > Hi Julien: > > We were hoping to post the text before, but we could not as we did not ha= ve the text till late. Any ways, we can use it as a starting point text for= the discussions. We can update the text as needed. If you can please revie= w and comment that will be great. > > > > Regards > Sri > > > > > On 3/14/11 2:58 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: > >> I am surprised that this document was revised without any mailing=20 >> discussions of the changes that were carried on... >> >> --julien >> >> On Mon, Mar 14, 2011 at 2:45 PM, =A0<Internet-Drafts@ietf.org> wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts=20 >>> directories. >>> This draft is a work item of the Network-Based Mobility Extensions=20 >>> Working Group of the IETF. >>> >>> >>> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Logical Interface Support fo= r multi-mode IP=20 >>> Hosts >>> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : T. Melia, S. Gundavelli >>> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: >>> draft-ietf-netext-logical-interface-support-02.txt >>> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 26 >>> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-03-14 >>> >>> A Logical Interface is a software semantic internal to the host=20 >>> operating system. =A0This semantic is available in all popular=20 >>> operating systems and is used in various protocol implementations. >>> The Logical Interface support is required on the mobile node=20 >>> operating in a Proxy Mobile IPv6 domain, for leveraging various=20 >>> network-based mobility management features such as inter-technology=20 >>> handoffs, multihoming and flow mobility support. =A0This document=20 >>> explains the operational details of Logical Interface construct and=20 >>> the specifics on how the link-layer implementations hide the=20 >>> physical interfaces from the IP stack and from the network nodes on=20 >>> the attached access networks. =A0Furthermore, this document identifies= =20 >>> the applicability of this approach to various link-layer=20 >>> technologies and analyzes the issues around it when used in context=20 >>> with various mobility management features. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-netext-logical-interf >>> a >>> ce-suppo >>> rt-02.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=20 >>> implementation to automatically retrieve the ASCII version of the=20 >>> Internet-Draft. >>> >>> >>> _______________________________________________ >>> 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 Wed Mar 16 11:29:46 2011 Return-Path: <julien.ietf@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 084A63A6947 for <netext@core3.amsl.com>; Wed, 16 Mar 2011 11:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLdY0vgj+pH2 for <netext@core3.amsl.com>; Wed, 16 Mar 2011 11:29:44 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 6D92A3A6966 for <netext@ietf.org>; Wed, 16 Mar 2011 11:29:44 -0700 (PDT) Received: by wyb42 with SMTP id 42so2133027wyb.31 for <netext@ietf.org>; Wed, 16 Mar 2011 11:31:10 -0700 (PDT) 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=rskHeCFidnt5lf0hEX2ucnMnmBiiALvxweYc7t2IoIM=; b=ZY3yFm1FNIHq3bAZFyowD5KZbZw7QpRNMZ2NbOej0nVczAoEd/cbVMDXSakYU+fKdc /FwTXZ6MGUD47lP9e1sO4AfIm+gVwO5fWapaTr4LCyaDTcIFqoIr+xNsEINKOE8h+PhN OBIEKF48bWGS7j5KjXYGnfl4/iDBPClxgDWyA= 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=TZ+u3oADqwSpXlPdpDDYMQ8InQBE8yCZnubykUf+1HBuRut+gzSl7rb3oixtVpGVXa 3Rv/E8BWW6Ra9Xy8EHgzBhEIWELS3PFRA53kcZwFRz1AXAsL4JlcXRFfYUHIGqpS4gz2 mzIKisFwlvB6+Z/9w9rNXUkGDbITUdG55NXtc= MIME-Version: 1.0 Received: by 10.216.24.73 with SMTP id w51mr284819wew.72.1300300269609; Wed, 16 Mar 2011 11:31:09 -0700 (PDT) Received: by 10.216.89.205 with HTTP; Wed, 16 Mar 2011 11:31:09 -0700 (PDT) In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C4620190B829@ftrdmel0.rd.francetelecom.fr> References: <843DA8228A1BA74CA31FB4E111A5C4620190B524@ftrdmel0.rd.francetelecom.fr> <C9A54F91.138B8%sgundave@cisco.com> <843DA8228A1BA74CA31FB4E111A5C4620190B829@ftrdmel0.rd.francetelecom.fr> Date: Wed, 16 Mar 2011 11:31:09 -0700 Message-ID: <AANLkTin7yx4DYH9cDsKEmrOunmRUOjnsOnLorHmix5sj@mail.gmail.com> From: Julien Laganier <julien.ietf@gmail.com> To: pierrick.seite@orange-ftgroup.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] #4: Logical interface support: Point to point links X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Mar 2011 18:29:46 -0000 Pierrick, I am confused... Do you disagree that a vanilla IEEE 802.11 isn't a point-to-point link? --julien On Wed, Mar 16, 2011 at 12:22 AM, <pierrick.seite@orange-ftgroup.com> wrot= e: > > agreed > >> -----Message d'origine----- >> De=C2=A0: Sri Gundavelli [mailto:sgundave@cisco.com] >> Envoy=C3=A9=C2=A0: mercredi 16 mars 2011 02:17 >> =C3=80=C2=A0: SEITE Pierrick RD-RESA-REN; julien.ietf@gmail.com >> Cc=C2=A0: netext@ietf.org >> Objet=C2=A0: Re: [netext] #4: Logical interface support: Point to point = links >> >> Hi Pierrick, >> >> The sentence can be reworded. Agree, the link model between the MAG and >> the >> MN is still a point-to-point link. From 5213 perspective, as long as the >> point-to-point communication semantics are there between the MN and MAG, >> we >> meet the requirement and there is no protocol violation. =C2=A0How that = P2P >> link >> model is achieved, based a tunnel interface, putting the access point in= a >> unicast mode, are all the possible options. >> >> >> >> Sri >> >> >> >> On 3/15/11 1:21 AM, "pierrick.seite@orange-ftgroup.com" >> <pierrick.seite@orange-ftgroup.com> wrote: >> >> > >> > Hi Sri, >> > >> > If I understand correctly, there is no violation of RFC5213 if all >> physical >> > links are p2p. However the proposed text allows the virtual interface = to >> bound >> > physical shared links. If so, I think we may have the issue described = in >> > section 4.2 of http://tools.ietf.org/html/draft-ietf-netlmm-mn-ar-if-0= 3. >> > Maybe, the text should be clarified to restrict to physical p2p links. >> > >> > BR, >> > Pierrick >> > >> >> -----Message d'origine----- >> >> De=C2=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De= la >> part >> >> de Sri Gundavelli >> >> Envoy=C3=A9=C2=A0: mardi 15 mars 2011 04:04 >> >> =C3=80=C2=A0: Julien Laganier >> >> Cc=C2=A0: netext@ietf.org >> >> Objet=C2=A0: Re: [netext] #4: Logical interface support: Point to poi= nt >> links >> >> >> >> Julien: >> >> >> >> Lets see, what is the violation here ? >> >> >> >> - We are stating the logical interface appears to the applications as >> an >> >> interface attached to a shared link. For the simple reason, that we >> have >> >> multiple neighbors on different network segments attached through >> >> different >> >> sub-interface of that logical interface. We don't have a single >> >> neighbor/MAG. >> >> >> >> - "Underneath the logical interface ...", there are sub-interfaces >> which >> >> may >> >> be very well attached to different p2p links. As long as the network >> has >> >> the >> >> semantics to send a RA with PIO, exclusively to this node, no other >> node >> >> on >> >> that access link can receive that Prefix set, we are confirming to 52= 13 >> >> link >> >> model. From any of the MAG's perspective, attached to any of the acce= ss >> >> links, it can still be kept as a p2p link >> >> >> >> - Exposing the logical interface as a shared link to the applications >> on >> >> the >> >> *mobile node*, is not violating 5213 principles. The path chosen for = a >> >> packet through a sub-interface can be still a p2p link and the rules = of >> >> link-layer resolution of the peer, or adding l2 headers skipping l2 >> >> resolution, is still the approach in use. >> >> >> >> >> >> >> >> >> >> Sri >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On 3/14/11 5:20 PM, "Julien Laganier" <julien.ietf@gmail.com> wrote: >> >> >> >>> Sri - >> >>> >> >>> 5213 supports only PtP links thus I do not understand how the >> >>> following resolution resolves anything. Please clarify what is the >> >>> issue you' re addressing and how this is addressing it. >> >>> >> >>> --julien >> >>> >> >>> On Mon, Mar 14, 2011 at 4:24 PM, Sri Gundavelli <sgundave@cisco.com> >> >> wrote: >> >>>>> #4: Logical interface support: Point to point links >> >>>> >> >>>> =C2=A0Clarify the use and >> >>>>> behavior of the logical interface on PtP links. >> >>>> >> >>>> >> >>>> Folks: Again, reflecting the team's contributions on this topic, th= e >> >> authors >> >>>> of this document have discussed this and resolve it with the >> following >> >> text. >> >>>> The key points we tried to reflect are around that the logical >> >> interface >> >>>> appears to the application as a shared link. There were thoughts >> around >> >>>> making it appear like a p2p link, given that there are multiple >> >> neighbors on >> >>>> each sub interface, this choice appears reasonable. With respect to >> how >> >> a >> >>>> packet is transmitted, is still based on the chosen link model at >> each >> >> sub >> >>>> interface level. Let us know, if you see any issues with it. This i= s >> >> proven >> >>>> based on the multiple implementations from some of the co-authors o= f >> >> this >> >>>> doc. >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> --- >> >>>> 6.3. =C2=A0Supported Link models for a logical interface >> >>>> >> >>>> =C2=A0The sub-interfaces of a logical interface can be bound to a p= oint- >> to- >> >>>> =C2=A0 point or a shared link (Example: LTE and WLAN). =C2=A0The lo= gical >> >>>> =C2=A0 interface appears as a shared-link to the applications, and = adapts >> to >> >>>> =C2=A0 the link model of the sub-interface for packet communication= . =C2=A0For >> >>>> =C2=A0 example, when transmitting a packet on a sub-interface which= is >> >>>> =C2=A0 attached to a p2p link, the transmission conforms to the p2p= link >> >>>> =C2=A0 model and when transmitting on a sub-interface attached to a= shared >> >>>> =C2=A0 link, the transmission conforms to the shared link model. >> >>>> >> >>>> =C2=A0 Based on the link to which the sub-interface is attached to,= the >> >>>> =C2=A0 layer-2 resolutions may or may not be needed. =C2=A0If the i= nterface is >> >>>> =C2=A0 bound to a P2P link with PPP running, there will not be any = link- >> >>>> =C2=A0 layer resolutions in the form of ARP/ND messages. =C2=A0Howe= ver, if the >> >>>> =C2=A0 interface is bound to a shared link such as Ethernet, there = will be >> >>>> =C2=A0 ND resolutions. =C2=A0The logical interface implementation h= as to >> maintain >> >>>> =C2=A0 the required link model and the associated state for each su= b- >> >>>> =C2=A0 interface. >> >>>> -- >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> On 3/3/11 9:17 AM, "netext issue tracker" >> >> <trac+netext@trac.tools.ietf.org> >> >>>> wrote: >> >>>> >> >>>>> #4: Logical interface support: Point to point links >> >>>> >> >>>> =C2=A0Clarify the use and >> >>>>> behavior of the logical interface on PtP links. >> >>>> >> >>>> -- >> >>>>> >> >>>> ---------------------------------------+---------------------------= -- >> -- >> >> ----- >> >>>> >> >>>>> >> Reporter: =C2=A0basavaraj.patil@=C5=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| =C2=A0 =C2=A0 =C2=A0 Owner: =C2=A0telemaco.melia@=C5=A0 >> >>>>> >> >>>> =C2=A0 =C2=A0 Type: =C2=A0defect =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0Status: =C2=A0new >> >>>>> >> >>>> =C2=A0Priority: =C2=A0major =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 Milestone: >> >>>>> >> >>>> Component: =C2=A0logical-interface-support =C2=A0| =C2=A0 =C2=A0 Ve= rsion: >> >>>>> >> >>>> =C2=A0Severity: =C2=A0- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0Keywords: >> >>>>> >> >>>> ---------------------------------------+---------------------------= -- >> -- >> >> ----- >> >>>> >> >>>>> >> >>>> Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/4> >> >>>> netext >> >>>>> <http://tools.ietf.org/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 >> >>>> >> >> >> >> _______________________________________________ >> >> netext mailing list >> >> netext@ietf.org >> >> https://www.ietf.org/mailman/listinfo/netext > > From pierrick.seite@orange-ftgroup.com Wed Mar 16 11:51:49 2011 Return-Path: <pierrick.seite@orange-ftgroup.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBDCE3A69FD for <netext@core3.amsl.com>; Wed, 16 Mar 2011 11:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.037 X-Spam-Level: X-Spam-Status: No, score=-2.037 tagged_above=-999 required=5 tests=[AWL=0.212, 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 TZ+wjrl5x+tI for <netext@core3.amsl.com>; Wed, 16 Mar 2011 11:51:48 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 08B663A6997 for <netext@ietf.org>; Wed, 16 Mar 2011 11:51:48 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 789E36C0006; Wed, 16 Mar 2011 19:53:46 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 673D46F8005; Wed, 16 Mar 2011 19:53:46 +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 Mar 2011 19:53:13 +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: Wed, 16 Mar 2011 19:53:11 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C4620190BB09@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <AANLkTin7yx4DYH9cDsKEmrOunmRUOjnsOnLorHmix5sj@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] #4: Logical interface support: Point to point links Thread-Index: AcvkCFOEDlr5rpOAQKaG+vE0XXtb4wAAKAwg References: <843DA8228A1BA74CA31FB4E111A5C4620190B524@ftrdmel0.rd.francetelecom.fr><C9A54F91.138B8%sgundave@cisco.com><843DA8228A1BA74CA31FB4E111A5C4620190B829@ftrdmel0.rd.francetelecom.fr> <AANLkTin7yx4DYH9cDsKEmrOunmRUOjnsOnLorHmix5sj@mail.gmail.com> From: <pierrick.seite@orange-ftgroup.com> To: <julien.ietf@gmail.com> X-OriginalArrivalTime: 16 Mar 2011 18:53:13.0501 (UTC) FILETIME=[670F24D0:01CBE40B] Cc: netext@ietf.org Subject: Re: [netext] #4: Logical interface support: Point to point links X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Mar 2011 18:51:49 -0000 DQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEp1bGllbiBMYWdhbmll ciBbbWFpbHRvOmp1bGllbi5pZXRmQGdtYWlsLmNvbV0NCj4gRW52b3nDqcKgOiBtZXJjcmVkaSAx NiBtYXJzIDIwMTEgMTk6MzENCj4gw4DCoDogU0VJVEUgUGllcnJpY2sgUkQtUkVTQS1SRU4NCj4g Q2PCoDogc2d1bmRhdmVAY2lzY28uY29tOyBuZXRleHRAaWV0Zi5vcmcNCj4gT2JqZXTCoDogUmU6 IFtuZXRleHRdICM0OiBMb2dpY2FsIGludGVyZmFjZSBzdXBwb3J0OiBQb2ludCB0byBwb2ludCBs aW5rcw0KPiANCj4gUGllcnJpY2ssDQo+IA0KPiBJIGFtIGNvbmZ1c2VkLi4uIERvIHlvdSBkaXNh Z3JlZSB0aGF0IGEgdmFuaWxsYSBJRUVFIDgwMi4xMSBpc24ndCBhDQo+IHBvaW50LXRvLXBvaW50 IGxpbms/DQo+IA0KDQpOby4uLiBJIHdhcyBqdXN0IGFncmVlaW5nICB0byByZXF1aXJlIHAycCBs aW5rIG1vZGVsIG9uIHRoZSBwaHlzaWNhbCBsaW5rcy4gU28sIDgwMi4xMSBjYW5ub3QgYmUgdXNl ZCB3aXRob3V0IGFkZGl0aW9uYWwgbWVjaGFuaXNtIHRvIGFjaGlldmUgYSBwb2ludC10by1wb2lu dCBsaW5rLiBBY3R1YWxseSwgbm90aGluZyBuZXcgd2l0aCByZWdhcmRzIHRvIFJGQzUyMTMuICAN Cg0KPiAtLWp1bGllbg0KPiANCj4gT24gV2VkLCBNYXIgMTYsIDIwMTEgYXQgMTI6MjIgQU0sICA8 cGllcnJpY2suc2VpdGVAb3JhbmdlLWZ0Z3JvdXAuY29tPg0KPiB3cm90ZToNCj4gPg0KPiA+IGFn cmVlZA0KPiA+DQo+ID4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+PiBEZcKgOiBT cmkgR3VuZGF2ZWxsaSBbbWFpbHRvOnNndW5kYXZlQGNpc2NvLmNvbV0NCj4gPj4gRW52b3nDqcKg OiBtZXJjcmVkaSAxNiBtYXJzIDIwMTEgMDI6MTcNCj4gPj4gw4DCoDogU0VJVEUgUGllcnJpY2sg UkQtUkVTQS1SRU47IGp1bGllbi5pZXRmQGdtYWlsLmNvbQ0KPiA+PiBDY8KgOiBuZXRleHRAaWV0 Zi5vcmcNCj4gPj4gT2JqZXTCoDogUmU6IFtuZXRleHRdICM0OiBMb2dpY2FsIGludGVyZmFjZSBz dXBwb3J0OiBQb2ludCB0byBwb2ludA0KPiBsaW5rcw0KPiA+Pg0KPiA+PiBIaSBQaWVycmljaywN Cj4gPj4NCj4gPj4gVGhlIHNlbnRlbmNlIGNhbiBiZSByZXdvcmRlZC4gQWdyZWUsIHRoZSBsaW5r IG1vZGVsIGJldHdlZW4gdGhlIE1BRyBhbmQNCj4gPj4gdGhlDQo+ID4+IE1OIGlzIHN0aWxsIGEg cG9pbnQtdG8tcG9pbnQgbGluay4gRnJvbSA1MjEzIHBlcnNwZWN0aXZlLCBhcyBsb25nIGFzDQo+ IHRoZQ0KPiA+PiBwb2ludC10by1wb2ludCBjb21tdW5pY2F0aW9uIHNlbWFudGljcyBhcmUgdGhl cmUgYmV0d2VlbiB0aGUgTU4gYW5kIE1BRywNCj4gPj4gd2UNCj4gPj4gbWVldCB0aGUgcmVxdWly ZW1lbnQgYW5kIHRoZXJlIGlzIG5vIHByb3RvY29sIHZpb2xhdGlvbi4gwqBIb3cgdGhhdCBQMlAN Cj4gPj4gbGluaw0KPiA+PiBtb2RlbCBpcyBhY2hpZXZlZCwgYmFzZWQgYSB0dW5uZWwgaW50ZXJm YWNlLCBwdXR0aW5nIHRoZSBhY2Nlc3MgcG9pbnQNCj4gaW4gYQ0KPiA+PiB1bmljYXN0IG1vZGUs IGFyZSBhbGwgdGhlIHBvc3NpYmxlIG9wdGlvbnMuDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IFNy aQ0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBPbiAzLzE1LzExIDE6MjEgQU0sICJwaWVycmljay5z ZWl0ZUBvcmFuZ2UtZnRncm91cC5jb20iDQo+ID4+IDxwaWVycmljay5zZWl0ZUBvcmFuZ2UtZnRn cm91cC5jb20+IHdyb3RlOg0KPiA+Pg0KPiA+PiA+DQo+ID4+ID4gSGkgU3JpLA0KPiA+PiA+DQo+ ID4+ID4gSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgdGhlcmUgaXMgbm8gdmlvbGF0aW9uIG9m IFJGQzUyMTMgaWYgYWxsDQo+ID4+IHBoeXNpY2FsDQo+ID4+ID4gbGlua3MgYXJlIHAycC4gSG93 ZXZlciB0aGUgcHJvcG9zZWQgdGV4dCBhbGxvd3MgdGhlIHZpcnR1YWwgaW50ZXJmYWNlDQo+IHRv DQo+ID4+IGJvdW5kDQo+ID4+ID4gcGh5c2ljYWwgc2hhcmVkIGxpbmtzLiBJZiBzbywgSSB0aGlu ayB3ZSBtYXkgaGF2ZSB0aGUgaXNzdWUgZGVzY3JpYmVkDQo+IGluDQo+ID4+ID4gc2VjdGlvbiA0 LjIgb2YgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRsbW0tbW4tYXIt aWYtDQo+IDAzLg0KPiA+PiA+IE1heWJlLCB0aGUgdGV4dCBzaG91bGQgYmUgY2xhcmlmaWVkIHRv IHJlc3RyaWN0IHRvIHBoeXNpY2FsIHAycCBsaW5rcy4NCj4gPj4gPg0KPiA+PiA+IEJSLA0KPiA+ PiA+IFBpZXJyaWNrDQo+ID4+ID4NCj4gPj4gPj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0t DQo+ID4+ID4+IERlwqA6IG5ldGV4dC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bmV0ZXh0LWJv dW5jZXNAaWV0Zi5vcmddIERlIGxhDQo+ID4+IHBhcnQNCj4gPj4gPj4gZGUgU3JpIEd1bmRhdmVs bGkNCj4gPj4gPj4gRW52b3nDqcKgOiBtYXJkaSAxNSBtYXJzIDIwMTEgMDQ6MDQNCj4gPj4gPj4g w4DCoDogSnVsaWVuIExhZ2FuaWVyDQo+ID4+ID4+IENjwqA6IG5ldGV4dEBpZXRmLm9yZw0KPiA+ PiA+PiBPYmpldMKgOiBSZTogW25ldGV4dF0gIzQ6IExvZ2ljYWwgaW50ZXJmYWNlIHN1cHBvcnQ6 IFBvaW50IHRvIHBvaW50DQo+ID4+IGxpbmtzDQo+ID4+ID4+DQo+ID4+ID4+IEp1bGllbjoNCj4g Pj4gPj4NCj4gPj4gPj4gTGV0cyBzZWUsIHdoYXQgaXMgdGhlIHZpb2xhdGlvbiBoZXJlID8NCj4g Pj4gPj4NCj4gPj4gPj4gLSBXZSBhcmUgc3RhdGluZyB0aGUgbG9naWNhbCBpbnRlcmZhY2UgYXBw ZWFycyB0byB0aGUgYXBwbGljYXRpb25zDQo+IGFzDQo+ID4+IGFuDQo+ID4+ID4+IGludGVyZmFj ZSBhdHRhY2hlZCB0byBhIHNoYXJlZCBsaW5rLiBGb3IgdGhlIHNpbXBsZSByZWFzb24sIHRoYXQg d2UNCj4gPj4gaGF2ZQ0KPiA+PiA+PiBtdWx0aXBsZSBuZWlnaGJvcnMgb24gZGlmZmVyZW50IG5l dHdvcmsgc2VnbWVudHMgYXR0YWNoZWQgdGhyb3VnaA0KPiA+PiA+PiBkaWZmZXJlbnQNCj4gPj4g Pj4gc3ViLWludGVyZmFjZSBvZiB0aGF0IGxvZ2ljYWwgaW50ZXJmYWNlLiBXZSBkb24ndCBoYXZl IGEgc2luZ2xlDQo+ID4+ID4+IG5laWdoYm9yL01BRy4NCj4gPj4gPj4NCj4gPj4gPj4gLSAiVW5k ZXJuZWF0aCB0aGUgbG9naWNhbCBpbnRlcmZhY2UgLi4uIiwgdGhlcmUgYXJlIHN1Yi1pbnRlcmZh Y2VzDQo+ID4+IHdoaWNoDQo+ID4+ID4+IG1heQ0KPiA+PiA+PiBiZSB2ZXJ5IHdlbGwgYXR0YWNo ZWQgdG8gZGlmZmVyZW50IHAycCBsaW5rcy4gQXMgbG9uZyBhcyB0aGUgbmV0d29yaw0KPiA+PiBo YXMNCj4gPj4gPj4gdGhlDQo+ID4+ID4+IHNlbWFudGljcyB0byBzZW5kIGEgUkEgd2l0aCBQSU8s IGV4Y2x1c2l2ZWx5IHRvIHRoaXMgbm9kZSwgbm8gb3RoZXINCj4gPj4gbm9kZQ0KPiA+PiA+PiBv bg0KPiA+PiA+PiB0aGF0IGFjY2VzcyBsaW5rIGNhbiByZWNlaXZlIHRoYXQgUHJlZml4IHNldCwg d2UgYXJlIGNvbmZpcm1pbmcgdG8NCj4gNTIxMw0KPiA+PiA+PiBsaW5rDQo+ID4+ID4+IG1vZGVs LiBGcm9tIGFueSBvZiB0aGUgTUFHJ3MgcGVyc3BlY3RpdmUsIGF0dGFjaGVkIHRvIGFueSBvZiB0 aGUNCj4gYWNjZXNzDQo+ID4+ID4+IGxpbmtzLCBpdCBjYW4gc3RpbGwgYmUga2VwdCBhcyBhIHAy cCBsaW5rDQo+ID4+ID4+DQo+ID4+ID4+IC0gRXhwb3NpbmcgdGhlIGxvZ2ljYWwgaW50ZXJmYWNl IGFzIGEgc2hhcmVkIGxpbmsgdG8gdGhlDQo+IGFwcGxpY2F0aW9ucw0KPiA+PiBvbg0KPiA+PiA+ PiB0aGUNCj4gPj4gPj4gKm1vYmlsZSBub2RlKiwgaXMgbm90IHZpb2xhdGluZyA1MjEzIHByaW5j aXBsZXMuIFRoZSBwYXRoIGNob3NlbiBmb3INCj4gYQ0KPiA+PiA+PiBwYWNrZXQgdGhyb3VnaCBh IHN1Yi1pbnRlcmZhY2UgY2FuIGJlIHN0aWxsIGEgcDJwIGxpbmsgYW5kIHRoZSBydWxlcw0KPiBv Zg0KPiA+PiA+PiBsaW5rLWxheWVyIHJlc29sdXRpb24gb2YgdGhlIHBlZXIsIG9yIGFkZGluZyBs MiBoZWFkZXJzIHNraXBwaW5nIGwyDQo+ID4+ID4+IHJlc29sdXRpb24sIGlzIHN0aWxsIHRoZSBh cHByb2FjaCBpbiB1c2UuDQo+ID4+ID4+DQo+ID4+ID4+DQo+ID4+ID4+DQo+ID4+ID4+DQo+ID4+ ID4+IFNyaQ0KPiA+PiA+Pg0KPiA+PiA+Pg0KPiA+PiA+Pg0KPiA+PiA+Pg0KPiA+PiA+Pg0KPiA+ PiA+Pg0KPiA+PiA+Pg0KPiA+PiA+Pg0KPiA+PiA+PiBPbiAzLzE0LzExIDU6MjAgUE0sICJKdWxp ZW4gTGFnYW5pZXIiIDxqdWxpZW4uaWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KPiA+PiA+Pg0KPiA+ PiA+Pj4gU3JpIC0NCj4gPj4gPj4+DQo+ID4+ID4+PiA1MjEzIHN1cHBvcnRzIG9ubHkgUHRQIGxp bmtzIHRodXMgSSBkbyBub3QgdW5kZXJzdGFuZCBob3cgdGhlDQo+ID4+ID4+PiBmb2xsb3dpbmcg cmVzb2x1dGlvbiByZXNvbHZlcyBhbnl0aGluZy4gUGxlYXNlIGNsYXJpZnkgd2hhdCBpcyB0aGUN Cj4gPj4gPj4+IGlzc3VlIHlvdScgcmUgYWRkcmVzc2luZyBhbmQgaG93IHRoaXMgaXMgYWRkcmVz c2luZyBpdC4NCj4gPj4gPj4+DQo+ID4+ID4+PiAtLWp1bGllbg0KPiA+PiA+Pj4NCj4gPj4gPj4+ IE9uIE1vbiwgTWFyIDE0LCAyMDExIGF0IDQ6MjQgUE0sIFNyaSBHdW5kYXZlbGxpDQo+IDxzZ3Vu ZGF2ZUBjaXNjby5jb20+DQo+ID4+ID4+IHdyb3RlOg0KPiA+PiA+Pj4+PiAjNDogTG9naWNhbCBp bnRlcmZhY2Ugc3VwcG9ydDogUG9pbnQgdG8gcG9pbnQgbGlua3MNCj4gPj4gPj4+Pg0KPiA+PiA+ Pj4+IMKgQ2xhcmlmeSB0aGUgdXNlIGFuZA0KPiA+PiA+Pj4+PiBiZWhhdmlvciBvZiB0aGUgbG9n aWNhbCBpbnRlcmZhY2Ugb24gUHRQIGxpbmtzLg0KPiA+PiA+Pj4+DQo+ID4+ID4+Pj4NCj4gPj4g Pj4+PiBGb2xrczogQWdhaW4sIHJlZmxlY3RpbmcgdGhlIHRlYW0ncyBjb250cmlidXRpb25zIG9u IHRoaXMgdG9waWMsDQo+IHRoZQ0KPiA+PiA+PiBhdXRob3JzDQo+ID4+ID4+Pj4gb2YgdGhpcyBk b2N1bWVudCBoYXZlIGRpc2N1c3NlZCB0aGlzIGFuZCByZXNvbHZlIGl0IHdpdGggdGhlDQo+ID4+ IGZvbGxvd2luZw0KPiA+PiA+PiB0ZXh0Lg0KPiA+PiA+Pj4+IFRoZSBrZXkgcG9pbnRzIHdlIHRy aWVkIHRvIHJlZmxlY3QgYXJlIGFyb3VuZCB0aGF0IHRoZSBsb2dpY2FsDQo+ID4+ID4+IGludGVy ZmFjZQ0KPiA+PiA+Pj4+IGFwcGVhcnMgdG8gdGhlIGFwcGxpY2F0aW9uIGFzIGEgc2hhcmVkIGxp bmsuIFRoZXJlIHdlcmUgdGhvdWdodHMNCj4gPj4gYXJvdW5kDQo+ID4+ID4+Pj4gbWFraW5nIGl0 IGFwcGVhciBsaWtlIGEgcDJwIGxpbmssIGdpdmVuIHRoYXQgdGhlcmUgYXJlIG11bHRpcGxlDQo+ ID4+ID4+IG5laWdoYm9ycyBvbg0KPiA+PiA+Pj4+IGVhY2ggc3ViIGludGVyZmFjZSwgdGhpcyBj aG9pY2UgYXBwZWFycyByZWFzb25hYmxlLiBXaXRoIHJlc3BlY3QNCj4gdG8NCj4gPj4gaG93DQo+ ID4+ID4+IGENCj4gPj4gPj4+PiBwYWNrZXQgaXMgdHJhbnNtaXR0ZWQsIGlzIHN0aWxsIGJhc2Vk IG9uIHRoZSBjaG9zZW4gbGluayBtb2RlbCBhdA0KPiA+PiBlYWNoDQo+ID4+ID4+IHN1Yg0KPiA+ PiA+Pj4+IGludGVyZmFjZSBsZXZlbC4gTGV0IHVzIGtub3csIGlmIHlvdSBzZWUgYW55IGlzc3Vl cyB3aXRoIGl0LiBUaGlzDQo+IGlzDQo+ID4+ID4+IHByb3Zlbg0KPiA+PiA+Pj4+IGJhc2VkIG9u IHRoZSBtdWx0aXBsZSBpbXBsZW1lbnRhdGlvbnMgZnJvbSBzb21lIG9mIHRoZSBjby1hdXRob3Jz DQo+IG9mDQo+ID4+ID4+IHRoaXMNCj4gPj4gPj4+PiBkb2MuDQo+ID4+ID4+Pj4NCj4gPj4gPj4+ Pg0KPiA+PiA+Pj4+DQo+ID4+ID4+Pj4NCj4gPj4gPj4+PiAtLS0NCj4gPj4gPj4+PiA2LjMuIMKg U3VwcG9ydGVkIExpbmsgbW9kZWxzIGZvciBhIGxvZ2ljYWwgaW50ZXJmYWNlDQo+ID4+ID4+Pj4N Cj4gPj4gPj4+PiDCoFRoZSBzdWItaW50ZXJmYWNlcyBvZiBhIGxvZ2ljYWwgaW50ZXJmYWNlIGNh biBiZSBib3VuZCB0byBhDQo+IHBvaW50LQ0KPiA+PiB0by0NCj4gPj4gPj4+PiDCoCBwb2ludCBv ciBhIHNoYXJlZCBsaW5rIChFeGFtcGxlOiBMVEUgYW5kIFdMQU4pLiDCoFRoZSBsb2dpY2FsDQo+ ID4+ID4+Pj4gwqAgaW50ZXJmYWNlIGFwcGVhcnMgYXMgYSBzaGFyZWQtbGluayB0byB0aGUgYXBw bGljYXRpb25zLCBhbmQNCj4gYWRhcHRzDQo+ID4+IHRvDQo+ID4+ID4+Pj4gwqAgdGhlIGxpbmsg bW9kZWwgb2YgdGhlIHN1Yi1pbnRlcmZhY2UgZm9yIHBhY2tldA0KPiBjb21tdW5pY2F0aW9uLiDC oEZvcg0KPiA+PiA+Pj4+IMKgIGV4YW1wbGUsIHdoZW4gdHJhbnNtaXR0aW5nIGEgcGFja2V0IG9u IGEgc3ViLWludGVyZmFjZSB3aGljaCBpcw0KPiA+PiA+Pj4+IMKgIGF0dGFjaGVkIHRvIGEgcDJw IGxpbmssIHRoZSB0cmFuc21pc3Npb24gY29uZm9ybXMgdG8gdGhlIHAycA0KPiBsaW5rDQo+ID4+ ID4+Pj4gwqAgbW9kZWwgYW5kIHdoZW4gdHJhbnNtaXR0aW5nIG9uIGEgc3ViLWludGVyZmFjZSBh dHRhY2hlZCB0byBhDQo+IHNoYXJlZA0KPiA+PiA+Pj4+IMKgIGxpbmssIHRoZSB0cmFuc21pc3Np b24gY29uZm9ybXMgdG8gdGhlIHNoYXJlZCBsaW5rIG1vZGVsLg0KPiA+PiA+Pj4+DQo+ID4+ID4+ Pj4gwqAgQmFzZWQgb24gdGhlIGxpbmsgdG8gd2hpY2ggdGhlIHN1Yi1pbnRlcmZhY2UgaXMgYXR0 YWNoZWQgdG8sIHRoZQ0KPiA+PiA+Pj4+IMKgIGxheWVyLTIgcmVzb2x1dGlvbnMgbWF5IG9yIG1h eSBub3QgYmUgbmVlZGVkLiDCoElmIHRoZSBpbnRlcmZhY2UNCj4gaXMNCj4gPj4gPj4+PiDCoCBi b3VuZCB0byBhIFAyUCBsaW5rIHdpdGggUFBQIHJ1bm5pbmcsIHRoZXJlIHdpbGwgbm90IGJlIGFu eQ0KPiBsaW5rLQ0KPiA+PiA+Pj4+IMKgIGxheWVyIHJlc29sdXRpb25zIGluIHRoZSBmb3JtIG9m IEFSUC9ORCBtZXNzYWdlcy4gwqBIb3dldmVyLCBpZg0KPiB0aGUNCj4gPj4gPj4+PiDCoCBpbnRl cmZhY2UgaXMgYm91bmQgdG8gYSBzaGFyZWQgbGluayBzdWNoIGFzIEV0aGVybmV0LCB0aGVyZSB3 aWxsDQo+IGJlDQo+ID4+ID4+Pj4gwqAgTkQgcmVzb2x1dGlvbnMuIMKgVGhlIGxvZ2ljYWwgaW50 ZXJmYWNlIGltcGxlbWVudGF0aW9uIGhhcyB0bw0KPiA+PiBtYWludGFpbg0KPiA+PiA+Pj4+IMKg IHRoZSByZXF1aXJlZCBsaW5rIG1vZGVsIGFuZCB0aGUgYXNzb2NpYXRlZCBzdGF0ZSBmb3IgZWFj aCBzdWItDQo+ID4+ID4+Pj4gwqAgaW50ZXJmYWNlLg0KPiA+PiA+Pj4+IC0tDQo+ID4+ID4+Pj4N Cj4gPj4gPj4+Pg0KPiA+PiA+Pj4+DQo+ID4+ID4+Pj4NCj4gPj4gPj4+PiBPbiAzLzMvMTEgOTox NyBBTSwgIm5ldGV4dCBpc3N1ZSB0cmFja2VyIg0KPiA+PiA+PiA8dHJhYytuZXRleHRAdHJhYy50 b29scy5pZXRmLm9yZz4NCj4gPj4gPj4+PiB3cm90ZToNCj4gPj4gPj4+Pg0KPiA+PiA+Pj4+PiAj NDogTG9naWNhbCBpbnRlcmZhY2Ugc3VwcG9ydDogUG9pbnQgdG8gcG9pbnQgbGlua3MNCj4gPj4g Pj4+Pg0KPiA+PiA+Pj4+IMKgQ2xhcmlmeSB0aGUgdXNlIGFuZA0KPiA+PiA+Pj4+PiBiZWhhdmlv ciBvZiB0aGUgbG9naWNhbCBpbnRlcmZhY2Ugb24gUHRQIGxpbmtzLg0KPiA+PiA+Pj4+DQo+ID4+ ID4+Pj4gLS0NCj4gPj4gPj4+Pj4NCj4gPj4gPj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0tDQo+ID4+IC0t DQo+ID4+ID4+IC0tLS0tDQo+ID4+ID4+Pj4NCj4gPj4gPj4+Pj4NCj4gPj4gUmVwb3J0ZXI6IMKg YmFzYXZhcmFqLnBhdGlsQMWgIMKgIMKgIMKgIMKgIMKgfCDCoCDCoCDCoCBPd25lcjogwqB0ZWxl bWFjby5tZWxpYUDFoA0KPiA+PiA+Pj4+Pg0KPiA+PiA+Pj4+IMKgIMKgIFR5cGU6IMKgZGVmZWN0 IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqAgwqAgwqBTdGF0dXM6IMKgbmV3DQo+ ID4+ID4+Pj4+DQo+ID4+ID4+Pj4gwqBQcmlvcml0eTogwqBtYWpvciDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoHwgwqAgTWlsZXN0b25lOg0KPiA+PiA+Pj4+Pg0KPiA+PiA+Pj4+IENv bXBvbmVudDogwqBsb2dpY2FsLWludGVyZmFjZS1zdXBwb3J0IMKgfCDCoCDCoCBWZXJzaW9uOg0K PiA+PiA+Pj4+Pg0KPiA+PiA+Pj4+IMKgU2V2ZXJpdHk6IMKgLSDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoHwgwqAgwqBLZXl3b3JkczoNCj4gPj4gPj4+Pj4NCj4gPj4gPj4+ PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gLS0tDQo+ID4+IC0tDQo+ID4+ID4+IC0tLS0tDQo+ID4+ID4+Pj4NCj4g Pj4gPj4+Pj4NCj4gPj4gPj4+PiBUaWNrZXQgVVJMOiA8aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5v cmcvd2cvbmV0ZXh0L3RyYWMvdGlja2V0LzQ+DQo+ID4+ID4+Pj4gbmV0ZXh0DQo+ID4+ID4+Pj4+ IDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvbmV0ZXh0Lz4NCj4gPj4gPj4+Pg0KPiA+PiA+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiA+Pj4+PiBf Xw0KPiA+PiA+Pj4+IG5ldGV4dCBtYWlsaW5nDQo+ID4+ID4+Pj4+IGxpc3QNCj4gPj4gPj4+PiBu ZXRleHRAaWV0Zi5vcmcNCj4gPj4gPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldGV4dA0KPiA+PiA+Pj4+DQo+ID4+ID4+Pj4NCj4gPj4gPj4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiA+Pj4+IG5ldGV4dCBt YWlsaW5nIGxpc3QNCj4gPj4gPj4+PiBuZXRleHRAaWV0Zi5vcmcNCj4gPj4gPj4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGV4dA0KPiA+PiA+Pj4+DQo+ID4+ID4+ DQo+ID4+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4+ID4+IG5ldGV4dCBtYWlsaW5nIGxpc3QNCj4gPj4gPj4gbmV0ZXh0QGlldGYub3JnDQo+ ID4+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0DQo+ID4N Cj4gPg0K From julien.ietf@gmail.com Wed Mar 16 12:02:32 2011 Return-Path: <julien.ietf@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65CD33A6A64 for <netext@core3.amsl.com>; Wed, 16 Mar 2011 12:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cXn8qC7yksa for <netext@core3.amsl.com>; Wed, 16 Mar 2011 12:02:31 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 40A133A6A56 for <netext@ietf.org>; Wed, 16 Mar 2011 12:02:31 -0700 (PDT) Received: by wyb42 with SMTP id 42so2170349wyb.31 for <netext@ietf.org>; Wed, 16 Mar 2011 12:03:57 -0700 (PDT) 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=FvKcYkgEUVh1BnyrXyLtzYl+uTokSTY8CsLfQXTfpXI=; b=fveVionfcJ32qxwx9lEehLKBRrOHdNrQ6nxHTDP/BWfYKz+RoVa5wZhFE1yTFmjbyl 9WZ6G6J1Waxot37e+LGiJhx3YnvT9ySf5UeAlLs5RBGQo7W676laIH/Dt5fSZl82d+xt RQKbvZ5HLzKuzv9LaaVj6mFHmNwSV+ZFWxpCI= 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=lJONR6YNOy5nPzyJoeRKnUfNrlyVYfpDRxfa2P9Ffdf2W/DQNeBijThvJM4nit1yPB BZ5rExazmIPHK9TJKWKNXEYvYMYfKB7/emyLcwnZrZKfs08HOAifqy7OGbCBJk9/xaz9 9C/lAoUzuY+BSviYjVIKMHX5vouJOcpo/pd8Q= MIME-Version: 1.0 Received: by 10.216.11.205 with SMTP id 55mr443277wex.72.1300302236866; Wed, 16 Mar 2011 12:03:56 -0700 (PDT) Received: by 10.216.89.205 with HTTP; Wed, 16 Mar 2011 12:03:56 -0700 (PDT) In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C4620190BB09@ftrdmel0.rd.francetelecom.fr> References: <843DA8228A1BA74CA31FB4E111A5C4620190B524@ftrdmel0.rd.francetelecom.fr> <C9A54F91.138B8%sgundave@cisco.com> <843DA8228A1BA74CA31FB4E111A5C4620190B829@ftrdmel0.rd.francetelecom.fr> <AANLkTin7yx4DYH9cDsKEmrOunmRUOjnsOnLorHmix5sj@mail.gmail.com> <843DA8228A1BA74CA31FB4E111A5C4620190BB09@ftrdmel0.rd.francetelecom.fr> Date: Wed, 16 Mar 2011 12:03:56 -0700 Message-ID: <AANLkTikjnVkk8-yGzQFNMqQvwCgiAXXULqPnte8JL_2y@mail.gmail.com> From: Julien Laganier <julien.ietf@gmail.com> 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] #4: Logical interface support: Point to point links X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Mar 2011 19:02:32 -0000 Pierrick, On Wed, Mar 16, 2011 at 11:53 AM, <pierrick.seite@orange-ftgroup.com> wrot= e: > > >> Julien Laganier <julien.ietf@gmail.com> wrote: >> >> Pierrick, >> >> I am confused... Do you disagree that a vanilla IEEE 802.11 isn't a >> point-to-point link? >> > > No... I was just agreeing =A0to require p2p link model on the physical li= nks. So, 802.11 cannot be used without additional mechanism to achieve a po= int-to-point link. Actually, nothing new with regards to RFC5213. Thanks for clarifying. --julien From sgundave@cisco.com Wed Mar 16 12:29:47 2011 Return-Path: <sgundave@cisco.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62D8D3A6A3C for <netext@core3.amsl.com>; Wed, 16 Mar 2011 12:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.426 X-Spam-Level: X-Spam-Status: No, score=-9.426 tagged_above=-999 required=5 tests=[AWL=-0.223, 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 g5ogCnoN0qNE for <netext@core3.amsl.com>; Wed, 16 Mar 2011 12:29:45 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 13C613A69CA for <netext@ietf.org>; Wed, 16 Mar 2011 12:29:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=1438; q=dns/txt; s=iport; t=1300303872; x=1301513472; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=7QcXiByRnKO0J4cxkTSiYuQcNsDH3ExqNBHW3QkLNXc=; b=hk6aTA1QjvlfTaewdwOgie2x3c4ZbwD6CWvv4dDJpCrNwDa8bEiasLo1 zlzzaJ90GBaiG0DvGg0PjFhnm84FDuN0C8lO0EzKfLU3cjvKnluqLEbmP GnsJiNGiklt0+gKEdCHv+Os8oVki6Kp2Gf1GoIYfVd7BWnCejmQKEz5Uf w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEutgE2tJV2Y/2dsb2JhbAClOVN3pWecV4VjBIUvhy+DU4Mg X-IronPort-AV: E=Sophos;i="4.63,195,1299456000"; d="scan'208";a="667815918" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-6.cisco.com with ESMTP; 16 Mar 2011 19:31:11 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2GJUcsn028586; Wed, 16 Mar 2011 19:31:10 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, 16 Mar 2011 12:31:07 -0700 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, 16 Mar 2011 19:31:06 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Wed, 16 Mar 2011 12:31:02 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: Julien Laganier <julien.ietf@gmail.com>, <pierrick.seite@orange-ftgroup.com> Message-ID: <C9A65E06.13AF1%sgundave@cisco.com> Thread-Topic: [netext] #4: Logical interface support: Point to point links Thread-Index: AcvkEK8wfav5/9cYFkyEKiL9R5ppvw== In-Reply-To: <AANLkTikjnVkk8-yGzQFNMqQvwCgiAXXULqPnte8JL_2y@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 16 Mar 2011 19:31:07.0681 (UTC) FILETIME=[B2937910:01CBE410] Cc: netext@ietf.org Subject: Re: [netext] #4: Logical interface support: Point to point links X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Mar 2011 19:29:48 -0000 I'm not sure, we can say, we need additional mechanisms in 802.11 to achiev= e p2p link model. We are not talking about protocol extensions, its rather about configuration. From PMIP perspective, we all agree, we need P2P link model. If some one wants to connect trusted WLAN access networks with PMIP domain, they can very well do that, as long as they support P2P link model. We also agreed, we can achieve that with today's 802.11 standards and today's boxes out there. =20 How they do that, if that's by configuring unique SSID's per MN, unique VLAN's, send unicast RA's per RFC-6085, set up some L3 tunnels, is beyond the scope of PMIP.=20 We can just state the requirement of P2P link model on any access technology, and leave it there. Sri On 3/16/11 11:03 AM, "Julien Laganier" <julien.ietf@gmail.com> wrote: > Pierrick, >=20 > On Wed, Mar 16, 2011 at 11:53 AM, <pierrick.seite@orange-ftgroup.com> wr= ote: >>=20 >>=20 >>> Julien Laganier <julien.ietf@gmail.com> wrote: >>>=20 >>> Pierrick, >>>=20 >>> I am confused... Do you disagree that a vanilla IEEE 802.11 isn't a >>> point-to-point link? >>>=20 >>=20 >> No... I was just agreeing =A0to require p2p link model on the physical lin= ks. >> So, 802.11 cannot be used without additional mechanism to achieve a >> point-to-point link. Actually, nothing new with regards to RFC5213. >=20 > Thanks for clarifying. >=20 > --julien From julien.ietf@gmail.com Wed Mar 16 12:42:05 2011 Return-Path: <julien.ietf@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD2433A6A84 for <netext@core3.amsl.com>; Wed, 16 Mar 2011 12:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VQHn3RYtxfv for <netext@core3.amsl.com>; Wed, 16 Mar 2011 12:42:05 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id A8A3E3A6A76 for <netext@ietf.org>; Wed, 16 Mar 2011 12:42:04 -0700 (PDT) Received: by wyb42 with SMTP id 42so2210413wyb.31 for <netext@ietf.org>; Wed, 16 Mar 2011 12:43:31 -0700 (PDT) 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=JFbnGXnruQpDtXnY8Y4rQ1iqIwSA9RroQm1+WUMIGRg=; b=BxD5VDol5d6N+dLiN0jk2SRIeiq17wMoTiX79a41TebCe3TLkazkXHmfSJedgRV8mq 62hg90MUUAAtlyuKs0riMhluSFo0Q4feKFk1zba8UV15ZNZWd5UGsBEooG4XvmUo/q98 jyMz+41MzYGL3wBX1GRb1V3csd3tf2gUs6Xis= 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=G88eIFCQreyH8f1BSzplxtbLL+utT+R914QkDnXlyHQrpem4kKUcLTQ0romQdmQgPL Ua6RgNImuNyLpIiNKVS2LGDzjx97GwEUogpihtEU/PwuYReQuvlKIXfGRRlblFXzsp3l HzJ3Pc3cAGkwz49uXJoLVAPkX2633r4gzpnvE= MIME-Version: 1.0 Received: by 10.216.11.205 with SMTP id 55mr480851wex.72.1300304610799; Wed, 16 Mar 2011 12:43:30 -0700 (PDT) Received: by 10.216.89.205 with HTTP; Wed, 16 Mar 2011 12:43:30 -0700 (PDT) In-Reply-To: <C9A65E06.13AF1%sgundave@cisco.com> References: <AANLkTikjnVkk8-yGzQFNMqQvwCgiAXXULqPnte8JL_2y@mail.gmail.com> <C9A65E06.13AF1%sgundave@cisco.com> Date: Wed, 16 Mar 2011 12:43:30 -0700 Message-ID: <AANLkTi=HfMj=HoU_jQX=6WyTtn+rmBd=VefhDfufVYcu@mail.gmail.com> From: Julien Laganier <julien.ietf@gmail.com> To: Sri Gundavelli <sgundave@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] #4: Logical interface support: Point to point links X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Mar 2011 19:42:06 -0000 Sri, On Wed, Mar 16, 2011 at 1:31 PM, Sri Gundavelli <sgundave@cisco.com> wrote: > I'm not sure, we can say, we need additional mechanisms in 802.11 to achi= eve > p2p link model. We are not talking about protocol extensions, its rather > about configuration. From PMIP perspective, we all agree, we need P2P lin= k > model. That is better, and different from what is in the draft that says shared link is supported. 6.3. Supported Link models for a logical interface The sub-interfaces of a logical interface can be bound to a point-to- point or a shared link (Example: LTE and WLAN). Do you disagree with the content of the draft? > If some one wants to connect trusted WLAN access networks with PMIP > domain, they can very well do that, as long as they support P2P link mode= l. Yes, as long as they support point to point link model, and unlike what is the current draft. > We also agreed, we can achieve that with today's 802.11 standards and > today's boxes out there. You can achieve that with today's 802.11 standards. Not sure about boxes out there. My AP only does shared link. This discussion seems to be moot since current APs do not have MAGs. > How they do that, if that's by configuring unique SSID's per MN, unique > VLAN's, send unicast RA's per RFC-6085, set up some L3 tunnels, is beyond > the scope of PMIP. Again, please do not equate sending unicast RAs with having a point to point link as these are two different things. I do not care how having a point to point link on a physical interface is done, my point is that was that the current draft says that shared link are supported while they are not, and I didn't put that text in that draft, for that matter. > We can just state the requirement of P2P link model on any access > technology, and leave it there. Right thus you agree the draft has to be corrected wherever it talks about shared links, to say that only point-to-point links are supported, and that shared links are not supported. Thanks. --julien > On 3/16/11 11:03 AM, "Julien Laganier" <julien.ietf@gmail.com> wrote: > >> Pierrick, >> >> On Wed, Mar 16, 2011 at 11:53 AM, =A0<pierrick.seite@orange-ftgroup.com>= wrote: >>> >>> >>>> Julien Laganier <julien.ietf@gmail.com> wrote: >>>> >>>> Pierrick, >>>> >>>> I am confused... Do you disagree that a vanilla IEEE 802.11 isn't a >>>> point-to-point link? >>>> >>> >>> No... I was just agreeing =A0to require p2p link model on the physical = links. >>> So, 802.11 cannot be used without additional mechanism to achieve a >>> point-to-point link. Actually, nothing new with regards to RFC5213. >> >> Thanks for clarifying. >> >> --julien From sgundave@cisco.com Wed Mar 16 12:46:35 2011 Return-Path: <sgundave@cisco.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1A803A6A91 for <netext@core3.amsl.com>; Wed, 16 Mar 2011 12:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.42 X-Spam-Level: X-Spam-Status: No, score=-9.42 tagged_above=-999 required=5 tests=[AWL=-0.217, 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 K2XoYE+Wlzuo for <netext@core3.amsl.com>; Wed, 16 Mar 2011 12:46:33 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id A7CE53A6A84 for <netext@ietf.org>; Wed, 16 Mar 2011 12:46:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=3354; q=dns/txt; s=iport; t=1300304880; x=1301514480; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=tnvURNPoJkRcFfQvmVVNf/02w+dpf8y1mD6SW6hwr50=; b=bSQ8hSBPDjpJntpk/6mINHZxPF2qFLfLsZF80LqND5imf5oyB1Why+7P BC/TSgIIE1ddsweAdPM2OiLs3ZvIwUr6+ivbLr+kuUOLJYXyI/DYz8BkN oPj5p0AeQx6OWk17UzFlUMu/JwE84UYHO5Xx5ga6ymkZjZmiHRcz+C25Y c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJOwgE2tJV2b/2dsb2JhbAClOVN3pXWcWIVjBIUvhy+DU4Mg X-IronPort-AV: E=Sophos;i="4.63,195,1299456000"; d="scan'208";a="225894660" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-1.cisco.com with ESMTP; 16 Mar 2011 19:48:00 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2GJlvTZ005347; Wed, 16 Mar 2011 19:47:58 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, 16 Mar 2011 12:47:57 -0700 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, 16 Mar 2011 19:47:56 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Wed, 16 Mar 2011 12:47:50 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: Julien Laganier <julien.ietf@gmail.com> Message-ID: <C9A661F6.13AFF%sgundave@cisco.com> Thread-Topic: [netext] #4: Logical interface support: Point to point links Thread-Index: AcvkEwgBizYjCgxfeEuwm3m8kiOzZw== In-Reply-To: <AANLkTi=HfMj=HoU_jQX=6WyTtn+rmBd=VefhDfufVYcu@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 16 Mar 2011 19:47:57.0938 (UTC) FILETIME=[0CBC7520:01CBE413] Cc: netext@ietf.org Subject: Re: [netext] #4: Logical interface support: Point to point links X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Mar 2011 19:46:35 -0000 Hi Julien, I already agreed, we need to put a qualifier on that one sentence, which states, the physical link being a shared link. If you agree, that qualifier can be, "the physical link attached to the logical interface can be a share= d link, as long as it can meet the point-to-point link model semantics". Agre= e ?=20 Regards Sri On 3/16/11 11:43 AM, "Julien Laganier" <julien.ietf@gmail.com> wrote: > Sri, >=20 > On Wed, Mar 16, 2011 at 1:31 PM, Sri Gundavelli <sgundave@cisco.com> wrot= e: >> I'm not sure, we can say, we need additional mechanisms in 802.11 to ach= ieve >> p2p link model. We are not talking about protocol extensions, its rather >> about configuration. From PMIP perspective, we all agree, we need P2P li= nk >> model. >=20 > That is better, and different from what is in the draft that says > shared link is supported. >=20 > 6.3. Supported Link models for a logical interface >=20 > The sub-interfaces of a logical interface can be bound to a point-to- > point or a shared link (Example: LTE and WLAN). >=20 > Do you disagree with the content of the draft? >=20 >> If some one wants to connect trusted WLAN access networks with PMIP >> domain, they can very well do that, as long as they support P2P link mod= el. >=20 > Yes, as long as they support point to point link model, and unlike > what is the current draft. >=20 >> We also agreed, we can achieve that with today's 802.11 standards and >> today's boxes out there. >=20 > You can achieve that with today's 802.11 standards. Not sure about > boxes out there. My AP only does shared link. This discussion seems to > be moot since current APs do not have MAGs. >=20 >> How they do that, if that's by configuring unique SSID's per MN, unique >> VLAN's, send unicast RA's per RFC-6085, set up some L3 tunnels, is beyon= d >> the scope of PMIP. >=20 > Again, please do not equate sending unicast RAs with having a point to > point link as these are two different things. >=20 > I do not care how having a point to point link on a physical interface > is done, my point is that was that the current draft says that shared > link are supported while they are not, and I didn't put that text in > that draft, for that matter. >=20 >> We can just state the requirement of P2P link model on any access >> technology, and leave it there. >=20 > Right thus you agree the draft has to be corrected wherever it talks > about shared links, to say that only point-to-point links are > supported, and that shared links are not supported. >=20 > Thanks. >=20 > --julien >=20 >> On 3/16/11 11:03 AM, "Julien Laganier" <julien.ietf@gmail.com> wrote: >>=20 >>> Pierrick, >>>=20 >>> On Wed, Mar 16, 2011 at 11:53 AM, =A0<pierrick.seite@orange-ftgroup.com> >>> wrote: >>>>=20 >>>>=20 >>>>> Julien Laganier <julien.ietf@gmail.com> wrote: >>>>>=20 >>>>> Pierrick, >>>>>=20 >>>>> I am confused... Do you disagree that a vanilla IEEE 802.11 isn't a >>>>> point-to-point link? >>>>>=20 >>>>=20 >>>> No... I was just agreeing =A0to require p2p link model on the physical l= inks. >>>> So, 802.11 cannot be used without additional mechanism to achieve a >>>> point-to-point link. Actually, nothing new with regards to RFC5213. >>>=20 >>> Thanks for clarifying. >>>=20 >>> --julien From julien.ietf@gmail.com Wed Mar 16 13:15:58 2011 Return-Path: <julien.ietf@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0C083A69D9 for <netext@core3.amsl.com>; Wed, 16 Mar 2011 13:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5W0wcgOGFm0 for <netext@core3.amsl.com>; Wed, 16 Mar 2011 13:15:57 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 758B13A6997 for <netext@ietf.org>; Wed, 16 Mar 2011 13:15:57 -0700 (PDT) Received: by wwa36 with SMTP id 36so1763381wwa.13 for <netext@ietf.org>; Wed, 16 Mar 2011 13:17:23 -0700 (PDT) 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=7NaWb/1lPG9+J2B8svgekeGPyEVIGoi7iVhew0xTNPY=; b=drUEkaSVC+I+Ejp1T2PUaKcfqSpmuyIHPS3JNgHVBZNBk/f2NeWJp4EcusVO6xlT2M OzKYkCfSAsKF2z4IaQiCXAh/g44zI77XPxAPf9HP3Mn3+q4P4Z2Cc/Zas7x4i54WxwEu Yb8Ris9EXhsUogznC4FTXO9ill01/wTSiXrQ4= 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=ImaAgKKcZ/mDztZZS/Ayu203P+TuvoFs7MC6sKOsFjPzT2kkFPalueWyMy24uSarpr TYxD8N5FG+hq3bjvS78AVtVvZ7WLGDcxUokstVyplm7FSuUkSlEKDKBraoKb40pzIqeU mQT4H+Jqof/TmtmNt/dWXeUQt0JJh3Kl0Z2HE= MIME-Version: 1.0 Received: by 10.216.9.141 with SMTP id 13mr511408wet.73.1300306643758; Wed, 16 Mar 2011 13:17:23 -0700 (PDT) Received: by 10.216.89.205 with HTTP; Wed, 16 Mar 2011 13:17:23 -0700 (PDT) In-Reply-To: <C9A661F6.13AFF%sgundave@cisco.com> References: <AANLkTi=HfMj=HoU_jQX=6WyTtn+rmBd=VefhDfufVYcu@mail.gmail.com> <C9A661F6.13AFF%sgundave@cisco.com> Date: Wed, 16 Mar 2011 13:17:23 -0700 Message-ID: <AANLkTi=5a_WTs85JeonH5ucn3kdupQKOXmv2A4J9GY82@mail.gmail.com> From: Julien Laganier <julien.ietf@gmail.com> To: Sri Gundavelli <sgundave@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] #4: Logical interface support: Point to point links X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Mar 2011 20:15:58 -0000 Hi Sri, I don't know what it means that a link meets the point-to-point link model semantic, and I certainly don't want the reader to be told it's sending an unicast RA. The link to which the physical interface has to be a point-to-point link as per 5213, period. We are not chartered to change this. --julien On Wed, Mar 16, 2011 at 1:47 PM, Sri Gundavelli <sgundave@cisco.com> wrote: > Hi Julien, > > I already agreed, we need to put a qualifier on that one sentence, which > states, the physical link being a shared link. If you agree, that qualifi= er > can be, "the physical link attached to the logical interface can be a sha= red > link, as long as it can meet the point-to-point link model semantics". Ag= ree > ? > > > Regards > Sri > > > > > On 3/16/11 11:43 AM, "Julien Laganier" <julien.ietf@gmail.com> wrote: > >> Sri, >> >> On Wed, Mar 16, 2011 at 1:31 PM, Sri Gundavelli <sgundave@cisco.com> wro= te: >>> I'm not sure, we can say, we need additional mechanisms in 802.11 to ac= hieve >>> p2p link model. We are not talking about protocol extensions, its rathe= r >>> about configuration. From PMIP perspective, we all agree, we need P2P l= ink >>> model. >> >> That is better, and different from what is in the draft that says >> shared link is supported. >> >> 6.3. =A0Supported Link models for a logical interface >> >> =A0 =A0The sub-interfaces of a logical interface can be bound to a point= -to- >> =A0 =A0point or a shared link (Example: LTE and WLAN). >> >> Do you disagree with the content of the draft? >> >>> =A0If some one wants to connect trusted WLAN access networks with PMIP >>> domain, they can very well do that, as long as they support P2P link mo= del. >> >> Yes, as long as they support point to point link model, and unlike >> what is the current draft. >> >>> We also agreed, we can achieve that with today's 802.11 standards and >>> today's boxes out there. >> >> You can achieve that with today's 802.11 standards. Not sure about >> boxes out there. My AP only does shared link. This discussion seems to >> be moot since current APs do not have MAGs. >> >>> How they do that, if that's by configuring unique SSID's per MN, unique >>> VLAN's, send unicast RA's per RFC-6085, set up some L3 tunnels, is beyo= nd >>> the scope of PMIP. >> >> Again, please do not equate sending unicast RAs with having a point to >> point link as these are two different things. >> >> I do not care how having a point to point link on a physical interface >> is done, my point is that was that the current draft says that shared >> link are supported while they are not, and I didn't put that text in >> that draft, for that matter. >> >>> We can just state the requirement of P2P link model on any access >>> technology, and leave it there. >> >> Right thus you agree the draft has to be corrected wherever it talks >> about shared links, to say that only point-to-point links are >> supported, and that shared links are not supported. >> >> Thanks. >> >> --julien >> >>> On 3/16/11 11:03 AM, "Julien Laganier" <julien.ietf@gmail.com> wrote: >>> >>>> Pierrick, >>>> >>>> On Wed, Mar 16, 2011 at 11:53 AM, =A0<pierrick.seite@orange-ftgroup.co= m> >>>> wrote: >>>>> >>>>> >>>>>> Julien Laganier <julien.ietf@gmail.com> wrote: >>>>>> >>>>>> Pierrick, >>>>>> >>>>>> I am confused... Do you disagree that a vanilla IEEE 802.11 isn't a >>>>>> point-to-point link? >>>>>> >>>>> >>>>> No... I was just agreeing =A0to require p2p link model on the physica= l links. >>>>> So, 802.11 cannot be used without additional mechanism to achieve a >>>>> point-to-point link. Actually, nothing new with regards to RFC5213. >>>> >>>> Thanks for clarifying. >>>> >>>> --julien > > From telemaco.melia@alcatel-lucent.com Thu Mar 17 06:18:49 2011 Return-Path: <telemaco.melia@alcatel-lucent.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF2063A695E for <netext@core3.amsl.com>; Thu, 17 Mar 2011 06:18:49 -0700 (PDT) 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.526, 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 sLf-J8v5FOEu for <netext@core3.amsl.com>; Thu, 17 Mar 2011 06:18:48 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 6EC313A68BD for <netext@ietf.org>; Thu, 17 Mar 2011 06:18:47 -0700 (PDT) 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 p2HDJpCv029770 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 17 Mar 2011 14:20:13 +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, 17 Mar 2011 14:20:10 +0100 From: "MELIA, TELEMACO (TELEMACO)" <telemaco.melia@alcatel-lucent.com> To: "pierrick.seite@orange-ftgroup.com" <pierrick.seite@orange-ftgroup.com>, "trac+netext@zinfandel.tools.ietf.org" <trac+netext@zinfandel.tools.ietf.org>, "basavaraj.patil@nokia.com" <basavaraj.patil@nokia.com> Date: Thu, 17 Mar 2011 14:20:09 +0100 Thread-Topic: [netext] #7: Logical interface: UL/DL packet processing Thread-Index: AcvZ9zLqaCiqXPtjQvqFSNx7xNb4BQJMWIEwACCXFbAAPqMugA== Message-ID: <3D6C64F2D792B540BAAEBCEF6509363B0EE6E5A764@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> References: <066.0751fc96f72ccc7f3cfc7cb7f3fb948e@trac.tools.ietf.org> <3D6C64F2D792B540BAAEBCEF6509363B0EE6E5A4EB@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> <843DA8228A1BA74CA31FB4E111A5C4620190B82F@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C4620190B82F@ftrdmel0.rd.francetelecom.fr> 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" <netext@ietf.org> Subject: Re: [netext] #7: Logical interface: UL/DL packet processing X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 17 Mar 2011 13:18:50 -0000 Hell Pierrick,=20 Agreed, the policies are node-scoped. Would folks believe that a sending/updating algorithm would better clarify = UL/DL packet handling? telemaco=20 -----Message d'origine----- De : pierrick.seite@orange-ftgroup.com [mailto:pierrick.seite@orange-ftgrou= p.com]=20 Envoy=E9 : mercredi 16 mars 2011 08:34 =C0 : MELIA, TELEMACO (TELEMACO); trac+netext@zinfandel.tools.ietf.org; bas= avaraj.patil@nokia.com Cc : netext@ietf.org Objet : RE: [netext] #7: Logical interface: UL/DL packet processing Hi Tele, What is the reason for the flow routing policies entry in the LIF table? IM= HO, this entry is useless. I mean, routing policies should be node-scoped a= nd only allow to select the interface, i.e configure the flow table; that's= it.=20 BTW, when a flow handover is performed, policies should also be updated (In= order to select the correct interface for new flow).=20 BR, Pierrick > -----Message d'origine----- > De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la=20 > part de MELIA, TELEMACO (TELEMACO) Envoy=E9=A0: mardi 15 mars 2011 16:57 = =C0=A0 > : netext issue tracker; basavaraj.patil@nokia.com Cc=A0: netext@ietf.org= =20 > Objet=A0: Re: [netext] #7: Logical interface: UL/DL packet processing >=20 > Folks, reflecting the discussions in the team here is the proposed=20 > text to solve this issue. Let us know any problem you see with the propos= ed text. >=20 > =3D=3D=3D=3D=3D > 6.6. Logical Interface Forwarding Conceptual Data Structures >=20 >=20 > The LIF should maintain the LIF and FLOW table data structures > depicted in Figure 4 >=20 > LIF TABLE FLOW table > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+ +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ > | PIF_ID | FLOW RoutingPolicies | | FLOW ID | PIF_ID | > | | Home Network Prefix | +-------------------------------+ > | | Link Layer Address | | FLOW_ID | PIF_ID | > | | Status | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ > +-------------------------------| > | PIF_ID | FLOW RoutingPolicies | > | | Home Network Prefix | > | | Link Layer Address | > | | Status | > +-------------------------------+ > | .... | .... | > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+ >=20 >=20 > Figure 4 >=20 > The LIF table maintains the mapping between the LIF and each PIF > associated to the LIF (see P3). For each PIF entry the table should > store the associated Routing Policies, the Home Network Prefix > received during the SLAAC procedure, the configured Link Layer > Address (as described above) and the Status of the PIF (e.g. active, > not active). >=20 > The method by which the Routing Policies are configured in the UE is > out of scope of this document. It is however assumed that this > method is in place and that these policies are configured in the LIF > TABLE. >=20 > The FLOW table allows a LIF to properly route each IP flow to the > right interface (see P7). The LIF can identify flows arriving on its > PIFs and can map them accordingly for transmitting the corresponding > packets. For locally generated traffic (e.g. unidirectional outgoing > flows, mobile initiated traffic, etc.), the LIF should perform > interface selection based on the Flow Routing Policies. In case > traffic of an existing flow is suddenly received from the network on > a different PIF than the one locally stored, the LIF should interpret > the event as an explicit flow mobility trigger from the network and > it should update the PIF_ID parameter in the FLOW table. Similarly, > locally generated events from the PIFs or configuration updates to > the local policy rules can cause updates to the table and hence > trigger flow mobility. >=20 >=20 > -----Message d'origine----- > De : netext issue tracker=20 > [mailto:trac+netext@zinfandel.tools.ietf.org] > Envoy=E9 : vendredi 4 mars 2011 00:03 > =C0 : MELIA, TELEMACO (TELEMACO); basavaraj.patil@nokia.com Cc :=20 > netext@ietf.org Objet : [netext] #7: Logical interface: UL/DL packet=20 > processing >=20 > #7: Logical interface: UL/DL packet processing >=20 > Uplink/downlink packet matching: Draft says the Logical interface=20 > should transmit uplink packets on the same physical interface on which=20 > the downlink packet was received for the particular prefix/flow. How=20 > does the logical interface associates an uplink packet to a downlink pack= et? >=20 > -- > ---------------------------------------+------------------------------ > ---------------------------------------+-- > ---------------------------------------+---- > Reporter: basavaraj.patil@. | Owner: telemaco.melia@. > Type: defect | Status: new > Priority: major | Milestone: > Component: Localized routing | Version: > Severity: Active WG Document | Keywords: > ---------------------------------------+------------------------------ > ---------------------------------------+-- > ---------------------------------------+---- >=20 > Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/7> > netext <http://tools.ietf.org/netext/> >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From telemaco.melia@alcatel-lucent.com Thu Mar 17 06:18:56 2011 Return-Path: <telemaco.melia@alcatel-lucent.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F65B3A6981 for <netext@core3.amsl.com>; Thu, 17 Mar 2011 06:18:56 -0700 (PDT) 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.526, 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 y0P3XiwYHJet for <netext@core3.amsl.com>; Thu, 17 Mar 2011 06:18:56 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id C764F3A68BD for <netext@ietf.org>; Thu, 17 Mar 2011 06:18:55 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p2HDKFW3003878 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 17 Mar 2011 14:20:22 +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; Thu, 17 Mar 2011 14:20:11 +0100 From: "MELIA, TELEMACO (TELEMACO)" <telemaco.melia@alcatel-lucent.com> To: "pierrick.seite@orange-ftgroup.com" <pierrick.seite@orange-ftgroup.com>, "trac+netext@zinfandel.tools.ietf.org" <trac+netext@zinfandel.tools.ietf.org>, "basavaraj.patil@nokia.com" <basavaraj.patil@nokia.com> Date: Thu, 17 Mar 2011 14:20:09 +0100 Thread-Topic: [netext] #7: Logical interface: UL/DL packet processing Thread-Index: AcvZ9zLqaCiqXPtjQvqFSNx7xNb4BQJMWIEwACCXFbAAPqMugA== Message-ID: <3D6C64F2D792B540BAAEBCEF6509363B0EE6E5A765@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> References: <066.0751fc96f72ccc7f3cfc7cb7f3fb948e@trac.tools.ietf.org> <3D6C64F2D792B540BAAEBCEF6509363B0EE6E5A4EB@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> <843DA8228A1BA74CA31FB4E111A5C4620190B82F@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C4620190B82F@ftrdmel0.rd.francetelecom.fr> 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.84 Cc: "netext@ietf.org" <netext@ietf.org> Subject: Re: [netext] #7: Logical interface: UL/DL packet processing X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 17 Mar 2011 13:18:56 -0000 Hell Pierrick,=20 Agreed, the policies are node-scoped. Would folks believe that a sending/updating algorithm would better clarify = UL/DL packet handling? telemaco=20 -----Message d'origine----- De : pierrick.seite@orange-ftgroup.com [mailto:pierrick.seite@orange-ftgrou= p.com]=20 Envoy=E9 : mercredi 16 mars 2011 08:34 =C0 : MELIA, TELEMACO (TELEMACO); trac+netext@zinfandel.tools.ietf.org; bas= avaraj.patil@nokia.com Cc : netext@ietf.org Objet : RE: [netext] #7: Logical interface: UL/DL packet processing Hi Tele, What is the reason for the flow routing policies entry in the LIF table? IM= HO, this entry is useless. I mean, routing policies should be node-scoped a= nd only allow to select the interface, i.e configure the flow table; that's= it.=20 BTW, when a flow handover is performed, policies should also be updated (In= order to select the correct interface for new flow).=20 BR, Pierrick > -----Message d'origine----- > De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la=20 > part de MELIA, TELEMACO (TELEMACO) Envoy=E9=A0: mardi 15 mars 2011 16:57 = =C0=A0 > : netext issue tracker; basavaraj.patil@nokia.com Cc=A0: netext@ietf.org= =20 > Objet=A0: Re: [netext] #7: Logical interface: UL/DL packet processing >=20 > Folks, reflecting the discussions in the team here is the proposed=20 > text to solve this issue. Let us know any problem you see with the propos= ed text. >=20 > =3D=3D=3D=3D=3D > 6.6. Logical Interface Forwarding Conceptual Data Structures >=20 >=20 > The LIF should maintain the LIF and FLOW table data structures > depicted in Figure 4 >=20 > LIF TABLE FLOW table > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+ +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ > | PIF_ID | FLOW RoutingPolicies | | FLOW ID | PIF_ID | > | | Home Network Prefix | +-------------------------------+ > | | Link Layer Address | | FLOW_ID | PIF_ID | > | | Status | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ > +-------------------------------| > | PIF_ID | FLOW RoutingPolicies | > | | Home Network Prefix | > | | Link Layer Address | > | | Status | > +-------------------------------+ > | .... | .... | > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+ >=20 >=20 > Figure 4 >=20 > The LIF table maintains the mapping between the LIF and each PIF > associated to the LIF (see P3). For each PIF entry the table should > store the associated Routing Policies, the Home Network Prefix > received during the SLAAC procedure, the configured Link Layer > Address (as described above) and the Status of the PIF (e.g. active, > not active). >=20 > The method by which the Routing Policies are configured in the UE is > out of scope of this document. It is however assumed that this > method is in place and that these policies are configured in the LIF > TABLE. >=20 > The FLOW table allows a LIF to properly route each IP flow to the > right interface (see P7). The LIF can identify flows arriving on its > PIFs and can map them accordingly for transmitting the corresponding > packets. For locally generated traffic (e.g. unidirectional outgoing > flows, mobile initiated traffic, etc.), the LIF should perform > interface selection based on the Flow Routing Policies. In case > traffic of an existing flow is suddenly received from the network on > a different PIF than the one locally stored, the LIF should interpret > the event as an explicit flow mobility trigger from the network and > it should update the PIF_ID parameter in the FLOW table. Similarly, > locally generated events from the PIFs or configuration updates to > the local policy rules can cause updates to the table and hence > trigger flow mobility. >=20 >=20 > -----Message d'origine----- > De : netext issue tracker=20 > [mailto:trac+netext@zinfandel.tools.ietf.org] > Envoy=E9 : vendredi 4 mars 2011 00:03 > =C0 : MELIA, TELEMACO (TELEMACO); basavaraj.patil@nokia.com Cc :=20 > netext@ietf.org Objet : [netext] #7: Logical interface: UL/DL packet=20 > processing >=20 > #7: Logical interface: UL/DL packet processing >=20 > Uplink/downlink packet matching: Draft says the Logical interface=20 > should transmit uplink packets on the same physical interface on which=20 > the downlink packet was received for the particular prefix/flow. How=20 > does the logical interface associates an uplink packet to a downlink pack= et? >=20 > -- > ---------------------------------------+------------------------------ > ---------------------------------------+-- > ---------------------------------------+---- > Reporter: basavaraj.patil@. | Owner: telemaco.melia@. > Type: defect | Status: new > Priority: major | Milestone: > Component: Localized routing | Version: > Severity: Active WG Document | Keywords: > ---------------------------------------+------------------------------ > ---------------------------------------+-- > ---------------------------------------+---- >=20 > Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/7> > netext <http://tools.ietf.org/netext/> >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From jari.arkko@piuha.net Sun Mar 20 16:33:46 2011 Return-Path: <jari.arkko@piuha.net> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B222328C10C for <netext@core3.amsl.com>; Sun, 20 Mar 2011 16:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 utZtBwx1xMxO for <netext@core3.amsl.com>; Sun, 20 Mar 2011 16:33:45 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id A6ECB28C10B for <netext@ietf.org>; Sun, 20 Mar 2011 16:33:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 543D92D2DF; Mon, 21 Mar 2011 01:35:16 +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 qLGfuKB3oyVd; Mon, 21 Mar 2011 01:35:15 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id AE0F82CC2F; Mon, 21 Mar 2011 01:35:15 +0200 (EET) Message-ID: <4D868F32.7000909@piuha.net> Date: Mon, 21 Mar 2011 00:35:14 +0100 From: Jari Arkko <jari.arkko@piuha.net> User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: "netext@ietf.org" <netext@ietf.org>, draft-ietf-netext-redirect@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netext] AD review of draft-ietf-netext-redirect X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 20 Mar 2011 23:33:46 -0000 I have reviewed this draft. I believe it is in good shape and can move forward. I think I understand the entire operation and could not seen any issues. Just a minor editorial comment: > following considerations has to taken into account ... has to be taken into account ... I have asked for the IETF Last Call to be initiated for this document. Jari From iesg-secretary@ietf.org Mon Mar 21 07:46:52 2011 Return-Path: <iesg-secretary@ietf.org> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D68EB28C157; Mon, 21 Mar 2011 07:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 CwhkmHAaYTB5; Mon, 21 Mar 2011 07:46:52 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A4ED3A6870; Mon, 21 Mar 2011 07:46:52 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110321144652.11378.80711.idtracker@localhost> Date: Mon, 21 Mar 2011 07:46:52 -0700 Cc: netext@ietf.org Subject: [netext] Last Call: <draft-ietf-netext-redirect-07.txt> (Runtime LMA Assignment Support for Proxy Mobile IPv6) to Proposed Standard 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 21 Mar 2011 14:46:52 -0000 The IESG has received a request from the Network-Based Mobility Extensions WG (netext) to consider the following document: - 'Runtime LMA Assignment Support for Proxy Mobile IPv6' <draft-ietf-netext-redirect-07.txt> as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-04-10. 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-redirect/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-netext-redirect/ The following IPR Declarations may be related to this I-D: /ipr/1405/ From yoshifumi.nishida@gmail.com Tue Mar 15 01:25:13 2011 Return-Path: <yoshifumi.nishida@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B82D3A6A5D; Tue, 15 Mar 2011 01:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 foz-lqvTrPzD; Tue, 15 Mar 2011 01:25:11 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id CF9CC3A6BF2; Tue, 15 Mar 2011 01:25:10 -0700 (PDT) Received: by gwb20 with SMTP id 20so171113gwb.31 for <multiple recipients>; Tue, 15 Mar 2011 01:26:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:cc:content-type; bh=BD625DETR+zU5HvLaMCrrXdiwl7NtW/Zcc1SwXoE7bQ=; b=JwwvQuhTCDVG3+TDPT3AlA6R8QEvc4s4Q3UgKfJPn4TW1vtALmjzqQusBJOXNWBj9J kmWiy+Uo2Rzy10lhFiFmfdb4bfPPJ7tOmsSXgxPGE1AWH/ViBeEjlnq2Zqf4YFtBn9Ul AUU1iD2lXEICGOmH1stpec10SU5DY5qBTuSkg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=N1t5QV0K4rOxhHEaq+IES+amxQv2G9TgkqS5Vb5170XJaNY98QHOSc2pjQ/VS+cvjP uKiLQ96HvjRWsC9qV0PwtY2jx2LCiKnTEiWfCAITrFzcpuGHOMEdFoMB3MKIIlQe1sWl 8Rtnnzof40iJDjorNdHeVQLGSJA1R2zPK8ezY= MIME-Version: 1.0 Received: by 10.146.74.13 with SMTP id w13mr19416290yaa.18.1300177595174; Tue, 15 Mar 2011 01:26:35 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.147.171.12 with HTTP; Tue, 15 Mar 2011 01:26:35 -0700 (PDT) Date: Tue, 15 Mar 2011 01:26:35 -0700 X-Google-Sender-Auth: xJ3XyU9XCBjlFtEF2Pndk0ZWnZQ Message-ID: <AANLkTikB1A+ipaj6XN7VBJpVtOvpjJe0rpCbPhbZMmrD@mail.gmail.com> From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp> To: ietf@ietf.org, netext@ietf.org, draft-ietf-netext-pmip6-lr-ps@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Mon, 21 Mar 2011 08:47:49 -0700 Cc: Transport Directorate <tsv-dir@ietf.org> Subject: [netext] TSVDIR Review for 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Mar 2011 08:25:13 -0000 Hello, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@ietf.org if you reply to or forward this review. Summary: This draft describes the problem space for localized routing in PMIPv6, which supports direct communication between MAGs for MN and CN. This draft is basically ready for publication and I couldn't find any transport related issues in the draft. Minor comments: Would it be better to mention error detection and fallback function in Functional Requirements? It would be useful and helpful to fall back to normal routing when something happens. I believe localize routing is very useful in most cases. However, I think there will be the cases where we had better avoid localized routing, such as a case where there are some restrictions (policy, network quality or configuration, etc) in communications between MAGs. It might be better to address having some kind of control to enable localized routing in Functional Requirements in addition to checking source and destination addresses. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From trac+netext@trac.tools.ietf.org Mon Mar 21 09:04:20 2011 Return-Path: <trac+netext@trac.tools.ietf.org> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C914A3A6886 for <netext@core3.amsl.com>; Mon, 21 Mar 2011 09:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 jPTyMWrM3okm for <netext@core3.amsl.com>; Mon, 21 Mar 2011 09:04:19 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id EB84A3A6881 for <netext@ietf.org>; Mon, 21 Mar 2011 09:04:19 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from <trac+netext@trac.tools.ietf.org>) id 1Q1hbw-0000Z9-Tp; Mon, 21 Mar 2011 09:05:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "netext issue tracker" <trac+netext@trac.tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: liebsch@neclab.eu, basavaraj.patil@nokia.com X-Trac-Project: netext Date: Mon, 21 Mar 2011 16:05:40 -0000 X-URL: http://tools.ietf.org/netext/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/netext/trac/ticket/8 Message-ID: <066.ac042b61a410c326c291fd90be684bb3@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: liebsch@neclab.eu, basavaraj.patil@nokia.com, draft-ietf-netext-pmip6-lr-ps@tools.ietf.org, netext@ietf.org X-SA-Exim-Mail-From: trac+netext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: netext@ietf.org, draft-ietf-netext-pmip6-lr-ps@tools.ietf.org Subject: [netext] #8: TSV review of LR PS I-D X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 21 Mar 2011 16:04:20 -0000 #8: TSV review of LR PS I-D Hello, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@ietf.org if you reply to or forward this review. Summary: This draft describes the problem space for localized routing in PMIPv6, which supports direct communication between MAGs for MN and CN. This draft is basically ready for publication and I couldn't find any transport related issues in the draft. Minor comments: Would it be better to mention error detection and fallback function in Functional Requirements? It would be useful and helpful to fall back to normal routing when something happens. I believe localize routing is very useful in most cases. However, I think there will be the cases where we had better avoid localized routing, such as a case where there are some restrictions (policy, network quality or configuration, etc) in communications between MAGs. It might be better to address having some kind of control to enable localized routing in Functional Requirements in addition to checking source and destination addresses. Thanks, -- Yoshifumi Nishida -- ---------------------------------------+------------------------------------ Reporter: basavaraj.patil@… | Owner: liebsch@… Type: defect | Status: new Priority: minor | Milestone: Component: pmip6-lr-ps | Version: Severity: - | Keywords: ---------------------------------------+------------------------------------ Ticket URL: <https://svn.tools.ietf.org/wg/netext/trac/ticket/8> netext <http://tools.ietf.org/netext/> From iesg-secretary@ietf.org Mon Mar 21 14:24:26 2011 Return-Path: <iesg-secretary@ietf.org> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8360628C17E; Mon, 21 Mar 2011 14:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 AM-9l-JkfFZn; Mon, 21 Mar 2011 14:24:25 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51D2028C186; Mon, 21 Mar 2011 14:24:25 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110321212425.18634.42745.idtracker@localhost> Date: Mon, 21 Mar 2011 14:24:25 -0700 Cc: netext mailing list <netext@ietf.org>, Internet Architecture Board <iab@iab.org>, netext chair <netext-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org> Subject: [netext] Document Action: 'PMIPv6 Localized Routing Problem Statement' to Informational RFC (draft-ietf-netext-pmip6-lr-ps-06.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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 21 Mar 2011 21:24:26 -0000 The IESG has approved the following document: - 'PMIPv6 Localized Routing Problem Statement' (draft-ietf-netext-pmip6-lr-ps-06.txt) as an Informational RFC This document is the product of the Network-Based Mobility Extensions Working Group. The IESG contact persons are Jari Arkko and Ralph Droms. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-netext-pmip6-lr-ps/ Technical Summary This document explains why route optimization in PMIP networks may be necessary and what challenges are involved designing such a feature. Working Group Summary This is a product of the NETEXT WG. Document Quality The document has gone through WGLC in the working group, and the area director believes that the document is well written. Personnel The Document Shepherd is Basavaraj Patil and the responsible Area Director is Jari Arkko. From julien.ietf@gmail.com Thu Mar 24 11:06:02 2011 Return-Path: <julien.ietf@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75B7C28C141 for <netext@core3.amsl.com>; Thu, 24 Mar 2011 11:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.31 X-Spam-Level: X-Spam-Status: No, score=-3.31 tagged_above=-999 required=5 tests=[AWL=0.289, 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 TIMLRvTlQ81f for <netext@core3.amsl.com>; Thu, 24 Mar 2011 11:06:01 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id B3F0328C13D for <netext@ietf.org>; Thu, 24 Mar 2011 11:06:00 -0700 (PDT) Received: by ewy19 with SMTP id 19so186117ewy.31 for <netext@ietf.org>; Thu, 24 Mar 2011 11:07:35 -0700 (PDT) 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=Kn5Tkmu6aVD5jzMKb6MBSHJb0YtatU0HR6OV4apraJs=; b=brMOnxwGRiKmHP5YWo6qT5d75IfgdkYIugj+aByELLWoIJV6uA2SIrDGbVqVBVdC1A mV8xAo5mb0CwKKcYWK1y2VsC8ww/Iuhl04RkYmqIQ25N2B4hwZ4pH722t1cVJ/deXUXE rbxkXCY0/4ATw3aRrvlC/g+zf2HY3LbErSxEA= 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=mRyL82PTDBB1xj8ctIDIrKZ6/+ziI3RhCncgdwlXShBZy7Xrl2ysoIQqsBjpMutCMz voUpEdo9C5StHOPgjWVShUegsTxeeTh2GVdTy+5MgtbRQGauW7cEpx+qfpLp154KPQAK K7+rjgUyvYSFAlqgWp+3yhpYcNnDuznjb/33Y= MIME-Version: 1.0 Received: by 10.216.24.73 with SMTP id w51mr7466280wew.72.1300990054871; Thu, 24 Mar 2011 11:07:34 -0700 (PDT) Received: by 10.216.89.205 with HTTP; Thu, 24 Mar 2011 11:07:34 -0700 (PDT) In-Reply-To: <AANLkTi=5a_WTs85JeonH5ucn3kdupQKOXmv2A4J9GY82@mail.gmail.com> References: <AANLkTi=HfMj=HoU_jQX=6WyTtn+rmBd=VefhDfufVYcu@mail.gmail.com> <C9A661F6.13AFF%sgundave@cisco.com> <AANLkTi=5a_WTs85JeonH5ucn3kdupQKOXmv2A4J9GY82@mail.gmail.com> Date: Thu, 24 Mar 2011 11:07:34 -0700 Message-ID: <AANLkTi=ODv3RDAtGqo2C7n-C_DiWcty28NUkqxLRFsgT@mail.gmail.com> From: Julien Laganier <julien.ietf@gmail.com> To: netext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [netext] #4: Logical interface support: Point to point links X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 24 Mar 2011 18:06:02 -0000 Folks, I've been chatting offline with Sri and I'd like to share with the rest of the WG my latest proposal regarding the content of section 6.3. I would reword the first sentence of the paragraph: The sub-interfaces of a logical interface can be bound to a point-to- point or a shared link (Example: LTE and WLAN). into: As per the original PMIPv6 specificiation [RFC5213] the physical interface underneath the logical interface has to be bound to point-to-point link [RFC4861]. Access technologies that provides a shared media (e.g., IEEE 802.11) can be supported as long as they provide a point-to-point link [rfc4861]. The details of how a shared media provides a point to point link are link layer specific and/or operational matters that are out of scope of this document. For example IEEE 802.11 media can provide a point-to-point link via the appropriate use of IEEE 802.1Q VLAN header where a distinct VLAN is configured between the MAG and each of the mobile node. I would remove the second sentence: The logical interface appears as a shared-link to the applications, and adapts to the link model of the sub-interface for packet communication. For example, when transmitting a packet on a sub-interface which is attached to a p2p link, the transmission conforms to the p2p link model and when transmitting on a sub-interface attached to a shared link, the transmission conforms to the shared link model. Because it doesn' t add much, for the two following reasons: 1) I don' t know what it means that a transmission conforms to the {ptp, shared} link model, and 2) it is tautologic, e.g., if the link is {ptp, shared} then transmit conforming to the {ptp, shared} link model... I would remove entirely the second paragraph: Based on the link to which the sub-interface is attached to, the layer-2 resolutions may or may not be needed. If the interface is bound to a P2P link with PPP running, there will not be any link- layer resolutions in the form of ARP/ND messages. However, if the interface is bound to a shared link such as Ethernet, there will be ND resolutions. The logical interface implementation has to maintain the required link model and the associated state for each sub- interface. as it is tautologic as well, it sort of says: 1. address resolution may or may not be needed =3D> how could it be different. it's like saying it might day or it might be night, where is the information? 2. if address resolution is not needed, it is not performed =3D> ditto. 3. if address resolution is needed, it is performed. Finally it talks about shared link that we do not support. Thus I think we should remove it altogether. On Wed, Mar 16, 2011 at 1:17 PM, Julien Laganier <julien.ietf@gmail.com> wr= ote: > Hi Sri, > > I don't know what it means that a link meets the point-to-point link > model semantic, and I certainly don't want the reader to be told it's > sending an unicast RA. > > The link to which the physical interface has to be a point-to-point > link as per 5213, period. We are not chartered to change this. > > --julien > > On Wed, Mar 16, 2011 at 1:47 PM, Sri Gundavelli <sgundave@cisco.com> wrot= e: >> Hi Julien, >> >> I already agreed, we need to put a qualifier on that one sentence, which >> states, the physical link being a shared link. If you agree, that qualif= ier >> can be, "the physical link attached to the logical interface can be a sh= ared >> link, as long as it can meet the point-to-point link model semantics". A= gree >> ? >> >> >> Regards >> Sri >> >> >> >> >> On 3/16/11 11:43 AM, "Julien Laganier" <julien.ietf@gmail.com> wrote: >> >>> Sri, >>> >>> On Wed, Mar 16, 2011 at 1:31 PM, Sri Gundavelli <sgundave@cisco.com> wr= ote: >>>> I'm not sure, we can say, we need additional mechanisms in 802.11 to a= chieve >>>> p2p link model. We are not talking about protocol extensions, its rath= er >>>> about configuration. From PMIP perspective, we all agree, we need P2P = link >>>> model. >>> >>> That is better, and different from what is in the draft that says >>> shared link is supported. >>> >>> 6.3. =A0Supported Link models for a logical interface >>> >>> =A0 =A0The sub-interfaces of a logical interface can be bound to a poin= t-to- >>> =A0 =A0point or a shared link (Example: LTE and WLAN). >>> >>> Do you disagree with the content of the draft? >>> >>>> =A0If some one wants to connect trusted WLAN access networks with PMIP >>>> domain, they can very well do that, as long as they support P2P link m= odel. >>> >>> Yes, as long as they support point to point link model, and unlike >>> what is the current draft. >>> >>>> We also agreed, we can achieve that with today's 802.11 standards and >>>> today's boxes out there. >>> >>> You can achieve that with today's 802.11 standards. Not sure about >>> boxes out there. My AP only does shared link. This discussion seems to >>> be moot since current APs do not have MAGs. >>> >>>> How they do that, if that's by configuring unique SSID's per MN, uniqu= e >>>> VLAN's, send unicast RA's per RFC-6085, set up some L3 tunnels, is bey= ond >>>> the scope of PMIP. >>> >>> Again, please do not equate sending unicast RAs with having a point to >>> point link as these are two different things. >>> >>> I do not care how having a point to point link on a physical interface >>> is done, my point is that was that the current draft says that shared >>> link are supported while they are not, and I didn't put that text in >>> that draft, for that matter. >>> >>>> We can just state the requirement of P2P link model on any access >>>> technology, and leave it there. >>> >>> Right thus you agree the draft has to be corrected wherever it talks >>> about shared links, to say that only point-to-point links are >>> supported, and that shared links are not supported. >>> >>> Thanks. >>> >>> --julien >>> >>>> On 3/16/11 11:03 AM, "Julien Laganier" <julien.ietf@gmail.com> wrote: >>>> >>>>> Pierrick, >>>>> >>>>> On Wed, Mar 16, 2011 at 11:53 AM, =A0<pierrick.seite@orange-ftgroup.c= om> >>>>> wrote: >>>>>> >>>>>> >>>>>>> Julien Laganier <julien.ietf@gmail.com> wrote: >>>>>>> >>>>>>> Pierrick, >>>>>>> >>>>>>> I am confused... Do you disagree that a vanilla IEEE 802.11 isn't a >>>>>>> point-to-point link? >>>>>>> >>>>>> >>>>>> No... I was just agreeing =A0to require p2p link model on the physic= al links. >>>>>> So, 802.11 cannot be used without additional mechanism to achieve a >>>>>> point-to-point link. Actually, nothing new with regards to RFC5213. >>>>> >>>>> Thanks for clarifying. >>>>> >>>>> --julien >> >> > From pierrick.seite@orange-ftgroup.com Fri Mar 25 05:32:20 2011 Return-Path: <pierrick.seite@orange-ftgroup.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC00128B56A for <netext@core3.amsl.com>; Fri, 25 Mar 2011 05:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[AWL=0.269, 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 q8dl6ctKTSdW for <netext@core3.amsl.com>; Fri, 25 Mar 2011 05:32:18 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 4AB2F3A6847 for <netext@ietf.org>; Fri, 25 Mar 2011 05:32:17 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3268C79800A; Fri, 25 Mar 2011 13:39:48 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 29F4A798009; Fri, 25 Mar 2011 13:39:48 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Mar 2011 13:33:51 +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, 25 Mar 2011 13:33:50 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462019551AD@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <AANLkTi=ODv3RDAtGqo2C7n-C_DiWcty28NUkqxLRFsgT@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] #4: Logical interface support: Point to point links Thread-Index: AcvqTlp5UQOktyHvTxWL02PizBSAeQAmIgNQ References: <AANLkTi=HfMj=HoU_jQX=6WyTtn+rmBd=VefhDfufVYcu@mail.gmail.com><C9A661F6.13AFF%sgundave@cisco.com><AANLkTi=5a_WTs85JeonH5ucn3kdupQKOXmv2A4J9GY82@mail.gmail.com> <AANLkTi=ODv3RDAtGqo2C7n-C_DiWcty28NUkqxLRFsgT@mail.gmail.com> From: <pierrick.seite@orange-ftgroup.com> To: <julien.ietf@gmail.com>, <netext@ietf.org> X-OriginalArrivalTime: 25 Mar 2011 12:33:51.0807 (UTC) FILETIME=[E5C004F0:01CBEAE8] Subject: Re: [netext] #4: Logical interface support: Point to point links X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Mar 2011 12:32:20 -0000 Hi Julien, IMHO, your text can replace the current section; there is no need to say = more. Pierrick > -----Message d'origine----- > De=A0: Julien Laganier [mailto:julien.ietf@gmail.com] > Envoy=E9=A0: jeudi 24 mars 2011 19:08 > =C0=A0: netext@ietf.org > Cc=A0: SEITE Pierrick RD-RESA-REN; Sri Gundavelli > Objet=A0: Re: [netext] #4: Logical interface support: Point to point = links >=20 > Folks, >=20 > I've been chatting offline with Sri and I'd like to share with the > rest of the WG my latest proposal regarding the content of section > 6.3. >=20 > I would reword the first sentence of the paragraph: >=20 > The sub-interfaces of a logical interface can be bound to a = point-to- > point or a shared link (Example: LTE and WLAN). >=20 > into: >=20 > As per the original PMIPv6 specificiation [RFC5213] the physical > interface underneath the logical interface has to be bound to > point-to-point link [RFC4861]. Access technologies that provides a > shared media (e.g., IEEE 802.11) can be supported as long as they > provide a point-to-point link [rfc4861]. The details of how a shared > media provides a point to point link are link layer specific and/or > operational matters that are out of scope of this document. For > example IEEE 802.11 media can provide a point-to-point link via the > appropriate use of IEEE 802.1Q VLAN header where a distinct VLAN is > configured between the MAG and each of the mobile node. >=20 > I would remove the second sentence: >=20 > The logical interface appears as a shared-link to the applications, > and adapts to > the link model of the sub-interface for packet communication. For > example, when transmitting a packet on a sub-interface which is > attached to a p2p link, the transmission conforms to the p2p link > model and when transmitting on a sub-interface attached to a shared > link, the transmission conforms to the shared link model. >=20 > Because it doesn' t add much, for the two following reasons: 1) I don' = t > know what it means that a transmission conforms to the {ptp, shared} > link model, and 2) it is tautologic, e.g., if the link is {ptp, > shared} then transmit conforming to the {ptp, shared} link model... >=20 > I would remove entirely the second paragraph: >=20 > Based on the link to which the sub-interface is attached to, the > layer-2 resolutions may or may not be needed. If the interface is > bound to a P2P link with PPP running, there will not be any link- > layer resolutions in the form of ARP/ND messages. However, if the > interface is bound to a shared link such as Ethernet, there will be > ND resolutions. The logical interface implementation has to = maintain > the required link model and the associated state for each sub- > interface. >=20 > as it is tautologic as well, it sort of says: >=20 > 1. address resolution may or may not be needed =3D> how could it be > different. it's like saying it might day or it might be night, where > is the information? > 2. if address resolution is not needed, it is not performed =3D> = ditto. > 3. if address resolution is needed, it is performed. >=20 > Finally it talks about shared link that we do not support. Thus I > think we should remove it altogether. >=20 > On Wed, Mar 16, 2011 at 1:17 PM, Julien Laganier = <julien.ietf@gmail.com> > wrote: > > Hi Sri, > > > > I don't know what it means that a link meets the point-to-point link > > model semantic, and I certainly don't want the reader to be told = it's > > sending an unicast RA. > > > > The link to which the physical interface has to be a point-to-point > > link as per 5213, period. We are not chartered to change this. > > > > --julien > > > > On Wed, Mar 16, 2011 at 1:47 PM, Sri Gundavelli <sgundave@cisco.com> > wrote: > >> Hi Julien, > >> > >> I already agreed, we need to put a qualifier on that one sentence, > which > >> states, the physical link being a shared link. If you agree, that > qualifier > >> can be, "the physical link attached to the logical interface can be = a > shared > >> link, as long as it can meet the point-to-point link model = semantics". > Agree > >> ? > >> > >> > >> Regards > >> Sri > >> > >> > >> > >> > >> On 3/16/11 11:43 AM, "Julien Laganier" <julien.ietf@gmail.com> = wrote: > >> > >>> Sri, > >>> > >>> On Wed, Mar 16, 2011 at 1:31 PM, Sri Gundavelli = <sgundave@cisco.com> > wrote: > >>>> I'm not sure, we can say, we need additional mechanisms in 802.11 = to > achieve > >>>> p2p link model. We are not talking about protocol extensions, its > rather > >>>> about configuration. From PMIP perspective, we all agree, we need = P2P > link > >>>> model. > >>> > >>> That is better, and different from what is in the draft that says > >>> shared link is supported. > >>> > >>> 6.3. =A0Supported Link models for a logical interface > >>> > >>> =A0 =A0The sub-interfaces of a logical interface can be bound to a = point- > to- > >>> =A0 =A0point or a shared link (Example: LTE and WLAN). > >>> > >>> Do you disagree with the content of the draft? > >>> > >>>> =A0If some one wants to connect trusted WLAN access networks with = PMIP > >>>> domain, they can very well do that, as long as they support P2P = link > model. > >>> > >>> Yes, as long as they support point to point link model, and unlike > >>> what is the current draft. > >>> > >>>> We also agreed, we can achieve that with today's 802.11 standards = and > >>>> today's boxes out there. > >>> > >>> You can achieve that with today's 802.11 standards. Not sure about > >>> boxes out there. My AP only does shared link. This discussion = seems to > >>> be moot since current APs do not have MAGs. > >>> > >>>> How they do that, if that's by configuring unique SSID's per MN, > unique > >>>> VLAN's, send unicast RA's per RFC-6085, set up some L3 tunnels, = is > beyond > >>>> the scope of PMIP. > >>> > >>> Again, please do not equate sending unicast RAs with having a = point to > >>> point link as these are two different things. > >>> > >>> I do not care how having a point to point link on a physical = interface > >>> is done, my point is that was that the current draft says that = shared > >>> link are supported while they are not, and I didn't put that text = in > >>> that draft, for that matter. > >>> > >>>> We can just state the requirement of P2P link model on any access > >>>> technology, and leave it there. > >>> > >>> Right thus you agree the draft has to be corrected wherever it = talks > >>> about shared links, to say that only point-to-point links are > >>> supported, and that shared links are not supported. > >>> > >>> Thanks. > >>> > >>> --julien > >>> > >>>> On 3/16/11 11:03 AM, "Julien Laganier" <julien.ietf@gmail.com> = wrote: > >>>> > >>>>> Pierrick, > >>>>> > >>>>> On Wed, Mar 16, 2011 at 11:53 AM, =A0<pierrick.seite@orange- > ftgroup.com> > >>>>> wrote: > >>>>>> > >>>>>> > >>>>>>> Julien Laganier <julien.ietf@gmail.com> wrote: > >>>>>>> > >>>>>>> Pierrick, > >>>>>>> > >>>>>>> I am confused... Do you disagree that a vanilla IEEE 802.11 = isn't > a > >>>>>>> point-to-point link? > >>>>>>> > >>>>>> > >>>>>> No... I was just agreeing =A0to require p2p link model on the > physical links. > >>>>>> So, 802.11 cannot be used without additional mechanism to = achieve a > >>>>>> point-to-point link. Actually, nothing new with regards to = RFC5213. > >>>>> > >>>>> Thanks for clarifying. > >>>>> > >>>>> --julien > >> > >> > > From Basavaraj.Patil@nokia.com Wed Mar 30 17:15:00 2011 Return-Path: <Basavaraj.Patil@nokia.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94DE228C0FD for <netext@core3.amsl.com>; Wed, 30 Mar 2011 17:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.077 X-Spam-Level: X-Spam-Status: No, score=-103.077 tagged_above=-999 required=5 tests=[AWL=0.522, 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 Ex9YSKqNqduB for <netext@core3.amsl.com>; Wed, 30 Mar 2011 17:14:59 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id CEEBB3A6BE4 for <netext@ietf.org>; Wed, 30 Mar 2011 17:14:59 -0700 (PDT) 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 p2V0Ga6T029261 for <netext@ietf.org>; Thu, 31 Mar 2011 03:16:37 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 Mar 2011 03:16:31 +0300 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 31 Mar 2011 02:16:31 +0200 Received: from 008-AM1MPN1-023.mgdnok.nokia.com ([169.254.3.94]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0270.002; Thu, 31 Mar 2011 02:16:30 +0200 From: <Basavaraj.Patil@nokia.com> To: <netext@ietf.org> Thread-Topic: Volunteers for minutes and jabber scribe? Thread-Index: AQHL7zjiFqQiBl4sWkef6y5ZfqSiOg== Date: Thu, 31 Mar 2011 00:16:29 +0000 Message-ID: <C9B9320C.128D1%basavaraj.patil@nokia.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: [130.129.69.45] Content-Type: text/plain; charset="us-ascii" Content-ID: <64F980141F06D84CA1DC1288E7A540B3@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 31 Mar 2011 00:16:31.0472 (UTC) FILETIME=[E2EF1F00:01CBEF38] X-Nokia-AV: Clean Subject: [netext] Volunteers for minutes and jabber scribe? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 31 Mar 2011 00:15:00 -0000 Hello, Requesting a couple of volunteers to take minutes and a jabber scribe. Please respond ASAP. -Basavaraj From behcetsarikaya@yahoo.com Thu Mar 31 04:59:18 2011 Return-Path: <behcetsarikaya@yahoo.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E157728C14A for <netext@core3.amsl.com>; Thu, 31 Mar 2011 04:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.051 X-Spam-Level: X-Spam-Status: No, score=-1.051 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_50=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 gtybkXwk6Eh3 for <netext@core3.amsl.com>; Thu, 31 Mar 2011 04:59:16 -0700 (PDT) Received: from nm2.bullet.mail.sp2.yahoo.com (nm2.bullet.mail.sp2.yahoo.com [98.139.91.72]) by core3.amsl.com (Postfix) with SMTP id DC5F528C147 for <netext@ietf.org>; Thu, 31 Mar 2011 04:59:16 -0700 (PDT) Received: from [98.139.91.68] by nm2.bullet.mail.sp2.yahoo.com with NNFMP; 31 Mar 2011 12:00:54 -0000 Received: from [98.139.91.22] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 31 Mar 2011 12:00:54 -0000 Received: from [127.0.0.1] by omp1022.mail.sp2.yahoo.com with NNFMP; 31 Mar 2011 12:00:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 88763.88071.bm@omp1022.mail.sp2.yahoo.com Received: (qmail 77789 invoked by uid 60001); 31 Mar 2011 12:00:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1301572853; bh=17txqJrJGb4eT2ZWj5SO9FqSjBR3omGbQ0prBvAsxuU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=V32OROjkEIG7jgnOiqVdi4RjJkUX7da/6vUrxGgS2WXG1+ud9C2N75nDboTSUVRgSUNg6ls77aV+JNIe2xq1fBeOPU0Fii0TIhgEh6MhIRr0+0GJBiXQ8US8rRex4qziPYUIxpZ1H/115NxxeEcH6UdlXGC3Vr4T+izj/6E6Yng= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=XTw4znwBpiEvzDvAjZf3GtGsNK4CiB4mZyKyTtrD8DDBoWFIIB4QBt+fAZXFYB5Pn1y/gBbY3WB7E+QG/u1A9/uV6/sj66trXyqAgCzQdzafhd80uepRnJFMm4tWLHcOYZHz3uGWda1hKttm65ZmL+rhdjM917T47MeC0Fe4Zfs=; Message-ID: <567666.9185.qm@web111412.mail.gq1.yahoo.com> X-YMail-OSG: lSnPaWQVM1kpmGafal4AUzCrKtGlkTfUS3nPkjdw_qwP2Jk gsAvpt2WJhBNyu6EgMaPIPM60RK3ROLRDKhXRzDfCmtzSgGs1cl00MzJc_LH .d.zaWaWf6AbJq0oVofUHSXoYoow9vp8zIV.uW20sKiG99p6rMH2G3LyMZGj kYf98a.5qC1pl_wHwKslbs9CnYfJyc3.VLS5q6L2QnTKX.BBz_EXCh035aEH V.nBCYdHlzbZAwnuEjnylPWzdHSUkb2GWXCvKJ04Yqmd5RG4wazJw6nNYjkC xVlAZ4uBhlaWIIQBb4Sc5sW4aRvq8OiwxWRy3A8LUMJRpSyJL_461X3NBDht nptsz45LfyFQcFLlmPQQfT.pwVmcjL.ZgxOLsvFIyfpcy3ZkEs4WmuCOKiHY K0D.K63J5Aw-- Received: from [130.129.68.193] by web111412.mail.gq1.yahoo.com via HTTP; Thu, 31 Mar 2011 05:00:53 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.109.295617 Date: Thu, 31 Mar 2011 05:00:53 -0700 (PDT) From: Behcet Sarikaya <behcetsarikaya@yahoo.com> To: netext@ietf.org, zhou.xingyue@zte.com.cn MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [netext] draft-zhou-netext-pd-pmip-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya <sarikaya@ieee.org> List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 31 Mar 2011 11:59:18 -0000 Hi Joy, I saw this draft. I was wondering if the authors have seen http://tools.ietf.org/html/draft-sarikaya-netext-prefix-delegation-00 this draft is currently expired and does not appear on tools page. Regards, Behcet From alexandru.petrescu@gmail.com Thu Mar 31 05:10:10 2011 Return-Path: <alexandru.petrescu@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F270D3A69BB for <netext@core3.amsl.com>; Thu, 31 Mar 2011 05:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.769 X-Spam-Level: X-Spam-Status: No, score=-3.769 tagged_above=-999 required=5 tests=[AWL=-0.170, 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 fozegSQe4ATA for <netext@core3.amsl.com>; Thu, 31 Mar 2011 05:10:09 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 1BD5A28B797 for <netext@ietf.org>; Thu, 31 Mar 2011 05:10:08 -0700 (PDT) Received: by wwa36 with SMTP id 36so1904904wwa.13 for <netext@ietf.org>; Thu, 31 Mar 2011 05:11:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=yR0qvv12fwzH3UurmzWURlTNIHo/rRCGKW2hRzQ+vxE=; b=DpGHRLQN5sSw6RNJE7AWFxRGxYCiyALAzSsO7PFMngHqr6Izvdb2+1tNwdtXxUaz9v HXTO0eDzEFXYz+GPsBpF1XupoTHgIdwPdsu3lyZ1hgXODtPMgjIgs1AgcsicYphr916V 6twHRXi5GBV8i85Ox9ialOYBwebG6oA2GrqAk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=yFvR3z7MQHD1fOQlNdU4SeNk4cSrCJBAlZgW9Tjvy4kZH0yVuXgmb4+6guDjWgBQAp aYapLdv6csCimaW3ZM0e8OpmCR5+lf3wgxfyCKwLZzldeEy7iZNcahUXlPsnaBbBNIvg iifK0Hyj19rLKADba2/NVj1TME5eN+10io5Lw= Received: by 10.227.100.219 with SMTP id z27mr2654819wbn.45.1301573507986; Thu, 31 Mar 2011 05:11:47 -0700 (PDT) Received: from [127.0.0.1] (dhcp-150a.meeting.ietf.org [130.129.21.10]) by mx.google.com with ESMTPS id y29sm616615wbd.4.2011.03.31.05.11.46 (version=SSLv3 cipher=OTHER); Thu, 31 Mar 2011 05:11:47 -0700 (PDT) Message-ID: <4D946F7F.1060809@gmail.com> Date: Thu, 31 Mar 2011 14:11:43 +0200 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: netext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netext] how to do ptp links on wifi without modifying the MN? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 31 Mar 2011 12:10:10 -0000 Hi netext, How to do ptp links on a wifi access? I am asking because I think there is no method. Or otherwise they require modifs on the MN - right? Alex From alexandru.petrescu@gmail.com Thu Mar 31 05:41:56 2011 Return-Path: <alexandru.petrescu@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2CD028C0E4 for <netext@core3.amsl.com>; Thu, 31 Mar 2011 05:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.741 X-Spam-Level: X-Spam-Status: No, score=-3.741 tagged_above=-999 required=5 tests=[AWL=-0.142, 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 OFlw9W5Njv+G for <netext@core3.amsl.com>; Thu, 31 Mar 2011 05:41:55 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 9B5AD3A6B4E for <netext@ietf.org>; Thu, 31 Mar 2011 05:41:54 -0700 (PDT) Received: by wwa36 with SMTP id 36so1929474wwa.13 for <netext@ietf.org>; Thu, 31 Mar 2011 05:43:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=PoMj1EOg5KxymSqlkpKC4AqtRftzgTBnbeNhtEYUVxA=; b=kxSjWKfouK1nMZ1mYCyPZUsa0XWP+CSBP+dmEqox9/XrFr3im4xeplXGkbfhNTGgOW B2j6OE0BvNJu7OPwqZI9HsMNzD4C+sqyZEUpEoYWKTjJVvO6paO5ij6fXcOtO78QffWx yeAwjnKP5St/usT3T4ic01eW9V5F6ty+7OVDM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=NuUxyWS20B2e4jAvGZDl7QmkxUOkFmsDN5/FWD5xX+NzH8y3Erk0ELv5OYRoNQIWnS dh3e21zaWL+dulXUlSl9WY0Iokhxdf1QdlNtTKRFDaFc4KSXldS66zVrxN1SyIVqU2zV /WhNukyVfP1IYy3Jyt5xkN4GhuAi4hPH3c1fs= Received: by 10.227.150.101 with SMTP id x37mr1234662wbv.225.1301575413734; Thu, 31 Mar 2011 05:43:33 -0700 (PDT) Received: from [127.0.0.1] (dhcp-150a.meeting.ietf.org [130.129.21.10]) by mx.google.com with ESMTPS id y29sm626091wbd.55.2011.03.31.05.43.32 (version=SSLv3 cipher=OTHER); Thu, 31 Mar 2011 05:43:33 -0700 (PDT) Message-ID: <4D9476F1.1090708@gmail.com> Date: Thu, 31 Mar 2011 14:43:29 +0200 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Kaibo Zhou <zhoukaibo@catr.cn> References: <4D946F7F.1060809@gmail.com> <4D94734A.7090909@catr.cn> In-Reply-To: <4D94734A.7090909@catr.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: netext@ietf.org Subject: Re: [netext] how to do ptp links on wifi without modifying the MN? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 31 Mar 2011 12:41:56 -0000 thanks... does pppoeconf run on the mn? Alex Le 31/03/2011 14:27, Kaibo Zhou a écrit : > I once tried to set up a PPP connection on the WLAN using pppoeconf, and > it works well. > > > On 03/31/2011 08:11 PM, Alexandru Petrescu wrote: >> Hi netext, >> >> How to do ptp links on a wifi access? >> >> I am asking because I think there is no method. Or otherwise they >> require modifs on the MN - right? >> >> >> Alex >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> >> > From alexandru.petrescu@gmail.com Thu Mar 31 07:40:24 2011 Return-Path: <alexandru.petrescu@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 543913A6B33 for <netext@core3.amsl.com>; Thu, 31 Mar 2011 07:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.916 X-Spam-Level: X-Spam-Status: No, score=-3.916 tagged_above=-999 required=5 tests=[AWL=-0.317, 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 vdBBksmXNJll for <netext@core3.amsl.com>; Thu, 31 Mar 2011 07:40:23 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 320543A6B24 for <netext@ietf.org>; Thu, 31 Mar 2011 07:40:23 -0700 (PDT) Received: by wwa36 with SMTP id 36so2032754wwa.13 for <netext@ietf.org>; Thu, 31 Mar 2011 07:42:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=35pwLAsfCrqJcRLyGhEpg+zrXhZ2eNtJm/+869Aopto=; b=W2rHO0I6MVRaqrVI8SXki+YaLpCkqGagungzsDbsZEGWllMBIAbLwFVw1rRBsqvsny Mv3SjXAtXg/0ig/BU+vU1wlU7v7yVLXSF/pwrWP1XUQPKrLtKzLVi7IS2FJ7baJ4+4zA MXRFUut5S0fqydX9jMFr0Va2gHXIiUc9AkRsA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ntXqA2NuCuUNZxp/TJOeVRcWSiRA/7NQFcYUN93GA4kmOqWicM2HBZt/bokWBCM2zT Bg/NzXWBGjVpYCmtbTAE5Nc36zlYNOhwUdoxrhXgBJL3TeaBFaUziN/wxBYsjq7am0Qw 1nTYi55zZ+ZWtqxxI8Zx+hKYxiUbCpR5tE234= Received: by 10.227.209.8 with SMTP id ge8mr2744574wbb.211.1301582522253; Thu, 31 Mar 2011 07:42:02 -0700 (PDT) Received: from [127.0.0.1] (dhcp-150a.meeting.ietf.org [130.129.21.10]) by mx.google.com with ESMTPS id b20sm691111wbb.33.2011.03.31.07.42.00 (version=SSLv3 cipher=OTHER); Thu, 31 Mar 2011 07:42:01 -0700 (PDT) Message-ID: <4D9492B6.7040805@gmail.com> Date: Thu, 31 Mar 2011 16:41:58 +0200 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Kaibo Zhou <zhoukaibo@catr.cn> References: <4D946F7F.1060809@gmail.com> <4D94734A.7090909@catr.cn> <4D9476F1.1090708@gmail.com> <4D948AB9.3000603@catr.cn> In-Reply-To: <4D948AB9.3000603@catr.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: netext@ietf.org Subject: Re: [netext] how to do ptp links on wifi without modifying the MN? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 31 Mar 2011 14:40:24 -0000 Thanks... can I make a ptp link on MN without running pppoeconf on MN? (e.g. run pppoeconf only on some MAG or some switch, but not on MN) I am asking because I believe it is not possible to not use pppoeconf on MN if one wants ptp links on it. I.e. pppoeconf MAY be the only solution to make pmipv6 work with wifi MN. Do you think different? Alex Le 31/03/2011 16:07, Kaibo Zhou a écrit : > I use pppoeconf in Ubuntu, so I guess it should be able to run on > some kind of MN. > > BR/Zhou > > On 03/31/2011 08:43 PM, Alexandru Petrescu wrote: >> thanks... does pppoeconf run on the mn? >> >> Alex >> >> Le 31/03/2011 14:27, Kaibo Zhou a écrit : >>> I once tried to set up a PPP connection on the WLAN using >>> pppoeconf, and it works well. >>> >>> >>> On 03/31/2011 08:11 PM, Alexandru Petrescu wrote: >>>> Hi netext, >>>> >>>> How to do ptp links on a wifi access? >>>> >>>> I am asking because I think there is no method. Or otherwise >>>> they require modifs on the MN - right? >>>> >>>> >>>> Alex _______________________________________________ netext >>>> mailing list netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>> >>>> >>> >> >> >> > From cjbc@it.uc3m.es Thu Mar 31 09:26:00 2011 Return-Path: <cjbc@it.uc3m.es> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E0E43A69BF for <netext@core3.amsl.com>; Thu, 31 Mar 2011 09:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFevRMqx9K9l for <netext@core3.amsl.com>; Thu, 31 Mar 2011 09:25:59 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id C92003A6844 for <netext@ietf.org>; Thu, 31 Mar 2011 09:25:58 -0700 (PDT) X-uc3m-safe: yes Received: from [10.115.19.249] (unknown [80.187.150.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id C7321759666; Thu, 31 Mar 2011 18:27:36 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <cjbc@it.uc3m.es> To: Alexandru Petrescu <alexandru.petrescu@gmail.com> In-Reply-To: <4D9492B6.7040805@gmail.com> References: <4D946F7F.1060809@gmail.com> <4D94734A.7090909@catr.cn> <4D9476F1.1090708@gmail.com> <4D948AB9.3000603@catr.cn> <4D9492B6.7040805@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-UsiY8cn6bdgpPAk4vF8v" Organization: Universidad Carlos III de Madrid Date: Thu, 31 Mar 2011 18:29:30 +0200 Message-ID: <1301588970.4305.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-18046.000 Cc: netext@ietf.org Subject: Re: [netext] how to do ptp links on wifi without modifying the MN? 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 31 Mar 2011 16:26:00 -0000 --=-UsiY8cn6bdgpPAk4vF8v Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Alex, Isn't it enough to ensure that the RAs sent by the MAG are just unicast to the MN (at L2 or L3) to "emulate" a ptp link, with regard of 5213 operation? I use this and works perfectly well. Carlos On Thu, 2011-03-31 at 16:41 +0200, Alexandru Petrescu wrote: > Thanks... can I make a ptp link on MN without running pppoeconf on MN? > (e.g. run pppoeconf only on some MAG or some switch, but not on MN) >=20 > I am asking because I believe it is not possible to not use pppoeconf on > MN if one wants ptp links on it. I.e. pppoeconf MAY be the only > solution to make pmipv6 work with wifi MN. >=20 > Do you think different? >=20 > Alex >=20 >=20 > Le 31/03/2011 16:07, Kaibo Zhou a =E9crit : > > I use pppoeconf in Ubuntu, so I guess it should be able to run on > > some kind of MN. > > > > BR/Zhou > > > > On 03/31/2011 08:43 PM, Alexandru Petrescu wrote: > >> thanks... does pppoeconf run on the mn? > >> > >> Alex > >> > >> Le 31/03/2011 14:27, Kaibo Zhou a =E9crit : > >>> I once tried to set up a PPP connection on the WLAN using > >>> pppoeconf, and it works well. > >>> > >>> > >>> On 03/31/2011 08:11 PM, Alexandru Petrescu wrote: > >>>> Hi netext, > >>>> > >>>> How to do ptp links on a wifi access? > >>>> > >>>> I am asking because I think there is no method. Or otherwise > >>>> they require modifs on the MN - right? > >>>> > >>>> > >>>> Alex _______________________________________________ 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 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-UsiY8cn6bdgpPAk4vF8v Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk2Uq+oACgkQNdy6TdFwT2cSIACeJd9ybE9c6uGMA1ExyDyQo9T8 p4oAniTRGyjQ6/2ZOGOiURHwY8+ddKAA =r//K -----END PGP SIGNATURE----- --=-UsiY8cn6bdgpPAk4vF8v-- From alexandru.petrescu@gmail.com Thu Mar 31 12:18:58 2011 Return-Path: <alexandru.petrescu@gmail.com> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69F263A6B91 for <netext@core3.amsl.com>; Thu, 31 Mar 2011 12:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.837 X-Spam-Level: X-Spam-Status: No, score=-3.837 tagged_above=-999 required=5 tests=[AWL=-0.237, 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 CX1QZPe28PPZ for <netext@core3.amsl.com>; Thu, 31 Mar 2011 12:18:57 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 4DA563A6873 for <netext@ietf.org>; Thu, 31 Mar 2011 12:18:57 -0700 (PDT) Received: by bwz13 with SMTP id 13so2185555bwz.31 for <netext@ietf.org>; Thu, 31 Mar 2011 12:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=F3K9T0jsUGkqoiSmjdR4DjHpyOaIHGEh0Q4TKgNQSso=; b=LyQj7W/RFcRy6j6aOo86twGjYVJUuHPDir9ciBdnFIlNjpSxbT7JoWcYKsUIwTVvmL 9Ik0KH83s0G6LJ4VLWDZLUH+DRJqynZz1x9b2PGSvO6SMXvS8HQIkczSGuM3EVQYJWCP P1AotZELqkID/dAFJUHfXL8J8Ilis4aoNOXuc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Tcr5V/x8MqChnPsPuOr1WM6vlrVDKWtCVolCAqU/s6a+GQ2bLZMrX37goMFQSBvG5a 0sgSGbMpf9WhK8Or64bOT5BvNQztEtoNhZNCgi0v2z5BleLhkDEtsRJiWi+KUm+uIfKQ yiQt2dcAkGVml+wR3auRY8233yMj8s7TwGXj8= Received: by 10.204.19.14 with SMTP id y14mr2776657bka.187.1301599236486; Thu, 31 Mar 2011 12:20:36 -0700 (PDT) Received: from [127.0.0.1] (dhcp-150a.meeting.ietf.org [130.129.21.10]) by mx.google.com with ESMTPS id 16sm945634bkm.18.2011.03.31.12.20.34 (version=SSLv3 cipher=OTHER); Thu, 31 Mar 2011 12:20:35 -0700 (PDT) Message-ID: <4D94D3FF.4080300@gmail.com> Date: Thu, 31 Mar 2011 21:20:31 +0200 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <4D946F7F.1060809@gmail.com> <4D94734A.7090909@catr.cn> <4D9476F1.1090708@gmail.com> <4D948AB9.3000603@catr.cn> <4D9492B6.7040805@gmail.com> <1301588970.4305.5.camel@acorde.it.uc3m.es> In-Reply-To: <1301588970.4305.5.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Cc: netext@ietf.org Subject: Re: [netext] how to do ptp links on wifi without modifying the MN? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 31 Mar 2011 19:18:58 -0000 Hi Carlos, In a sense yes. If MAG wants to send a unicast RA to a MN, it must first learn the link-local address of that MN somehow, in order to send that RA to that ll address. Is this what you mean? Alex Le 31/03/2011 18:29, Carlos Jesús Bernardos Cano a écrit : > Hi Alex, > > Isn't it enough to ensure that the RAs sent by the MAG are just unicast > to the MN (at L2 or L3) to "emulate" a ptp link, with regard of 5213 > operation? > > I use this and works perfectly well. > > Carlos > > On Thu, 2011-03-31 at 16:41 +0200, Alexandru Petrescu wrote: >> Thanks... can I make a ptp link on MN without running pppoeconf on MN? >> (e.g. run pppoeconf only on some MAG or some switch, but not on MN) >> >> I am asking because I believe it is not possible to not use pppoeconf on >> MN if one wants ptp links on it. I.e. pppoeconf MAY be the only >> solution to make pmipv6 work with wifi MN. >> >> Do you think different? >> >> Alex >> >> >> Le 31/03/2011 16:07, Kaibo Zhou a écrit : >>> I use pppoeconf in Ubuntu, so I guess it should be able to run on >>> some kind of MN. >>> >>> BR/Zhou >>> >>> On 03/31/2011 08:43 PM, Alexandru Petrescu wrote: >>>> thanks... does pppoeconf run on the mn? >>>> >>>> Alex >>>> >>>> Le 31/03/2011 14:27, Kaibo Zhou a écrit : >>>>> I once tried to set up a PPP connection on the WLAN using >>>>> pppoeconf, and it works well. >>>>> >>>>> >>>>> On 03/31/2011 08:11 PM, Alexandru Petrescu wrote: >>>>>> Hi netext, >>>>>> >>>>>> How to do ptp links on a wifi access? >>>>>> >>>>>> I am asking because I think there is no method. Or otherwise >>>>>> they require modifs on the MN - right? >>>>>> >>>>>> >>>>>> Alex _______________________________________________ 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 zhou.xingyue@zte.com.cn Thu Mar 31 18:17:02 2011 Return-Path: <zhou.xingyue@zte.com.cn> X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92C853A6A2D for <netext@core3.amsl.com>; Thu, 31 Mar 2011 18:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.998 X-Spam-Level: X-Spam-Status: No, score=-92.998 tagged_above=-999 required=5 tests=[AWL=-2.808, BAYES_50=0.001, 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 5BaTg42KxmND for <netext@core3.amsl.com>; Thu, 31 Mar 2011 18:17:01 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 72D6E3A69CB for <netext@ietf.org>; Thu, 31 Mar 2011 18:17:00 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 50831465182496; Fri, 1 Apr 2011 09:17:28 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 98218.2078363663; Fri, 1 Apr 2011 09:07:58 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p311IRTn098146; Fri, 1 Apr 2011 09:18:27 +0800 (GMT-8) (envelope-from zhou.xingyue@zte.com.cn) In-Reply-To: <567666.9185.qm@web111412.mail.gq1.yahoo.com> To: Behcet Sarikaya <sarikaya@ieee.org> MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: <OFF1F3B116.39A70F80-ON48257865.000726F7-48257865.00072E92@zte.com.cn> From: zhou.xingyue@zte.com.cn Date: Fri, 1 Apr 2011 09:18:16 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-04-01 09:18:27, Serialize complete at 2011-04-01 09:18:27 Content-Type: multipart/alternative; boundary="=_alternative 00072E9148257865_=" X-MAIL: mse02.zte.com.cn p311IRTn098146 Cc: netext@ietf.org Subject: [netext] =?gb2312?b?tPC4tDogZHJhZnQtemhvdS1uZXRleHQtcGQtcG1pcC0w?= =?gb2312?b?MC50eHQ=?= X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 01 Apr 2011 01:17:02 -0000 This is a multipart message in MIME format. --=_alternative 00072E9148257865_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgQmVoY2V0LA0KSSBkaWQgbm90IHNlZSB0aGlzIGRyYWZ0LCBzb3JyeS4gDQpKdXN0IGJyb3dz ZSBpdCBhbmQgZmluZCB0aGF0IHlvdXIgZHJhZnQgaXMgZm9jdXMgb24gYWxsb2NhdGlvbiBvZiBI TlAgdmlhIA0KREhDUHY2LVBEIHdoaWxlIG1pbmUgYWltcyB0byBhc3NvY2lhdGUgdGhlIGRlbGVn YXRlZCBwcmVmaXggd2l0aCB0aGUgUE1JUCANCnNlc3Npb24gaW4gTkVNTyBzY2VuYXJpby4gSSB3 aWxsIHVwZGF0ZSB0aGUgZHJhZnQgc29vbi4gQW55IGNvbW1lbnN0IGlzIA0Kd2VsY29tZS4NCg0K UmVnYXJkcywNCkpveQ0KDQoNCg0KQmVoY2V0IFNhcmlrYXlhIDxiZWhjZXRzYXJpa2F5YUB5YWhv by5jb20+IA0KMjAxMS0wMy0zMSDPws7nIDA4OjAwDQrH67TwuLQguPgNCkJlaGNldCBTYXJpa2F5 YSA8c2FyaWtheWFAaWVlZS5vcmc+DQoNCg0KytW8/sjLDQpuZXRleHRAaWV0Zi5vcmcsIHpob3Uu eGluZ3l1ZUB6dGUuY29tLmNuDQqzrcvNDQoNCtb3zOINCmRyYWZ0LXpob3UtbmV0ZXh0LXBkLXBt aXAtMDAudHh0DQoNCg0KDQoNCg0KDQpIaSBKb3ksDQogIEkgc2F3IHRoaXMgZHJhZnQuDQpJIHdh cyB3b25kZXJpbmcgaWYgdGhlIGF1dGhvcnMgaGF2ZSBzZWVuDQoNCmh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXNhcmlrYXlhLW5ldGV4dC1wcmVmaXgtZGVsZWdhdGlvbi0wMA0KDQp0 aGlzIGRyYWZ0IGlzIGN1cnJlbnRseSBleHBpcmVkIGFuZCBkb2VzIG5vdCBhcHBlYXIgb24gdG9v bHMgcGFnZS4NCg0KUmVnYXJkcywNCg0KQmVoY2V0DQoNCg0KDQoNCg== --=_alternative 00072E9148257865_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEJlaGNldCw8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgZGlkIG5vdCBzZWUgdGhpcyBkcmFm dCwgc29ycnkuIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SnVz dCBicm93c2UgaXQgYW5kIGZpbmQgdGhhdCB5b3VyIGRyYWZ0DQppcyBmb2N1cyBvbiBhbGxvY2F0 aW9uIG9mIEhOUCB2aWEgREhDUHY2LVBEIHdoaWxlIG1pbmUgYWltcyB0byBhc3NvY2lhdGUNCnRo ZSBkZWxlZ2F0ZWQgcHJlZml4IHdpdGggdGhlIFBNSVAgc2Vzc2lvbiBpbiBORU1PIHNjZW5hcmlv LiBJIHdpbGwgdXBkYXRlDQp0aGUgZHJhZnQgc29vbi4gQW55IGNvbW1lbnN0IGlzIHdlbGNvbWUu PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5SZWdhcmRz LDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Sm95PC9mb250Pg0K PGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkJlaGNldCBTYXJp a2F5YSAmbHQ7YmVoY2V0c2FyaWtheWFAeWFob28uY29tJmd0OzwvYj4NCjwvZm9udD4NCjxwPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDExLTAzLTMxIM/CzucgMDg6MDA8L2ZvbnQ+ DQo8dGFibGUgYm9yZGVyPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgYmdjb2xvcj13aGl0ZT4NCjxk aXYgYWxpZ249Y2VudGVyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7H67TwuLQguPg8 YnI+DQpCZWhjZXQgU2FyaWtheWEgJmx0O3NhcmlrYXlhQGllZWUub3JnJmd0OzwvZm9udD48L2Rp dj48L3RhYmxlPg0KPGJyPg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPm5ldGV4dEBpZXRmLm9yZywgemhvdS54aW5neXVlQHp0ZS5jb20uY248L2ZvbnQ+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3 zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmRyYWZ0 LXpob3UtbmV0ZXh0LXBkLXBtaXAtMDAudHh0PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+ DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5IaSBKb3ksPGJyPg0KICZuYnNwO0kgc2F3IHRo aXMgZHJhZnQuPGJyPg0KSSB3YXMgd29uZGVyaW5nIGlmIHRoZSBhdXRob3JzIGhhdmUgc2Vlbjxi cj4NCjxicj4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNhcmlrYXlhLW5ldGV4 dC1wcmVmaXgtZGVsZWdhdGlvbi0wMDxicj4NCjxicj4NCnRoaXMgZHJhZnQgaXMgY3VycmVudGx5 IGV4cGlyZWQgYW5kIGRvZXMgbm90IGFwcGVhciBvbiB0b29scyBwYWdlLjxicj4NCjxicj4NClJl Z2FyZHMsPGJyPg0KPGJyPg0KQmVoY2V0PGJyPg0KPGJyPg0KPGJyPg0KPC9mb250PjwvdHQ+DQo8 YnI+DQo= --=_alternative 00072E9148257865_=--