From sarikaya2012@gmail.com Tue Sep 11 11:12:48 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A333B21F84B5 for ; Tue, 11 Sep 2012 11:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LV8gDhRMG+6C for ; Tue, 11 Sep 2012 11:12:48 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2502221F8608 for ; Tue, 11 Sep 2012 11:12:48 -0700 (PDT) Received: by ieak13 with SMTP id k13so1604127iea.31 for ; Tue, 11 Sep 2012 11:12:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=hhzj6LMDvNk+Y4cuusPQgbLxGwJF1TFrgMiDitgRvgo=; b=im4wSrb17rU5hNYxMRUTKooQ9MtUIpAkoDI2BXQ1wHe/QX+rI+G8fwk9jkR+bNG5Ek G/eb/r4QTKe/URD7H3pTVU4KqeHQJzyXL4MmPnY8b+nrT18H0t+n2h7ivexk6rj7ImlS LOgNdLHqUShyfmCz88aslstcLZIcXIsZhViyy4ssJwjbFcglU3n1mVUDHkgz7t7bpL2u GQQap7LiZp7lBArkhYTD84eDQwWsmCBvjBo6yGGnjcnOdbpZT0mm7b5PyXcfE0ei0/zV kSjLv8cQ+xfyGN8tjnNPTE2i7Xg8AXvmQPHWNJZwZNF8n0EdY7zDL2jIAJGvFcHvNy+a L7Jw== MIME-Version: 1.0 Received: by 10.50.57.202 with SMTP id k10mr18183250igq.45.1347387167604; Tue, 11 Sep 2012 11:12:47 -0700 (PDT) Received: by 10.231.55.70 with HTTP; Tue, 11 Sep 2012 11:12:47 -0700 (PDT) Date: Tue, 11 Sep 2012 13:12:47 -0500 Message-ID: From: Behcet Sarikaya To: netext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [netext] COMMENTS ON draft-ietf-netext-pmipv6-flowmob-04 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 18:12:48 -0000 I had posted this mail almost a month ago and have not seen any reply yet? On Fri, Aug 24, 2012 at 4:13 PM, Behcet Sarikaya wrote: > Hi Carlos, > > I have questions on Section 3.2.1. on MN sharing a common set of > prefixes on all MAGs. > > I don't understand why this is related to flow mobility but not prefix > allocation policy. > In Fig. 2, you consider flow Y to pref1::mn1 on if2 > > and then you move flow Y to if1. I am confused about the figure. How > come pref1::mn1 and pref1::mn1 stays the same? What is mn1? Is it the > iid? > Do you assume that both if1 and if2 have the same iid? How could this > be possible? Secondly you did not mention this assumption. > > I think that if2 should be referred to as mn2 then the situation will > be clear, i.e. moving flows between two different interfaces with > different addresses, so this case is not any different than the cases > you have in Sections 3.2.2 and 3.2.3. > > You explain in this section that some flow mobility update action (?) > happens in both LMA and MN and the flow is magically moved. Even if we > assume what you have is correct this case does not deserve any mention > in the draft, i.e. there is no observable action to specify. > > I have more coming up later. > > Regards, > > Behcet From cjbc@it.uc3m.es Tue Sep 11 13:58:11 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2A521F8669 for ; Tue, 11 Sep 2012 13:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNEx1wRYtquU for ; Tue, 11 Sep 2012 13:58:10 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 27B2921F865E for ; Tue, 11 Sep 2012 13:58:09 -0700 (PDT) X-uc3m-safe: yes Received: from [10.64.28.194] (93-158-5-42.subs.ibrowse.com [93.158.5.42]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id 2A4EC86C2AB; Tue, 11 Sep 2012 22:58:06 +0200 (CEST) Message-ID: <1347397084.17961.31.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: sarikaya@ieee.org Date: Tue, 11 Sep 2012 22:58:04 +0200 In-Reply-To: References: Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-pHbejJQzfMHk4l+7kjUg" X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-19178.001 X-TM-AS-Result: No--14.814-7.0-31-1 X-imss-scan-details: No--14.814-7.0-31-1 Cc: netext@ietf.org Subject: Re: [netext] COMMENTS ON draft-ietf-netext-pmipv6-flowmob-04 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 20:58:11 -0000 --=-pHbejJQzfMHk4l+7kjUg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Behcet, I just came back from holidays. I'm catching up with e-mails and I'll go back to you early next week. Thanks for the understanding. Carlos On Tue, 2012-09-11 at 13:12 -0500, Behcet Sarikaya wrote: > I had posted this mail almost a month ago and have not seen any reply yet= ? >=20 > On Fri, Aug 24, 2012 at 4:13 PM, Behcet Sarikaya = wrote: > > Hi Carlos, > > > > I have questions on Section 3.2.1. on MN sharing a common set of > > prefixes on all MAGs. > > > > I don't understand why this is related to flow mobility but not prefix > > allocation policy. > > In Fig. 2, you consider flow Y to pref1::mn1 on if2 > > > > and then you move flow Y to if1. I am confused about the figure. How > > come pref1::mn1 and pref1::mn1 stays the same? What is mn1? Is it the > > iid? > > Do you assume that both if1 and if2 have the same iid? How could this > > be possible? Secondly you did not mention this assumption. > > > > I think that if2 should be referred to as mn2 then the situation will > > be clear, i.e. moving flows between two different interfaces with > > different addresses, so this case is not any different than the cases > > you have in Sections 3.2.2 and 3.2.3. > > > > You explain in this section that some flow mobility update action (?) > > happens in both LMA and MN and the flow is magically moved. Even if we > > assume what you have is correct this case does not deserve any mention > > in the draft, i.e. there is no observable action to specify. > > > > I have more coming up later. > > > > Regards, > > > > Behcet > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --=20 Carlos Jes=C3=BAs Bernardos Cano http://www.netcom.it.uc3m.es/ GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-pHbejJQzfMHk4l+7kjUg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAlBPpdwACgkQNdy6TdFwT2fHkQCdHayNMe+eSk8xCeoOIuTUqPc+ gWYAoKelsDQo8TWe0TaYjAOFUXLz2Hur =ToVP -----END PGP SIGNATURE----- --=-pHbejJQzfMHk4l+7kjUg-- From internet-drafts@ietf.org Wed Sep 12 18:24:38 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5AB121F854A; Wed, 12 Sep 2012 18:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZ7Yw3zfyum3; Wed, 12 Sep 2012 18:24:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE0E21F84F5; Wed, 12 Sep 2012 18:24:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120913012438.30138.2180.idtracker@ietfa.amsl.com> Date: Wed, 12 Sep 2012 18:24:38 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmipv6-sipto-option-06.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 01:24:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Working= Group of the IETF. Title : IPv4 Traffic Offload Selector Option for Proxy Mobile IP= v6 Author(s) : Sri Gundavelli Xingyue Zhou Jouni Korhonen Rajeev Koodli Filename : draft-ietf-netext-pmipv6-sipto-option-06.txt Pages : 13 Date : 2012-09-12 Abstract: This specification defines a mechanism and a related mobility option for carrying IPv4 Offload traffic selectors between a mobile access gateway and a local mobility anchor in a Proxy Mobile IPv6 domain. Based on the received offload flow selectors from the local mobility anchor, a mobile access gateway can enable offload traffic rule on the selected IPv4 flows. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmipv6-sipto-option There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pmipv6-sipto-option-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-pmipv6-sipto-option-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From cjbc@it.uc3m.es Tue Sep 18 10:45:58 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F324B21E8043 for ; Tue, 18 Sep 2012 10:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UA5TmX7L8KZ for ; Tue, 18 Sep 2012 10:45:57 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id EF53221F851C for ; Tue, 18 Sep 2012 10:45:56 -0700 (PDT) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 732A7CAE9A2; Tue, 18 Sep 2012 19:45:52 +0200 (CEST) Message-ID: <1347990352.18353.115.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: sarikaya@ieee.org Date: Tue, 18 Sep 2012 19:45:52 +0200 In-Reply-To: References: Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-n11MisSI5k/vJAHNqw0v" X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-19192.000 X-TM-AS-Result: No--9.403-7.0-31-1 X-imss-scan-details: No--9.403-7.0-31-1 Cc: netext@ietf.org Subject: Re: [netext] draft-ietf-netext-pmipv6-flowmob-04 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 17:45:58 -0000 --=-n11MisSI5k/vJAHNqw0v Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ni Behcet, all, Again, apologies for the late reply. Thanks for your comments and questions. Please find some comments inline below. On Fri, 2012-08-24 at 16:13 -0500, Behcet Sarikaya wrote: > Hi Carlos, >=20 > I have questions on Section 3.2.1. on MN sharing a common set of > prefixes on all MAGs. >=20 > I don't understand why this is related to flow mobility but not prefix > allocation policy. > In Fig. 2, you consider flow Y to pref1::mn1 on if2 >=20 > and then you move flow Y to if1. I am confused about the figure. How > come pref1::mn1 and pref1::mn1 stays the same? What is mn1? Is it the > iid? mn1 are the 128-N rightmost bits of the MN1 address, where N is the prefix length. Typically mn1 would correspond to the iid. > Do you assume that both if1 and if2 have the same iid? How could this > be possible? Secondly you did not mention this assumption. The document does not go into the details of whether if1 and if2 have the same iid or not. The assumptions on the MN side are the following: "It is assumed that the mobile node IP layer interface can simultaneously and/or sequentially attach to multiple MAGs, possibly over multiple media. One form to achieve this multiple attachment is described in [I-D.ietf-netext-logical-interface-support], which allows the mobile node supporting traffic flows on different physical interfaces regardless of the assigned prefixes on those physical interfaces." You can also check Section 6 on MN considerations. >=20 > I think that if2 should be referred to as mn2 then the situation will > be clear, i.e. moving flows between two different interfaces with > different addresses, so this case is not any different than the cases > you have in Sections 3.2.2 and 3.2.3. The point is to address (in Section 3.2.1) a different scenario in which the same prefix (or set of prefixes) is assigned to different physical interfaces. This is possible, so it should be considered. >=20 > You explain in this section that some flow mobility update action (?) > happens in both LMA and MN and the flow is magically moved. Even if we > assume what you have is correct this case does not deserve any mention > in the draft, i.e. there is no observable action to specify. It is needed to specify how to ensure that different physical interfaces of the same MN get assigned the same prefix (or set of prefixes). Thanks again for your comments, Carlos >=20 > I have more coming up later. >=20 > Regards, >=20 > Behcet > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --=20 Carlos Jes=C3=BAs Bernardos Cano http://www.netcom.it.uc3m.es/ GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-n11MisSI5k/vJAHNqw0v Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAlBYs1AACgkQNdy6TdFwT2fQUQCg5CDwcUc/KeMhVUQ2w3zezwEX qZcAnArhaI3E0rWXUlEsBhZOEWlNWyvC =4pbd -----END PGP SIGNATURE----- --=-n11MisSI5k/vJAHNqw0v-- From sarikaya2012@gmail.com Wed Sep 19 13:07:20 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDA421E80A7 for ; Wed, 19 Sep 2012 13:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.333 X-Spam-Level: X-Spam-Status: No, score=-3.333 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5YVM7Lr8mH3 for ; Wed, 19 Sep 2012 13:07:19 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6E58921E8034 for ; Wed, 19 Sep 2012 13:07:19 -0700 (PDT) Received: by oagn5 with SMTP id n5so978265oag.31 for ; Wed, 19 Sep 2012 13:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=iW7jNgFl1tZl8/qeKtXR4m9q7fx5O/GEv/1QqKh4sNw=; b=womHMEwlOefZnbLMZUU4+1C6RyM4Rqd9JsJcVIrJCVYz+twf0sziZ7xPINyd6OptqN N3SE1KaN+Plp59jRz5cCbf+iQTCIWs6zU2hsQFL2oGHaK2Ve3O2lGM3HHqFlYd8ZWBYB Q1qewE7uKoYs/h1oRDwRd42BYlaFUkEwoLWsqYZJkolAdpM5xd3gyA40bEUaCeqLL3sO fmoWRQ1NxiiTG1KG/iXyUUhSBru3FFaODPvt46YIkMxq5rVF06WVXl6eYFO5GxW5ykm3 fhgsOetirXjpvKd1x6i/JaG+LaosDkidZE5sQbRloo2XB0vqKGurcSMqnQPL6K552/gi e6Bg== MIME-Version: 1.0 Received: by 10.182.52.3 with SMTP id p3mr2446126obo.56.1348085229597; Wed, 19 Sep 2012 13:07:09 -0700 (PDT) Received: by 10.60.17.37 with HTTP; Wed, 19 Sep 2012 13:07:09 -0700 (PDT) In-Reply-To: <1347990352.18353.115.camel@acorde.it.uc3m.es> References: <1347990352.18353.115.camel@acorde.it.uc3m.es> Date: Wed, 19 Sep 2012 15:07:09 -0500 Message-ID: From: Behcet Sarikaya To: cjbc@it.uc3m.es Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] draft-ietf-netext-pmipv6-flowmob-04 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 20:07:20 -0000 Hi Carlos, Please see inline. On Tue, Sep 18, 2012 at 12:45 PM, Carlos Jes=FAs Bernardos Cano wrote: > Ni Behcet, all, > > Again, apologies for the late reply. > > Thanks for your comments and questions. Please find some comments inline > below. > > On Fri, 2012-08-24 at 16:13 -0500, Behcet Sarikaya wrote: >> Hi Carlos, >> >> I have questions on Section 3.2.1. on MN sharing a common set of >> prefixes on all MAGs. >> >> I don't understand why this is related to flow mobility but not prefix >> allocation policy. You did not answer this one. >> In Fig. 2, you consider flow Y to pref1::mn1 on if2 >> >> and then you move flow Y to if1. I am confused about the figure. How >> come pref1::mn1 and pref1::mn1 stays the same? What is mn1? Is it the >> iid? > > mn1 are the 128-N rightmost bits of the MN1 address, where N is the > prefix length. Typically mn1 would correspond to the iid. > >> Do you assume that both if1 and if2 have the same iid? How could this >> be possible? Secondly you did not mention this assumption. > > The document does not go into the details of whether if1 and if2 have > the same iid or not. The assumptions on the MN side are the following: > > "It is > assumed that the mobile node IP layer interface can simultaneously > and/or sequentially attach to multiple MAGs, possibly over multiple > media. One form to achieve this multiple attachment is described in > [I-D.ietf-netext-logical-interface-support], which allows the mobile > node supporting traffic flows on different physical interfaces > regardless of the assigned prefixes on those physical interfaces." > > You can also check Section 6 on MN considerations. > Can I say that pref1::mn1 can not be the same? This is based on your reply and the fact that you did not make any assumption/requirement on this, so you need to modify the figure accordingly. >> >> I think that if2 should be referred to as mn2 then the situation will >> be clear, i.e. moving flows between two different interfaces with >> different addresses, so this case is not any different than the cases >> you have in Sections 3.2.2 and 3.2.3. > > The point is to address (in Section 3.2.1) a different scenario in which > the same prefix (or set of prefixes) is assigned to different physical > interfaces. This is possible, so it should be considered. > Yes but the problem is not any different than when different prefixes are assigned, so what is the big deal that requires a different section which happens to be the first section (3.2.1)? >> >> You explain in this section that some flow mobility update action (?) >> happens in both LMA and MN and the flow is magically moved. Even if we >> assume what you have is correct this case does not deserve any mention >> in the draft, i.e. there is no observable action to specify. > > It is needed to specify how to ensure that different physical interfaces > of the same MN get assigned the same prefix (or set of prefixes). Please see above. If this case is no different than the cases in 3.2.2 and 3.2.3 then why? Regards, Behcet From wwwrun@rfc-editor.org Wed Sep 19 17:35:46 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5EDA21E8041; Wed, 19 Sep 2012 17:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.01 X-Spam-Level: X-Spam-Status: No, score=-102.01 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70Ft13KTcU2l; Wed, 19 Sep 2012 17:35:46 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 1461021E8048; Wed, 19 Sep 2012 17:35:39 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3CA4EB1E003; Wed, 19 Sep 2012 17:32:02 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120920003202.3CA4EB1E003@rfc-editor.org> Date: Wed, 19 Sep 2012 17:32:02 -0700 (PDT) Cc: netext@ietf.org, rfc-editor@rfc-editor.org Subject: [netext] RFC 6705 on Localized Routing for Proxy Mobile IPv6 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 00:35:46 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6705 Title: Localized Routing for Proxy Mobile IPv6 Author: S. Krishnan, R. Koodli, P. Loureiro, Q. Wu, A. Dutta Status: Standards Track Stream: IETF Date: September 2012 Mailbox: suresh.krishnan@ericsson.com, rkoodli@cisco.com, loureiro@neclab.eu, Sunseawq@huawei.com, adutta@niksun.com Pages: 20 Characters: 43309 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netext-pmip-lr-10.txt URL: http://www.rfc-editor.org/rfc/rfc6705.txt Proxy Mobile IPv6 (PMIPv6) is a network based mobility management protocol that enables IP mobility for a host without requiring its participation in any mobility-related signaling. PMIPv6 requires all communications to go through the local mobility anchor. As this can be suboptimal, Localized Routing (LR) allows Mobile Nodes (MNs) attached to the same or different Mobile Access Gateways (MAGs) to route traffic by using localized forwarding or a direct tunnel between the gateways. This document proposes initiation, utilization, and termination mechanisms for localized routing between mobile access gateways within a proxy mobile IPv6 domain. It defines two new signaling messages, Localized Routing Initiation (LRI) and Local Routing Acknowledgment (LRA), that are used to realize this mechanism. [STANDARDS-TRACK] This document is a product of the Network-Based Mobility Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From cjbc@it.uc3m.es Thu Sep 20 01:32:44 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C61E821F8624 for ; Thu, 20 Sep 2012 01:32:44 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLiRRkV8-Yyr for ; Thu, 20 Sep 2012 01:32:43 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 946B821F8449 for ; Thu, 20 Sep 2012 01:32:43 -0700 (PDT) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id AF11DCAE92F; Thu, 20 Sep 2012 10:32:37 +0200 (CEST) Message-ID: <1348129957.18353.179.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: sarikaya@ieee.org Date: Thu, 20 Sep 2012 10:32:37 +0200 In-Reply-To: References: <1347990352.18353.115.camel@acorde.it.uc3m.es> Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-VxQ3SArs5BPUYB0xhEIm" X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-19196.000 X-TM-AS-Result: No--22.526-7.0-31-1 X-imss-scan-details: No--22.526-7.0-31-1 Cc: netext@ietf.org Subject: Re: [netext] draft-ietf-netext-pmipv6-flowmob-04 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 08:32:45 -0000 --=-VxQ3SArs5BPUYB0xhEIm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Behcet, On Wed, 2012-09-19 at 15:07 -0500, Behcet Sarikaya wrote: > Hi Carlos, >=20 > Please see inline. >=20 > On Tue, Sep 18, 2012 at 12:45 PM, Carlos Jes=C3=BAs Bernardos Cano > wrote: > > Ni Behcet, all, > > > > Again, apologies for the late reply. > > > > Thanks for your comments and questions. Please find some comments inlin= e > > below. > > > > On Fri, 2012-08-24 at 16:13 -0500, Behcet Sarikaya wrote: > >> Hi Carlos, > >> > >> I have questions on Section 3.2.1. on MN sharing a common set of > >> prefixes on all MAGs. > >> > >> I don't understand why this is related to flow mobility but not prefix > >> allocation policy. >=20 > You did not answer this one. Sorry, I didn't see any question there. If you want me to comment on this, assigning a common set of prefixes is one of the possible ways of enabling flow mobility -- as documented in the draft -- and therefore I see it as related to flow mobility. >=20 > >> In Fig. 2, you consider flow Y to pref1::mn1 on if2 > >> > >> and then you move flow Y to if1. I am confused about the figure. How > >> come pref1::mn1 and pref1::mn1 stays the same? What is mn1? Is it the > >> iid? > > > > mn1 are the 128-N rightmost bits of the MN1 address, where N is the > > prefix length. Typically mn1 would correspond to the iid. > > > >> Do you assume that both if1 and if2 have the same iid? How could this > >> be possible? Secondly you did not mention this assumption. > > > > The document does not go into the details of whether if1 and if2 have > > the same iid or not. The assumptions on the MN side are the following: > > > > "It is > > assumed that the mobile node IP layer interface can simultaneously > > and/or sequentially attach to multiple MAGs, possibly over multiple > > media. One form to achieve this multiple attachment is described in > > [I-D.ietf-netext-logical-interface-support], which allows the mobile > > node supporting traffic flows on different physical interfaces > > regardless of the assigned prefixes on those physical interfaces." > > > > You can also check Section 6 on MN considerations. > > >=20 >=20 > Can I say that pref1::mn1 can not be the same? > This is based on your reply and the fact that you did not make any > assumption/requirement on this, so you need to modify the figure > accordingly. You mean the iid part of the address not being the same, while the prefixes are? I don't see what would be the value of doing so. If the addresses assigned by distinct MAGs are different, then the other mechanisms described in the draft could be used, but using different prefixes is cleaner, simpler and avoids potential ND-related problems. >=20 > >> > >> I think that if2 should be referred to as mn2 then the situation will > >> be clear, i.e. moving flows between two different interfaces with > >> different addresses, so this case is not any different than the cases > >> you have in Sections 3.2.2 and 3.2.3. > > > > The point is to address (in Section 3.2.1) a different scenario in whic= h > > the same prefix (or set of prefixes) is assigned to different physical > > interfaces. This is possible, so it should be considered. > > >=20 > Yes but the problem is not any different than when different prefixes > are assigned, so what is the big deal that requires a different > section which happens to be the first section (3.2.1)? I disagree here. The problem is different, as in one case there is no additional changes required in the MAG routing to be able to forward packets, while in the other there is. The order of the section is not meaningful, there is no special reason for having it first, just that we felt it was easier to describe the solutions in that way. >=20 > >> > >> You explain in this section that some flow mobility update action (?) > >> happens in both LMA and MN and the flow is magically moved. Even if we > >> assume what you have is correct this case does not deserve any mention > >> in the draft, i.e. there is no observable action to specify. > > > > It is needed to specify how to ensure that different physical interface= s > > of the same MN get assigned the same prefix (or set of prefixes). >=20 > Please see above. If this case is no different than the cases in 3.2.2 > and 3.2.3 then why? But the case is different. Thanks, Carlos >=20 > Regards, >=20 > Behcet --=20 Carlos Jes=C3=BAs Bernardos Cano http://www.netcom.it.uc3m.es/ GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-VxQ3SArs5BPUYB0xhEIm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAlBa1KUACgkQNdy6TdFwT2dFdQCbB6ZWCTaUdBGkkG8w0pVqrn3j TZ0AniRXRNXvT9YBXWwrYYNXVzwp4lsQ =V9Xz -----END PGP SIGNATURE----- --=-VxQ3SArs5BPUYB0xhEIm-- From sarikaya2012@gmail.com Mon Sep 24 15:29:12 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E8921F887E for ; Mon, 24 Sep 2012 15:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.338 X-Spam-Level: X-Spam-Status: No, score=-3.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LixNnh07CcqD for ; Mon, 24 Sep 2012 15:29:11 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id CCB8D21F8868 for ; Mon, 24 Sep 2012 15:29:11 -0700 (PDT) Received: by iec9 with SMTP id 9so13579597iec.31 for ; Mon, 24 Sep 2012 15:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=2CJGPJJhi9/zSAGkT+BTngyV+z86vLqYm3upzCkhRb4=; b=0QCO7Hmuv7BksmOqWm0KErYid87VPRquK4/rxb0SZr2zTjXV9zr2oe2JXkGKleXT0u MyyTnWrS6vkffoobucXzY/rcYFMnOhHebZp+5Ysnszl/zgtRb1NPY4PPttEg9oB9Kjsu eNntmiZBVjqDo6Yh+s8z6oZth7tLkkJv3MG+8TGSWNEqhHntpGv1fdySovIA+ZoSZoug PGKISMHn3A98XHVFVaT6dYqBVPN3Jnm1JMRlrnLoTmL+ueLesJwm5zfGO+zoSY/e41/O wu9jDmdvdZ3cDY+i5BN80OLiWMklYk37o1e9E9ploUaIg9FU5WBK1/1lxmlXB1Kccvs7 0Cdw== MIME-Version: 1.0 Received: by 10.50.16.172 with SMTP id h12mr6610777igd.41.1348525751309; Mon, 24 Sep 2012 15:29:11 -0700 (PDT) Received: by 10.231.55.70 with HTTP; Mon, 24 Sep 2012 15:29:11 -0700 (PDT) In-Reply-To: <20120924222725.25801.48712.idtracker@ietfa.amsl.com> References: <20120924222725.25801.48712.idtracker@ietfa.amsl.com> Date: Mon, 24 Sep 2012 17:29:11 -0500 Message-ID: From: Behcet Sarikaya To: netext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [netext] New Version Notification for draft-sarikaya-netext-flowmob-ext-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 22:29:12 -0000 A new version of I-D, draft-sarikaya-netext-flowmob-ext-00.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Filename: draft-sarikaya-netext-flowmob-ext Revision: 00 Title: PMIPv6 Multihoming Support Extensions for Flow Mobility Creation date: 2012-09-24 WG ID: Individual Submission Number of pages: 11 URL: http://www.ietf.org/internet-drafts/draft-sarikaya-netext-flowmob-ext-00.txt Status: http://datatracker.ietf.org/doc/draft-sarikaya-netext-flowmob-ext Htmlized: http://tools.ietf.org/html/draft-sarikaya-netext-flowmob-ext-00 Abstract: Base Proxy Mobile IPv6 multihoming support treats each active interface of the Mobile Node separately and creates a different binding cache entry for each interface. This is similar to Mobile IPv6 restricting only one care-of address to be registered with the home agent and this restriction which did not allow flow mobility between interfaces has been removed by allowing multiple care-of address registration. In this document we specify a similar solution for Proxy Mobile IPv6 (PMIPv6) to support flow mobility among simultaneously connected interfaces. Binding cache, binding update list and home network prefix option are slighlty extended to allow indicating the home interface and other interfaces. The IETF Secretariat