From sarikaya2012@gmail.com Mon Oct 1 13:51: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 5855D1F0D36 for ; Mon, 1 Oct 2012 13:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.463 X-Spam-Level: X-Spam-Status: No, score=-3.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 8Og0CyAo4BTc for ; Mon, 1 Oct 2012 13:51:19 -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 A141D1F040A for ; Mon, 1 Oct 2012 13:51:19 -0700 (PDT) Received: by iec9 with SMTP id 9so15235251iec.31 for ; Mon, 01 Oct 2012 13:51:19 -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; bh=FOzWJspcP3kZ35t75uEhveLLI9tvBnwYmdX/fr55PJI=; b=rlPJEmoTyNpFSSoZRWFMZaGrDmX7Qx5bv4iIKl3kOyvfZkvuXt+WUXJJC22Q1rCMzX crhtX45yxWwwLiIq67t99sLoNp2jr4QWCx/xGGT2JhBPIJ+cXZk5b/RTEXdFagWuk5jg HeqwdaTKph+Ppl813/Rt7OaoOyMlZdnvHkxy+TRZkCqLRUOF0MV8nYBS/ZDvSQZ7Pb8n UOac+++G0ORAAGy15TcM2GA4XWhhIMmpBagvRXpKGwJZv0P8CkqD87PlsXdw4W3fIztS 52iCzGjTUyotK2UxVr0lqJOvtk3H866YGY7/9zLEfYKzrFeLwOeGzz5+xS2LAk0UtXs8 8zHA== MIME-Version: 1.0 Received: by 10.50.208.101 with SMTP id md5mr112148igc.37.1349124679183; Mon, 01 Oct 2012 13:51:19 -0700 (PDT) Received: by 10.231.55.70 with HTTP; Mon, 1 Oct 2012 13:51:19 -0700 (PDT) In-Reply-To: <1348129957.18353.179.camel@acorde.it.uc3m.es> References: <1347990352.18353.115.camel@acorde.it.uc3m.es> <1348129957.18353.179.camel@acorde.it.uc3m.es> Date: Mon, 1 Oct 2012 15:51:19 -0500 Message-ID: From: Behcet Sarikaya To: cjbc@it.uc3m.es Content-Type: text/plain; charset=ISO-8859-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: 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, 01 Oct 2012 20:51:20 -0000 Hi Carlos, Sorry for my late reply. We need to continue this conversation. >> >> 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. > > 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. > Sorry, MAGs do not assign addresses, MAGs advertise HNPs and MN makes an address like you call pref1::mn1. So MN receives pref1 on if1 it makes pref1::mn1 and MN receives pref1 on if2, it does not make pref1::mn1 because mn1 is the hardware address (or iid) on if1 and on if2, the hardware address (or iid) is different, you need to show it as pref1::mn1', maybe, with mn1 not = mn1'. You have this type of misleading terminology in more than one figure (Figs 4,5 &6) and that is what I am asking you to correct. I hope it is clear now? >> >> >> >> >> 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)? > > 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. Why? I guess you mean LMA routing. LMA has to send the two flows to two different addresses anyway, right? So what is different in Section 3.2.1? I have comments on other section, I am going to create different threads for each. Regards, Behcet From sarikaya2012@gmail.com Mon Oct 1 14:21:27 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A751F0D3F for ; Mon, 1 Oct 2012 14:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.319 X-Spam-Level: X-Spam-Status: No, score=-3.319 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 PgavMQ2dSWoQ for ; Mon, 1 Oct 2012 14:21:27 -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 F162E1F040A for ; Mon, 1 Oct 2012 14:21:26 -0700 (PDT) Received: by iec9 with SMTP id 9so15304341iec.31 for ; Mon, 01 Oct 2012 14:21:26 -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=a5dXAArw6HR1suaw/KPQd8pKKeVtrA6EqTSXDl9A/JA=; b=rDvuCVItmbm2dOu2yU4iKEn0fbv3tuVCwFKdQKhlBKcMlwD7K1G3rBSwvpXjAHg6B0 ZdlVCAxN3/yJI5ApPhYIV3hkV6w3qgRyuf9EODqEet7oCp9A/I9msKpNA5lFSqOZnNbC 2/JUYHPRwcbCQPCXT6Q+2rpCR6OJAVEica04OXeRYQZaEoetoRJQBrX4ZOSYZAywDqNB NK9YZZr+jpBMsdy4uFHMnAQIWPcFQremFSIIq73xVHpQFWiPLiKXuTnWKLD9x60Ted+0 jzCEEuSaHcjNjMpR/vlPgMGSOq8UuPlknfNP+ZfpA8gD8YuTnyK7NRKl5+WXzKODe1Oa 9Peg== MIME-Version: 1.0 Received: by 10.50.194.163 with SMTP id hx3mr7066475igc.37.1349126486650; Mon, 01 Oct 2012 14:21:26 -0700 (PDT) Received: by 10.231.55.70 with HTTP; Mon, 1 Oct 2012 14:21:26 -0700 (PDT) Date: Mon, 1 Oct 2012 16:21:26 -0500 Message-ID: From: Behcet Sarikaya To: netext@ietf.org, =?ISO-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= Content-Type: text/plain; charset=ISO-8859-1 Subject: [netext] draft-ietf-netext-pmipv6-flowmob-04 Section 3.2.2 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, 01 Oct 2012 21:21:27 -0000 Hi Carlos, I am unabe to understand this sentence at the beginning of Sec. 3.2.2 (as we discussed in the previous thread): A different flow mobility scenario happens when the local mobility anchor assigns different sets of prefixes to physical interfaces of the same mobile node. Again, this statement: Since the local mobility anchor cannot send a PBA message which has not been triggered in response to a received PBU message, new signaling messages are defined to cover this case. Why not structure it in two sections: LMA Initiated Flow Mobility where you need to define new signaling and MAG Initiated Flow Mobility where existing PBU/PBA exchange can be used? For LMA Initiated case, why do you think Flow Identification Mobility option initiated by MN would be sufficient? Shouldn't LMA be able to do more things? More actions? Below on Page 13, you have: The MAG MAY also include the Flow Identification Mobility option in the PBU message that it sends to the LMA. This serves as a request from MAG to LMA to consider the flow policy rules specified in the option. This is basically defining MAG Initiated flow mobility. How would a MAG know that MN has multiple interfaces? Only LMA can inform MAG about this, please see draft-sarikaya-netext-flowmob-ext-00 that I posted last week. My overall comment is that in Section 3 there is too much emphasis on the prefix assignment and not enough emphasis on the real protocol issues. I am not convinced that playing with the way PMIPv6 assigns HNPs is the solution to flow mobility. Regards, Behcet From sarikaya2012@gmail.com Mon Oct 1 14:31:57 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57241F0D64 for ; Mon, 1 Oct 2012 14:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.318 X-Spam-Level: X-Spam-Status: No, score=-3.318 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 Irk85Z4tpglj for ; Mon, 1 Oct 2012 14:31:57 -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 3FF741F040A for ; Mon, 1 Oct 2012 14:31:57 -0700 (PDT) Received: by iec9 with SMTP id 9so15327538iec.31 for ; Mon, 01 Oct 2012 14:31:54 -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=iDTfIwTlB3dc+kvU7gPJxA2anGAtXOVDop5MrHndCfQ=; b=HhM/oSwO762UQRQndrYmQqz89EYUqzhejvBVaHhU/7alNlOSeGpD3VKP2sdg8nOPnX /8gMpmKArpkTTDzO4pbfJC0phSIV1UYBaGhJiOiyYQLXHTrGAo1AIgdmS9PrbSoDX/5l g70bZUhJxUe7S3zxCcWFfFdfkejaLVVh15uQvz9yDKUSFWYUe7Wy5NKFfLPcs9eEAJL1 KsBVcaOk327GmkI6mBtB9BASaYTiDoT+ctXYS/ioJWZTrQI9KrkCOYVUaIpV1mLDE+Ll CVZLJSntfWgTilXUgOJ5Hses7KPTwhDds+1SngyqEItMayDL2RYzqtVuz9y37bVzh7J0 qiJw== MIME-Version: 1.0 Received: by 10.50.5.239 with SMTP id v15mr7094264igv.41.1349127113987; Mon, 01 Oct 2012 14:31:53 -0700 (PDT) Received: by 10.231.55.70 with HTTP; Mon, 1 Oct 2012 14:31:53 -0700 (PDT) Date: Mon, 1 Oct 2012 16:31:53 -0500 Message-ID: From: Behcet Sarikaya To: netext@ietf.org, =?ISO-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= Content-Type: text/plain; charset=ISO-8859-1 Subject: [netext] draft-ietf-netext-pmipv6-flowmob-04 Section 5.1 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, 01 Oct 2012 21:31:57 -0000 Hi Carlos, Section 5.1 is entitled Multiple Care-of Address Registration. In PMIPv6 there is no care-address so there can not be care-of address registration, right? In Figure 7, you have BID. This is adopted from RFC 5648. Can we really adopt BID in PMIPv6? Please refer to Section 3 in draft-sarikaya-netext-flowmob-ext-00, unfortunately BID loses its meaning in PMIPv6. It seems to me that this section needs to be completely rewritten. Regards, Behcet From cjbc@it.uc3m.es Mon Oct 8 00:28:57 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF98F21F857E for ; Mon, 8 Oct 2012 00:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.77 X-Spam-Level: X-Spam-Status: No, score=-4.77 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, 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 MVL+ZkXJdvZH for ; Mon, 8 Oct 2012 00:28:56 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id C15A121F8754 for ; Mon, 8 Oct 2012 00:28:55 -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@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id CE0B776B64D; Mon, 8 Oct 2012 09:28:52 +0200 (CEST) Message-ID: <1349681332.4721.26.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: sarikaya@ieee.org Date: Mon, 08 Oct 2012 09:28:52 +0200 In-Reply-To: References: <1347990352.18353.115.camel@acorde.it.uc3m.es> <1348129957.18353.179.camel@acorde.it.uc3m.es> Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-9Y58p5rmKWzRmvnHxgCs" 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-19252.005 X-TM-AS-Result: No--32.373-7.0-31-1 X-imss-scan-details: No--32.373-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: Mon, 08 Oct 2012 07:28:57 -0000 --=-9Y58p5rmKWzRmvnHxgCs Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Behcet, Please, see inline. On Mon, 2012-10-01 at 15:51 -0500, Behcet Sarikaya wrote: > Hi Carlos, >=20 > Sorry for my late reply. We need to continue this conversation. > >> >> 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. Ho= w > >> >> come pref1::mn1 and pref1::mn1 stays the same? What is mn1? Is it t= he > >> >> 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 th= is > >> >> be possible? Secondly you did not mention this assumption. > >> > > >> > The document does not go into the details of whether if1 and if2 hav= e > >> > the same iid or not. The assumptions on the MN side are the followin= g: > >> > > >> > "It is > >> > assumed that the mobile node IP layer interface can simultaneousl= y > >> > and/or sequentially attach to multiple MAGs, possibly over multip= le > >> > media. One form to achieve this multiple attachment is described= in > >> > [I-D.ietf-netext-logical-interface-support], which allows the mob= ile > >> > 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. > > > > 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 > Sorry, MAGs do not assign addresses, MAGs advertise HNPs and MN makes > an address like you call pref1::mn1. Well, I did mean "assigned at distinct MAGs", but anyway, MAGs can assign addresses (section 6.9.1.1 of RFC5213: "If the mobile access gateway learns the mobile node's home network prefix(es) either from its policy store or from other means, the mobile access gateway MAY choose to request the local mobility anchor to allocate the specific prefix(es) by including a Home Network Prefix option for each of those requested prefixes."). > So MN receives pref1 on if1 it makes pref1::mn1 > and MN receives pref1 on if2, it does not make pref1::mn1 because mn1 > is the hardware address (or iid) on if1 and on if2, the hardware > address (or iid) is different, you need to show it as pref1::mn1', > maybe, with mn1 not =3D mn1'. >=20 > You have this type of misleading terminology in more than one figure > (Figs 4,5 &6) and that is what I am asking you to correct. >=20 > I hope it is clear now? I understand now your comment and I see your point. I'll update the figures and the text to clarify this. The point is, that even with different IIDs, the scenarios are different, as when the MN is sharing a common set of prefixes on all MAGs, the MAGs already have the required forwarding state, so no signaling is required on the network to achieve flow mobility. Thanks for the comment. >=20 >=20 > >> > >> >> > >> >> I think that if2 should be referred to as mn2 then the situation wi= ll > >> >> be clear, i.e. moving flows between two different interfaces with > >> >> different addresses, so this case is not any different than the cas= es > >> >> 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 w= hich > >> > the same prefix (or set of prefixes) is assigned to different physic= al > >> > 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)? > > > > 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. >=20 >=20 > Why? I guess you mean LMA routing. LMA has to send the two flows to > two different addresses anyway, right? >=20 > So what is different in Section 3.2.1? In one case the assigned prefixes on different interfaces of the MN are different, whereas in the other they are not. >=20 > I have comments on other section, I am going to create different > threads for each. OK, I'll follow those threads. 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 --=-9Y58p5rmKWzRmvnHxgCs 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) iEYEABECAAYFAlBygLQACgkQNdy6TdFwT2cAWwCbBgS3lZUvqyDoWCi55I2uh36n fz4AoNlJdNi3XYcjh6+KKQLyP0HA4dWN =9JTU -----END PGP SIGNATURE----- --=-9Y58p5rmKWzRmvnHxgCs-- From cjbc@it.uc3m.es Mon Oct 8 00:28:57 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 084C121F8777 for ; Mon, 8 Oct 2012 00:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.537 X-Spam-Level: X-Spam-Status: No, score=-4.537 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_20=-0.74, 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 X10Nqn5BIGOQ for ; Mon, 8 Oct 2012 00:28:56 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id C15F921F8767 for ; Mon, 8 Oct 2012 00:28:55 -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@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id ACDE776B64D; Mon, 8 Oct 2012 09:28:54 +0200 (CEST) Message-ID: <1349681334.4721.27.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: sarikaya@ieee.org Date: Mon, 08 Oct 2012 09:28:54 +0200 In-Reply-To: References: Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-iYyuiuWb0GKAtk38AE1y" 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-19252.005 X-TM-AS-Result: No--17.159-7.0-31-1 X-imss-scan-details: No--17.159-7.0-31-1 Cc: netext@ietf.org Subject: Re: [netext] draft-ietf-netext-pmipv6-flowmob-04 Section 3.2.2 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 07:28:57 -0000 --=-iYyuiuWb0GKAtk38AE1y Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Behcet, Thanks for the comments. Please, see below. On Mon, 2012-10-01 at 16:21 -0500, Behcet Sarikaya wrote: > Hi Carlos, > I am unabe to understand this sentence at the beginning of Sec. 3.2.2 > (as we discussed in the previous thread): >=20 > A different flow mobility scenario happens when the local mobility > anchor assigns different sets of prefixes to physical interfaces of > the same mobile node. I think I covered this in my other e-mail. >=20 > Again, this statement: >=20 > Since the local mobility anchor cannot send a PBA message > which has not been triggered in response to a received PBU message, > new signaling messages are defined to cover this case. >=20 > Why not structure it in two sections: LMA Initiated Flow Mobility > where you need to define new signaling and > MAG Initiated Flow Mobility where existing PBU/PBA exchange can be used? The draft does not make any assumption on who initiates flow mobility, but just defines protocol changes to make it happen. This was long time ago discussed and the draft reflects the consensus. Nobody complained about current structure. >=20 > For LMA Initiated case, why do you think Flow Identification Mobility > option initiated by MN would be sufficient? Shouldn't LMA be able to > do more things? More actions? >=20 > Below on Page 13, you have: > The MAG MAY also include the Flow > Identification Mobility option in the PBU message that it sends to > the LMA. This serves as a request from MAG to LMA to consider the > flow policy rules specified in the option. >=20 > This is basically defining MAG Initiated flow mobility. As I mentioned before, the draft does not assume MAG or LMA initiated mobility, but it is as most generic as possible. =20 >=20 > How would a MAG know that MN has multiple interfaces? This is out of the scope of the document. Thanks, Carlos >=20 > Only LMA can inform MAG about this, please see > draft-sarikaya-netext-flowmob-ext-00 that I posted last week. >=20 > My overall comment is that in Section 3 there is too much emphasis on > the prefix assignment and not enough emphasis on the real protocol > issues. I am not convinced that playing with the way PMIPv6 assigns > HNPs is the solution to flow mobility. >=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 --=-iYyuiuWb0GKAtk38AE1y 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) iEYEABECAAYFAlBygLYACgkQNdy6TdFwT2cEVACfet365T0214oMxjjvqSfT9QPP Fw0AoJX2YKn93obkIdDT0jTBnqQBHxci =51Yb -----END PGP SIGNATURE----- --=-iYyuiuWb0GKAtk38AE1y-- From cjbc@it.uc3m.es Mon Oct 8 00:28:59 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 EA47721F877E for ; Mon, 8 Oct 2012 00:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.327 X-Spam-Level: X-Spam-Status: No, score=-5.327 tagged_above=-999 required=5 tests=[AWL=0.372, 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 TwncEtXd8Abf for ; Mon, 8 Oct 2012 00:28:59 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id E271321F8767 for ; Mon, 8 Oct 2012 00:28:58 -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@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id 092949D7518; Mon, 8 Oct 2012 09:28:57 +0200 (CEST) Message-ID: <1349681336.4721.28.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: sarikaya@ieee.org Date: Mon, 08 Oct 2012 09:28:56 +0200 In-Reply-To: References: Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-pXC0VLSfpL2LvyRxRnFp" 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-19252.005 X-TM-AS-Result: No--8.843-7.0-31-1 X-imss-scan-details: No--8.843-7.0-31-1 Cc: netext@ietf.org Subject: Re: [netext] draft-ietf-netext-pmipv6-flowmob-04 Section 5.1 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 07:29:00 -0000 --=-pXC0VLSfpL2LvyRxRnFp Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Behcet, On Mon, 2012-10-01 at 16:31 -0500, Behcet Sarikaya wrote: > Hi Carlos, >=20 > Section 5.1 is entitled Multiple Care-of Address Registration. In > PMIPv6 there is no care-address so there can not be care-of address > registration, right? Would "Multiple Proxy Care-of Address Registration" suit you? >=20 > In Figure 7, you have BID. This is adopted from RFC 5648. >=20 > Can we really adopt BID in PMIPv6? Please refer to Section 3 in > draft-sarikaya-netext-flowmob-ext-00, unfortunately BID loses its > meaning in PMIPv6. I don't quite follow this. We are proposing to reuse some mechanisms (as RFC 5648) to avoid redoing the whole thing. Carlos >=20 > It seems to me that this section needs to be completely rewritten. >=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 --=-pXC0VLSfpL2LvyRxRnFp 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) iEYEABECAAYFAlBygLgACgkQNdy6TdFwT2d+HgCgnGYhqxMENLS9ZmJD2o/xHqyZ F18AnR+401XmeeJZCaldkFbA35M1aN0L =MSkH -----END PGP SIGNATURE----- --=-pXC0VLSfpL2LvyRxRnFp-- From sarikaya2012@gmail.com Mon Oct 8 13:19:55 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 13EB01F042A for ; Mon, 8 Oct 2012 13:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.501 X-Spam-Level: X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 EsZzIQBpkO-f for ; Mon, 8 Oct 2012 13:19:54 -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 06FAE21F8812 for ; Mon, 8 Oct 2012 13:19:53 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so11785719iec.31 for ; Mon, 08 Oct 2012 13:19:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=QgY2UUhoYpnw+3NoP9SdkhPnHZK2BxvwUEKsGabaS9c=; b=Rz28W2TN8AJ2Guh4o8fewSE6jUeUEp8B8s6gDNYXvRDSxDXND5wfDzFAp7O/3W+uql VV7uRtFVwGgTElv+aq9+Nx8fmhJo5CvuXYMuELjWU4mlGnfZMh0LFQ8P1qMUvgMUMOSN JV9FeYxcCYEaNwYi33K0/4AxbegGWvId3UMKlxWXm4afSTYYO9Y/nYlgEbgIkaM2+OZ+ HfOGIaBbBhdsb0FTR1efJ7VrOttiIlaIbHIvzV7I88qhD3KN8yhdzhUW09jeFehpHSMv mEz6lp0DYvF8RySVMm4vc84uucQoTg1BweP7eay44264GGpuQ2BRubCaAhELvxh0m5YR Zzgg== MIME-Version: 1.0 Received: by 10.50.194.163 with SMTP id hx3mr9469922igc.37.1349727593562; Mon, 08 Oct 2012 13:19:53 -0700 (PDT) Received: by 10.231.85.26 with HTTP; Mon, 8 Oct 2012 13:19:53 -0700 (PDT) In-Reply-To: <1349681332.4721.26.camel@acorde.it.uc3m.es> References: <1347990352.18353.115.camel@acorde.it.uc3m.es> <1348129957.18353.179.camel@acorde.it.uc3m.es> <1349681332.4721.26.camel@acorde.it.uc3m.es> Date: Mon, 8 Oct 2012 15:19:53 -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: Mon, 08 Oct 2012 20:19:55 -0000 Hi Carlos, Please see inline. On Mon, Oct 8, 2012 at 2:28 AM, Carlos Jes=FAs Bernardos Cano wrote: > Hi Behcet, > > Please, see inline. > > On Mon, 2012-10-01 at 15:51 -0500, Behcet Sarikaya wrote: >> Hi Carlos, >> >> Sorry for my late reply. We need to continue this conversation. >> >> >> 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. H= ow >> >> >> 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 t= his >> >> >> be possible? Secondly you did not mention this assumption. >> >> > >> >> > The document does not go into the details of whether if1 and if2 ha= ve >> >> > the same iid or not. The assumptions on the MN side are the followi= ng: >> >> > >> >> > "It is >> >> > assumed that the mobile node IP layer interface can simultaneous= ly >> >> > and/or sequentially attach to multiple MAGs, possibly over multi= ple >> >> > media. One form to achieve this multiple attachment is describe= d in >> >> > [I-D.ietf-netext-logical-interface-support], which allows the mo= bile >> >> > 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. >> > >> > 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. >> > >> >> Sorry, MAGs do not assign addresses, MAGs advertise HNPs and MN makes >> an address like you call pref1::mn1. > > Well, I did mean "assigned at distinct MAGs", but anyway, MAGs can > assign addresses (section 6.9.1.1 of RFC5213: "If the mobile access > gateway learns the mobile node's home network prefix(es) either from its > policy store or from other means, the mobile access gateway MAY choose > to request the local mobility anchor to allocate the specific prefix(es) > by including a Home Network Prefix option for each of those requested > prefixes."). > You are talking about MAG suggesting prefixes (HNPs) to LMA not addresses. >> So MN receives pref1 on if1 it makes pref1::mn1 >> and MN receives pref1 on if2, it does not make pref1::mn1 because mn1 >> is the hardware address (or iid) on if1 and on if2, the hardware >> address (or iid) is different, you need to show it as pref1::mn1', >> maybe, with mn1 not =3D mn1'. >> >> You have this type of misleading terminology in more than one figure >> (Figs 4,5 &6) and that is what I am asking you to correct. >> >> I hope it is clear now? > > I understand now your comment and I see your point. I'll update the > figures and the text to clarify this. Good thanks. > The point is, that even with > different IIDs, the scenarios are different, as when the MN is sharing a > common set of prefixes on all MAGs, the MAGs already have the required > forwarding state, so no signaling is required on the network to achieve > flow mobility. I don't understand your point. It is the LMA that does the routing of different flows to different interfaces based on the flow state. What does it mean to say that MAG has the required forwarding state? MAG forwards to the proper LMA of MN, in most cases only to one LMA. > > Thanks for the comment. > >> >> >> >> >> >> >> >> >> >> I think that if2 should be referred to as mn2 then the situation w= ill >> >> >> be clear, i.e. moving flows between two different interfaces with >> >> >> different addresses, so this case is not any different than the ca= ses >> >> >> 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 physi= cal >> >> > 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)? >> > >> > 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. >> >> >> Why? I guess you mean LMA routing. LMA has to send the two flows to >> two different addresses anyway, right? >> >> So what is different in Section 3.2.1? > > In one case the assigned prefixes on different interfaces of the MN are > different, whereas in the other they are not. > Why does this change LMA's flow routing, that was my question. Still not yet answered? Regards, Behcet From cjbc@it.uc3m.es Wed Oct 10 05:22:00 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C41A21F86C6 for ; Wed, 10 Oct 2012 05:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.08 X-Spam-Level: X-Spam-Status: No, score=-5.08 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] 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 e1SMvSVK3eYA for ; Wed, 10 Oct 2012 05:21:57 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 9C79021F86C2 for ; Wed, 10 Oct 2012 05:21:54 -0700 (PDT) X-uc3m-safe: yes Received: from [172.17.141.131] (unknown [147.67.241.226]) (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 1FA1F8825CB; Wed, 10 Oct 2012 14:21:52 +0200 (CEST) Message-ID: <1349871706.4849.47.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: sarikaya@ieee.org Date: Wed, 10 Oct 2012 14:21:46 +0200 In-Reply-To: References: <1347990352.18353.115.camel@acorde.it.uc3m.es> <1348129957.18353.179.camel@acorde.it.uc3m.es> <1349681332.4721.26.camel@acorde.it.uc3m.es> Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-f/Z2e1govuI8ddMA9SBz" 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-19258.002 X-TM-AS-Result: No--35.284-7.0-31-1 X-imss-scan-details: No--35.284-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: Wed, 10 Oct 2012 12:22:00 -0000 --=-f/Z2e1govuI8ddMA9SBz Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Behcet, More comments below inline. On Mon, 2012-10-08 at 15:19 -0500, Behcet Sarikaya wrote: > Hi Carlos, > Please see inline. >=20 > On Mon, Oct 8, 2012 at 2:28 AM, Carlos Jes=C3=BAs Bernardos Cano > wrote: > > Hi Behcet, > > > > Please, see inline. > > > > On Mon, 2012-10-01 at 15:51 -0500, Behcet Sarikaya wrote: > >> Hi Carlos, > >> > >> Sorry for my late reply. We need to continue this conversation. > >> >> >> 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 i= t the > >> >> >> iid? > >> >> > > >> >> > mn1 are the 128-N rightmost bits of the MN1 address, where N is t= he > >> >> > 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 follo= wing: > >> >> > > >> >> > "It is > >> >> > assumed that the mobile node IP layer interface can simultaneo= usly > >> >> > and/or sequentially attach to multiple MAGs, possibly over mul= tiple > >> >> > media. One form to achieve this multiple attachment is descri= bed 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 interfac= es." > >> >> > > >> >> > 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. > >> > > >> > 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 th= e > >> > 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 problem= s. > >> > > >> > >> Sorry, MAGs do not assign addresses, MAGs advertise HNPs and MN makes > >> an address like you call pref1::mn1. > > > > Well, I did mean "assigned at distinct MAGs", but anyway, MAGs can > > assign addresses (section 6.9.1.1 of RFC5213: "If the mobile access > > gateway learns the mobile node's home network prefix(es) either from it= s > > policy store or from other means, the mobile access gateway MAY choose > > to request the local mobility anchor to allocate the specific prefix(es= ) > > by including a Home Network Prefix option for each of those requested > > prefixes."). > > >=20 > You are talking about MAG suggesting prefixes (HNPs) to LMA not addresses= . Right, but addresses are then configured out of those prefixes... >=20 >=20 > >> So MN receives pref1 on if1 it makes pref1::mn1 > >> and MN receives pref1 on if2, it does not make pref1::mn1 because mn1 > >> is the hardware address (or iid) on if1 and on if2, the hardware > >> address (or iid) is different, you need to show it as pref1::mn1', > >> maybe, with mn1 not =3D mn1'. > >> > >> You have this type of misleading terminology in more than one figure > >> (Figs 4,5 &6) and that is what I am asking you to correct. > >> > >> I hope it is clear now? > > > > I understand now your comment and I see your point. I'll update the > > figures and the text to clarify this. >=20 > Good thanks. >=20 > > The point is, that even with > > different IIDs, the scenarios are different, as when the MN is sharing = a > > common set of prefixes on all MAGs, the MAGs already have the required > > forwarding state, so no signaling is required on the network to achieve > > flow mobility. >=20 > I don't understand your point. It is the LMA that does the routing of > different flows to different interfaces based on the flow state. >=20 > What does it mean to say that MAG has the required forwarding state? > MAG forwards to the proper LMA of MN, in most cases only to one LMA. Think of the other direction (LMA->MAG). In order to perform flow mobility, you need the MAG routing state to be consistent. Carlos >=20 > > > > Thanks for the comment. > > > >> > >> > >> >> > >> >> >> > >> >> >> I think that if2 should be referred to as mn2 then the situation= will > >> >> >> be clear, i.e. moving flows between two different interfaces wit= h > >> >> >> 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 i= n which > >> >> > the same prefix (or set of prefixes) is assigned to different phy= sical > >> >> > interfaces. This is possible, so it should be considered. > >> >> > > >> >> > >> >> Yes but the problem is not any different than when different prefix= es > >> >> 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 n= o > >> > additional changes required in the MAG routing to be able to forward > >> > packets, while in the other there is. > >> > >> > >> Why? I guess you mean LMA routing. LMA has to send the two flows to > >> two different addresses anyway, right? > >> > >> So what is different in Section 3.2.1? > > > > In one case the assigned prefixes on different interfaces of the MN are > > different, whereas in the other they are not. > > >=20 > Why does this change LMA's flow routing, that was my question. Still > not yet answered? >=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 --=-f/Z2e1govuI8ddMA9SBz 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) iEYEABECAAYFAlB1aFoACgkQNdy6TdFwT2dKDwCgv76M+MNumBwWbDR94ebxT2P1 eo8AoM4BbPmR0aFGzcEVgTTxvNqDQUm7 =Nqxs -----END PGP SIGNATURE----- --=-f/Z2e1govuI8ddMA9SBz-- From sarikaya2012@gmail.com Wed Oct 10 12:37:51 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E5A21F86D6 for ; Wed, 10 Oct 2012 12:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.504 X-Spam-Level: X-Spam-Status: No, score=-3.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 sM6jiq91PU8J for ; Wed, 10 Oct 2012 12:37:50 -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 A057B21F86DC for ; Wed, 10 Oct 2012 12:37:50 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so1891815iec.31 for ; Wed, 10 Oct 2012 12:37:50 -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=1kcpX5zADRY1YhWfSLXb2PAcDczOqw010W4d41quPpY=; b=yMA0SKDfe4o8Xw5cXqZ1zJ6QjICxbWpUMTU2+A8uy/ZXIuJMn5OGuI2t1SREpZQuq3 jRvTxwfPvc6LnJUC5ExFRM6KDAkQB17DoEfRtsfxMAp/9Roysa/xkS56SvyqG8XRj+ek lUrOZzifk+AroswNNXkOP+cSUWRthwHqrCxhq4FAFd7TTQKhHxpSxumhXEztYaIo27Ju w7Hga9bzhqPke8Mqp63mTgxJy48MmLMVq7rvBwCiFPswiTmfoDMBK1wt/HJ9/hsiLRDF dfCijkP7Y4s93if/OVjoXSPuOBSxmVinbvPpdnRVZAhCDxpJJxjYsdYhQpkRrF1+j4fg WVow== MIME-Version: 1.0 Received: by 10.50.16.172 with SMTP id h12mr6552173igd.41.1349897870272; Wed, 10 Oct 2012 12:37:50 -0700 (PDT) Received: by 10.231.85.26 with HTTP; Wed, 10 Oct 2012 12:37:50 -0700 (PDT) In-Reply-To: <1349871706.4849.47.camel@acorde.it.uc3m.es> References: <1347990352.18353.115.camel@acorde.it.uc3m.es> <1348129957.18353.179.camel@acorde.it.uc3m.es> <1349681332.4721.26.camel@acorde.it.uc3m.es> <1349871706.4849.47.camel@acorde.it.uc3m.es> Date: Wed, 10 Oct 2012 14:37:50 -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, 10 Oct 2012 19:37:51 -0000 Hi Carlos, Please see inline. On Wed, Oct 10, 2012 at 7:21 AM, Carlos Jes=FAs Bernardos Cano wrote: > Hi Behcet, > > More comments below inline. > > On Mon, 2012-10-08 at 15:19 -0500, Behcet Sarikaya wrote: >> Hi Carlos, >> Please see inline. >> >> On Mon, Oct 8, 2012 at 2:28 AM, Carlos Jes=FAs Bernardos Cano >> wrote: >> > Hi Behcet, >> > >> > Please, see inline. >> > >> > On Mon, 2012-10-01 at 15:51 -0500, Behcet Sarikaya wrote: >> >> Hi Carlos, >> >> >> >> Sorry for my late reply. We need to continue this conversation. >> >> >> >> 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 coul= d 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 foll= owing: >> >> >> > >> >> >> > "It is >> >> >> > assumed that the mobile node IP layer interface can simultane= ously >> >> >> > and/or sequentially attach to multiple MAGs, possibly over mu= ltiple >> >> >> > media. One form to achieve this multiple attachment is descr= ibed in >> >> >> > [I-D.ietf-netext-logical-interface-support], which allows the= mobile >> >> >> > node supporting traffic flows on different physical interface= s >> >> >> > regardless of the assigned prefixes on those physical interfa= ces." >> >> >> > >> >> >> > 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. >> >> > >> >> > 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 t= he >> >> > addresses assigned by distinct MAGs are different, then the other >> >> > mechanisms described in the draft could be used, but using differen= t >> >> > prefixes is cleaner, simpler and avoids potential ND-related proble= ms. >> >> > >> >> >> >> Sorry, MAGs do not assign addresses, MAGs advertise HNPs and MN makes >> >> an address like you call pref1::mn1. >> > >> > Well, I did mean "assigned at distinct MAGs", but anyway, MAGs can >> > assign addresses (section 6.9.1.1 of RFC5213: "If the mobile access >> > gateway learns the mobile node's home network prefix(es) either from i= ts >> > policy store or from other means, the mobile access gateway MAY choose >> > to request the local mobility anchor to allocate the specific prefix(e= s) >> > by including a Home Network Prefix option for each of those requested >> > prefixes."). >> > >> >> You are talking about MAG suggesting prefixes (HNPs) to LMA not addresse= s. > > Right, but addresses are then configured out of those prefixes... > Thanks, this is what I said. So when MN configures addresses, even if the prefixes are the same the addresses are different. Addresses assigned to the interfaces of MN that are simultaneously connected are different. These are the addresses that are used as source/destination addresses in the traffic selectors defined in RFC 6088 Section 3.2. >> >> >> >> So MN receives pref1 on if1 it makes pref1::mn1 >> >> and MN receives pref1 on if2, it does not make pref1::mn1 because mn1 >> >> is the hardware address (or iid) on if1 and on if2, the hardware >> >> address (or iid) is different, you need to show it as pref1::mn1', >> >> maybe, with mn1 not =3D mn1'. >> >> >> >> You have this type of misleading terminology in more than one figure >> >> (Figs 4,5 &6) and that is what I am asking you to correct. >> >> >> >> I hope it is clear now? >> > >> > I understand now your comment and I see your point. I'll update the >> > figures and the text to clarify this. >> >> Good thanks. >> >> > The point is, that even with >> > different IIDs, the scenarios are different, as when the MN is sharing= a >> > common set of prefixes on all MAGs, the MAGs already have the required >> > forwarding state, so no signaling is required on the network to achiev= e >> > flow mobility. >> >> I don't understand your point. It is the LMA that does the routing of >> different flows to different interfaces based on the flow state. >> >> What does it mean to say that MAG has the required forwarding state? >> MAG forwards to the proper LMA of MN, in most cases only to one LMA. > > Think of the other direction (LMA->MAG). In order to perform flow > mobility, you need the MAG routing state to be consistent. > Absolutely. Let's consider then LMA to MAG flow routing. LMA receives a packet for MN which has multiple active interfaces (destination address pointing at Interface A). It checks the binding cache and finds the TS and then matches the TS with the packet and it wants to redirect this packet to interface B. Please tell me how does it help to assign the same prefix to all interfaces= ? Even if HNPs are the same, you would have to distinguish the interfaces based on the addresses anyway, right? Regards, Behcet From seiljeon@av.it.pt Tue Oct 16 10:41:01 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BF321F8866 for ; Tue, 16 Oct 2012 10:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEXeL9PXemCW for ; Tue, 16 Oct 2012 10:41:00 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 87BFB21F885B for ; Tue, 16 Oct 2012 10:41:00 -0700 (PDT) Received: from [193.136.93.156] (account seiljeon@av.it.pt HELO ATNoGSeil) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 66633454 for netext@ietf.org; Tue, 16 Oct 2012 18:40:59 +0100 From: "Seil Jeon" To: References: <20121016161413.7347.13591.idtracker@ietfa.amsl.com> In-Reply-To: <20121016161413.7347.13591.idtracker@ietfa.amsl.com> Date: Tue, 16 Oct 2012 18:40:58 +0100 Message-ID: <000b01cdabc5$672c83d0$35858b70$@av.it.pt> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEOlUBuxLPGY6mKJO25aW4KyGaFGpk6XRyQ Content-Language: ko Subject: [netext] FW: New Version Notification for draft-sijeon-netext-mmag-pmip-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 17:41:01 -0000 Hi all, We've just posted a new I-D describing network mobility using mobile MAG = in PMIPv6 domain. This I-D aims at re-using MAG function on mobile = router, called mobile MAG, being responsible for detecting MN and = performing mobility management on behalf of MNs. This draft does require = any extension to MN. This draft is based on stateless IP configuration = method for mobile nodes attached to mobile MAG. This draft can be found on following link; http://tools.ietf.org/html/draft-sijeon-netext-mmag-pmip-00 Hope to have comments. Best Regards, Seil -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Tuesday, October 16, 2012 5:14 PM To: seiljeon@av.it.pt Cc: sarikaya@ieee.org; ruilaa@ua.pt Subject: New Version Notification for = draft-sijeon-netext-mmag-pmip-00.txt A new version of I-D, draft-sijeon-netext-mmag-pmip-00.txt has been successfully submitted by Seil Jeon and posted to the IETF = repository. Filename: draft-sijeon-netext-mmag-pmip Revision: 00 Title: Network Mobility Support using Mobile MAG in Proxy Mobile IPv6 = Domain Creation date: 2012-10-15 WG ID: Individual Submission Number of pages: 9 URL: = http://www.ietf.org/internet-drafts/draft-sijeon-netext-mmag-pmip-00.txt Status: = http://datatracker.ietf.org/doc/draft-sijeon-netext-mmag-pmip Htmlized: = http://tools.ietf.org/html/draft-sijeon-netext-mmag-pmip-00 Abstract: This draft specifies IP mobility support protocol for moving network including mobile nodes (MNs) over Proxy Mobile IPv6 network by introducing a new functional entity, mobile MAG (mMAG) on the moving network. The mMAG takes charges of MN's movement detection, binding update on behalf of MNs as a mobile access gateway (MAG) does in PMIPv6 infrastructure. This protocol also supports IP session continuity for a mobile node to move between mobile network and fixed MAG. This protocol does not require any modification or extension on the MN. = =20 The IETF Secretariat From sarikaya2012@gmail.com Tue Oct 16 13:20: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 87DC71F0C90 for ; Tue, 16 Oct 2012 13:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yx9Q0ECEDsU6 for ; Tue, 16 Oct 2012 13:20:45 -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 797201F0C91 for ; Tue, 16 Oct 2012 13:20:45 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so12127275iec.31 for ; Tue, 16 Oct 2012 13:20:45 -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=2ziHtXFOncMIMfHpyosJh/tZT3Jq9qirBblFtk+ARX8=; b=Ir+hUeTH7tFvcjW2QKfOg3n+UQHoAWjDe5yE5Habgyx0e5M4/aC0ei2N4eHIIEg2A9 NL9hvSqlVa8y1VrOVgPQW5Ri1o08yRHal9iqLxcHnRGcRQA0yXdiOvvUeS5RK3AF+hkO MH/no1Qhdv8tcQexmPng1p2wQbcngUSwYXEBYNLYazN7A5A4glF1aixiP3XerrXbBNlh HpqkWvsRo/fm6qbZ1rKPRc4VeMKimhUZuySTOyFEOTFAVJzl8zFYr12jggo0hkADZSwa UP5EqvOGdnj36t1VaBWlRdbPALPe/uCj1ZOEiaUMpjtZ7HusuK7Z1uSis7wbCEHOpoWg OYdQ== MIME-Version: 1.0 Received: by 10.50.47.129 with SMTP id d1mr13573066ign.45.1350418845060; Tue, 16 Oct 2012 13:20:45 -0700 (PDT) Received: by 10.231.85.26 with HTTP; Tue, 16 Oct 2012 13:20:44 -0700 (PDT) In-Reply-To: <1349681336.4721.28.camel@acorde.it.uc3m.es> References: <1349681336.4721.28.camel@acorde.it.uc3m.es> Date: Tue, 16 Oct 2012 15:20:44 -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 Section 5.1 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, 16 Oct 2012 20:20:46 -0000 Hi Carlos, My comments below. Regards, Behcet On Mon, Oct 8, 2012 at 2:28 AM, Carlos Jes=FAs Bernardos Cano wrote: > Hi Behcet, > > On Mon, 2012-10-01 at 16:31 -0500, Behcet Sarikaya wrote: >> Hi Carlos, >> >> Section 5.1 is entitled Multiple Care-of Address Registration. In >> PMIPv6 there is no care-address so there can not be care-of address >> registration, right? > > Would "Multiple Proxy Care-of Address Registration" suit you? > Yes, it would be better. Also you need to distinguish home and visited link registrations from simultaneously connected interfaces, similar to RFC 5648. Feel free to take a look at draft-sarikaya-netext-flowmob-ext-00. When you do this, it will be easier for a MAG to know the interface of MN it serves is a home link or visited link. Base PMIPv6 needs to be modified to enable multiple proxy care-of address registrations, i.e. binding cache modifications are needed. >> >> In Figure 7, you have BID. This is adopted from RFC 5648. >> >> Can we really adopt BID in PMIPv6? Please refer to Section 3 in >> draft-sarikaya-netext-flowmob-ext-00, unfortunately BID loses its >> meaning in PMIPv6. > > I don't quite follow this. We are proposing to reuse some mechanisms (as > RFC 5648) to avoid redoing the whole thing. > Well, not everything in RFC 5648 applies to PMIPv6. BID does not apply. So you need to reuse whatever applies or needed. Behcet From bpatil1@gmail.com Tue Oct 16 13:31:01 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251DA11E80E9; Tue, 16 Oct 2012 13:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTmFIj8h4rJ5; Tue, 16 Oct 2012 13:30:59 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 38ED711E80E6; Tue, 16 Oct 2012 13:30:59 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so5652435iad.31 for ; Tue, 16 Oct 2012 13:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=+NgpTM/cEoyYuEBrf232O2J/Sm5J1m5+Lu+Gufm5jbQ=; b=pn/Pynt4X6BpgvYSEOkpDCbMa+fjPFYcxdUD/MAx/4R9lYoupy9VF0IV1JvkNPUqfw +6ir4w6NYxv2xrDkEoZStvpok/KSf60KP+nerAsRTSjY28aHHwFl/l+g8C4bsXaS7y3s UO8jhZLhJzCv3LrTXYgFy6hPLnMMuhYyLPR8OI/YCXCxAiHFv/8xyRlFhG/RgCArn2Cw +XaiNa9dZw1v533gIVMwRzRaZ9wWVTQ0pNp9VXfPs1E8G0HXxd4Z1b7kIWQO8YdsC9kC kGZKVVowsrmqsSc6Aq6AiDVcblh+fpO8qaNojm42gXpIejXc5fGyg4f0xWF1GF90MbMP om2Q== MIME-Version: 1.0 Received: by 10.50.46.134 with SMTP id v6mr13420281igm.55.1350419458680; Tue, 16 Oct 2012 13:30:58 -0700 (PDT) Received: by 10.43.89.1 with HTTP; Tue, 16 Oct 2012 13:30:58 -0700 (PDT) Date: Tue, 16 Oct 2012 15:30:58 -0500 Message-ID: From: Basavaraj Patil To: iesg-secretary@ietf.org Content-Type: multipart/alternative; boundary=14dae9340f5321e6da04cc3308ad X-Mailman-Approved-At: Tue, 16 Oct 2012 13:34:57 -0700 Cc: netext@ietf.org, netext-chairs@tools.ietf.org Subject: [netext] Request to progress I-D: draft-ietf-netext-pmipv6-sipto-option-06 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 20:32:37 -0000 --14dae9340f5321e6da04cc3308ad Content-Type: text/plain; charset=ISO-8859-1 Hello, The Netext WG has completed working group last call on the I-D: draft-ietf-netext-pmipv6-sipto-option The I-D is ready for IESG review and publication. Please find below the proto writeup for this Netext WG document. I-D: draft-ietf-netext-pmipv6-sipto-option-06.txt Title: IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Type of RFC being requested: Proposed Standard The I-D proposes a new option to be included for use in Proxy Mobile IPv6 signalng (RFC5213) and hence a proposed standard status is being requested for the document. The title page header of the I-D requests a Proposed standard status for the RFC. (2) 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: Technical Summary: 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 intent of the option being defined in this I-D is to enable IPv4 traffic associated with a mobile node to be routed from the access network itself instead of having to tunnel it back to the home network (Local Mobility Agent). Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There is nothing unusual about this I-D or WG process w.r.t this I-D that is noteworthy. The I-D has been presented and discussed at various IETF meetings and has been reviewed by several WG members and chair. Since one of the co-authors (Rajeev Koodli) is also a Netext WG chair, he has recused himself from the review or shepherding process and I am acting as the sole chair with responsibility for this I-D. Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Document shepherd: Basavaraj Patil (NetExt WG Co-chair) Responsible AD: Brian Haberman (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I (Basavaraj Patil) have reviewed the I-D multiple times and provided feedback to the authors. The authors have made efforts to address my comments and resolve them. The current version of the I-D is ready to be progressed to the IESG since the proposed option/extension to Proxy MIP6 signaling is quite clear as specified in the I-D. The authors are likely to revise the I-D further based on some additional comments that I have sent them. However I believe that the I-D in its current state is ready for IESG review. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. The I-D has been reviewed by WG members who understand the protocol well as well as people outside the WG. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. There is some ambiguity regarding the interaction with policy servers and protocols used for such. However the I-D clearly indicates that such interaction is out of scope of this I-D. The focus of this I-D is to specify the option that allows selective IPv4 traffic offloading using NAT functionality in the access network. And hence the policy aspects which are described in the I-D are not part of the core functionality being specified here. (6) Describe any specific concerns or issues that the Document Shepherd has 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. As document shepherd, I have expressed some reservations about parts of the I-D which explain how an LMA sets the traffic selectors or how a MAG chooses the traffic selectors to be sent as a proposal in the request. The WG has discussed these issues in the past and I have raised the same with the authors. There are no concerns about these scenarios and it is okay to advance the document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Each author has confirmed that all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and 79 have been met. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) 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 WG consensus behind this I-D. While a few are very vocal and strongly support it the WG as a whole understands its need and supports it. (10) 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 publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. None. As per IDnits tool: Summary: 0 errors (**), 0 warnings (==), 1 comment (--). (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. The document does not define any MIBS, media types or URI types. (13) Have all references within this document been identified as either normative or informative? Yes. (14) 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 plan for their completion? No. All normative references are existing RFCs. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. Publication of this document will not change the status of existing Proxy Mobile IPv6 RFCs. This is an extension to RFC5213 and does not affect the base protocol. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). I have reviewed the IANA considerations section and it is consistent with the body of the document. The instructions for assignment by IANA are clear. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new IANA registries are needed or require expert review for future allocations. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Document does not specify any XML code, BNF rules or, MIB definitions and hence no such reviews have been performed. -Basavaraj -- Basavaraj Patil --14dae9340f5321e6da04cc3308ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

