From jari.arkko@piuha.net Wed May 5 16:30:41 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 159F13A6A9A for ; Wed, 5 May 2010 16:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.48 X-Spam-Level: X-Spam-Status: No, score=-0.48 tagged_above=-999 required=5 tests=[AWL=-0.481, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDe0VQpG+Beu for ; Wed, 5 May 2010 16:30:40 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 6C9A03A6A8E for ; Wed, 5 May 2010 16:30:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C4BE82CEB5 for ; Thu, 6 May 2010 02:30:17 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQOuB32G8ZH0 for ; Thu, 6 May 2010 02:30:17 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id CA9A12CCCF for ; Thu, 6 May 2010 02:30:16 +0300 (EEST) Message-ID: <4BE1FF88.8020108@piuha.net> Date: Thu, 06 May 2010 01:30:16 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "netext@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netext] liaison X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for 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, 05 May 2010 23:30:41 -0000 I have reviewed the situation with the liaison statement again today. I realize that there has been controversy about sending this liaison message. The consensus behind sending it is rough at best. In retrospect we could have managed the process much better and I take the blame for that. I have discussed the issue with the chairs and if there are similar situations in the future we will take the discussion from a problem (this seems to be unclear) to a solution (we could send this text). However, after considering the arguments I have decided to send the liaison statement forward, though with edits. I made this decision based on two principles. The first principle is that we should always be able to describe factual state of affairs as well as we can. The goals, constraints and schedule plans of our working groups could change in the future, but their current status is a fact. The second principle is that we should rather err on the side of sending more information than too little. In particular the bar for sending information about the current plans of a WG to someone who might use the results is really low. We have and continue to use many different channels to convey this information, including liaison statements, coordination calls, and joint participation. However, based on the above and arguments from the list discussion I decided to include a statement about the full scope being described in the charter page. The charters are our best description of our plans and should represent both the positive (we will soon have some new technology) and negative aspects (it is limited in this manner). I hope this represents a reasonable compromise, and that the working group can now get to its real work, i.e., actually fulfilling promises from the milestones. Jari To: 3GPP SA2 Subject: Flow mobility feature being specified for Proxy Mobile IPv6 (RFC5213) in the NETEXT WG Dear Balazs, Andy and, Hong, We would like to inform you about the work being done on extending Proxy Mobile IPv6 (RFC5213) to support flow mobility within the NETEXT WG in the IETF. The NETEXT WG charter was revised and approved in February 2010 with this new work. One of the current goals and milestones of the group is: Oct 2010 - Initial WG document(s) on Proxy Mobile IPv6 Extensions to Support Flow Mobility and Inter-access Handovers on a Logical Interface over Multiple Physical Interfaces Full scope of the effort and more details are described in http://www.ietf.org/dyn/wg/charter/netext-charter. Please consider this as an informative update for SA2 on the developments in NETEXT WG in the IETF. Best Regards, IETF NETEXT WG chairs IETF Internet Area Director Rajeev Koodli Jari Arkko Basavaraj Patil From julienl@qualcomm.com Wed May 5 16:55:40 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45C4C3A68EC for ; Wed, 5 May 2010 16:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.326 X-Spam-Level: X-Spam-Status: No, score=-106.326 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXd8TnnwBfl1 for ; Wed, 5 May 2010 16:55:39 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 040483A6868 for ; Wed, 5 May 2010 16:55:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1273103725; x=1304639725; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Jari=20Arkko=20,=20"netext@i etf.org"=20|Date:=20Wed,=205=20May=20201 0=2016:54:42=20-0700|Subject:=20RE:=20[netext]=20liaison |Thread-Topic:=20[netext]=20liaison|Thread-Index:=20Acrsq unUlmBSoPNfR/KCYw9VSfowXQAAQqRA|Message-ID:=20|References:=20<4BE1FF88.8020108@piuha.net> |In-Reply-To:=20<4BE1FF88.8020108@piuha.net> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=h5P9oaRyiz0Qp86LoBvtWRvc8U0+v8dG9iSc8ixdptY=; b=S1vro+SERc5K+dAUnhCs8CKxUGYR+MGGZSaChuBE55k7sRkMlDNQBt5i G1E+afVCfAaFX1A0B7CsGrC7jEY0vPqPaZ3rgcd9fbZEVQQ3M6bFbHS5P 6lG4LuXDbcjC+Esu7zFx0Iti5ptKkSl4pg6HSB0XnXLPE+SMSdnluxmM3 o=; X-IronPort-AV: E=McAfee;i="5400,1158,5973"; a="40516803" Received: from ironmsg01-l.qualcomm.com ([172.30.48.15]) by wolverine01.qualcomm.com with ESMTP; 05 May 2010 16:55:06 -0700 X-IronPort-AV: E=Sophos;i="4.52,335,1270450800"; d="scan'208";a="22581134" Received: from nasanexhub01.na.qualcomm.com ([10.46.93.121]) by ironmsg01-l.qualcomm.com with ESMTP/TLS/RC4-MD5; 05 May 2010 16:55:06 -0700 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.2.234.1; Wed, 5 May 2010 16:54:44 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Wed, 5 May 2010 16:54:45 -0700 From: "Laganier, Julien" To: Jari Arkko , "netext@ietf.org" Date: Wed, 5 May 2010 16:54:42 -0700 Thread-Topic: [netext] liaison Thread-Index: AcrsqunUlmBSoPNfR/KCYw9VSfowXQAAQqRA Message-ID: References: <4BE1FF88.8020108@piuha.net> In-Reply-To: <4BE1FF88.8020108@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netext] liaison X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for 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, 05 May 2010 23:55:40 -0000 Jari, Jari Arkko wrote: >=20 > I have reviewed the situation with the liaison statement again today. >=20 > I realize that there has been controversy about sending this liaison > message. The consensus behind sending it is rough at best. In > retrospect we could have managed the process much better and I take the > blame for that. I have discussed the issue with the chairs and if there > are similar situations in the future we will take the discussion from a > problem (this seems to be unclear) to a solution (we could send this > text). >=20 > However, after considering the arguments I have decided to send the > liaison statement forward, though with edits. I made this decision based > on two principles. The first principle is that we should always be able > to describe factual state of affairs as well as we can. The goals, > constraints and schedule plans of our working groups could change in the > future, but their current status is a fact. The second principle is that > we should rather err on the side of sending more information than too > little. In particular the bar for sending information about the current > plans of a WG to someone who might use the results is really low. We > have and continue to use many different channels to convey this > information, including liaison statements, coordination calls, and > joint participation. >=20 > However, based on the above and arguments from the list discussion I > decided to include a statement about the full scope being described in > the charter page. The charters are our best description of our plans > and should represent both the positive (we will soon have some new > technology) and negative aspects (it is limited in this manner). >=20 > I hope this represents a reasonable compromise, and that the working > group can now get to its real work, i.e., actually fulfilling promises > from the milestones. As you note there are both positive and negative aspects captured in the ch= arter -- IMHO it would be fair and reasonable to include both in any LS we'= re sending out. In this specific case, inserting in the LS the following limitation from ou= t charter would make sense: The work in this charter is entirely internal to the network and does not affect host IP stack operation in any way (except perhaps through impacting packet forwarding capacity visible to the hosts). The working group is not allowed to specify new IP layer protocol mechanisms to signal mobility related events between the host and the network. --julien > To: 3GPP SA2 > Subject: Flow mobility feature being specified for Proxy Mobile IPv6 > (RFC5213) in the NETEXT WG >=20 > Dear Balazs, Andy and, Hong, >=20 > We would like to inform you about the work being done on extending > Proxy > Mobile IPv6 (RFC5213) to support flow mobility within the NETEXT WG in > the IETF. The NETEXT WG charter was revised and approved in February > 2010 with this new work. One of the current goals and milestones of the > group is: >=20 > Oct 2010 - Initial WG document(s) on Proxy Mobile IPv6 Extensions to > Support Flow Mobility and Inter-access Handovers on a Logical Interface > over Multiple Physical Interfaces >=20 > Full scope of the effort and more details are described in > http://www.ietf.org/dyn/wg/charter/netext-charter. >=20 > Please consider this as an informative update for SA2 on the > developments in NETEXT WG in the IETF. >=20 > Best Regards, >=20 > IETF NETEXT WG chairs IETF Internet Area Director > Rajeev Koodli Jari Arkko > Basavaraj Patil > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From junghoon.jee@gmail.com Wed May 5 22:08:51 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12DDD3A681B for ; Wed, 5 May 2010 22:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxoefILpd5cU for ; Wed, 5 May 2010 22:08:51 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id 7AE593A691A for ; Wed, 5 May 2010 22:08:50 -0700 (PDT) Received: by iwn27 with SMTP id 27so7368575iwn.5 for ; Wed, 05 May 2010 22:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Zg4XTuOl9NT8x/oVXexzVQCjTuswEgRQn8sprmoVM50=; b=gfJnMzobF/KIPL5fqVaJNjfOlKXYQz/7A2ihLW2oaG22ZKY1TbSGmeDwcuG8NcL6LD 0DqDlpOakpvafy08xSSuZBIdNrm1rEKUx9EgbLg9vOGXjx1FnqbllE+N6vgwL8DiekUw 9dg/YZo8EvaQMPbI/vrXJfzzzLnGoIyZT/tDQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=FftIVsPenB5udzXOsh4Az8CuMcPkO6WxcatuR1Q5pdGiPevDUnzJ/miT6eFVlV9Pzc W6d4gGoH7aDgdut356SLm2uuLGNRNoEVWROOzKDERFgK6yu9wXSiqUytMPNOvLAm1wgu Vsyi6LAKUOmCpwNl4vgX0jpbqOYAUyr8BSxrg= MIME-Version: 1.0 Received: by 10.231.146.146 with SMTP id h18mr1096595ibv.27.1273122514169; Wed, 05 May 2010 22:08:34 -0700 (PDT) Sender: junghoon.jee@gmail.com Received: by 10.231.208.73 with HTTP; Wed, 5 May 2010 22:08:34 -0700 (PDT) In-Reply-To: References: <4BE1FF88.8020108@piuha.net> Date: Thu, 6 May 2010 14:08:34 +0900 X-Google-Sender-Auth: 43241a3b22b48b47 Message-ID: From: Junghoon Jee To: "Laganier, Julien" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "netext@ietf.org" Subject: Re: [netext] liaison X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for 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, 06 May 2010 05:08:51 -0000 Dear all, I can not find any value to add the proposed statements to the liaison lett= er. I think current content in the liaison letter that Jari sent out is fairly enough. Best Regards, Junghoon On Thu, May 6, 2010 at 8:54 AM, Laganier, Julien wro= te: > > Jari, > > Jari Arkko wrote: >> >> I have reviewed the situation with the liaison statement again today. >> >> I realize that there has been controversy about sending this liaison >> message. The consensus behind sending it is rough at best. =C2=A0In >> retrospect we could have managed the process much better and I take the >> blame for that. I have discussed the issue with the chairs and if there >> are similar situations in the future we will take the discussion from a >> problem (this seems to be unclear) to a solution (we could send this >> text). >> >> However, after considering the arguments I have decided to send the >> liaison statement forward, though with edits. I made this decision based >> on two principles. The first principle is that we should always be able >> to describe factual state of affairs as well as we can. The goals, >> constraints and schedule plans of our working groups could change in the >> future, but their current status is a fact. The second principle is that >> we should rather err on the side of sending more information than too >> little. In particular the bar for sending information about the current >> plans of a WG to someone who might use the results is really low. We >> have and continue to use many different channels to convey this >> information, including liaison statements, coordination calls, and >> joint participation. >> >> However, based on the above and arguments from the list discussion I >> decided to include a statement about the full scope being described in >> the charter page. The charters are our best description of our plans >> and should represent both the positive (we will soon have some new >> technology) and negative aspects (it is limited in this manner). >> >> I hope this represents a reasonable compromise, and that the working >> group can now get to its real work, i.e., actually fulfilling promises >> from the milestones. > > As you note there are both positive and negative aspects captured in the = charter -- IMHO it would be fair and reasonable to include both in any LS w= e're sending out. > > In this specific case, inserting in the LS the following limitation from = out charter would make sense: > > =C2=A0The work in this charter is entirely internal to the network and do= es > =C2=A0not affect host IP stack operation in any way (except perhaps throu= gh > =C2=A0impacting packet forwarding capacity visible to the hosts). The wor= king > =C2=A0group is not allowed to specify new IP layer protocol mechanisms to > =C2=A0signal mobility related events between the host and the network. > > --julien > >> To: 3GPP SA2 >> Subject: =C2=A0Flow mobility feature being specified for Proxy Mobile IP= v6 >> (RFC5213) in the NETEXT WG >> >> Dear Balazs, Andy and, Hong, >> >> We would like to inform you about the work being done on extending >> Proxy >> Mobile IPv6 (RFC5213) to support flow mobility within the NETEXT WG in >> the IETF. The NETEXT =C2=A0WG charter was revised and approved in Februa= ry >> 2010 with this new work. One of the current goals and milestones of the >> group is: >> >> Oct 2010 - Initial WG document(s) on Proxy Mobile IPv6 Extensions to >> Support Flow Mobility and Inter-access Handovers on a Logical Interface >> over Multiple Physical Interfaces >> >> Full scope of the effort and more details are described in >> http://www.ietf.org/dyn/wg/charter/netext-charter. >> >> Please consider this as an informative update for SA2 on the >> developments in NETEXT WG in the IETF. >> >> Best Regards, >> >> IETF NETEXT WG chairs =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 IETF Internet Area Director >> Rajeev Koodli =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Jari Arkko >> Basavaraj Patil >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From ahmad.muhanna@ericsson.com Thu May 6 06:35:13 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81BA828C370 for ; Thu, 6 May 2010 06:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.613 X-Spam-Level: X-Spam-Status: No, score=-1.613 tagged_above=-999 required=5 tests=[AWL=-1.614, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OltqLROzeH3e for ; Thu, 6 May 2010 06:35:12 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 5438C28C10E for ; Thu, 6 May 2010 06:24:55 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o46DOfFB020582 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 May 2010 08:24:41 -0500 Received: from EUSAACMS0714.eamcs.ericsson.se ([169.254.1.162]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 6 May 2010 09:24:41 -0400 From: Ahmad Muhanna To: Jari Arkko , "netext@ietf.org" Date: Thu, 6 May 2010 09:24:40 -0400 Thread-Topic: [netext] liaison Thread-Index: AcrsqvuYNVeq0MmjQieibDdQTPFzAAAdG86g Message-ID: <1FCAE7B6027FE3489B8497A060C704C4261CECA2FF@EUSAACMS0714.eamcs.ericsson.se> References: <4BE1FF88.8020108@piuha.net> In-Reply-To: <4BE1FF88.8020108@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netext] liaison X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for 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, 06 May 2010 13:35:13 -0000 Thanks Jari. The proposed LS looks perfect! Regards, Ahmad > -----Original Message----- > From: netext-bounces@ietf.org=20 > [mailto:netext-bounces@ietf.org] On Behalf Of Jari Arkko > Sent: Wednesday, May 05, 2010 6:30 PM > To: netext@ietf.org > Subject: [netext] liaison >=20 > I have reviewed the situation with the liaison statement again today. >=20 > I realize that there has been controversy about sending this=20 > liaison message. The consensus behind sending it is rough at=20 > best. In retrospect we could have managed the process much=20 > better and I take the blame for that. I have discussed the=20 > issue with the chairs and if there are similar situations in=20 > the future we will take the discussion from a problem (this=20 > seems to be unclear) to a solution (we could send this text). >=20 > However, after considering the arguments I have decided to=20 > send the liaison statement forward, though with edits. I made=20 > this decision based on two principles. The first principle is=20 > that we should always be able to describe factual state of=20 > affairs as well as we can. The goals, constraints and=20 > schedule plans of our working groups could change in the=20 > future, but their current status is a fact. The second=20 > principle is that we should rather err on the side of sending=20 > more information than too little. In particular the bar for=20 > sending information about the current plans of a WG to=20 > someone who might use the results is really low. We have and=20 > continue to use many different channels to convey this=20 > information, including liaison statements, coordination=20 > calls, and joint participation. >=20 > However, based on the above and arguments from the list=20 > discussion I decided to include a statement about the full=20 > scope being described in the charter page. The charters are=20 > our best description of our plans and should represent both=20 > the positive (we will soon have some new > technology) and negative aspects (it is limited in this manner). >=20 > I hope this represents a reasonable compromise, and that the=20 > working group can now get to its real work, i.e., actually=20 > fulfilling promises from the milestones. >=20 > Jari >=20 >=20 > To: 3GPP SA2 > Subject: Flow mobility feature being specified for Proxy Mobile IPv6 > (RFC5213) in the NETEXT WG >=20 > Dear Balazs, Andy and, Hong, >=20 > We would like to inform you about the work being done on=20 > extending Proxy Mobile IPv6 (RFC5213) to support flow=20 > mobility within the NETEXT WG in the IETF. The NETEXT WG=20 > charter was revised and approved in February 2010 with this=20 > new work. One of the current goals and milestones of the group is: >=20 > Oct 2010 - Initial WG document(s) on Proxy Mobile IPv6=20 > Extensions to Support Flow Mobility and Inter-access=20 > Handovers on a Logical Interface over Multiple Physical Interfaces >=20 > Full scope of the effort and more details are described in=20 > http://www.ietf.org/dyn/wg/charter/netext-charter. >=20 > Please consider this as an informative update for SA2 on the=20 > developments in NETEXT WG in the IETF. >=20 > Best Regards, >=20 > IETF NETEXT WG chairs IETF Internet=20 > Area Director > Rajeev Koodli Jari Arkko > Basavaraj Patil > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > = From behcetsarikaya@yahoo.com Thu May 6 07:46:35 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64C9028C20D for ; Thu, 6 May 2010 07:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.171 X-Spam-Level: X-Spam-Status: No, score=0.171 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zas-Si3rsoyn for ; Thu, 6 May 2010 07:46:34 -0700 (PDT) Received: from web111414.mail.gq1.yahoo.com (web111414.mail.gq1.yahoo.com [67.195.15.210]) by core3.amsl.com (Postfix) with SMTP id 541F728C212 for ; Thu, 6 May 2010 07:25:18 -0700 (PDT) Received: (qmail 21414 invoked by uid 60001); 6 May 2010 14:25:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1273155905; bh=B+c8xRIB9uxCMxjM6jxm3hnMKqRK6R1zcb22mQydp80=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Cqhut/Szcn+dm36pChjILpW9l3eXWSJoVkAEY39PoTc0awOBY2Af/MjZajO8KSSKXCWhDTAcRffx0QMMAI8Aschz5fyX6G31XF9LUo49lQNQSp5/Hf45RROmCNhCVH6+3C/G59P01h1bpcw964napchiZk5aCWb9sAR47JnCBQQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=i0o/CL7E0jtny/ozv5bE5NVi7puS3INANQjj3BF8cZs6/xSn3By5X+EQgjEayZPHCbX1kjgg4k91rWaWxsPkyFze6atDTrYkjqQx+CDxjYJVHXYQhq1W44cIY/FPenXq8GNFKoCwtdBTFwNDsvwOG1RAO3KYOBtQ+ASihSdUmLw=; Message-ID: <745028.20511.qm@web111414.mail.gq1.yahoo.com> X-YMail-OSG: q4Z2bpMVM1loES0LMoYaN4Yq.mZPSNjempnAGSXCNCl4Op7 CJycDxAlxa5rl3xTDiG3PnEy_mt0UmBZYI4zLPz4sqHziiXvkdyU9.x3TM53 N1xjx_7QGzFDy2Hkns4Sv0JOf6x4WxYVcluKRneBgTWo3lyoaLV_sqi4tEiw kPFLNf9AZ7XVMBDeuz7btHBS4tBFmxn7UmPXr2kwQMYbYEB_D60efpTjaz.2 NBu9s7h58ZFB3HLWOk1aDEEjfu_kfNnq1QxLz7z1bBY54WNN8eF4OKMo9.hB ErKRYOSd.H2nNoS2rIzwnx.g.64jAZIheqLXHQJtGiyBgLN4vzYnZ7iHxuMx VW3bsFBJLJOg0vMwLoA-- Received: from [206.16.17.212] by web111414.mail.gq1.yahoo.com via HTTP; Thu, 06 May 2010 07:25:05 PDT X-Mailer: YahooMailRC/348.5 YahooMailWebService/0.8.103.269680 References: <4BE1FF88.8020108@piuha.net> <1FCAE7B6027FE3489B8497A060C704C4261CECA2FF@EUSAACMS0714.eamcs.ericsson.se> Date: Thu, 6 May 2010 07:25:05 -0700 (PDT) From: Behcet Sarikaya To: Ahmad Muhanna , Jari Arkko , "netext@ietf.org" In-Reply-To: <1FCAE7B6027FE3489B8497A060C704C4261CECA2FF@EUSAACMS0714.eamcs.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [netext] liaison X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 14:46:35 -0000 +1=0A=0A=0A=A0=0A=0A=0A----- Original Message ----=0A> From: Ahmad Muhanna = =0A> To: Jari Arkko ; "ne= text@ietf.org" =0A> Sent: Thu, May 6, 2010 8:24:40 AM=0A> = Subject: Re: [netext] liaison=0A> =0A> Thanks Jari.=0A=0AThe proposed LS lo= oks =0A> perfect!=0A=0ARegards,=0AAhmad=0A=0A> -----Original Message-----= =0A> =0A> From: > href=3D"mailto:netext-bounces@ietf.org">netext-bounces@ie= tf.org =0A> =0A> [mailto:> href=3D"mailto:netext-bounces@ietf.org">netext-b= ounces@ietf.org] On Behalf Of =0A> Jari Arkko=0A> Sent: Wednesday, May 05, = 2010 6:30 PM=0A> To: > ymailto=3D"mailto:netext@ietf.org" =0A> href=3D"mail= to:netext@ietf.org">netext@ietf.org=0A> Subject: [netext] =0A> liaison=0A> = =0A> I have reviewed the situation with the liaison =0A> statement again to= day.=0A> =0A> I realize that there has been =0A> controversy about sending = this =0A> liaison message. The consensus behind =0A> sending it is rough at= =0A> best.=A0 In retrospect we could have managed =0A> the process much = =0A> better and I take the blame for that. I have discussed =0A> the =0A> i= ssue with the chairs and if there are similar situations in =0A> =0A> the f= uture we will take the discussion from a problem (this =0A> =0A> seems to b= e unclear) to a solution (we could send this text).=0A> =0A> =0A> However, = after considering the arguments I have decided to =0A> send the =0A> liaiso= n statement forward, though with edits. I made =0A> this decision =0A> base= d on two principles. The first principle is =0A> that we should always =0A>= be able to describe factual state of =0A> affairs as well as we can. The = =0A> goals, constraints and =0A> schedule plans of our working groups could= =0A> change in the =0A> future, but their current status is a fact. The se= cond =0A> =0A> principle is that we should rather err on the side of sendin= g =0A> =0A> more information than too little. In particular the bar for =0A= > sending =0A> information about the current plans of a WG to =0A> someone = who might use =0A> the results is really low. We have and =0A> continue to = use many different =0A> channels to convey this =0A> information, including= liaison statements, =0A> coordination =0A> calls, and joint participation.= =0A> =0A> However, =0A> based on the above and arguments from the list =0A>= discussion I decided to =0A> include a statement about the full =0A> scope= being described in the charter =0A> page. The charters are =0A> our best d= escription of our plans and should =0A> represent both =0A> the positive (w= e will soon have some new=0A> =0A> technology) and negative aspects (it is = limited in this manner).=0A> =0A> =0A> I hope this represents a reasonable = compromise, and that the =0A> =0A> working group can now get to its real wo= rk, i.e., actually =0A> fulfilling =0A> promises from the milestones.=0A> = =0A> Jari=0A> =0A> =0A> =0A> To: 3GPP SA2=0A> Subject:=A0 Flow mobility fea= ture being specified for =0A> Proxy Mobile IPv6=0A> (RFC5213) in the NETEXT= WG=0A> =0A> Dear =0A> Balazs, Andy and, Hong,=0A> =0A> We would like to in= form you about the =0A> work being done on =0A> extending Proxy Mobile IPv6= (RFC5213) to support =0A> flow =0A> mobility within the NETEXT WG in the I= ETF. The NETEXT=A0 WG =0A> =0A> charter was revised and approved in Februar= y 2010 with this =0A> =0A> new work. One of the current goals and milestone= s of the group is:=0A> =0A> =0A> Oct 2010 - Initial WG document(s) on Proxy= Mobile IPv6 =0A> =0A> Extensions to Support Flow Mobility and Inter-access= =0A> Handovers on a =0A> Logical Interface over Multiple Physical Interfac= es=0A> =0A> Full scope =0A> of the effort and more details are described in= =0A> =0A> http://www.ietf.org/dyn/wg/charter/netext-charter.=0A> =0A> Plea= se =0A> consider this as an informative update for SA2 on the =0A> developm= ents in =0A> NETEXT WG in the IETF.=0A> =0A> Best Regards,=0A> =0A> IETF = =0A> NETEXT WG chairs=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =0A> =A0 =A0 IETF = Internet =0A> Area Director=0A> Rajeev Koodli=A0 =0A> =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Jari Arkko=0A> Bas= avaraj =0A> Patil=0A> _______________________________________________=0A> n= etext =0A> mailing list=0A> > href=3D"mailto:netext@ietf.org">netext@ietf.o= rg=0A> > href=3D"https://www.ietf.org/mailman/listinfo/netext" target=3D_bl= ank =0A> >https://www.ietf.org/mailman/listinfo/netext=0A> =0A> =0A________= _______________________________________=0Anetext mailing list=0A> ymailto= =3D"mailto:netext@ietf.org" =0A> href=3D"mailto:netext@ietf.org">netext@iet= f.org=0A> href=3D"https://www.ietf.org/mailman/listinfo/netext" target=3D_b= lank =0A> >https://www.ietf.org/mailman/listinfo/netext=0A=0A=0A From jxyswallow@gmail.com Fri May 7 00:21:34 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 427113A695A for ; Fri, 7 May 2010 00:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.091 X-Spam-Level: X-Spam-Status: No, score=-1.091 tagged_above=-999 required=5 tests=[AWL=-0.907, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2vQa358Dbd1 for ; Fri, 7 May 2010 00:21:31 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 42E003A6C86 for ; Fri, 7 May 2010 00:20:27 -0700 (PDT) Received: by pxi19 with SMTP id 19so407185pxi.31 for ; Fri, 07 May 2010 00:20:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=i4qijyBcFSTGNoNPrDbAX13NZ7mFvAJqegLKNRq4Hpk=; b=RadPjjhqyuDX+xYSYaresP0aDlcxDFHBUbwPdPPOi84JcC/wP6RrZG+uLnElhoDFcX nNv19YfU96ZzGCldyfmpUojMVvweOe2F+K7cg+BNg3vkOVDfvUjBQ6OAzKkr8xuLWIld TOo99PXxcYDhLVilPhsP9vksu9tHpMVDARhZo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=Au7onlL9hcd1KZ21F/mi1z7IPcFklUFf4mm//JuHi61OPO0gbBKOE0uORYQHEeTHKs i0I96OwXvcTj5xmTOubD5s0O5tL1bbsJAPm2n+SOv8TgvqEN+P5ajlFeYtbu86M1ITjH uMEbSl7+TQFmiPNq9hTFq1i5qoBlTE9X22xLo= MIME-Version: 1.0 Received: by 10.142.119.1 with SMTP id r1mr1236547wfc.80.1273216803789; Fri, 07 May 2010 00:20:03 -0700 (PDT) Received: by 10.142.158.2 with HTTP; Fri, 7 May 2010 00:20:03 -0700 (PDT) Date: Fri, 7 May 2010 15:20:03 +0800 Message-ID: From: Xiaoyan Jiang To: jouni.nospam@gmail.com Content-Type: multipart/alternative; boundary=001636e0b6ba4fda6e0485fbe344 Cc: netext@ietf.org Subject: Re: [netext] Security question on anycast mode of draft-ietf-netext-redirect-01 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 07:21:34 -0000 --001636e0b6ba4fda6e0485fbe344 Content-Type: text/plain; charset=ISO-8859-1 Hi Jouni When there are multiple LMAs in the same PMIP damain, how are the LMAs associated with each other? And, from the MAG's perspective, what' s the difference between the LMAs? Thank you! > o LMAs with multiple IP addresses: a cluster of LMAs or a blade > architecture LMA may appear to the routing system as multiple LMAs > with separate unicast IP addresses. A MAG can initially select > any of those LMA IP addresses as the LMA Address using e.g., DNS- > and AAA-based solutions. However, MAG's initial selection may be > suboptimal from the LMA point of view and immediate redirection to > a "proper LMA" would be needed. The LMA could use [RFC5142] based > approach but that would imply unnecessary setting up of a mobility > session in a "wrong LMA" with associated backend support system > interactions, involve additional signaling between the MAG and the > LMA, and re-establishing mobility session to the new LMA again > with associated signaling. Xiaoyan Jiang --001636e0b6ba4fda6e0485fbe344 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi =A0 Jouni

When there are multiple LMAs in the same PMIP damain, h= ow are the LMAs associated with each other? And, from the MAG's perspec= tive, what' s the difference between the LMAs?

Thank you!
> o=A0 LMAs with multiple IP addresses: a cluster of LMAs or a blade
= >=A0=A0=A0=A0=A0 architecture LMA may appear to the routing system as mu= ltiple LMAs
>=A0=A0=A0=A0 with separate unicast IP addresses.=A0 A MA= G can initially select
>=A0=A0=A0=A0=A0 any of those LMA IP addresses as the LMA Address using = e.g., DNS-
>=A0=A0=A0=A0=A0 and AAA-based solutions.=A0 However, MAG&= #39;s initial selection may be
>=A0=A0=A0=A0=A0 suboptimal from the L= MA point of view and immediate redirection to
>=A0=A0=A0=A0=A0 a "proper LMA" would be needed.=A0 The LMA co= uld use [RFC5142] based
>=A0=A0=A0=A0=A0 approach but that would impl= y unnecessary setting up of a mobility
>=A0=A0=A0=A0=A0 session in a = "wrong LMA" with associated backend support system
>=A0=A0=A0=A0=A0 interactions, involve additional signaling between the = MAG and the
>=A0=A0=A0=A0=A0 LMA, and re-establishing mobility sessio= n to the new LMA again
>=A0=A0=A0=A0=A0 with associated signaling.
Xiaoyan Jiang

--001636e0b6ba4fda6e0485fbe344-- From jouni.nospam@gmail.com Fri May 7 00:33:25 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C02643A6AF2 for ; Fri, 7 May 2010 00:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.206 X-Spam-Level: X-Spam-Status: No, score=-1.206 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXY+FfTKKNqd for ; Fri, 7 May 2010 00:33:25 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id C51783A691C for ; Fri, 7 May 2010 00:33:09 -0700 (PDT) Received: by fxm4 with SMTP id 4so616097fxm.31 for ; Fri, 07 May 2010 00:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=GmZd852m+SWKYkHE6h8B/dIZotGqENVqVHYIVQavgC4=; b=REFAaiKTDmHXwhSfg4C8gVD2McPXHPRp+nGjP6uxRjsX9slQ10x10C451HaLhvWa1h nJrQHl3tTsgevYM5p+0LtWguA5ymGXjOFdrDk34NZIkkf3la2HM4SXjuVuvHjKhd8Mhd Lrt+sd2HX57KmaKzpuLKX4x2Yj+BMFGxF6gTk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=vKNo2MN6WcNm1ddZm0c2AHkNGW7MBW+E7LR70+pHVJNaVmRXFtvSOlwwTma/CkeTBu Eeur33SwZMrZ1XWVB55OJmS0L+L7GM7F4Lwc0KLh8+Rp2KDdW+E4AJOqvAPOtdJ5I98C GNwuWG0WyBXfXCyDMpfyW5U35eYNfm7IXRXZE= Received: by 10.223.22.145 with SMTP id n17mr1008701fab.23.1273217573927; Fri, 07 May 2010 00:32:53 -0700 (PDT) Received: from a88-114-64-208.elisa-laajakaista.fi (a88-114-64-208.elisa-laajakaista.fi [88.114.64.208]) by mx.google.com with ESMTPS id b17sm3532772fka.43.2010.05.07.00.32.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 May 2010 00:32:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Fri, 7 May 2010 10:32:50 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Xiaoyan Jiang X-Mailer: Apple Mail (2.1078) Cc: netext@ietf.org Subject: Re: [netext] Security question on anycast mode of draft-ietf-netext-redirect-01 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 07:33:25 -0000 Hi, On May 7, 2010, at 10:20 AM, Xiaoyan Jiang wrote: > Hi Jouni >=20 > When there are multiple LMAs in the same PMIP damain, how are the LMAs = associated with each other? And, from the MAG's perspective, what' s the = difference between the LMAs? Associated with each other? I don't really understand the question. = Those LMAs are within the same Redirection Domain and under the same = administration. This does not really differentiate from any anycast = deployment.=20 =46rom a MAG point of view, when using anycast addressing, it sees no = difference between LMAs. When runtime assignment takes place, the MAG = learns the individual LMA that was picked up. The MAG will eventually = have a separate SA with each individual LMA (either dynamically or = manually established). - Jouni >=20 > Thank you! >=20 > > o LMAs with multiple IP addresses: a cluster of LMAs or a blade > > architecture LMA may appear to the routing system as multiple = LMAs > > with separate unicast IP addresses. A MAG can initially select > > any of those LMA IP addresses as the LMA Address using e.g., = DNS- > > and AAA-based solutions. However, MAG's initial selection may = be > > suboptimal from the LMA point of view and immediate redirection = to > > a "proper LMA" would be needed. The LMA could use [RFC5142] = based > > approach but that would imply unnecessary setting up of a = mobility > > session in a "wrong LMA" with associated backend support system > > interactions, involve additional signaling between the MAG and = the > > LMA, and re-establishing mobility session to the new LMA again > > with associated signaling. >=20 > Xiaoyan Jiang >=20 From jxyswallow@gmail.com Fri May 7 00:46:31 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A01C73A6AD3 for ; Fri, 7 May 2010 00:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.637 X-Spam-Level: X-Spam-Status: No, score=-0.637 tagged_above=-999 required=5 tests=[AWL=-0.454, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBH+wDpnHdgH for ; Fri, 7 May 2010 00:46:30 -0700 (PDT) Received: from mail-pz0-f200.google.com (mail-pz0-f200.google.com [209.85.222.200]) by core3.amsl.com (Postfix) with ESMTP id 217343A6927 for ; Fri, 7 May 2010 00:46:24 -0700 (PDT) Received: by pzk38 with SMTP id 38so395983pzk.31 for ; Fri, 07 May 2010 00:46:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=hWdux1dYetVdRQBf5SMGCKNhF3PK5aBlnLirZWus4d0=; b=V9Kxn8L74LIi+2EMxPPx46juguwgDygyN54w1SP4JPonk61Xw0b2vyCeVLMsBqIIbG ZYXN6O4NWHW57uKbgUnudMtbj9JWuFvZcp5QvdSU+mPoceO7WXo7vUANWsAFHl2ryWFI S95+IW+2fDeJoL43fB22X7yVQFchgfogT/8g0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=e6AtAzzHPgFlgXCGDAScaphYQri07ZpxegTaFKj9vXwKRvaDejExtsT7WO5nFopzrs UtEzlyWQY4y4wqThf4sSsKGHTK3s9eWKhikPc/idZXbBrbMgWKXu131L/Z6+fq2g6DQs zq3wR/syTkh219/rBzNIfo/CiZqpP8xAkD1ac= MIME-Version: 1.0 Received: by 10.143.24.24 with SMTP id b24mr2786132wfj.180.1273218369070; Fri, 07 May 2010 00:46:09 -0700 (PDT) Received: by 10.142.158.2 with HTTP; Fri, 7 May 2010 00:46:09 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 May 2010 15:46:09 +0800 Message-ID: From: Xiaoyan Jiang To: jouni korhonen Content-Type: multipart/alternative; boundary=001636e0a6ae9c26210485fc406b Cc: netext@ietf.org Subject: Re: [netext] Security question on anycast mode of draft-ietf-netext-redirect-01 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 07:46:31 -0000 --001636e0a6ae9c26210485fc406b Content-Type: text/plain; charset=ISO-8859-1 2010/5/7 jouni korhonen > Hi, > > On May 7, 2010, at 10:20 AM, Xiaoyan Jiang wrote: > > > Hi Jouni > > > > When there are multiple LMAs in the same PMIP damain, how are the LMAs > associated with each other? And, from the MAG's perspective, what' s the > difference between the LMAs? > > Associated with each other? I don't really understand the question. Those > LMAs are within the same Redirection Domain and under the same > administration. This does not really differentiate from any anycast > deployment. > > Ok, I know, it is like the anycast deployment. > From a MAG point of view, when using anycast addressing, it sees no > difference between LMAs. When runtime assignment takes place, the MAG learns > the individual LMA that was picked up. The MAG will eventually have a > separate SA with each individual LMA (either dynamically or manually > established). > I mean when MAG selects LMA for MN to register, it just considers the load factor or there are other factors, such as the different LMA provides different service? Xiaoyan Jiang > - Jouni > > > > > Thank you! > > > > > o LMAs with multiple IP addresses: a cluster of LMAs or a blade > > > architecture LMA may appear to the routing system as multiple LMAs > > > with separate unicast IP addresses. A MAG can initially select > > > any of those LMA IP addresses as the LMA Address using e.g., DNS- > > > and AAA-based solutions. However, MAG's initial selection may be > > > suboptimal from the LMA point of view and immediate redirection to > > > a "proper LMA" would be needed. The LMA could use [RFC5142] based > > > approach but that would imply unnecessary setting up of a mobility > > > session in a "wrong LMA" with associated backend support system > > > interactions, involve additional signaling between the MAG and the > > > LMA, and re-establishing mobility session to the new LMA again > > > with associated signaling. > > > > Xiaoyan Jiang > > > > --001636e0a6ae9c26210485fc406b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


2010/5/7 jouni korhonen <jouni.nospam@gmail.com<= /a>>
Hi,

On May 7, 2010, at 10:20 AM, Xiaoyan Jiang wrote:

> Hi =A0 Jouni
>
> When there are multiple LMAs in the same PMIP damain, how are the LMAs= associated with each other? And, from the MAG's perspective, what'= s the difference between the LMAs?

Associated with each other? I don't really understand the questio= n. Those LMAs are within the same Redirection Domain and under the same adm= inistration. This does not really differentiate from any anycast deployment= .

Ok, I know, it is like the anycast deployment.
=A0=
>From a MAG point of view, when using anycast addressing, it sees no differe= nce between LMAs. When runtime assignment takes place, the MAG learns the i= ndividual LMA that was picked up. The MAG will eventually have a separate S= A with each individual LMA (either dynamically or manually established).

I mean when MAG selects LMA for MN to register, it ju= st considers the load factor or there are other factors, such as the different LMA provides different service?
=A0
Xiaoyan Jiang


- Jouni

>
> Thank you!
>
> > o =A0LMAs with multiple IP addresses: a cluster of LMAs or a blad= e
> > =A0 =A0 =A0architecture LMA may appear to the routing system as m= ultiple LMAs
> > =A0 =A0 with separate unicast IP addresses. =A0A MAG can initiall= y select
> > =A0 =A0 =A0any of those LMA IP addresses as the LMA Address using= e.g., DNS-
> > =A0 =A0 =A0and AAA-based solutions. =A0However, MAG's initial= selection may be
> > =A0 =A0 =A0suboptimal from the LMA point of view and immediate re= direction to
> > =A0 =A0 =A0a "proper LMA" would be needed. =A0The LMA c= ould use [RFC5142] based
> > =A0 =A0 =A0approach but that would imply unnecessary setting up o= f a mobility
> > =A0 =A0 =A0session in a "wrong LMA" with associated bac= kend support system
> > =A0 =A0 =A0interactions, involve additional signaling between the= MAG and the
> > =A0 =A0 =A0LMA, and re-establishing mobility session to the new L= MA again
> > =A0 =A0 =A0with associated signaling.
>
> Xiaoyan Jiang
>


--001636e0a6ae9c26210485fc406b-- From jouni.nospam@gmail.com Fri May 7 03:19:04 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A62503A6943 for ; Fri, 7 May 2010 03:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.942 X-Spam-Level: X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[AWL=0.657, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ct0XIZk8sT+B for ; Fri, 7 May 2010 03:19:03 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id 992453A69B4 for ; Fri, 7 May 2010 03:18:56 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so525514fgb.13 for ; Fri, 07 May 2010 03:18:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=4YdNYGLA1GkaoHWmOGV65XgO1lkcHeMlWzz73s0RHy4=; b=ew68tJBSKEZYwmUBLG/MR0XbWTX3+R0oYJJvwmm5oAPH+JIJ+BknAiWs1pBGtSHvxg t25B4T6Q/5K68nBRhDr82n8GaA1qiMHS5hqLTjDHYkNazrNFMfZpz//ptVf84Q5BfPj0 n9vPMZG9gJCqxOTfTryvfMD1EfzfnukfviVAY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=p5TAbplwDoJD5IDhF343XFh/CPT7uBZDpowHD22LspWuHj2TeWy7qtreYoskcKuPUE 4Gtk3VqMSalcUDk52LQgVrCuesoVnRbP6BFCmdqiXjnC6AcDjrIU1dJYgGFl9/iwEh9w lLZtcZdwOSA1x7LOg9oby7veCULkY2Bu/jvMQ= Received: by 10.87.63.1 with SMTP id q1mr3338433fgk.38.1273227520831; Fri, 07 May 2010 03:18:40 -0700 (PDT) Received: from a88-114-64-208.elisa-laajakaista.fi (a88-114-64-208.elisa-laajakaista.fi [88.114.64.208]) by mx.google.com with ESMTPS id 26sm3820038fks.52.2010.05.07.03.18.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 May 2010 03:18:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Fri, 7 May 2010 13:18:37 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Xiaoyan Jiang X-Mailer: Apple Mail (2.1078) Cc: netext@ietf.org Subject: Re: [netext] Security question on anycast mode of draft-ietf-netext-redirect-01 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 10:19:05 -0000 Hi, On May 7, 2010, at 10:46 AM, Xiaoyan Jiang wrote: > 2010/5/7 jouni korhonen > Hi, >=20 > On May 7, 2010, at 10:20 AM, Xiaoyan Jiang wrote: >=20 > > Hi Jouni > > > > When there are multiple LMAs in the same PMIP damain, how are the = LMAs associated with each other? And, from the MAG's perspective, what' = s the difference between the LMAs? >=20 > Associated with each other? I don't really understand the question. = Those LMAs are within the same Redirection Domain and under the same = administration. This does not really differentiate from any anycast = deployment. >=20 > Ok, I know, it is like the anycast deployment. > =20 > =46rom a MAG point of view, when using anycast addressing, it sees no = difference between LMAs. When runtime assignment takes place, the MAG = learns the individual LMA that was picked up. The MAG will eventually = have a separate SA with each individual LMA (either dynamically or = manually established). >=20 > I mean when MAG selects LMA for MN to register, it just considers the = load factor or there are other factors, such as the different LMA = provides different service? The MAG does not generally do such decision. The decision which LMA at = the end gets assigned to the MAG (and the MN) takes place in the rfLMA. = The only selection the MAG does is to located a LMA (actually a rfLMA in = runtime LMA assignment scope) based on generic criteria such as provided = services (see discussion around this in = draft-ietf-netlmm-lma-discovery-03). - Jouni > =20 > Xiaoyan Jiang >=20 >=20 > - Jouni >=20 > > > > Thank you! > > > > > o LMAs with multiple IP addresses: a cluster of LMAs or a blade > > > architecture LMA may appear to the routing system as multiple = LMAs > > > with separate unicast IP addresses. A MAG can initially = select > > > any of those LMA IP addresses as the LMA Address using e.g., = DNS- > > > and AAA-based solutions. However, MAG's initial selection = may be > > > suboptimal from the LMA point of view and immediate = redirection to > > > a "proper LMA" would be needed. The LMA could use [RFC5142] = based > > > approach but that would imply unnecessary setting up of a = mobility > > > session in a "wrong LMA" with associated backend support = system > > > interactions, involve additional signaling between the MAG = and the > > > LMA, and re-establishing mobility session to the new LMA = again > > > with associated signaling. > > > > Xiaoyan Jiang > > >=20 >=20 From Telemaco.Melia@alcatel-lucent.com Wed May 12 06:09:17 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AC8B28C161 for ; Wed, 12 May 2010 06:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+oWb5t+0g+B for ; Wed, 12 May 2010 06:09:16 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 4342E28C156 for ; Wed, 12 May 2010 06:06:11 -0700 (PDT) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o4CD5oma006146; Wed, 12 May 2010 15:05:58 +0200 Received: from FRVELSMBS14.ad2.ad.alcatel.com ([155.132.6.32]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 May 2010 15:05:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 May 2010 15:05:57 +0200 Message-ID: <853DD750D9C3724FBF2DF7164FCF641C0451E086@FRVELSMBS14.ad2.ad.alcatel.com> In-Reply-To: <4BE1FF88.8020108@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] liaison Thread-Index: AcrsqvVJFdj8oaMcRr2usQF8Yj40RAFKMJfg References: <4BE1FF88.8020108@piuha.net> From: "MELIA TELEMACO" To: "Jari Arkko" , X-OriginalArrivalTime: 12 May 2010 13:05:57.0778 (UTC) FILETIME=[DCC51F20:01CAF1D3] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Subject: Re: [netext] liaison X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for 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, 12 May 2010 13:09:17 -0000 Hi Jari, We support the current version of the LS. Thanks, Telemaco -----Message d'origine----- De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la = part de Jari Arkko Envoy=E9=A0: jeudi 6 mai 2010 01:30 =C0=A0: netext@ietf.org Objet=A0: [netext] liaison I have reviewed the situation with the liaison statement again today. I realize that there has been controversy about sending this liaison=20 message. The consensus behind sending it is rough at best. In=20 retrospect we could have managed the process much better and I take the=20 blame for that. I have discussed the issue with the chairs and if there=20 are similar situations in the future we will take the discussion from a=20 problem (this seems to be unclear) to a solution (we could send this = text). However, after considering the arguments I have decided to send the=20 liaison statement forward, though with edits. I made this decision based = on two principles. The first principle is that we should always be able=20 to describe factual state of affairs as well as we can. The goals,=20 constraints and schedule plans of our working groups could change in the = future, but their current status is a fact. The second principle is that = we should rather err on the side of sending more information than too=20 little. In particular the bar for sending information about the current=20 plans of a WG to someone who might use the results is really low. We=20 have and continue to use many different channels to convey this=20 information, including liaison statements, coordination calls, and joint = participation. However, based on the above and arguments from the list discussion I=20 decided to include a statement about the full scope being described in=20 the charter page. The charters are our best description of our plans and = should represent both the positive (we will soon have some new=20 technology) and negative aspects (it is limited in this manner). I hope this represents a reasonable compromise, and that the working=20 group can now get to its real work, i.e., actually fulfilling promises=20 from the milestones. Jari To: 3GPP SA2 Subject: Flow mobility feature being specified for Proxy Mobile IPv6=20 (RFC5213) in the NETEXT WG Dear Balazs, Andy and, Hong, We would like to inform you about the work being done on extending Proxy = Mobile IPv6 (RFC5213) to support flow mobility within the NETEXT WG in=20 the IETF. The NETEXT WG charter was revised and approved in February=20 2010 with this new work. One of the current goals and milestones of the=20 group is: Oct 2010 - Initial WG document(s) on Proxy Mobile IPv6 Extensions to=20 Support Flow Mobility and Inter-access Handovers on a Logical Interface=20 over Multiple Physical Interfaces Full scope of the effort and more details are described in=20 http://www.ietf.org/dyn/wg/charter/netext-charter. Please consider this as an informative update for SA2 on the=20 developments in NETEXT WG in the IETF. Best Regards, IETF NETEXT WG chairs IETF Internet Area Director Rajeev Koodli Jari Arkko Basavaraj Patil _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From root@core3.amsl.com Fri May 14 00:30:02 2010 Return-Path: X-Original-To: netext@ietf.org Delivered-To: netext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 070EF3A6A35; Fri, 14 May 2010 00:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100514073002.070EF3A6A35@core3.amsl.com> Date: Fri, 14 May 2010 00:30:01 -0700 (PDT) Cc: netext@ietf.org Subject: [netext] I-D Action:draft-ietf-netext-redirect-02.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 07:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : Runtime LMA Assignment Support for Proxy Mobile IPv6 Author(s) : J. Korhonen, et al. Filename : draft-ietf-netext-redirect-02.txt Pages : 22 Date : 2010-05-14 This document describes a redirect functionality and corresponding mobility options for Proxy Mobile IPv6. The redirect functionality allows a dynamic runtime assignment of a Local Mobility Anchor and redirecting the mobility session to the assigned Local Mobility Anchor. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-redirect-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netext-redirect-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-14001736.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon May 24 04:45:01 2010 Return-Path: X-Original-To: netext@ietf.org Delivered-To: netext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8FC763A6B96; Mon, 24 May 2010 04:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100524114501.8FC763A6B96@core3.amsl.com> Date: Mon, 24 May 2010 04:45:01 -0700 (PDT) Cc: netext@ietf.org Subject: [netext] I-D Action:draft-ietf-netext-redirect-03.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 11:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : Runtime LMA Assignment Support for Proxy Mobile IPv6 Author(s) : J. Korhonen, et al. Filename : draft-ietf-netext-redirect-03.txt Pages : 22 Date : 2010-05-24 This document describes a redirect functionality and corresponding mobility options for Proxy Mobile IPv6. The redirect functionality allows a dynamic runtime assignment of a Local Mobility Anchor and redirecting the mobility session to the assigned Local Mobility Anchor. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-redirect-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netext-redirect-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-24043158.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon May 24 09:30:03 2010 Return-Path: X-Original-To: netext@ietf.org Delivered-To: netext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id ACBB23A6BE1; Mon, 24 May 2010 09:30:03 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100524163003.ACBB23A6BE1@core3.amsl.com> Date: Mon, 24 May 2010 09:30:03 -0700 (PDT) Cc: netext@ietf.org Subject: [netext] I-D Action:draft-ietf-netext-radius-pmip6-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 16:30:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : RADIUS Support for Proxy Mobile IPv6 Author(s) : F. Xia, et al. Filename : draft-ietf-netext-radius-pmip6-00.txt Pages : 33 Date : 2010-05-24 This document defines new attributes to facilitate Proxy Mobile IPv6 operations using the RADIUS infrastructure. The RADIUS interactions between the Mobile Access Gateway and the RADIUS server take place when the Mobile Node attaches, authenticates and authorizes to a Proxy Mobile IPv6 domain. Furthermore, this document defines the RADIUS-based interface between the Local Mobility Anchor and the RADIUS server for authorizing received Proxy Binding Update messages for the MN's mobility session. In addition to the mobility session setup related interactions, this document defines the baseline for the Mobile Access Gateway and the Local Mobility Anchor generated accounting. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-radius-pmip6-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netext-radius-pmip6-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-24091656.I-D@ietf.org> --NextPart--