The Netext WG has completed working gr= oup last call on the I-D:
draft-ietf-netext-pmipv6-sipto-option= =A0
The I-D is ready for IESG review and publication. Please find= below
the proto writeup for this Netext WG document.

I-D: draft-ietf-netext-pmipv6-sipto-option-06.txt
Title: IPv4 T= raffic Offload Selector Option for Proxy Mobile IPv6

(1) What type of RFC is being requested (BCP, Proposed Standard,
=
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the<= /div>
title page header?=A0

Type of RFC being reque= sted: Proposed Standard
The I-D proposes a new option to be inclu= ded for use in Proxy Mobile
IPv6 signalng (RFC5213) and hence a p= roposed standard status is being
requested for the document.=A0
The title page header of the = I-D requests a Proposed standard status
for the RFC.
(2) The IESG approval announcement includes a Document Announc= ement
Write-Up. Please provide such a Document Announcement Write-Up. Recent=
examples can be found in the "Action" announcements fo= r approved
documents. The approval announcement contains the foll= owing sections:=A0

Technical Summary:

=A0 =A0This= specification defines a mechanism and a related mobility option
= =A0 =A0for carrying IPv4 Offload traffic selectors between a mobile access<= /div>
=A0 =A0gateway and a local mobility anchor in a Proxy Mobile IPv6 doma= in.
=A0 =A0Based on the received offload flow selectors from the = local mobility
=A0 =A0anchor, a mobile access gateway can enable = offload traffic rule on
=A0 =A0the selected IPv4 flows.

=A0 =A0The in= tent of the option being defined in this I-D is to enable
=A0 =A0= IPv4 traffic associated with a mobile node to be routed from the
= =A0 =A0access network itself instead of having to tunnel it back to the
=A0 =A0home network (Local Mobility Agent).

W= orking Group Summary:

Was there anything in WG pro= cess that is worth noting? For example,
was there controversy abo= ut particular points or were there decisions
where the consensus was particularly rough?=A0

There is nothing unusual about this I-D or WG process w.r.t this I-D
that is noteworthy. The I-D has been presented and discussed at
various IETF meetings and has been reviewed by several WG members and<= /div>
chair. Since one of the co-authors (Rajeev Koodli) is also a Nete= xt WG
chair, he has recused himself from the review or shepherdin= g process
and I am acting as the sole chair with responsibility for this I-D.

Document Quality:

Are there= existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a=
conclusion that the document had no substantive issues? If there was a=
MIB Doctor, Media Type or other expert review, what was its cour= se
(briefly)? In the case of a Media Type review, on what date wa= s the
request posted?=A0

Personnel:

<= /div>
Who is the Document Shepherd? Who is the Responsible Area Directo= r?

Document shepherd: Basavaraj Patil (NetExt WG C= o-chair)
Responsible AD: Brian Haberman

(3) Briefly de= scribe the review of this document that was performed by
the Docu= ment Shepherd. If this version of the document is not ready
for p= ublication, please explain why the document is being forwarded to
the IESG.=A0

I (Basavaraj Patil) have reviewe= d the I-D multiple times and provided
feedback to the authors. Th= e authors have made efforts to address my
comments and resolve th= em. The current version of the I-D is ready to
be progressed to the IESG since the proposed option/extension to Proxy=
MIP6 signaling is quite clear as specified in the I-D. The autho= rs are
likely to revise the I-D further based on some additional = comments
that I have sent them. However I believe that the I-D in its current
state is ready for IESG review.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?=A0

No. The I-D has been reviewed by WG members who understand the
=
protocol well as well as people outside the WG.

(5) Do portions of the document need review from a particular or from<= /div>
broader perspective, e.g., security, operational complexity, AAA,= DNS,
DHCP, XML, or internationalization? If so, describe the rev= iew that
took place.=A0

There is some ambiguity regard= ing the interaction with policy servers
and protocols used for su= ch. However the I-D clearly indicates that
such interaction is ou= t of scope of this I-D. The focus of this I-D is
to specify the option that allows selective IPv4 traffic offloading
using NAT functionality in the access network. And hence the policy=
aspects which are described in the I-D are not part of the core<= /div>
functionality being specified here.

(6) Descr= ibe any specific concerns or issues that the Document
Shepherd ha= s with this document that the Responsible Area Director
and/or th= e 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.=A0

As document shepherd, I have expressed some reservations about part= s
of the I-D which explain how an LMA sets the traffic selectors = or how
a MAG chooses the traffic selectors to be sent as a proposal in the
request. The WG has discussed these issues in the past and I have
raised the same with the authors. There are no concerns about thes= e
scenarios and it is okay to advance the document.

=
(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?=A0

Each author has confirmed that all appropriate IPR disclo= sures
required for full conformance with the provisions of BCP 78= and 79
have been met.=A0

(8) Has an IPR disclosure b= een filed that references this document? If
so, summarize any WG = discussion and conclusion regarding the IPR
disclosures.=A0

No.

(9) How solid is the WG co= nsensus behind this document? Does it
represent the strong concur= rence of a few individuals, with others
being silent, or does the= WG as a whole understand and agree with it?=A0

There is strong WG consensus behind this I-D. While a f= ew are very
vocal and strongly support it the WG as a whole under= stands its need and
supports it.=A0

(10)= Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate<= /div>
email messages to the Responsible Area Director. (It should be in= a
separate email because this questionnaire is publicly availabl= e.)=A0

No.

(11) Identify any ID nits = the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ a= nd the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.=A0

None.
=

As per IDnits tool: =A0Summary: 0 errors (**), 0 warnin= gs (=3D=3D), 1 comment (--).

(12) Describe how the document meets any required forma= l review
criteria, such as the MIB Doctor, media type, and URI ty= pe reviews.=A0

The document does not define any MI= BS, media types or URI types.

(13) Have all references within this document been iden= tified as
either normative or informative?=A0

Yes.

(14) 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 plan for their completion?=A0

No. All normative references are existing RFCs.

(15) Are there downward normative references references= (see RFC
3967)? If so, list these downward references to support= the Area
Director in the Last Call procedure.=A0

No.


(16) Will publicatio= n of this document change the status of any
existing RFCs? Are th= ose RFCs listed on the title page header, listed
in the abstract,= and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to=
the part of the document where the relationship of this document= to
the other RFCs is discussed. If this information is not in th= e
document, explain why the WG considers it unnecessary.=A0
No. Publication of this document will not change the status of=
existing Proxy Mobile IPv6 RFCs. This is an extension to RFC5213= and
does not affect the base protocol.

(17) Descr= ibe the Document Shepherd's review of the IANA
considerations= section, especially with regard to its consistency with
the body= of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in=
IANA registries. Confirm that any referenced IANA registries hav= e been
clearly identified. Confirm that newly created IANA regist= ries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, an= d
a reasonable name for the new registry has been suggested (see = RFC
5226).=A0

I have reviewed the IANA considerat= ions section and it is consistent
with the body of the document. = The instructions for assignment by IANA
are clear.

(18) List any new IANA registries that require Expert Review for=
future allocations. Provide any public guidance that the IESG wo= uld
find useful in selecting the IANA Experts for these new regis= tries.=A0

No new IANA registries are needed or require expert rev= iew for future
allocations.

(19) Describ= e reviews and automated checks performed by the Document
Shepherd= to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.=A0
<= div>
Document does not specify any XML code, BNF rules or, MI= B definitions
and hence no such reviews have been performed.

-Basavaraj

--
Basavaraj Patil --14dae9340f5321e6da04cc3308ad-- From bpatil1@gmail.com Tue Oct 16 13:39:52 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D874E1F0CA0 for ; Tue, 16 Oct 2012 13:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 dVkNJbBu4xmU for ; Tue, 16 Oct 2012 13:39:51 -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 31F491F0C9C for ; Tue, 16 Oct 2012 13:39:51 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so12162051iec.31 for ; Tue, 16 Oct 2012 13:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=UKhSpqGfQg9+c19VWeb0IyjkqT6HyV8JxjZ7idcj75E=; b=QxOmtLYR2jEfTbGCpdM5t8DtD6cNFqXYgpGY3eyX/jXOcLgawYRuupr8OjJYVma0oM JPGGswo+x1CNtiRG4ocpsSwzGq5JnrA3aWZYKqkBUdi38s90f6wJPzNM6G9agFGls3ql fL/GD5IbAp9ffNqQMbtXJin1DJsPE+ZoMFe0MQ5JZ0xW+r6pvSi6in+W2us2b0jaYHjD QPsg9vFfYCtx3KY2DX9uWu4/VkCgaCBm9LyePynWQCrdewNG9g1j3WtoXYi9EV6TUjTM t7ARgDmzzbeI+tVIdt9YFEDsJm7NJD+RtBDfyCEcm3hKqgPvyt1havtKaoRFcJD1thHI R4Qw== MIME-Version: 1.0 Received: by 10.50.161.169 with SMTP id xt9mr11647133igb.62.1350419990804; Tue, 16 Oct 2012 13:39:50 -0700 (PDT) Received: by 10.43.89.1 with HTTP; Tue, 16 Oct 2012 13:39:50 -0700 (PDT) Date: Tue, 16 Oct 2012 15:39:50 -0500 Message-ID: From: Basavaraj Patil To: netext@ietf.org Content-Type: multipart/alternative; boundary=14dae9340a69d978a804cc332772 Subject: [netext] Soliciting agenda items for IETF85 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 20:39:52 -0000 --14dae9340a69d978a804cc332772 Content-Type: text/plain; charset=ISO-8859-1 Hello, The Netext WG is scheduled to meet on Monday November 5th. The WG has been allocated a 2 hour meeting slot. We are soliciting agenda items and timeslot requests at this time. Please send your requests to netext-chairs@tools.ietf.org and include the title of the I-D and its relevance to the Netext WG from the charter and goals perspective. -Chairs --14dae9340a69d978a804cc332772 Content-Type: text/html; charset=ISO-8859-1 Hello,

The Netext WG is scheduled to meet on Monday November 5th.
The WG has been allocated a 2 hour meeting slot.

We are soliciting agenda items and timeslot requests at this time.
Please send your requests to netext-chairs@tools.ietf.org and include the title of the I-D and its relevance to the Netext WG from the charter and goals perspective.

-Chairs
--14dae9340a69d978a804cc332772-- From bpatil1@gmail.com Tue Oct 16 15:30: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 1125021F859C for ; Tue, 16 Oct 2012 15:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzi2J7OWvbwt for ; Tue, 16 Oct 2012 15:30:37 -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 7EADF21F8559 for ; Tue, 16 Oct 2012 15:30:37 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so12337784iec.31 for ; Tue, 16 Oct 2012 15:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=JnGL8WWXlpBTFXrHzYj8nC3h3Oz6raCnI21vNFBbtHk=; b=J0CDo9r/uaeRSP13rEMuNhO/BuCvdNUF1YwT4xHopgEr6uN40JR6qj4f3XTzWwfBg5 KmzDr+3Elh+eBamZdWPoTUS78oaMZ91qUGypk26LIRtqQ2hklOEDfPWhmt98z5v2JI7D elzWMfBheIkImPvW1NWQSZz1C/qa3ATmnfPkw9u+PMC/WT60aUrDqWVy6B3aidgI6edg ausuP+rL/kUJsxxSGkduMYQf++2ry0/R6dMuwELOT6sLS90BXxzOe1bM6oDZZC9s3tXi VfhkjAUTmRMj5K3Cb9+DZuLieqR6WI2nIMxOp49DVVlrKTwr6561mDkh3Hi117MMtzN2 1OXw== MIME-Version: 1.0 Received: by 10.50.46.226 with SMTP id y2mr13332706igm.62.1350426637122; Tue, 16 Oct 2012 15:30:37 -0700 (PDT) Received: by 10.43.89.1 with HTTP; Tue, 16 Oct 2012 15:30:37 -0700 (PDT) Date: Tue, 16 Oct 2012 17:30:37 -0500 Message-ID: From: Basavaraj Patil To: netext@ietf.org Content-Type: multipart/alternative; boundary=14dae9340bcf003dc604cc34b4ba Cc: draft-ietf-netext-rfc5149bis@tools.ietf.org, netext-chairs@tools.ietf.org Subject: [netext] WG last call for I-D: X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 22:30:38 -0000 --14dae9340bcf003dc604cc34b4ba Content-Type: text/plain; charset=ISO-8859-1 Hello, Please consider this as the start of the working group last call for I-D: Service Selection for Mobile IPv6 and Proxy Mobile IPv6 The last call will end on October 31st, 2012. Please review and provide feedback via the mailing list or to the authors directly. I would encourage WG members to review the I-D and provide their views and comments on this document. -Chairs --14dae9340bcf003dc604cc34b4ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hello,

Please consider this as= the start of the working group last call for I-D:=A0
Service Selection for Mobile IPv6 and Proxy Mobi= le IPv6
<draft-ietf-netext-rfc5149bis>

The last call will end on October 31st, 2012.
Please review and provide feedback via the mailing li=
st or to the authors directly. 

I would encourage WG members to review the I-D and provide their views and =
comments on this document.

-Chairs

 --14dae9340bcf003dc604cc34b4ba-- From yokota@kddilabs.jp Wed Oct 17 06:15:31 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 4D10721F874C for ; Wed, 17 Oct 2012 06:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OdRZ+Bdk4np for ; Wed, 17 Oct 2012 06:15:30 -0700 (PDT) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id A7C4921F873B for ; Wed, 17 Oct 2012 06:15:30 -0700 (PDT) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 9E0271748188; Wed, 17 Oct 2012 22:15:22 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPvh7uUyAGbu; Wed, 17 Oct 2012 22:15:22 +0900 (JST) Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [172.19.90.145]) by mandala.kddilabs.jp (Postfix) with ESMTP id 5D376174817A; Wed, 17 Oct 2012 22:15:22 +0900 (JST) Received: from [10.8.0.6] (unknown [10.8.0.6]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id 48E7C1B9B1; Wed, 17 Oct 2012 22:13:20 +0900 (JST) Message-ID: <507EAF67.3050605@kddilabs.jp> Date: Wed, 17 Oct 2012 22:15:19 +0900 From: Hidetoshi Yokota User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "netext-chairs@tools.ietf.org" , "netext@ietf.org" Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [netext] Request to register on the NetExt WG charter X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 13:15:31 -0000 Hi Raj, The I-D "draft-ietf-netext-pmip6-qos" has been adopted as a WG draft, but has not been listed on the charter, yet. Could you add it with its milestone? This I-D is gaining attention in 3GPP and I would like to see it making progress with a clear target. Thanks in advance, -- Hidetoshi From bpatil1@gmail.com Wed Oct 17 06:51:41 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 916A021F8772 for ; Wed, 17 Oct 2012 06:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.478 X-Spam-Level: X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 fSFKAmqy+tsN for ; Wed, 17 Oct 2012 06:51:40 -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 9D63721F85F4 for ; Wed, 17 Oct 2012 06:51:40 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so13542154iec.31 for ; Wed, 17 Oct 2012 06:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vT6sieTcYXqIfZDpjhjxS+MDN9ZmWzoehHHj6CxhP60=; b=o39eyXbF1mu1tOlelEI9ObG8MkPahhor3dn1hh3CuvLE3Zub3MFdGufPtS2l4pSW2Q oJjfr2aVhgtf1ah+aeoay0VtaGpqZEnLV96U+hLfWP1qaYw+9TH8OGdagYTD6byQk+Pp hCYRldN/eO15un74YDU54wqrLsYbyP0hrYL2xREh6y8BUDF0rfPs+BXfnoopwnIqZ+On 6lJOrW9fWbk4YueFGBCNcktg+yL3eNXeWczhnxvrNM44vSq0unT1mOJwEh8RMwRHxVXA /C0kbZEtGzOkWw4wRSY+AFgU5Y8NZ7L/EoLJ/obGTvS/US6MtwRIxEDQdjl6bF6iZHDW 4BGA== MIME-Version: 1.0 Received: by 10.50.13.138 with SMTP id h10mr1574226igc.55.1350481900267; Wed, 17 Oct 2012 06:51:40 -0700 (PDT) Received: by 10.43.89.1 with HTTP; Wed, 17 Oct 2012 06:51:40 -0700 (PDT) In-Reply-To: <507EAF67.3050605@kddilabs.jp> References: <507EAF67.3050605@kddilabs.jp> Date: Wed, 17 Oct 2012 08:51:40 -0500 Message-ID: From: Basavaraj Patil To: Hidetoshi Yokota Content-Type: multipart/alternative; boundary=f46d044468e3f0e8c804cc4191b8 Cc: "netext@ietf.org" , "netext-chairs@tools.ietf.org" Subject: Re: [netext] Request to register on the NetExt WG charter X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 13:51:41 -0000 --f46d044468e3f0e8c804cc4191b8 Content-Type: text/plain; charset=ISO-8859-1 Hi Yokota-san, The I-D is listed as a WG document at: http://datatracker.ietf.org/wg/netext/ But if you meant that the milestones in the charter do not reflect the timeline for this I-D, that is true. I will send an updated milestones list which includes this I-D to the AD for approval. Thanks. -Raj On Wed, Oct 17, 2012 at 8:15 AM, Hidetoshi Yokota wrote: > Hi Raj, > > The I-D "draft-ietf-netext-pmip6-qos" has been adopted as a WG draft, > but has not been listed on the charter, yet. Could you add it with its > milestone? This I-D is gaining attention in 3GPP and I would like to see > it making progress with a clear target. > > Thanks in advance, > -- > Hidetoshi > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > -- Basavaraj Patil --f46d044468e3f0e8c804cc4191b8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Yokota-san,

The I-D is listed as a WG = document at:

But if y= ou meant that the milestones in the charter do not reflect the timeline for= this I-D, that is true. I will send an updated milestones list which inclu= des this I-D to the AD for approval.

Thanks.
-Raj

On Wed, Oct 17, 2012 at 8:15 AM, Hidetoshi Yokota <<= a href=3D"mailto:yokota@kddilabs.jp" target=3D"_blank">yokota@kddilabs.jp> wrote:
Hi Raj,

The I-D "draft-ietf-netext-pmip6-qos" has been adopted as a WG dr= aft,
but has not been listed on the charter, yet. Could you add it with its
milestone? This I-D is gaining attention in 3GPP and I would like to see it making progress with a clear target.

Thanks in advance,
--
Hidetoshi
_______________________________________________
netext mailing list
netext@ietf.org
= https://www.ietf.org/mailman/listinfo/netext



-- Basavaraj Patil
--f46d044468e3f0e8c804cc4191b8-- From yokota@kddilabs.jp Wed Oct 17 21:48:55 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 DE91F21F8475 for ; Wed, 17 Oct 2012 21:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GX4N1YVVttFs for ; Wed, 17 Oct 2012 21:48:55 -0700 (PDT) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id BDAD121F8464 for ; Wed, 17 Oct 2012 21:48:54 -0700 (PDT) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 4CE251748179; Thu, 18 Oct 2012 13:48:46 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8scobyQPEsUx; Thu, 18 Oct 2012 13:48:44 +0900 (JST) Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [172.19.90.145]) by mandala.kddilabs.jp (Postfix) with ESMTP id DED621748165; Thu, 18 Oct 2012 13:48:44 +0900 (JST) Received: from [172.19.90.27] (YokoletsJ10.mn.mip.kddilabs.jp [172.19.90.27]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id 03C2E1B9B1; Thu, 18 Oct 2012 13:46:41 +0900 (JST) Message-ID: <507F8A29.4080607@kddilabs.jp> Date: Thu, 18 Oct 2012 13:48:41 +0900 From: Hidetoshi Yokota User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: bpatil1@gmail.com References: <507EAF67.3050605@kddilabs.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: "netext@ietf.org" , "netext-chairs@tools.ietf.org" Subject: Re: [netext] Request to register on the NetExt WG charter 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, 18 Oct 2012 04:48:56 -0000 Hi Raj, Thanks a lot for your very quick response! Yes, I meant its milestone and goal. In order to list that I-D as a reference, it's important when it will get published as RFC. Regards, -- Hidetoshi (2012/10/17 22:51), Basavaraj Patil wrote: > > Hi Yokota-san, > > The I-D is listed as a WG document at: > http://datatracker.ietf.org/wg/netext/ > > But if you meant that the milestones in the charter do not reflect the > timeline for this I-D, that is true. I will send an updated milestones > list which includes this I-D to the AD for approval. > > Thanks. > -Raj > > On Wed, Oct 17, 2012 at 8:15 AM, Hidetoshi Yokota > wrote: > > Hi Raj, > > The I-D "draft-ietf-netext-pmip6-qos" has been adopted as a WG draft, > but has not been listed on the charter, yet. Could you add it with its > milestone? This I-D is gaining attention in 3GPP and I would like to see > it making progress with a clear target. > > Thanks in advance, > -- > Hidetoshi > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > > > > -- > Basavaraj Patil From wwwrun@rfc-editor.org Thu Oct 18 12:15:34 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04ED321F84FA; Thu, 18 Oct 2012 12:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.017 X-Spam-Level: X-Spam-Status: No, score=-102.017 tagged_above=-999 required=5 tests=[AWL=-0.017, 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 72HVd01njo4N; Thu, 18 Oct 2012 12:15:33 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 97BE221F84E6; Thu, 18 Oct 2012 12:15:33 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3F86DB1E004; Thu, 18 Oct 2012 12:10:12 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20121018191012.3F86DB1E004@rfc-editor.org> Date: Thu, 18 Oct 2012 12:10:12 -0700 (PDT) Cc: netext@ietf.org, rfc-editor@rfc-editor.org Subject: [netext] RFC 6757 on Access Network Identifier (ANI) Option 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, 18 Oct 2012 19:15:34 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6757 Title: Access Network Identifier (ANI) Option for Proxy Mobile IPv6 Author: S. Gundavelli, Ed., J. Korhonen, Ed., M. Grayson, K. Leung, R. Pazhyannur Status: Standards Track Stream: IETF Date: October 2012 Mailbox: sgundave@cisco.com, jouni.nospam@gmail.com, mgrayson@cisco.com, kleung@cisco.com, rpazhyan@cisco.com Pages: 19 Characters: 43863 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netext-access-network-option-13.txt URL: http://www.rfc-editor.org/rfc/rfc6757.txt The local mobility anchor in a Proxy Mobile IPv6 (PMIPv6) domain is able to provide access-network- and access-operator-specific handling or policing of the mobile node traffic using information about the access network to which the mobile node is attached. This specification defines a mechanism and a related mobility option for carrying the access network identifier and the access operator identification information from the mobile access gateway to the local mobility anchor over Proxy Mobile IPv6. [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 internet-drafts@ietf.org Thu Oct 18 19:58:21 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE6B1F0C61; Thu, 18 Oct 2012 19:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 U8gCo1oYutVP; Thu, 18 Oct 2012 19:58:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90B91F0C4C; Thu, 18 Oct 2012 19:58:20 -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: <20121019025820.12760.69424.idtracker@ietfa.amsl.com> Date: Thu, 18 Oct 2012 19:58:20 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pd-pmip-04.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: Fri, 19 Oct 2012 02:58:21 -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 : Prefix Delegation for Proxy Mobile IPv6 Author(s) : Xingyue Zhou Jouni Korhonen Carl Williams Sri Gundavelli Carlos J. Bernardos Filename : draft-ietf-netext-pd-pmip-04.txt Pages : 18 Date : 2012-10-18 Abstract: Proxy Mobile IPv6 enables IP mobility for a host without requiring its participation in any mobility signaling, being the network responsible for managing IP mobility on behalf of the host. However, Proxy Mobile IPv6 does not support assigning a prefix to a router and managing its IP mobility. This document specifies an extension to Proxy Mobile IPv6 protocol for supporting network mobility using DHCPv6-based Prefix Delegation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pd-pmip There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pd-pmip-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-pd-pmip-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sun Oct 21 22:35:43 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 8C74E21F8AF1; Sun, 21 Oct 2012 22:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 BcwBEe9UAcko; Sun, 21 Oct 2012 22:35:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A06321F8A62; Sun, 21 Oct 2012 22:35:43 -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: <20121022053543.18450.4510.idtracker@ietfa.amsl.com> Date: Sun, 21 Oct 2012 22:35:43 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmipv6-sipto-option-07.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 05:35:43 -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-07.txt Pages : 14 Date : 2012-10-21 Abstract: This specification defines a traffic offload 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 negotiated IPv4 traffic offload flow selectors with 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-pmipv6-sipto-option-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From cjbc@it.uc3m.es Mon Oct 22 07:18:53 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9877F21F8A98 for ; Mon, 22 Oct 2012 07:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.389 X-Spam-Level: X-Spam-Status: No, score=-5.389 tagged_above=-999 required=5 tests=[AWL=0.310, 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 sv3Mt7xdFTUo for ; Mon, 22 Oct 2012 07:18:52 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB8221F8A0F for ; Mon, 22 Oct 2012 07:18:52 -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@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id A262F894D4C; Mon, 22 Oct 2012 16:18:50 +0200 (CEST) Message-ID: <1350915531.5139.71.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: sarikaya@ieee.org Date: Mon, 22 Oct 2012 16:18:51 +0200 In-Reply-To: References: <1347990352.18353.115.camel@acorde.it.uc3m.es> <1348129957.18353.179.camel@acorde.it.uc3m.es> <1349681332.4721.26.camel@acorde.it.uc3m.es> <1349871706.4849.47.camel@acorde.it.uc3m.es> Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-R4ZDRGzzt0RQO1blX4ZY" 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-19294.007 X-TM-AS-Result: No--32.786-7.0-31-1 X-imss-scan-details: No--32.786-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: Mon, 22 Oct 2012 14:18:53 -0000 --=-R4ZDRGzzt0RQO1blX4ZY Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Behcet, On Wed, 2012-10-10 at 14:37 -0500, Behcet Sarikaya wrote: > Hi Carlos, >=20 > Please see inline. >=20 > On Wed, Oct 10, 2012 at 7:21 AM, Carlos Jes=C3=BAs Bernardos Cano > wrote: > > Hi Behcet, > > > > More comments below inline. > > > > On Mon, 2012-10-08 at 15:19 -0500, Behcet Sarikaya wrote: > >> Hi Carlos, > >> Please see inline. > >> > >> On Mon, Oct 8, 2012 at 2:28 AM, Carlos Jes=C3=BAs Bernardos Cano > >> wrote: > >> > Hi Behcet, > >> > > >> > Please, see inline. > >> > > >> > On Mon, 2012-10-01 at 15:51 -0500, Behcet Sarikaya wrote: > >> >> Hi Carlos, > >> >> > >> >> Sorry for my late reply. We need to continue this conversation. > >> >> >> >> 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 figu= re. How > >> >> >> >> come pref1::mn1 and pref1::mn1 stays the same? What is mn1? I= s it the > >> >> >> >> iid? > >> >> >> > > >> >> >> > mn1 are the 128-N rightmost bits of the MN1 address, where N i= s the > >> >> >> > prefix length. Typically mn1 would correspond to the iid. > >> >> >> > > >> >> >> >> Do you assume that both if1 and if2 have the same iid? How co= uld this > >> >> >> >> be possible? Secondly you did not mention this assumption. > >> >> >> > > >> >> >> > The document does not go into the details of whether if1 and i= f2 have > >> >> >> > the same iid or not. The assumptions on the MN side are the fo= llowing: > >> >> >> > > >> >> >> > "It is > >> >> >> > assumed that the mobile node IP layer interface can simulta= neously > >> >> >> > and/or sequentially attach to multiple MAGs, possibly over = multiple > >> >> >> > media. One form to achieve this multiple attachment is des= cribed in > >> >> >> > [I-D.ietf-netext-logical-interface-support], which allows t= he mobile > >> >> >> > node supporting traffic flows on different physical interfa= ces > >> >> >> > regardless of the assigned prefixes on those physical inter= faces." > >> >> >> > > >> >> >> > 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 a= ny > >> >> >> 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 th= e > >> >> > 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 differ= ent > >> >> > prefixes is cleaner, simpler and avoids potential ND-related prob= lems. > >> >> > > >> >> > >> >> Sorry, MAGs do not assign addresses, MAGs advertise HNPs and MN mak= es > >> >> an address like you call pref1::mn1. > >> > > >> > Well, I did mean "assigned at distinct MAGs", but anyway, MAGs can > >> > assign addresses (section 6.9.1.1 of RFC5213: "If the mobile access > >> > gateway learns the mobile node's home network prefix(es) either from= its > >> > policy store or from other means, the mobile access gateway MAY choo= se > >> > to request the local mobility anchor to allocate the specific prefix= (es) > >> > by including a Home Network Prefix option for each of those requeste= d > >> > prefixes."). > >> > > >> > >> You are talking about MAG suggesting prefixes (HNPs) to LMA not addres= ses. > > > > Right, but addresses are then configured out of those prefixes... > > >=20 > Thanks, this is what I said. >=20 > So when MN configures addresses, even if the prefixes are the same the > addresses are different. Addresses assigned to the interfaces of MN > that are simultaneously connected are different. These are the > addresses that are used as source/destination addresses in the traffic > selectors defined in RFC 6088 Section 3.2. >=20 > >> > >> > >> >> So MN receives pref1 on if1 it makes pref1::mn1 > >> >> and MN receives pref1 on if2, it does not make pref1::mn1 because m= n1 > >> >> is the hardware address (or iid) on if1 and on if2, the hardware > >> >> address (or iid) is different, you need to show it as pref1::mn1', > >> >> maybe, with mn1 not =3D mn1'. > >> >> > >> >> You have this type of misleading terminology in more than one figur= e > >> >> (Figs 4,5 &6) and that is what I am asking you to correct. > >> >> > >> >> I hope it is clear now? > >> > > >> > I understand now your comment and I see your point. I'll update the > >> > figures and the text to clarify this. > >> > >> Good thanks. > >> > >> > The point is, that even with > >> > different IIDs, the scenarios are different, as when the MN is shari= ng a > >> > common set of prefixes on all MAGs, the MAGs already have the requir= ed > >> > forwarding state, so no signaling is required on the network to achi= eve > >> > flow mobility. > >> > >> I don't understand your point. It is the LMA that does the routing of > >> different flows to different interfaces based on the flow state. > >> > >> What does it mean to say that MAG has the required forwarding state? > >> MAG forwards to the proper LMA of MN, in most cases only to one LMA. > > > > Think of the other direction (LMA->MAG). In order to perform flow > > mobility, you need the MAG routing state to be consistent. > > >=20 > Absolutely. >=20 > Let's consider then LMA to MAG flow routing. > LMA receives a packet for MN which has multiple active interfaces > (destination address pointing at Interface A). It checks the binding > cache and finds the TS and then matches the TS with the packet and it > wants to redirect this packet to interface B. >=20 > Please tell me how does it help to assign the same prefix to all interfac= es? >=20 > Even if HNPs are the same, you would have to distinguish the > interfaces based on the addresses anyway, right? On the LMA yes, but in the MAGs then you don't need additional routing state. 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 --=-R4ZDRGzzt0RQO1blX4ZY 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) iEYEABECAAYFAlCFVcsACgkQNdy6TdFwT2fRMACcCnrb4NKouBPIyUVti/jMWg1r uQEAnijC+dg4POE896q+CFB+R/l6ZD7r =aW5i -----END PGP SIGNATURE----- --=-R4ZDRGzzt0RQO1blX4ZY-- From cjbc@it.uc3m.es Mon Oct 22 10:33:00 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C022B11E80BA for ; Mon, 22 Oct 2012 10:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.433 X-Spam-Level: X-Spam-Status: No, score=-5.433 tagged_above=-999 required=5 tests=[AWL=0.266, 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 o8lRrWNmVdn5 for ; Mon, 22 Oct 2012 10:32:59 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id AAEA811E80A5 for ; Mon, 22 Oct 2012 10:32:59 -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 0A8E9CC5FDC; Mon, 22 Oct 2012 19:32:59 +0200 (CEST) Message-ID: <1350927179.5139.92.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: sarikaya@ieee.org Date: Mon, 22 Oct 2012 19:32:59 +0200 In-Reply-To: References: <1349681336.4721.28.camel@acorde.it.uc3m.es> Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-ghIL2xVO1fyE+NF2JGH8" 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-19296.000 X-TM-AS-Result: No--19.165-7.0-31-1 X-imss-scan-details: No--19.165-7.0-31-1 Cc: netext@ietf.org Subject: Re: [netext] draft-ietf-netext-pmipv6-flowmob-04 Section 5.1 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:33:00 -0000 --=-ghIL2xVO1fyE+NF2JGH8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Behcet, On Tue, 2012-10-16 at 15:20 -0500, Behcet Sarikaya wrote: > Hi Carlos, >=20 > My comments below. >=20 > Regards, >=20 > Behcet >=20 > On Mon, Oct 8, 2012 at 2:28 AM, Carlos Jes=C3=BAs Bernardos Cano > wrote: > > Hi Behcet, > > > > On Mon, 2012-10-01 at 16:31 -0500, Behcet Sarikaya wrote: > >> Hi Carlos, > >> > >> Section 5.1 is entitled Multiple Care-of Address Registration. In > >> PMIPv6 there is no care-address so there can not be care-of address > >> registration, right? > > > > Would "Multiple Proxy Care-of Address Registration" suit you? > > >=20 > Yes, it would be better. Also you need to distinguish home and visited > link registrations from simultaneously connected interfaces, similar > to RFC 5648. Feel free to take a look at > draft-sarikaya-netext-flowmob-ext-00. When you do this, it will be > easier for a MAG to know the interface of MN it serves is a home link > or visited link. >=20 > Base PMIPv6 needs to be modified to enable multiple proxy care-of > address registrations, i.e. binding cache modifications are needed. This is already mentioned in the draft. I've tried to make it more clear in the next revision. >=20 >=20 > >> > >> In Figure 7, you have BID. This is adopted from RFC 5648. > >> > >> Can we really adopt BID in PMIPv6? Please refer to Section 3 in > >> draft-sarikaya-netext-flowmob-ext-00, unfortunately BID loses its > >> meaning in PMIPv6. > > > > I don't quite follow this. We are proposing to reuse some mechanisms (a= s > > RFC 5648) to avoid redoing the whole thing. > > >=20 > Well, not everything in RFC 5648 applies to PMIPv6. BID does not apply. > So you need to reuse whatever applies or needed. Why BID does not apply? If the BC is extended to support multiple registrations, you need an identifier for each of them. The BID is used for that. Thanks, Carlos >=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 --=-ghIL2xVO1fyE+NF2JGH8 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) iEYEABECAAYFAlCFg0wACgkQNdy6TdFwT2dMYQCgxX2+OARtQGmLz4wOGAZxbeBj UnUAn3EyB+yafS3t2OWh45+gg/+sjtDh =XCsB -----END PGP SIGNATURE----- --=-ghIL2xVO1fyE+NF2JGH8-- From internet-drafts@ietf.org Mon Oct 22 10:57:59 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 B678921F8B3D; Mon, 22 Oct 2012 10:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 m5btwgxl+UCJ; Mon, 22 Oct 2012 10:57:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5141421F8A98; Mon, 22 Oct 2012 10:57:59 -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: <20121022175759.4690.43666.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 10:57:59 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmipv6-flowmob-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:57:59 -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 : Proxy Mobile IPv6 Extensions to Support Flow Mobility Author(s) : Carlos J. Bernardos Filename : draft-ietf-netext-pmipv6-flowmob-05.txt Pages : 22 Date : 2012-10-22 Abstract: Proxy Mobile IPv6 allows a mobile node to connect to the same Proxy Mobile IPv6 domain through different interfaces. However, the ability of movement of selected flows from one access technology to another is missing in the basic Proxy Mobile IPv6 protocol. This document describes extensions to the Proxy Mobile IPv6 protocol that are required to support network based flow mobility over multiple physical interfaces. The extensions required consist on the operations performed by the local mobility anchor and the mobile access gateway to manage the prefixes assigned to the different interfaces of the mobile node, as well as how the forwarding policies are handled by the network to ensure consistent flow mobility management. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmipv6-flowmob There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pmipv6-flowmob-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-pmipv6-flowmob-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From cjbc@it.uc3m.es Mon Oct 22 11:05:53 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487A211E8100 for ; Mon, 22 Oct 2012 11:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.467 X-Spam-Level: X-Spam-Status: No, score=-5.467 tagged_above=-999 required=5 tests=[AWL=0.232, 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 aSSwXsiSlU89 for ; Mon, 22 Oct 2012 11:05:52 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 430D411E8101 for ; Mon, 22 Oct 2012 11:05:52 -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 43B87CC58C6 for ; Mon, 22 Oct 2012 20:05:51 +0200 (CEST) Message-ID: <1350929152.5139.99.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: netext@ietf.org Date: Mon, 22 Oct 2012 20:05:52 +0200 Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-K0AiE1HLHDhqUH8oP53K" 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-19296.001 X-TM-AS-Result: No--7.563-7.0-31-1 X-imss-scan-details: No--7.563-7.0-31-1 Subject: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-05.txt] X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 18:05:54 -0000 --=-K0AiE1HLHDhqUH8oP53K Content-Type: multipart/mixed; boundary="=-6UVRDmz7S1CU36+QmfIb" --=-6UVRDmz7S1CU36+QmfIb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, A new version of the draft has been posted. Summary of changes: - More details have been added to section 5.x to clarify the operation of the proposed extensions (trying to address comments received on the mailing list). - Some additional clarifications here and there (also to address comments received on the mailing list). - The security considerations section has been improved. Comments are welcome! Carlos --=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 --=-6UVRDmz7S1CU36+QmfIb Content-Disposition: inline Content-Description: Forwarded message - [netext] I-D Action: draft-ietf-netext-pmipv6-flowmob-05.txt Content-Type: message/rfc822 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on antispam.uc3m.es X-Spam-Level: X-Spam-Status: No, score=1.0 required=3.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.7-deb X-Original-To: cjbc@it.uc3m.es Delivered-To: cjbc@correo01.uc3m.es Received: from smtp01.uc3m.es (pip-L01.uc3m.es [163.117.176.61]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by correo01.uc3m.es (Postfix) with ESMTPS id 3AD0A136C6; Mon, 22 Oct 2012 19:58:16 +0200 (CEST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.30]) by smtp01.uc3m.es (Postfix) with ESMTP id D6F54CC5FD7; Mon, 22 Oct 2012 19:58:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1350928682; bh=tzv2oBj10V/EKpUSdlAxxf4J3np0IN3vGy7hVZEN3I4=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=fpcxLKm9qREDbVBuql02MKgpL58mDACX22AQZB36VkNC1S1Gz0XX8Iil/pYeAp55n rUEhzTO/IFWW5EjZpi7rveqYGTXJg0Mg6dWozhhyQvRVvY4sjNDlWKghtO2QfGvWtd kx5bt19bT0C1b1ybTtYXXV+hrPfmOmJRx9yEJIPM= X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com X-Virus-Scanned: amavisd-new at amsl.com MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022175759.4690.43666.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 10:57:59 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmipv6-flowmob-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Sender: netext-bounces@ietf.org Errors-To: netext-bounces@ietf.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (smtp01.uc3m.es); Mon, 22 Oct 2012 19:58:15 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-19296.000 X-TM-AS-Result: No--3.118-7.0-31-1 X-imss-scan-details: No--3.118-7.0-31-1 Content-Transfer-Encoding: quoted-printable 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 : Proxy Mobile IPv6 Extensions to Support Flow Mobility Author(s) : Carlos J. Bernardos Filename : draft-ietf-netext-pmipv6-flowmob-05.txt Pages : 22 Date : 2012-10-22 Abstract: Proxy Mobile IPv6 allows a mobile node to connect to the same Proxy Mobile IPv6 domain through different interfaces. However, the ability of movement of selected flows from one access technology to another is missing in the basic Proxy Mobile IPv6 protocol. This document describes extensions to the Proxy Mobile IPv6 protocol that are required to support network based flow mobility over multiple physical interfaces. The extensions required consist on the operations performed by the local mobility anchor and the mobile access gateway to manage the prefixes assigned to the different interfaces of the mobile node, as well as how the forwarding policies are handled by the network to ensure consistent flow mobility management. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmipv6-flowmob There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pmipv6-flowmob-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-pmipv6-flowmob-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext --=-6UVRDmz7S1CU36+QmfIb-- --=-K0AiE1HLHDhqUH8oP53K 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) iEYEABECAAYFAlCFiwAACgkQNdy6TdFwT2eoagCggkIdW7znmwYlYfZGOKrAcrS/ AAYAn35OtvIyen+x5nVQgp9e3cVkWGwC =F7qH -----END PGP SIGNATURE----- --=-K0AiE1HLHDhqUH8oP53K-- From internet-drafts@ietf.org Mon Oct 22 11:40:30 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 2947A11E8099; Mon, 22 Oct 2012 11:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 XTRqrImD0M0S; Mon, 22 Oct 2012 11:40:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878B521F87E0; Mon, 22 Oct 2012 11:40:29 -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: <20121022184029.31772.87916.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 11:40:29 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-logical-interface-support-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: Mon, 22 Oct 2012 18:40:30 -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 : Logical Interface Support for multi-mode IP Hosts Author(s) : Telemaco Melia Sri Gundavelli Filename : draft-ietf-netext-logical-interface-support-06.txt Pages : 25 Date : 2012-10-22 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-logical-interface-support There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-logical-interface-support-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-logical-interface-supp= ort-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 22 13:16:17 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 D4C4C11E809B; Mon, 22 Oct 2012 13:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 I-xyv6Mqq8p5; Mon, 22 Oct 2012 13:16:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E28621F8923; Mon, 22 Oct 2012 13:16:17 -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: <20121022201617.16215.75636.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 13:16:17 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmip6-qos-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 20:16:18 -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 : Quality of Service Option for Proxy Mobile IPv6 Author(s) : Marco Liebsch Pierrick Seite Hidetoshi Yokota Jouni Korhonen Sri Gundavelli Filename : draft-ietf-netext-pmip6-qos-01.txt Pages : 33 Date : 2012-10-22 Abstract: This specification defines a new mobility option that can be used by the mobility entities in the Proxy Mobile IPv6 domain to exchange Quality of Service parameters associated with a subscriber's IP flows. Using the QoS option, the local mobility anchor and the mobile access gateway can exchange available QoS attributes and associated values. This enables QoS policing and labeling of packets to enforce QoS differentiation on the path between the local mobility anchor and the mobile access gateway. Furthermore, making QoS parameters available on the MAG enables mapping these parameters to QoS rules being specific to the access technology which operates below the mobile access gateway. After such mapping, QoS rules can be enforced on the access technology components, such as an IEEE 802.11e Wireless LAN controller. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmip6-qos There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pmip6-qos-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-pmip6-qos-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 22 16:13: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 723EB11E80EA; Mon, 22 Oct 2012 16:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 bJs+LtTnl3ET; Mon, 22 Oct 2012 16:13:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F4211E80A2; Mon, 22 Oct 2012 16:13:45 -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: <20121022231345.8057.44343.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 16:13:45 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pd-pmip-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 23:13:46 -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 : Prefix Delegation for Proxy Mobile IPv6 Author(s) : Xingyue Zhou Jouni Korhonen Carl Williams Sri Gundavelli Carlos J. Bernardos Filename : draft-ietf-netext-pd-pmip-05.txt Pages : 19 Date : 2012-10-22 Abstract: Proxy Mobile IPv6 enables IP mobility for a host without requiring its participation in any mobility signaling, being the network responsible for managing IP mobility on behalf of the host. However, Proxy Mobile IPv6 does not support assigning a prefix to a router and managing its IP mobility. This document specifies an extension to Proxy Mobile IPv6 protocol for supporting network mobility using DHCPv6-based Prefix Delegation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pd-pmip There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pd-pmip-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-pd-pmip-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From alexandru.petrescu@gmail.com Tue Oct 23 01:03:22 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 55CE721F86A2 for ; Tue, 23 Oct 2012 01:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.419 X-Spam-Level: X-Spam-Status: No, score=-9.419 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_00=-2.599, HELO_EQ_FR=0.35, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_HI=-8] 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 bPJbuNMX1COB for ; Tue, 23 Oct 2012 01:03:21 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7331B21F869E for ; Tue, 23 Oct 2012 01:03:21 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q9N83Keh006059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 23 Oct 2012 10:03:20 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q9N83JKb025085 for ; Tue, 23 Oct 2012 10:03:20 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q9N839fW007554 for ; Tue, 23 Oct 2012 10:03:19 +0200 Message-ID: <50864F3E.5000400@gmail.com> Date: Tue, 23 Oct 2012 10:03:10 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 CC: netext@ietf.org References: <20121022231345.8057.44343.idtracker@ietfa.amsl.com> In-Reply-To: <20121022231345.8057.44343.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [netext] I-D Action: draft-ietf-netext-pd-pmip-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 08:03:22 -0000 Hi, I noticed the addition of a new option to PBU: Delegated Mobile Network Prefix Option. Arguably a new option in PBU may make sense if the existing RFC5213 Home Network Prefix Option can not be reused to communicate this 'delegated' prefix. But it has a GRE key in it... should we all implement it (even if set to 0)? Could the DMNP option be present in PBU and the HNP option absent? Also I notice the addition of IPv4 (DMNP can be IPv4 or IPv6). Is there a particular form of IPv4-in-IPv6 encapsulation that is preferred? Alex Le 23/10/2012 01:13, internet-drafts@ietf.org a écrit : > > 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 : Prefix Delegation for Proxy Mobile IPv6 Author(s) > : Xingyue Zhou Jouni Korhonen Carl Williams Sri Gundavelli Carlos J. > Bernardos Filename : draft-ietf-netext-pd-pmip-05.txt Pages > : 19 Date : 2012-10-22 > > Abstract: Proxy Mobile IPv6 enables IP mobility for a host without > requiring its participation in any mobility signaling, being the > network responsible for managing IP mobility on behalf of the host. > However, Proxy Mobile IPv6 does not support assigning a prefix to a > router and managing its IP mobility. This document specifies an > extension to Proxy Mobile IPv6 protocol for supporting network > mobility using DHCPv6-based Prefix Delegation. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netext-pd-pmip > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-netext-pd-pmip-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-pd-pmip-05 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ I-D-Announce mailing > list I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft > directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > From sgundave@cisco.com Tue Oct 23 08:31:15 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488A821F86AF for ; Tue, 23 Oct 2012 08:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 UShC-ygFRZqK for ; Tue, 23 Oct 2012 08:31:14 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 56F5821F8672 for ; Tue, 23 Oct 2012 08:31:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4138; q=dns/txt; s=iport; t=1351006274; x=1352215874; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=lonxglUI0d/MYjo8cnZvorJTgMkMBaCGvST5uBj4Uc0=; b=bTVXUuEgaeu9wZWajH3F1YsQu8GZIhnPYJNOX/NwWhffub+jse4yrYZm WFQzrEScYZMfowU3qqD5ZyismVgZfx+wTIA5bkMBhmpe+iHBRA5r89Fnm uJiRsaP0bHqYiKxkOnesi4BWKj4w3rSbw9MXJSryR7lwTpfwOr9gTuRBf k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGi3hlCtJV2b/2dsb2JhbABEwWaBCIIgAQQBAQEPAVsLEgEIIkUGCyUCBA4FCAEZh1ADDwubeY9chl4NiVSKeGeFfmADiCWLd4JsihIDgyKBa4Jvghg X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; d="scan'208";a="134487740" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 23 Oct 2012 15:31:14 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9NFVDjP026169 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Oct 2012 15:31:13 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 10:31:13 -0500 From: "Sri Gundavelli (sgundave)" To: Alexandru Petrescu Thread-Topic: [netext] I-D Action: draft-ietf-netext-pd-pmip-05.txt Thread-Index: AQHNsTNvcsHP4oRN/EKVold0XapWjQ== Date: Tue, 23 Oct 2012 15:31:13 +0000 Message-ID: <24C0F3E22276D9438D6F366EB89FAEA80F56365B@xmb-aln-x03.cisco.com> In-Reply-To: <50864F3E.5000400@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.210] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19298.000 x-tm-as-result: No--39.726000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3D3D821DB18A5649B984097BF49A42C3@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" Subject: Re: [netext] I-D Action: draft-ietf-netext-pd-pmip-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 15:31:15 -0000 Hi Alex, Thanks for reviewing the spec and appreciate your comments. Please see inline. On 10/23/12 1:03 AM, "Alexandru Petrescu" wrote: >Hi, > >I noticed the addition of a new option to PBU: Delegated Mobile Network >Prefix Option. > >Arguably a new option in PBU may make sense if the existing RFC5213 Home >Network Prefix Option can not be reused to communicate this 'delegated' >prefix. HNP option is intended for MN-MAG link and while we need a prefix for delegation. Also quite a bit of LMA/MAG logic is tied to the existing HNP option. By separating the two we thought it will avoid any ambiguity and will easier for implementors to build this. > >But it has a GRE key in it... should we all implement it (even if set to >0)? If its set to 0, you can ignore it. Generally not needed when overlapping IP is not in use. > >Could the DMNP option be present in PBU and the HNP option absent? Yes. The HNP option is for the MR-MAG link. The prefix is hosted on that link. MR can continue to obtain IPv6 addresses from the HNP prefixes hosted by the MAG and it can obtain delegated prefixes from the DMNP option. > >Also I notice the addition of IPv4 (DMNP can be IPv4 or IPv6). Is there >a particular form of IPv4-in-IPv6 encapsulation that is preferred? Any standard encapsulation. GRE-IPv4, GRE-IPv6, IPv4-IPv4, IPv4-IPv6. Standard modes that we support in RFC5213 and RFC5844. This is a good comment. We will add few lines on the encapsulation modes. Regards Sri > On 10/23/12 1:03 AM, "Alexandru Petrescu" wrote: >Hi, > >I noticed the addition of a new option to PBU: Delegated Mobile Network >Prefix Option. > >Arguably a new option in PBU may make sense if the existing RFC5213 Home >Network Prefix Option can not be reused to communicate this 'delegated' >prefix. > >But it has a GRE key in it... should we all implement it (even if set to >0)? > >Could the DMNP option be present in PBU and the HNP option absent? > >Also I notice the addition of IPv4 (DMNP can be IPv4 or IPv6). Is there >a particular form of IPv4-in-IPv6 encapsulation that is preferred? > >Alex > >Le 23/10/2012 01:13, internet-drafts@ietf.org a =E9crit : >> >> 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 : Prefix Delegation for Proxy Mobile IPv6 Author(s) >> : Xingyue Zhou Jouni Korhonen Carl Williams Sri Gundavelli Carlos J. >> Bernardos Filename : draft-ietf-netext-pd-pmip-05.txt Pages >> : 19 Date : 2012-10-22 >> >> Abstract: Proxy Mobile IPv6 enables IP mobility for a host without >> requiring its participation in any mobility signaling, being the >> network responsible for managing IP mobility on behalf of the host. >> However, Proxy Mobile IPv6 does not support assigning a prefix to a >> router and managing its IP mobility. This document specifies an >> extension to Proxy Mobile IPv6 protocol for supporting network >> mobility using DHCPv6-based Prefix Delegation. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-netext-pd-pmip >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-netext-pd-pmip-05 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-pd-pmip-05 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ I-D-Announce mailing >> list I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft >> directories: http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> > > >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext From bpatil1@gmail.com Tue Oct 23 16:05:25 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3211F0CB3 for ; Tue, 23 Oct 2012 16:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 XZi-4jdBVWJT for ; Tue, 23 Oct 2012 16:05:24 -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 76FD31F0C96 for ; Tue, 23 Oct 2012 16:05:24 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so7150020iec.31 for ; Tue, 23 Oct 2012 16:05:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=WO6zOYzStRoCd+mp+1O9QNWlR7Ksv5TjHoUHK4PncLU=; b=OOvwlW9azDEdOfBd2NDu0ru0tx6yObMhtjB5v/HAawgHiw+8CTszMlIhCI23f/jwtS fm4jMXZhmLTmVB/VA+sv03G60a+Bbe+PYl/XQOufvQJNJAxveTLgurATHYd5tLu+gw+g JUWCM6yNQJ5CK1tr8gy3pmmZFpeUujzaAdDd66jbDPu3Q9ofjovKH8eHZCYVtiG88gi1 I4+6BDdpLOPB7ev02+TQIj4xcx40sThAR2UNPPUCHXsjshKlBIDGJnQR+kzhtJAGHewC LDN9y2sAgOfWoI+jn6oJaQdpKtkec35xr/0W7bFNtkixFXbn40y2c/UpcUB6PLityDcW IGOw== MIME-Version: 1.0 Received: by 10.50.13.138 with SMTP id h10mr651451igc.55.1351033519803; Tue, 23 Oct 2012 16:05:19 -0700 (PDT) Received: by 10.42.212.76 with HTTP; Tue, 23 Oct 2012 16:05:19 -0700 (PDT) Date: Tue, 23 Oct 2012 18:05:19 -0500 Message-ID: From: Basavaraj Patil To: netext@ietf.org Content-Type: multipart/alternative; boundary=f46d044468e3070f1304ccc2018e Subject: [netext] Draft agenda of the WG meeting at IETF85 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 23:05:25 -0000 --f46d044468e3070f1304ccc2018e Content-Type: text/plain; charset=ISO-8859-1 Please find below the draft agenda. If I have missed any requests for a timeslot, please do send me a note. -Raj Rev: 0 Network-Based Mobility Extensions (NetExt) WG meeting Monday, November 5th, 2012 1520-1720 Afternoon Session II (Salon B) ----------------------------------------------------------------- 1. Logistics (Bluesheets, minutes takers, jabber, agenda bashing) 5 mins 2. WG Status update Chairs 5 Mins 3. Proxy Mobile IPv6 Extensions to Support Flow Mobility 10 Mins I-D: draft-ietf-netext-pmipv6-flowmob CJ Bernardos 4. Prefix Delegation for Proxy Mobile IPv6 5 Mins I-D: draft-ietf-netext-pd-pmip Carl Williams 5. Quality of Service Option for Proxy Mobile IPv6 15 Mins I-D:draft-ietf-netext-pmip6-qos M. Liebsch 6. Network Mobility Support using Mobile MAG in PMIP6 domain 20 Mins I-D: draft-sijeon-netext-mmag-pmip-00.txt Seil Jeon 7. MN Status Option for Proxy Mobile IPv6 10 Mins I-D: draft-tu-netext-mn-status-option-02 Carl Williams 8. Mapping PMIP Quality of Service in WiFi Network 10 Mins I-D: draft-kaippallimalil-netext-pmip-qos-wifi-01 J. Kaipallimalli 9. Summary and Next Steps 5 Mins Chairs --f46d044468e3070f1304ccc2018e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Please find below the draft agenda. If I have missed any req= uests for a timeslot, please do send me a note.

-Raj

Rev: 0

Network-Based Mo= bility Extensions (NetExt) WG meeting

Monday, November 5th, 2012
1520-1720 Afternoo= n Session II (Salon B)

---------------------------= --------------------------------------

1. Logistic= s (Bluesheets, minutes takers, jabber, agenda bashing) 5 mins

2. WG Status update =A0Chairs =A0 =A05 Mins

3. Pro= xy Mobile IPv6 Extensions to Support Flow Mobility =A010 Mins
=A0 =A0I-D: draft-ietf-netext-pmipv6-flowmob =A0CJ Bernardos

4. Prefix Delegation for Proxy Mobile IPv6 =A05 Mins
=A0 =A0I-D: draft-ietf-netext-pd-pmip =A0Carl Williams

5. Quality of Service Option for Proxy Mobile IPv6 =A015 Mins
=A0 =A0I-D:draft-ietf-netext-pmip6-qos =A0 =A0 =A0 =A0 =A0 =A0M. Liebsch

<= /div>
6. Network Mobility Support using Mobile MAG in PMIP6 domain =A0 = 20 Mins
=A0 =A0I-D: draft-sijeon-netext-mmag-pmip-00.txt =A0 =A0 =A0 =A0 =A0 =A0Seil Jeo= n

7. MN Status Option for Proxy Mobile IPv6 =A010 Mins
=A0 =A0I-D: draft-tu-netext-mn-status-option-02 =A0Carl Williams

=
8. Mapping PMIP Quality of Service in WiFi Network =A010 Mins
=A0 =A0I-D: draft-kaippallimalil-netext-pmip-qos-wifi-01 =A0 =A0 J. Ka= ipallimalli

9. Summary and Next Steps 5 Mins Chairs

--f46d044468e3070f1304ccc2018e-- From sgundave@cisco.com Tue Oct 23 16:28:15 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9959A11E810B for ; Tue, 23 Oct 2012 16:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.765 X-Spam-Level: X-Spam-Status: No, score=-9.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_HTML_USL_OBFU=1.666] 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 tZSOqiJ75aO0 for ; Tue, 23 Oct 2012 16:28:15 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D0F5611E8106 for ; Tue, 23 Oct 2012 16:28:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6696; q=dns/txt; s=iport; t=1351034894; x=1352244494; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=2nT7BhAFgq1LjATgTGLmPProOSpoMcZ8K96g41374Pc=; b=HiThEy1Qs5KkLZ1xN6HMJakcchDWckBQjZ5W8xSrWT5cNpoDuJtQb0dU 6ar/71fcBEfBQNtMLzhCx2oFM/zDb89WlOV04h24fUuFd9cXmQZtVeB51 gI53oLpVhJvYQlFoD7nmwlU2y6M0B0xQwBRcMQBZ+KuoZblOtvfpO+gUc I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFwnh1CtJXHB/2dsb2JhbABEgkq/NYEIgh4BAQEEEgF4AQgOAwMBAgsdKBEUCQgCBAESCBqHUAMPmxuPXIZHDYlUinlnhX5gA5QdjH6DJYFrgm+CGA X-IronPort-AV: E=Sophos;i="4.80,637,1344211200"; d="scan'208,217";a="134719134" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 23 Oct 2012 23:28:14 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9NNSEtW015073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Oct 2012 23:28:14 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 18:28:14 -0500 From: "Sri Gundavelli (sgundave)" To: Basavaraj Patil , "netext@ietf.org" Thread-Topic: [netext] Draft agenda of the WG meeting at IETF85 Thread-Index: AQHNsXYSZ+uMccjr7kWokjCY6w6sIQ== Date: Tue, 23 Oct 2012 23:28:13 +0000 Message-ID: <24C0F3E22276D9438D6F366EB89FAEA80F564519@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.210] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19298.000 x-tm-as-result: No--29.987600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_24C0F3E22276D9438D6F366EB89FAEA80F564519xmbalnx03ciscoc_" MIME-Version: 1.0 Subject: Re: [netext] Draft agenda of the WG meeting at IETF85 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 23:28:15 -0000 --_000_24C0F3E22276D9438D6F366EB89FAEA80F564519xmbalnx03ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Raj: + A presentation slot on the Logical Interface document. We need to close t= hat work. Telemaco/myself can present the current status, expected changes = and the next steps before we close that work=85 Regards Sri From: Basavaraj Patil > Date: Tuesday, October 23, 2012 4:05 PM To: "netext@ietf.org" > Subject: [netext] Draft agenda of the WG meeting at IETF85 Please find below the draft agenda. If I have missed any requests for a tim= eslot, please do send me a note. -Raj Rev: 0 Network-Based Mobility Extensions (NetExt) WG meeting Monday, November 5th, 2012 1520-1720 Afternoon Session II (Salon B) ----------------------------------------------------------------- 1. Logistics (Bluesheets, minutes takers, jabber, agenda bashing) 5 mins 2. WG Status update Chairs 5 Mins 3. Proxy Mobile IPv6 Extensions to Support Flow Mobility 10 Mins I-D: draft-ietf-netext-pmipv6-flowmob CJ Bernardos 4. Prefix Delegation for Proxy Mobile IPv6 5 Mins I-D: draft-ietf-netext-pd-pmip Carl Williams 5. Quality of Service Option for Proxy Mobile IPv6 15 Mins I-D:draft-ietf-netext-pmip6-qos M. Liebsch 6. Network Mobility Support using Mobile MAG in PMIP6 domain 20 Mins I-D: draft-sijeon-netext-mmag-pmip-00.txt Seil Jeon 7. MN Status Option for Proxy Mobile IPv6 10 Mins I-D: draft-tu-netext-mn-status-option-02 Carl Williams 8. Mapping PMIP Quality of Service in WiFi Network 10 Mins I-D: draft-kaippallimalil-netext-pmip-qos-wifi-01 J. Kaipallimalli 9. Summary and Next Steps5 Mins Chairs --_000_24C0F3E22276D9438D6F366EB89FAEA80F564519xmbalnx03ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Raj:

+ A presentation slot on the Logical Interface document. We need t= o close that work. Telemaco/myself can present the current status, expected= changes and the next steps before we close that work=85



Regards
Sri



From: Basavaraj Patil <bpatil1@gmail.com>
Date: Tuesday, October 23, 2012 4:0= 5 PM
To: "netext@ietf.org" <= netext@ietf.org>
Subject: [netext] Draft agenda of t= he WG meeting at IETF85


Please find below the draft agenda. If I have missed any requests for a tim= eslot, please do send me a note.

-Raj

Rev: 0

Network-Based Mobility Extensions (NetExt) WG meeting

Monday, November 5th, 2012
1520-1720 Afternoon Session II (Salon B)

-----------------------------------------------------------------

1. Logistics (Bluesheets, minutes takers, jabber, agenda bashing) 5 mi= ns

2. WG Status update  Chairs    5 Mins

3. Proxy Mobile IPv6 Extensions to Support Flow Mobility  10 Mins=
   I-D: draft-ietf-netext-pmipv6-flowmob CJ Bernardos

4. Prefix Delegation for Proxy Mobile IPv6 5 Mins
   I-D: draft-ietf-netext-pd-pmip Carl Williams

5. Quality of Service Option for Proxy Mobile IPv6 15 Mins
   I-D:draft-ietf-netext-pmip6-qos            M. Liebsch

6. Network Mobility Support using Mobile MAG in PMIP6 domain   20= Mins
   I-D: draft-sijeon-netext-mmag-pmip-00.txt       =    Seil Jeon

7. MN Status Option for Proxy Mobile IPv6 10 Mins
   I-D: draft-tu-netext-mn-status-option-02 Carl Williams

8. Mapping PMIP Quality of Service in WiFi Network 10 Mins
   I-D: draft-kaippallimalil-netext-pmip-qos-wifi-01   =   J. Kaipallimalli

9. Summary and Next Steps5 Mins Chairs

--_000_24C0F3E22276D9438D6F366EB89FAEA80F564519xmbalnx03ciscoc_-- From bpatil1@gmail.com Tue Oct 23 17:24:28 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8305311E80D7 for ; Tue, 23 Oct 2012 17:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.679 X-Spam-Level: X-Spam-Status: No, score=-2.679 tagged_above=-999 required=5 tests=[AWL=-0.747, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 IeTOeVCIGlos for ; Tue, 23 Oct 2012 17:24:28 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D133511E8118 for ; Tue, 23 Oct 2012 17:24:27 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so4015715iad.31 for ; Tue, 23 Oct 2012 17:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OU1Ah81ATyDXjb1n9px62l7mtLc5t47YUcEcEgydpXw=; b=ux/xbbX6AhcIeS4Cd9EP4t4/ztj4Rn0yX9cSfsq/phPr6pVzTdLGA4SlBMdDJzvZYg pEUIlqhDt6q59Ea07jLCgqbawHwd+alrAXz0ntzWHuMggRR+12GJQ7IgCNHBycqfRj6u UKY5V2WGMYC9zIf17/5KLWfb2pEdHHAqgr376siefJvihFkyMPEK6FToemYfJIFjroyB 3TfWguadZoO67ScmoEqmqdD+/ulLchljJmPL0Wc3Osd8wDarxBeZl6lkRWRqaTblr3Sh d5ffyue1CW1WrZjZAGfKyJvLY2YPEAFElgjLN2chzULjRawGVj4MyDipK3VBnfeFRkUP tq/A== MIME-Version: 1.0 Received: by 10.50.190.137 with SMTP id gq9mr890863igc.27.1351038267234; Tue, 23 Oct 2012 17:24:27 -0700 (PDT) Received: by 10.42.212.76 with HTTP; Tue, 23 Oct 2012 17:24:27 -0700 (PDT) In-Reply-To: <24C0F3E22276D9438D6F366EB89FAEA80F564519@xmb-aln-x03.cisco.com> References: <24C0F3E22276D9438D6F366EB89FAEA80F564519@xmb-aln-x03.cisco.com> Date: Tue, 23 Oct 2012 19:24:27 -0500 Message-ID: From: Basavaraj Patil To: "Sri Gundavelli (sgundave)" Content-Type: multipart/alternative; boundary=f46d04478493ff183e04ccc31b6b Cc: "netext@ietf.org" Subject: Re: [netext] Draft agenda of the WG meeting at IETF85 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 00:24:28 -0000 --f46d04478493ff183e04ccc31b6b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Okay... I will add you to the agenda. I am also trying to connect with Julien and see if he will be able to contribute to this I-D. -Raj On Tue, Oct 23, 2012 at 6:28 PM, Sri Gundavelli (sgundave) < sgundave@cisco.com> wrote: > Raj: > > + A presentation slot on the Logical Interface document. We need to > close that work. Telemaco/myself can present the current status, expected > changes and the next steps before we close that work=85 > > > > Regards > Sri > > > > From: Basavaraj Patil > Date: Tuesday, October 23, 2012 4:05 PM > To: "netext@ietf.org" > Subject: [netext] Draft agenda of the WG meeting at IETF85 > > > Please find below the draft agenda. If I have missed any requests for a > timeslot, please do send me a note. > > -Raj > > Rev: 0 > > Network-Based Mobility Extensions (NetExt) WG meeting > > Monday, November 5th, 2012 > 1520-1720 Afternoon Session II (Salon B) > > ----------------------------------------------------------------- > > 1. Logistics (Bluesheets, minutes takers, jabber, agenda bashing) 5 mins > > 2. WG Status update Chairs 5 Mins > > 3. Proxy Mobile IPv6 Extensions to Support Flow Mobility 10 Mins > I-D: draft-ietf-netext-pmipv6-flowmob CJ Bernardos > > 4. Prefix Delegation for Proxy Mobile IPv6 5 Mins > I-D: draft-ietf-netext-pd-pmip Carl Williams > > 5. Quality of Service Option for Proxy Mobile IPv6 15 Mins > I-D:draft-ietf-netext-pmip6-qos M. Liebsch > > 6. Network Mobility Support using Mobile MAG in PMIP6 domain 20 Mins > I-D: draft-sijeon-netext-mmag-pmip-00.txt Seil Jeon > > 7. MN Status Option for Proxy Mobile IPv6 10 Mins > I-D: draft-tu-netext-mn-status-option-02 Carl Williams > > 8. Mapping PMIP Quality of Service in WiFi Network 10 Mins > I-D: draft-kaippallimalil-netext-pmip-qos-wifi-01 J. Kaipallimalli > > 9. Summary and Next Steps5 Mins Chairs > > --=20 Basavaraj Patil --f46d04478493ff183e04ccc31b6b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Okay... I will add you to the agenda. I am also trying to co= nnect with Julien and see if he will be able to contribute to this I-D.
-Raj

On Tue, Oct 23, 2012= at 6:28 PM, Sri Gundavelli (sgundave) <sgundave@cisco.com>= wrote:
Raj:

+ A presentation slot on the Logical Interface document. We need to cl= ose that work. Telemaco/myself can present the current status, expected cha= nges and the next steps before we close that work=85



Regards
Sri



From: Basavaraj Patil <bpatil1@gmail.com> Date: Tuesday, October 23, 2012 4:0= 5 PM
To: "netext@ietf.org" <netext@ietf.org>
Subject: [netext] Draft agenda of t= he WG meeting at IETF85


Please find below the draft agenda. If I have missed any requests for a tim= eslot, please do send me a note.

-Raj

Rev: 0

Network-Based Mobility Extensions (NetExt) WG meeting

Monday, November 5th, 2012
1520-1720 Afternoon Session II (Salon B)

-----------------------------------------------------------------

1. Logistics (Bluesheets, minutes takers, jabber, agenda bashing) 5 mi= ns

2. WG Status update =A0Chairs =A0 =A05 Mins

3. Proxy Mobile IPv6 Extensions to Support Flow Mobility =A010 Mins
=A0 =A0I-D: draft-ietf-netext-pmipv6-flowmob=A0CJ Bernardos

4. Prefix Delegation for Proxy Mobile IPv6=A05 Mins
=A0 =A0I-D: draft-ietf-netext-pd-pmip=A0Carl Williams

5. Quality of Service Option for Proxy Mobile IPv6=A015 Mins
=A0 =A0I-D:draft-ietf-netext-pmip6-qos =A0 =A0 =A0 =A0 =A0 =A0M. Liebsc= h

6. Network Mobility Support using Mobile MAG in PMIP6 domain =A0 20 Mi= ns
=A0 =A0I-D: draft-sijeon-netext-mmag-pmip-00.txt =A0=A0 =A0 =A0 =A0 =A0Seil Jeon

7. MN Status Option for Proxy Mobile IPv6=A010 Mins
=A0 =A0I-D: draft-tu-netext-mn-status-option-02=A0Carl Williams

8. Mapping PMIP Quality of Service in WiFi Network=A010 Mins
=A0 =A0I-D: draft-kaippallimalil-netext-pmip-qos-wifi-01 =A0 =A0 J. Ka= ipallimalli

9. Summary and Next Steps5= Mins Chairs




--
Basavaraj Pa= til
--f46d04478493ff183e04ccc31b6b-- From sgundave@cisco.com Tue Oct 23 17:56:19 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8801F0CBB for ; Tue, 23 Oct 2012 17:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.932 X-Spam-Level: X-Spam-Status: No, score=-8.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_HTML_USL_OBFU=1.666] 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 iKMru564ysVD for ; Tue, 23 Oct 2012 17:56:18 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id A43441F0C3A for ; Tue, 23 Oct 2012 17:56:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9058; q=dns/txt; s=iport; t=1351040178; x=1352249778; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=9NQLiUFgQS1783mYCqD/7TKHZ9UmQf0of4Ch8DLycSw=; b=RNfC3qOMH3Y2I0Meaa93joDVtPZXSdpCOcBAqXMYpnfqnh8E+H3nxmdG PRsAs0og48aR1tFfUXuvgqAiJcLOFup+qk9aa/5b6hkGvoTb0hMqCor9q Ast79w2gozeeF0DPKoyfabzoCexUydxwCMV1Qk0RZd4cl//++2xLydXEf Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPU7h1CtJXG8/2dsb2JhbABEgkq/OIEIgh4BAQEEEgFmEgEIDgMDAQILHSgRFAkIAgQOBQgah1ADD5sVkWyEMg2JVIp5Z4V+YAOUHYx+gyWBa4JiDYIY X-IronPort-AV: E=Sophos;i="4.80,638,1344211200"; d="scan'208,217";a="134480965" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 24 Oct 2012 00:56:18 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9O0uIFh008903 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Oct 2012 00:56:18 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 19:56:17 -0500 From: "Sri Gundavelli (sgundave)" To: Basavaraj Patil Thread-Topic: [netext] Draft agenda of the WG meeting at IETF85 Thread-Index: AQHNsYJfZ+uMccjr7kWokjCY6w6sIQ== Date: Wed, 24 Oct 2012 00:56:16 +0000 Message-ID: <24C0F3E22276D9438D6F366EB89FAEA80F564874@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.210] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19298.000 x-tm-as-result: No--45.231900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_24C0F3E22276D9438D6F366EB89FAEA80F564874xmbalnx03ciscoc_" MIME-Version: 1.0 Cc: "netext@ietf.org" Subject: Re: [netext] Draft agenda of the WG meeting at IETF85 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 00:56:19 -0000 --_000_24C0F3E22276D9438D6F366EB89FAEA80F564874xmbalnx03ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks. Yes =96 Julien is working on the text update. Sri From: Basavaraj Patil > Date: Tuesday, October 23, 2012 5:24 PM To: Sri Gundavelli > Cc: "netext@ietf.org" > Subject: Re: [netext] Draft agenda of the WG meeting at IETF85 Okay... I will add you to the agenda. I am also trying to connect with Juli= en and see if he will be able to contribute to this I-D. -Raj On Tue, Oct 23, 2012 at 6:28 PM, Sri Gundavelli (sgundave) > wrote: Raj: + A presentation slot on the Logical Interface document. We need to close t= hat work. Telemaco/myself can present the current status, expected changes = and the next steps before we close that work=85 Regards Sri From: Basavaraj Patil > Date: Tuesday, October 23, 2012 4:05 PM To: "netext@ietf.org" > Subject: [netext] Draft agenda of the WG meeting at IETF85 Please find below the draft agenda. If I have missed any requests for a tim= eslot, please do send me a note. -Raj Rev: 0 Network-Based Mobility Extensions (NetExt) WG meeting Monday, November 5th, 2012 1520-1720 Afternoon Session II (Salon B) ----------------------------------------------------------------- 1. Logistics (Bluesheets, minutes takers, jabber, agenda bashing) 5 mins 2. WG Status update Chairs 5 Mins 3. Proxy Mobile IPv6 Extensions to Support Flow Mobility 10 Mins I-D: draft-ietf-netext-pmipv6-flowmob CJ Bernardos 4. Prefix Delegation for Proxy Mobile IPv6 5 Mins I-D: draft-ietf-netext-pd-pmip Carl Williams 5. Quality of Service Option for Proxy Mobile IPv6 15 Mins I-D:draft-ietf-netext-pmip6-qos M. Liebsch 6. Network Mobility Support using Mobile MAG in PMIP6 domain 20 Mins I-D: draft-sijeon-netext-mmag-pmip-00.txt Seil Jeon 7. MN Status Option for Proxy Mobile IPv6 10 Mins I-D: draft-tu-netext-mn-status-option-02 Carl Williams 8. Mapping PMIP Quality of Service in WiFi Network 10 Mins I-D: draft-kaippallimalil-netext-pmip-qos-wifi-01 J. Kaipallimalli 9. Summary and Next Steps5 MinsChairs -- Basavaraj Patil --_000_24C0F3E22276D9438D6F366EB89FAEA80F564874xmbalnx03ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Thanks. Yes =96 Julien is working on the text update.

Sri



From: Basavaraj Patil <bpatil1@gmail.com>
Date: Tuesday, October 23, 2012 5:2= 4 PM
To: Sri Gundavelli <sgundave@cisco.com>
Cc: "netext@ietf.org" <= netext@ietf.org>
Subject: Re: [netext] Draft agenda = of the WG meeting at IETF85


Okay... I will add you to the agenda. I am also trying to connect with Juli= en and see if he will be able to contribute to this I-D.

-Raj

On Tue, Oct 23, 2012 at 6:28 PM, Sri Gundavelli = (sgundave) <sgundave@cisco.com> wrote:
Raj:

+ A presentation slot on the Logical Interface document. We need t= o close that work. Telemaco/myself can present the current status, expected= changes and the next steps before we close that work=85



Regards
Sri



From: Basavaraj Patil <bpatil1@gmail.com> Date: Tuesday, October 23, 2012 4:0= 5 PM
To: "netext@ietf.org" <netext@ietf.org>
Subject: [netext] Draft agenda of t= he WG meeting at IETF85


Please find below the draft agenda. If I have missed any requests for a tim= eslot, please do send me a note.

-Raj

Rev: 0

Network-Based Mobility Extensions (NetExt) WG meeting

Monday, November 5th, 2012
1520-1720 Afternoon Session II (Salon B)

-----------------------------------------------------------------

1. Logistics (Bluesheets, minutes takers, jabber, agenda bashing) 5 mi= ns

2. WG Status update  = Chairs   5 Mins

3. Proxy Mobile IPv6 Extensions to Support Flow Mobility  10 Mins=
   I-D: draft-ietf-netext-pmipv6-flowmob CJ Bernardos

4. Prefix Delegation for Proxy Mobile IPv6 5 Mins
   I-D: draft-ietf-netext-pd-pmip Carl Williams

5. Quality of Service Option for Proxy Mobile IPv6 15 Mins
   I-D:draft-ietf-netext-pmip6-qos           M. Liebsch

6. Network Mobility Support using Mobile MAG in PMIP6 domain   20= Mins
   I-D: draft-sijeon-netext-mmag-pmip-00.txt           Seil J= eon

7. MN Status Option for Proxy Mobile IPv6 10 Mins
   I-D: draft-tu-netext-mn-status-option-02 Carl Williams

8. Mapping PMIP Quality of Service in WiFi Network 10 Mins
   I-D: draft-kaippallimalil-netext-pmip-qos-wifi-01   =   J. Kaipallimalli

9. Summary and Next Steps5= MinsChairs




--
Basavaraj Patil
 --_000_24C0F3E22276D9438D6F366EB89FAEA80F564874xmbalnx03ciscoc_-- From bpatil1@gmail.com Thu Oct 25 15:27:34 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B8321F8755 for ; Thu, 25 Oct 2012 15:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 zonBw+x8BGzE for ; Thu, 25 Oct 2012 15:27:33 -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 C4F3521F86EA for ; Thu, 25 Oct 2012 15:27:33 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so3360041iec.31 for ; Thu, 25 Oct 2012 15:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=R2XUwBcXXm0V7vI0Fb7eXYxrDqgjdEFRrJzDjqgd8L8=; b=Yb6in1yeKc713J7/YW3XqHW5EOW788neH1B9bW9OulFdCfBD6c7P4cpfBCdP9cz0fc p7nZG7g0NVS3RXpgOs/P2BIovZI3aEtqz90NR60goBIHXpACDsOGJ4z6QaLJONCyOd4w 5yKMtbCzlossVTmUbxKxi6U2xv645jHe1V/Wv2+nbRm1tw6WhL5SFHeBWrs/L557ryGE 3Kg74Y0TL/uzTnwxU+M9uceIGwwV3wucxbViy/ryZXPyopDTjZ54T/ygP+CHi2u4vYVr rpDCxmSypmHMSfwMM7yeLSF7Rb6u0X1WgqN+okrDY69JPL83ezmreTDXKzoIAPQRjjg9 saqA== MIME-Version: 1.0 Received: by 10.50.13.138 with SMTP id h10mr182063igc.55.1351204053460; Thu, 25 Oct 2012 15:27:33 -0700 (PDT) Received: by 10.42.212.76 with HTTP; Thu, 25 Oct 2012 15:27:33 -0700 (PDT) Date: Thu, 25 Oct 2012 17:27:33 -0500 Message-ID: From: Basavaraj Patil To: netext@ietf.org Content-Type: multipart/alternative; boundary=f46d044468e3a024a504cce9b599 Subject: [netext] Updated agenda 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, 25 Oct 2012 22:27:34 -0000 --f46d044468e3a024a504cce9b599 Content-Type: text/plain; charset=ISO-8859-1 Rev 1 of the agenda has been posted. Please see: http://www.ietf.org/proceedings/85/agenda/agenda-85-netext -Chairs --f46d044468e3a024a504cce9b599 Content-Type: text/html; charset=ISO-8859-1

Rev 1 of the agenda has been posted. Please see:

-Chairs

--f46d044468e3a024a504cce9b599--