From: webmaster at hallmark.org (webmaster at hallmark.org) Date: Fri, 29 May 2009 18:12:44 +0200 (CEST) Subject: [Netext] You have received a card from a family member! Message-ID: <20090529162249.35A01181C0C0@medoc-server.de> An HTML attachment was scrubbed... URL: From: webmaster at hallmark.org (webmaster at hallmark.org) Date: Fri, 29 May 2009 17:30:54 +0200 (CEST) Subject: [Netext] You have received a card from a family member! Message-ID: <20090529153054.D839A17FC45D@medoc-server.de> An HTML attachment was scrubbed... URL: From: support at paypal.com (PayPal Customer Support) Date: 29 May 2009 11:22:50 -0400 Subject: [Netext] Update Your PayPal Account Message-ID: <1243610570.108293.qmail@paypal.com> An HTML attachment was scrubbed... URL: From: support at paypal.com (PayPal Customer Support) Date: 29 May 2009 11:10:16 -0400 Subject: [Netext] Update Your PayPal Account Message-ID: <1243609816.48408.qmail@paypal.com> An HTML attachment was scrubbed... URL: From: drahmedi.idowu74 at gmail.com (Dr.Ahmed Idowu) Date: Thu, 28 May 2009 15:23:06 -0700 Subject: [Netext] Investment Partner. Message-ID: <03e5e922-39961-31f26409570255@user-2d912a83ae> Dear Friend, I am making this contact to you in good faith. I got your email in my search for a trust worthy and honest person that could assist me in a confidential transaction. I am Honorable Dr. Ahmed Idowu .I am one of the members who conducted the 2007 election with some of my party members, after the election I discovered that the sum of $60 Million Dollars Was remaining and we decided to move it outside the country for safe keeping in a Finance House. I hereby write to seek for your opinion for an investment in your country . I will appreciate if you can be able to handle this project perfectly with us, by making sure that the money will be received and safe keep in your custody for investment . Kindly respond back soonest with your private telephone/ fax numbers for more details. Plesea kindly get back to me through my private email: drahmed104 at gmail.com Thanks and God bless. Yours sincerely, Hon. Dr.Ahmed Idowu From: sunseawq at huawei.com (Qin Wu) Date: Sat, 23 May 2009 16:08:53 +0800 Subject: [Netext] WG status References: <49F07492.6010703@piuha.net> <49F0D06F.1050601@piuha.net> Message-ID: <03b401c9db7d$b6fa4620$260ca40a@china.huawei.com> Hi, Jari: As regarding localized routing topic in the approved WG's charter, I have a minor comment. In the description of localized routing topic, it mentioned that " allow the MAGs to route traffic between hosts from one MAG to another, without being tunneled all the way to the LMA. This reduces latency and backhaul load. " I wonder how to understand backhaul load reduction, >From my understanding, the backbone network should be located between the MAG and the LMA, the backhaul refers to links that carry traffic from the MAG to the backbone network or the LMA. In this sense, the backhaul load reduction will be understood as reduce traffic to pass through the MAG. However the backhaul load reduction realy means the traffic does not need to pass through the LMA, am I right? For this reason,May I suggest to reword the backhaul as backbone? If I am wrong, please correct me. Regards! -Qin ----- Original Message ----- From: "Jari Arkko" To: Sent: Friday, April 24, 2009 4:32 AM Subject: [Netext] WG status > The IESG had a call today, and approved the WG's charter as it is below. > > Jari > >> Network-Based Mobility Extensions (netext) >> ------------------------------------------------------------- >> >> Last Modified: 2009-04-23 >> >> Current Status: Proposed Working Group >> >> Chair(s): >> TBD >> >> Internet Area Director(s): >> Ralph Droms >> Jari Arkko >> >> Internet Area Advisor: >> TBD >> >> Mailing Lists: >> http://www.mobileip.jp/mailman/listinfo/netext >> >> Description of Working Group: >> >> Proxy Mobile IPv6, specified in RFC 5213, is a network-based mobility >> protocol. It uses a Mobile Access Gateway (MAG) and a Local Mobility >> Anchor (LMA) to allow hosts to move around within a domain while keeping >> their address or address prefix stable. Proxy Mobile IPv6 has been >> incorporated into a number of products and deployments are starting. >> Certain deployment considerations, including localized routing and bulk >> refresh of lifetime are already emerging. >> >> The working group will focus on the following topics relevant for >> network-based mobility: >> >> Localized Routing: a specification for routing traffic between the >> MAG(s) without involving the LMA. That is, allow the MAGs to route >> traffic between hosts from one MAG to another, without being tunneled >> all the way to the LMA. This reduces latency and backhaul load. >> Applications such as voice can benefit from the reduced latency. >> From: sunseawq at huawei.com (Qin Wu) Date: Thu, 21 May 2009 16:05:17 +0800 Subject: [Netext] Fw: I-D Action:draft-wu-netext-pmipv6-ipv4-ro-ps-00.txt Message-ID: <03ea01c9d9ea$e3c1e6c0$260ca40a@china.huawei.com> Hi folks: May I interest you to read our draft on the problem statement of IPv4 Support for PMIPv6 localized routing? This draft investigates all the practical IPv4 support use cases and problems in case of IPv4 support for PMIPv6 localized routing. Hope it helps to progress the localized routing topic. The URL link for this Internet draft is http://tools.ietf.org/html/draft-wu-netext-pmipv6-ipv4-ro-ps-00 Your Comments are welcome. BR Qin ----- Original Message ----- From: To: Sent: Thursday, May 21, 2009 11:30 AM Subject: I-D Action:draft-wu-netext-pmipv6-ipv4-ro-ps-00.txt >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Problem Statement of IPv4 Support for PMIPv6 Localized Routing > Author(s) : W. Wu, Y. Wang > Filename : draft-wu-netext-pmipv6-ipv4-ro-ps-00.txt > Pages : 8 > Date : 2009-05-20 > > [ID-PMIP6-RO-PS] describes the problem space of localized routing > which allows end-to-end user traffic forwarding between MN and CN > directly without involving Local Mobility Anchor (LMA) in a single > Proxy Mobile IPv6 [RFC5213] domain. However, localized routing with > IPv4 support which allows IPv4 transport between MAG and LMA and/or > IPv4 enabled user traffic between MN and CN is not considered. This > document introduces the scenarios and problem statement for localized > routing with IPv4 support. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-wu-netext-pmipv6-ipv4-ro-ps-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. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce at 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 > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: draft-wu-netext-pmipv6-ipv4-ro-ps-00.txt URL: From: hardie at qualcomm.com (Ted Hardie) Date: Wed, 20 May 2009 13:49:02 -0700 Subject: [Netext] WG Action: Network-Based Mobility Extensions (netext) In-Reply-To: References: Message-ID: Thanks for the pointer. I assume, then, that others got it and commented on it as expected, and that I just had a very unlucky sample. Ted At 1:36 PM -0700 5/20/09, Basavaraj.Patil at nokia.com wrote: >Sent to the IETF announce list on Apr 14th: > >http://www.ietf.org/mail-archive/web/ietf-announce/current/msg05974.html > > >-Basavaraj > >On 5/20/09 3:21 PM, "ext Ted Hardie" wrote: > >> Is this the right message? I can't find a copy of a message requesting public >> comment on the charter in my archives, and the kind of offices of two others >> searching their archives turned up the same lack. >> >> Was this meant to be the "IESG solicits feedback message"? Or has >> the process changed >> regards, >> Ted >> >> >> At 12:43 PM -0700 5/20/09, IESG Secretary wrote: >>> A new IETF working group has been formed in the Internet Area. For >>> additional information, please contact the Area Directors or the WG >>> Chairs. >>> >>> Network-Based Mobility Extensions (netext) >>> ------------------------------------------------------------- >>> >>> Last Modified: 2009-05-19 >>> >>> Current Status: Active Working Group >>> >>> Chair(s): >>> Basavaraj Patil >>> Rajeev Koodli >>> >>> Internet Area Director(s): >>> Ralph Droms >>> Jari Arkko >>> >>> Internet Area Advisor: >>> Jari Arkko >>> >>> Mailing Lists: >>> >>> General Discussion: netext at mail.mobileip.jp >>> To Subscribe: http://www.mobileip.jp/mailman/listinfo/netext >>> Archive: http://www.mobileip.jp/pipermail/netext/ >>> >>> Description of Working Group: >>> >>> Proxy Mobile IPv6, specified in RFC 5213, is a network-based mobility >>> protocol. It uses a Mobile Access Gateway (MAG) and a Local Mobility >>> Anchor (LMA) to allow hosts to move around within a domain while keeping >>> their address or address prefix stable. Proxy Mobile IPv6 has been >>> incorporated into a number of products and deployments are starting. >>> Certain deployment considerations, including localized routing and bulk >>> refresh of lifetime are already emerging. >>> >>> The working group will focus on the following topics relevant for >>> network-based mobility: >>> >>> Localized Routing: a specification for routing traffic between the >>> MAG(s) without involving the LMA. That is, allow the MAGs to route >>> traffic between hosts from one MAG to another, without being tunneled >>> all the way to the LMA. This reduces latency and backhaul load. >>> Applications such as voice can benefit from the reduced latency. >>> >>> Bulk Refresh: a specification of improving the signaling load for >>> binding lifetime refresh. The current specifications call for the >>> handling of each mobility session independent of each other. When a >>> large number of hosts are served by a single MAG, a periodic refresh of >>> the binding lifetimes can lead to a signaling storm. The purpose of the >>> Bulk Refresh feature is to construct a protocol feature that allows such >>> refreshes to occur on a per-MAG basis. >>> >>> LMA Redirection: a specification for allowing an LMA to redirect a MAG >>> to another LMA. This is primarily needed as a way to perform load >>> balancing. This functionality is complementary to implementation >>> techniques that allow distributed MAG implementations to move tasks >>> around without a visible impact at the protocol level, and the >>> initial LMA discovery work in the NETLMM WG. An applicability statement >>> describing the situations where the new functionality is or is not >>> applicable has to be included in the specification. >>> >>> The work in this charter is entirely internal to the network and does >>> not affect hosts in any way (except perhaps through impacting packet > >> forwarding capacity visible to the hosts). >>> >>> The proposed activity will be complementary to the existing IETF Working >>> Groups, notably the NETLMM and MEXT WGs. The NETEXT working group will >>> also act as the primary forum where new extensions on top of the Proxy >>> Mobile IPv6 protocol can be developed. The addition of such new >>> extensions to the working group involves addition of the extension to >>> this charter through the normal rechartering process. >>> >>> This initial charter excludes a number of possible work items that were >>> discussed in the March 2009 BOF. The working group should continue the >>> discussion about a possible update of its charter and principles under >>> which the new work items must operate under. The completion of the work >>> items in the initial charter is not a requirement for the rechartering >>> to become possible. >>> >>> Milestones >>> >>> May 2009 WG chartered >>> July 2009 Initial WG draft on Bulk Refresh >>> July 2009 Decision on the inclusion of possible additional work items >>> September 2009 Initial WG draft on LMA Redirection >>> November 2009 Initial WG draft on Route Optimization >>> December 2009 Submit Bulk Refresh to IESG for publication as a Proposed >>> Standard RFC >>> January 2010 Submit LMA Redirection to IESG for publication as a >>> Proposed Standard RFC >>> April 2010 Submit Route Optimization to IESG for publication as a >>> Proposed Standard RFC >>> >>> _______________________________________________ >>> IETF-Announce mailing list >>> IETF-Announce at ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-announce >> From: Basavaraj.Patil at nokia.com (Basavaraj.Patil at nokia.com) Date: Wed, 20 May 2009 22:36:34 +0200 Subject: [Netext] WG Action: Network-Based Mobility Extensions (netext) In-Reply-To: Message-ID: Sent to the IETF announce list on Apr 14th: http://www.ietf.org/mail-archive/web/ietf-announce/current/msg05974.html -Basavaraj On 5/20/09 3:21 PM, "ext Ted Hardie" wrote: > Is this the right message? I can't find a copy of a message requesting public > comment on the charter in my archives, and the kind of offices of two others > searching their archives turned up the same lack. > > Was this meant to be the "IESG solicits feedback message"? Or has > the process changed > regards, > Ted > > > At 12:43 PM -0700 5/20/09, IESG Secretary wrote: >> A new IETF working group has been formed in the Internet Area. For >> additional information, please contact the Area Directors or the WG >> Chairs. >> >> Network-Based Mobility Extensions (netext) >> ------------------------------------------------------------- >> >> Last Modified: 2009-05-19 >> >> Current Status: Active Working Group >> >> Chair(s): >> Basavaraj Patil >> Rajeev Koodli >> >> Internet Area Director(s): >> Ralph Droms >> Jari Arkko >> >> Internet Area Advisor: >> Jari Arkko >> >> Mailing Lists: >> >> General Discussion: netext at mail.mobileip.jp >> To Subscribe: http://www.mobileip.jp/mailman/listinfo/netext >> Archive: http://www.mobileip.jp/pipermail/netext/ >> >> Description of Working Group: >> >> Proxy Mobile IPv6, specified in RFC 5213, is a network-based mobility >> protocol. It uses a Mobile Access Gateway (MAG) and a Local Mobility >> Anchor (LMA) to allow hosts to move around within a domain while keeping >> their address or address prefix stable. Proxy Mobile IPv6 has been >> incorporated into a number of products and deployments are starting. >> Certain deployment considerations, including localized routing and bulk >> refresh of lifetime are already emerging. >> >> The working group will focus on the following topics relevant for >> network-based mobility: >> >> Localized Routing: a specification for routing traffic between the >> MAG(s) without involving the LMA. That is, allow the MAGs to route >> traffic between hosts from one MAG to another, without being tunneled >> all the way to the LMA. This reduces latency and backhaul load. >> Applications such as voice can benefit from the reduced latency. >> >> Bulk Refresh: a specification of improving the signaling load for >> binding lifetime refresh. The current specifications call for the >> handling of each mobility session independent of each other. When a >> large number of hosts are served by a single MAG, a periodic refresh of >> the binding lifetimes can lead to a signaling storm. The purpose of the >> Bulk Refresh feature is to construct a protocol feature that allows such >> refreshes to occur on a per-MAG basis. >> >> LMA Redirection: a specification for allowing an LMA to redirect a MAG >> to another LMA. This is primarily needed as a way to perform load >> balancing. This functionality is complementary to implementation >> techniques that allow distributed MAG implementations to move tasks >> around without a visible impact at the protocol level, and the >> initial LMA discovery work in the NETLMM WG. An applicability statement >> describing the situations where the new functionality is or is not >> applicable has to be included in the specification. >> >> The work in this charter is entirely internal to the network and does >> not affect hosts in any way (except perhaps through impacting packet >> forwarding capacity visible to the hosts). >> >> The proposed activity will be complementary to the existing IETF Working >> Groups, notably the NETLMM and MEXT WGs. The NETEXT working group will >> also act as the primary forum where new extensions on top of the Proxy >> Mobile IPv6 protocol can be developed. The addition of such new >> extensions to the working group involves addition of the extension to >> this charter through the normal rechartering process. >> >> This initial charter excludes a number of possible work items that were >> discussed in the March 2009 BOF. The working group should continue the >> discussion about a possible update of its charter and principles under >> which the new work items must operate under. The completion of the work >> items in the initial charter is not a requirement for the rechartering >> to become possible. >> >> Milestones >> >> May 2009 WG chartered >> July 2009 Initial WG draft on Bulk Refresh >> July 2009 Decision on the inclusion of possible additional work items >> September 2009 Initial WG draft on LMA Redirection >> November 2009 Initial WG draft on Route Optimization >> December 2009 Submit Bulk Refresh to IESG for publication as a Proposed >> Standard RFC >> January 2010 Submit LMA Redirection to IESG for publication as a >> Proposed Standard RFC >> April 2010 Submit Route Optimization to IESG for publication as a >> Proposed Standard RFC >> >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce at ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce > From: hardie at qualcomm.com (Ted Hardie) Date: Wed, 20 May 2009 13:21:17 -0700 Subject: [Netext] WG Action: Network-Based Mobility Extensions (netext) In-Reply-To: <20090520194321.7E9B03A68A8@core3.amsl.com> References: <20090520194321.7E9B03A68A8@core3.amsl.com> Message-ID: Is this the right message? I can't find a copy of a message requesting public comment on the charter in my archives, and the kind of offices of two others searching their archives turned up the same lack. Was this meant to be the "IESG solicits feedback message"? Or has the process changed regards, Ted At 12:43 PM -0700 5/20/09, IESG Secretary wrote: >A new IETF working group has been formed in the Internet Area. For >additional information, please contact the Area Directors or the WG >Chairs. > >Network-Based Mobility Extensions (netext) >------------------------------------------------------------- > >Last Modified: 2009-05-19 > >Current Status: Active Working Group > >Chair(s): >Basavaraj Patil >Rajeev Koodli > >Internet Area Director(s): >Ralph Droms >Jari Arkko > >Internet Area Advisor: >Jari Arkko > >Mailing Lists: > >General Discussion: netext at mail.mobileip.jp >To Subscribe: http://www.mobileip.jp/mailman/listinfo/netext >Archive: http://www.mobileip.jp/pipermail/netext/ > >Description of Working Group: > >Proxy Mobile IPv6, specified in RFC 5213, is a network-based mobility >protocol. It uses a Mobile Access Gateway (MAG) and a Local Mobility >Anchor (LMA) to allow hosts to move around within a domain while keeping >their address or address prefix stable. Proxy Mobile IPv6 has been >incorporated into a number of products and deployments are starting. >Certain deployment considerations, including localized routing and bulk >refresh of lifetime are already emerging. > >The working group will focus on the following topics relevant for >network-based mobility: > >Localized Routing: a specification for routing traffic between the >MAG(s) without involving the LMA. That is, allow the MAGs to route >traffic between hosts from one MAG to another, without being tunneled >all the way to the LMA. This reduces latency and backhaul load. >Applications such as voice can benefit from the reduced latency. > >Bulk Refresh: a specification of improving the signaling load for >binding lifetime refresh. The current specifications call for the >handling of each mobility session independent of each other. When a >large number of hosts are served by a single MAG, a periodic refresh of >the binding lifetimes can lead to a signaling storm. The purpose of the >Bulk Refresh feature is to construct a protocol feature that allows such >refreshes to occur on a per-MAG basis. > >LMA Redirection: a specification for allowing an LMA to redirect a MAG >to another LMA. This is primarily needed as a way to perform load >balancing. This functionality is complementary to implementation >techniques that allow distributed MAG implementations to move tasks >around without a visible impact at the protocol level, and the >initial LMA discovery work in the NETLMM WG. An applicability statement >describing the situations where the new functionality is or is not >applicable has to be included in the specification. > >The work in this charter is entirely internal to the network and does >not affect hosts in any way (except perhaps through impacting packet >forwarding capacity visible to the hosts). > >The proposed activity will be complementary to the existing IETF Working >Groups, notably the NETLMM and MEXT WGs. The NETEXT working group will >also act as the primary forum where new extensions on top of the Proxy >Mobile IPv6 protocol can be developed. The addition of such new >extensions to the working group involves addition of the extension to >this charter through the normal rechartering process. > >This initial charter excludes a number of possible work items that were >discussed in the March 2009 BOF. The working group should continue the >discussion about a possible update of its charter and principles under >which the new work items must operate under. The completion of the work >items in the initial charter is not a requirement for the rechartering >to become possible. > >Milestones > >May 2009 WG chartered >July 2009 Initial WG draft on Bulk Refresh >July 2009 Decision on the inclusion of possible additional work items >September 2009 Initial WG draft on LMA Redirection >November 2009 Initial WG draft on Route Optimization >December 2009 Submit Bulk Refresh to IESG for publication as a Proposed >Standard RFC >January 2010 Submit LMA Redirection to IESG for publication as a >Proposed Standard RFC >April 2010 Submit Route Optimization to IESG for publication as a >Proposed Standard RFC > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce at ietf.org >https://www.ietf.org/mailman/listinfo/ietf-announce From: iesg-secretary at ietf.org (IESG Secretary) Date: Wed, 20 May 2009 12:43:21 -0700 (PDT) Subject: [Netext] WG Action: Network-Based Mobility Extensions (netext) Message-ID: <20090520194321.7E9B03A68A8@core3.amsl.com> A new IETF working group has been formed in the Internet Area. For additional information, please contact the Area Directors or the WG Chairs. Network-Based Mobility Extensions (netext) ------------------------------------------------------------- Last Modified: 2009-05-19 Current Status: Active Working Group Chair(s): Basavaraj Patil Rajeev Koodli Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: netext at mail.mobileip.jp To Subscribe: http://www.mobileip.jp/mailman/listinfo/netext Archive: http://www.mobileip.jp/pipermail/netext/ Description of Working Group: Proxy Mobile IPv6, specified in RFC 5213, is a network-based mobility protocol. It uses a Mobile Access Gateway (MAG) and a Local Mobility Anchor (LMA) to allow hosts to move around within a domain while keeping their address or address prefix stable. Proxy Mobile IPv6 has been incorporated into a number of products and deployments are starting. Certain deployment considerations, including localized routing and bulk refresh of lifetime are already emerging. The working group will focus on the following topics relevant for network-based mobility: Localized Routing: a specification for routing traffic between the MAG(s) without involving the LMA. That is, allow the MAGs to route traffic between hosts from one MAG to another, without being tunneled all the way to the LMA. This reduces latency and backhaul load. Applications such as voice can benefit from the reduced latency. Bulk Refresh: a specification of improving the signaling load for binding lifetime refresh. The current specifications call for the handling of each mobility session independent of each other. When a large number of hosts are served by a single MAG, a periodic refresh of the binding lifetimes can lead to a signaling storm. The purpose of the Bulk Refresh feature is to construct a protocol feature that allows such refreshes to occur on a per-MAG basis. LMA Redirection: a specification for allowing an LMA to redirect a MAG to another LMA. This is primarily needed as a way to perform load balancing. This functionality is complementary to implementation techniques that allow distributed MAG implementations to move tasks around without a visible impact at the protocol level, and the initial LMA discovery work in the NETLMM WG. An applicability statement describing the situations where the new functionality is or is not applicable has to be included in the specification. The work in this charter is entirely internal to the network and does not affect hosts in any way (except perhaps through impacting packet forwarding capacity visible to the hosts). The proposed activity will be complementary to the existing IETF Working Groups, notably the NETLMM and MEXT WGs. The NETEXT working group will also act as the primary forum where new extensions on top of the Proxy Mobile IPv6 protocol can be developed. The addition of such new extensions to the working group involves addition of the extension to this charter through the normal rechartering process. This initial charter excludes a number of possible work items that were discussed in the March 2009 BOF. The working group should continue the discussion about a possible update of its charter and principles under which the new work items must operate under. The completion of the work items in the initial charter is not a requirement for the rechartering to become possible. Milestones May 2009 WG chartered July 2009 Initial WG draft on Bulk Refresh July 2009 Decision on the inclusion of possible additional work items September 2009 Initial WG draft on LMA Redirection November 2009 Initial WG draft on Route Optimization December 2009 Submit Bulk Refresh to IESG for publication as a Proposed Standard RFC January 2010 Submit LMA Redirection to IESG for publication as a Proposed Standard RFC April 2010 Submit Route Optimization to IESG for publication as a Proposed Standard RFC From: sgundave at cisco.com (Sri Gundavelli) Date: Tue, 19 May 2009 15:35:17 -0700 (PDT) Subject: [Netext] review of draft-gundavelli-netext-extensions-motivation Re: Fwd: I-D Action:draft-tsirtsis-netext-controversy-00.txt In-Reply-To: References: Message-ID: Hi George, On Tue, 19 May 2009, George Tsirtsis wrote: > Sri, et.al., > > First of all thanks for putting this together. You seem to have done > this reluctantly implying that you had to waste your time doing this. > This is sad by itself, but it also compound by a number of sniping > comments and cheap shots which I am generally trying to ignore. > Lets focus on the technicals. I tried to keep my responses in a positive and an objective manner and not react to any provocative comments, or provoke you either. I really mean it. If not, I failed some where. Any case, lets move forward and identify what we agree and what we disagree. As I see it: 1.) Host awareness We both agree that for supporting some of the new features, it needs host awareness. Without qualifying the interface or how that can be achieved. 2.) On the historical facts as we understand, if host changes are allowed. We can disagree on this as we did all along. But, lets look at this this way. a.) If the initial NETLMM goal was only to support hosts (with no additional software requirements, or MN-AR interface signaling), we agree or not, the protocol supports many features under these constraints. So, we cant argue much here. b.) Now, the goal is to extend new feature support to hosts with some software requirements. Lets say this is a new requirement. Adding support for this, does not remove the support for #a. You dont agree to this requirement. 3.) Requiring software on the host, is the same as CMIP We disagreed on this point. I do not believe the required software will be as complex as implementing 5 other RFCS. But, this issue is mute, if we decide to support hosts with software requirements, complex or simple, the support exists. 4.) MN-AR Interface was always present. There is a disagreement here. You seem to say that this interface was never present. But, there was a WG doc. We also assumed SDO specific interface here. So, it appears we just need to decide if PMIP needs to extend support hosts with some software requirements. Thats the only disagreement. Rest of the disagreement or agreements is to fight for this one point. Secondly, on the interface layer, if IETF MN-AR interface, or it should be left unspecified for SDO's specific interface. > Believe it or not, however, your draft indicates progress in the > quality level of this discussion, which in general has been rather > low. > Ok. Good. > In draft-tsirtsis I had to spend an inordinate amount of time and > effort proving self-evident facts, like the fact that the > controversial extensions to PMIPv6 REQUIRE the definition of an MN-MAG > interface. This has been continually disputed by part of this > community, and it has consumed large amount of time during mailing > list discussions and even during the NETEXT BOF). The situation in > NETEXT BOF was actualy truly appalling with even the BOF chairs > refusing to recognize this as a fact, and even Jari being tentative > about it. > I do not believe any one is saying for supporting the new features such as flow mobility or some of the advanced inter-tech handoff scenarios we dont require host awareness. We need some software there. Offcourse, if the software requires changes to IETF protocols such as RFC-4861 is subjective, that is debatable. > You of course are trying to make it look like that this was the plan > all along, which is nonsense but that's OK. I am glad that at least > your draft openly and finally states that an MN-AR interface is indeed > needed. > MN-AR interface doc was a WG doc. I'm not making this up now. If you are saying we never planned for this interface, you can search for the WG doc in the archives. We did not pay attention to this as the base work, except for the advanced inter-tech handoff scenarios did not require this interface. And we also assumed the SDO specific layer to handle this. But, for supporting the new features, leveraging this interface makes sense. > So, please NETEXT funs, I do not want to have to argue another time > that inter-tech handoffs, multihoming, and flow movement need MN > involvement and MN-MAG signaling. > I'm not sure about multihoming (unless you bring up the lack of MAC address logic and the most interesting case of a dual-radio of same type, even then it should still assign different prefixes), But, flow movement or some of the inter-tech handoff requires the MN to know when to do the switch. That trigger handling or the host awareness is required. > Now our disagreement seems to be WRT what this MN-AR protocol is all > about, and how it compares to client Mobile IP. In my responses below > I am attempting to make you understand another obvious fact, one that > I hope will take less time to absorb than the need for the MN-MAG > protocol did. I summarise this here too: > > You state that the MN-MAG protocol is needed so that the MN can: > - Provide its interface ID(s), and (I am extrapolating) the presence of VIs etc > - Indicate whether it wants to handoff or not > - Register multiple IFs at the same time (multihoming) > - Indicate which flow should be routed to which MAG (flow movement) > I agree that all of this is needed to have a complete solution and had > to wrote draft-tsirtsis partly to prove this point. In > draft-gundavelli, however, you talk about these functions somewhat > dismissively as if they are trivial and not a big deal. If you > actually think for a minute you will realize this: > > 1) This MN-MAG protocol will be client initiated i.e., the MN will be > requesting various things from the MAGs > 2) All of these functions are exactly what client Mobile IP provides, > MIPv4 to the FA, MIPv6 directly to HA. > 3) When you add security all of the above becomes more complex than you think > > Why do you think this is going to be ?simpler? than client Mobile IP? > Requiring the host to handle this is more complex than client mobile IP, its again subjective. IMO, its lot simpler requiring the host to express these preferences and manage its interfaces, to implementing 5 RFC's. To prove it, some one can publish some psuedo code. > What I am claiming in draft-tsirtsis (section 5) is that the > functionality you require results in a protocol very much like MIPv4 > FA-mode, except maybe that security is likely to become a > chain-of-trust model with MN-MAG and MAG-LMA legs instead of the usual > end-to-end security used by MIP. I think such security model might > face some interesting challenges ahead, but thats a discussion for > another day. > > In the end you will end up with a lot (if not all) of the complexity > you allegedly trying to avoid. > If the complexity is so much, then PMIP will fail naturally, you dont have to even worry about this discussion. The published specs will not have any purpose. > This is why the comparison to client based mobility is relevant and > important, and why the bar for a new protocol must be high. This is > why once you introduce MN-MAG interface you have to question why this > is not just reintroduction of the FA in the MIPv6 architecture and if > it is really needed how it would be best introduced in the MIP > architecture. > > Have a nice day. > > George > P.S.: See more comments inline. > > > > > --------------------------------------------------------------------------------------------------------------------------------- > NETEXT WG S. Gundavelli > Internet-Draft Cisco > Intended status: Informational May 05, 2009 > Expires: November 6, 2009 > > > Extensions to Proxy Mobile IPv6 - Motivation > draft-gundavelli-netext-extensions-motivation-00.txt > ? > > > 6. Response to draft-tsirtsis-netext-controversy > > The [draft-tsirtsis-netext-controversy] argues that IETF should not > allow the proposed new extensions to Proxy Mobile IPv6. It is > unfortunate that the draft was not written in a constructive and an > impartial manner. Its clear, the basic purpose of the draft is to > favor client-based solution. That is fine. One can certainly > disregard these comments as one's opinion, affiliation or attachment > to a specific technology as the reason for strong and a one sided > view. But, to an innocent reader who may not know all the technical > details may be misled reading such views. So, its important to > respond to these comments. > > GT> I am glad you decided to speak for the ?innocent reader?. I will > try hard to ignore sniping comments like that letting your innocent > reader decide what they say about their author. > Provocative > > The draft mostly argues on legal grounds and makes number of > assumptions which are incorrect and continues to build the case based > on those assumptions and finally arrives at its own conclusions. To > state a few: > > o The draft assumes that the mobile node in a Proxy Mobile IPv6 > domain has no ability, or it should not be able to express > attachment, handoff or flow preferences to the network. The > document builds the entire case based on this argument. It > completely ignores the operating environment and does not even > mention about the MN-AR Interface document > [draft-ietf-netlmm-mn-ar-if-03], or the SDO specific interfaces, > which was always considered in the protocol design. > > GT> Maybe you should read draft-tsirtsis more carefully. Draft-tsirtsis > a) states the undisputed fact that the MN was never supposed to be > involved (this still the case according to NETLMM charter) But, this was disputed by many folks in the WG all along. Its ambiguous and not clear. Client not involved in the signaling with the HA/LMA or tunnel mgmt, to client managing its interfaces or flows is a different thing. I will leave it here. Thanks Sri From: tsirtsis at googlemail.com (George Tsirtsis) Date: Tue, 19 May 2009 11:34:25 -0400 Subject: [Netext] review of draft-gundavelli-netext-extensions-motivation Re: Fwd: I-D Action:draft-tsirtsis-netext-controversy-00.txt Message-ID: Sri, et.al., First of all thanks for putting this together. You seem to have done this reluctantly implying that you had to waste your time doing this. This is sad by itself, but it also compound by a number of sniping comments and cheap shots which I am generally trying to ignore. Believe it or not, however, your draft indicates progress in the quality level of this discussion, which in general has been rather low. In draft-tsirtsis I had to spend an inordinate amount of time and effort proving self-evident facts, like the fact that the controversial extensions to PMIPv6 REQUIRE the definition of an MN-MAG interface. This has been continually disputed by part of this community, and it has consumed large amount of time during mailing list discussions and even during the NETEXT BOF). The situation in NETEXT BOF was actualy truly appalling with even the BOF chairs refusing to recognize this as a fact, and even Jari being tentative about it. You of course are trying to make it look like that this was the plan all along, which is nonsense but that's OK. I am glad that at least your draft openly and finally states that an MN-AR interface is indeed needed. So, please NETEXT funs, I do not want to have to argue another time that inter-tech handoffs, multihoming, and flow movement need MN involvement and MN-MAG signaling. Now our disagreement seems to be WRT what this MN-AR protocol is all about, and how it compares to client Mobile IP. In my responses below I am attempting to make you understand another obvious fact, one that I hope will take less time to absorb than the need for the MN-MAG protocol did. I summarise this here too: You state that the MN-MAG protocol is needed so that the MN can: - Provide its interface ID(s), and (I am extrapolating) the presence of VIs etc - Indicate whether it wants to handoff or not - Register multiple IFs at the same time (multihoming) - Indicate which flow should be routed to which MAG (flow movement) I agree that all of this is needed to have a complete solution and had to wrote draft-tsirtsis partly to prove this point. In draft-gundavelli, however, you talk about these functions somewhat dismissively as if they are trivial and not a big deal. If you actually think for a minute you will realize this: 1) This MN-MAG protocol will be client initiated i.e., the MN will be requesting various things from the MAGs 2) All of these functions are exactly what client Mobile IP provides, MIPv4 to the FA, MIPv6 directly to HA. 3) When you add security all of the above becomes more complex than you think Why do you think this is going to be ?simpler? than client Mobile IP? What I am claiming in draft-tsirtsis (section 5) is that the functionality you require results in a protocol very much like MIPv4 FA-mode, except maybe that security is likely to become a chain-of-trust model with MN-MAG and MAG-LMA legs instead of the usual end-to-end security used by MIP. I think such security model might face some interesting challenges ahead, but thats a discussion for another day. In the end you will end up with a lot (if not all) of the complexity you allegedly trying to avoid. This is why the comparison to client based mobility is relevant and important, and why the bar for a new protocol must be high. This is why once you introduce MN-MAG interface you have to question why this is not just reintroduction of the FA in the MIPv6 architecture and if it is really needed how it would be best introduced in the MIP architecture. Have a nice day. George P.S.: See more comments inline. --------------------------------------------------------------------------------------------------------------------------------- NETEXT WG S. Gundavelli Internet-Draft Cisco Intended status: Informational May 05, 2009 Expires: November 6, 2009 Extensions to Proxy Mobile IPv6 - Motivation draft-gundavelli-netext-extensions-motivation-00.txt ? 6. Response to draft-tsirtsis-netext-controversy The [draft-tsirtsis-netext-controversy] argues that IETF should not allow the proposed new extensions to Proxy Mobile IPv6. It is unfortunate that the draft was not written in a constructive and an impartial manner. Its clear, the basic purpose of the draft is to favor client-based solution. That is fine. One can certainly disregard these comments as one's opinion, affiliation or attachment to a specific technology as the reason for strong and a one sided view. But, to an innocent reader who may not know all the technical details may be misled reading such views. So, its important to respond to these comments. GT> I am glad you decided to speak for the ?innocent reader?. I will try hard to ignore sniping comments like that letting your innocent reader decide what they say about their author. The draft mostly argues on legal grounds and makes number of assumptions which are incorrect and continues to build the case based on those assumptions and finally arrives at its own conclusions. To state a few: o The draft assumes that the mobile node in a Proxy Mobile IPv6 domain has no ability, or it should not be able to express attachment, handoff or flow preferences to the network. The document builds the entire case based on this argument. It completely ignores the operating environment and does not even mention about the MN-AR Interface document [draft-ietf-netlmm-mn-ar-if-03], or the SDO specific interfaces, which was always considered in the protocol design. GT> Maybe you should read draft-tsirtsis more carefully. Draft-tsirtsis a) states the undisputed fact that the MN was never supposed to be involved (this still the case according to NETLMM charter) b) it then proves that the desired extensions require that the MN is involved (e.g., in section 4). This which was necessary to do since the need for MN involvement has been disputed multiple times, including during the NETEXT BOF. So, I am now glad you finally agree and openly state that this is really unavoidable. c) The draft also talks about the implications of MN involvement (e.g., section 5) o The draft fails to differentiate between a mobile node expressing minimal hints to the network, such as attachment, connection or flow preferences, to a full blown mobile node with all the complex software requiring massive system resources and performing all aspects of mobility management. GT> I happen to work for a company that builds such functionality in mobile phones for a living; It might be reasonable to assume that I know something about what such devices can do. I suggest that you might be a bit behind in your appreciation of what such devices are capable of these days. It equates both as one and the same with the conclusion that any software on the host is the same as client-based mobility. But, it does not see the difference, boiling a glass of water to boiling an ocean. GT> You may want to consider that comparison yourself. Based on what you want to do in section 5 you will have to define a protocol that can handle: - roaming, - inter-tech handovers, - multihoming, and - flow movement. You will have to do this interoperably and securely. Why do you think that this is going to be a ?simple? protocol? Where do you think the perceived complexity involved with say MIPv6 coming from, if not from the fact that it needs to support all of the above functions? o The draft reviews some of the multihoming and flow mobility scenario's and makes a case that it is not possible to perform flow mobility or support complex handoff scenario's without the mobile node being aware and which is correct. Ack ! But, again it ignores the MN-AR Interface or SDO specific layer which can be used for such purpose. GT> Perfect, as I said many people in NETEXT BOF and in the mailing list have been trying to dodge the issue claiming that MN involvement may not actually be needed. o The draft ignores the market direction and the industry preferences for network-based mobility management, either in the form of Proxy Mobile IPv6 or Generic Tunneling Protocol [GTP], and the resulting benefits in that approach. GT> The draft does not ignore them at all. Markets, rarely ask for specific protocols. They mostly ask for functionality which we then have to provide with ?reasonable? protocol designs, which is what this discussion is all about. o The draft disregards the amount of scrutiny, reviews and the external validations that went into the base protocol design for ensuring the protocol followed the IETF design principles. GT> The draft does not ignore that either. On the contrary is fully aware of the resistance experienced during PMIPv6 base protocol design to even add basic requirements like the Handoff Indication to the design, and the fact that the same attitude of not facing up to issues is repeated now with further controversial extensions. The following sections respond to more specific comments, on section by section basis. 6.1. PMIP with Host Signaling & Historic Reasons - Clarification There is a comment, a mobile node in a Proxy Mobile IPv6 domain is not allowed to have any intelligence. And there will point you to some incomplete and ambiguous line in the charter that was never ever discussed widely during the formation of NETLMM working group and which went practically unnoticed. Even if it did, it does not mean much and is not relevant. In any case, following is the response to that comment. Proxy Mobile IPv6 was certainly created with the goal that the mobile node will not perform any mobility signaling with its local mobility anchor. GT> This is the only thing draft-tsirtsis says. It says nothing about mobiles being ?stupid?, ?dumb? or anything like that. So far it is correct. However, no where in the base protocol specification, it ever stated and assumed that: o that the mobile node that attached to a Proxy Mobile IPv6 domain will be a dumb and a stupid terminal which can do only a single attachment, cannot dynamically manage its interfaces or cannot configure an address dynamically on a real or on a virtual interface. o that it will be disallowed from providing handoff, attachment or flow preferences to the network, through a SDO specific interface layer. o that an operator cannot install any intelligent application software, such as connection manager which using the configured policies or user inputs, makes the network attachment decisions. o that it will be disallowed from being aware of the operating environment. GT> I am not sure what the above list proves and draft-tsirtsis does not contradict any of the above. These restrictions do not make any sense and are not needed. Providing attachment and handoff preferences was always factored in to the design. The MN-AR Interface document [draft-ietf-netlmm-mn-ar-if-03] which was a working document prior to the adoption of the initial Proxy Mobile IPv6 document, was specified for that purpose. The protocol also allowed this interface to be defined in a SDO specific manner, specifying the protocol between the network nodes only by reacting to the provided events. This is not a design flaw, but allowing the room for all the extensions to come in place in a evolutionary manner. An application software such as connection manager is a basic host requirement for any multihomed terminal and is not a Proxy Mobile IPv6 requirement. This component cannot be avoided on any multihomed host. The behavior of any host will be unpredictable and unreliable with respect to the choices it makes for all its network connections. Proxy Mobile IPv6 only requires few additional hooks on such software module, that too for supporting some features. GT> A Connectivity manager, is typically self-contained, in-box, implementation specific software, which does not produce any out-of-box signaling. What you are talking about here is MN to AR signaling which is clearly beyond the remit of what a normal connectivity manager normally is all about. This is not a bad thing by-itself but you keep talking about this as if existing connectivity manager will just provide the PMIP-hooks for free. 6.2. MAG ... the new FA ? Section 5.2.2 of [draft-tsirtsis-controversy-00] tries hard to imply that functional element, mobile access gateway is the same as foreign agent in Mobile IPv4, with the objective to prove that any software requirement on the client maps to Mobile IPv4 model. Sure, the models map in the mobility element count, but there are role differences in each of those models and the argument completely discounts this aspect. In a network-based mobility model, there is an element on the network that is designated to perform the mobility management functions. We can call this a foreign agent, mobile access gateway or a mobility proxy, but the functional role has a specific purpose and the model is not Mobile IPv4. The functional role of the mobile node is not beyond than managing its interfaces, address configuration and expressing handoff and flow preferences to the network. GT> Are you actually reading what you are writing? You claim that with PMIP the MN?s role is *passive*, and yet you also say it is ?expressing handoff and flow preferences to the network. ?. What does client Mobile IP do beyond that?? It plays a mere passive role and allowing the mobile access gateway to play the active role on the aspects of mobility management. So, there is a fundamental difference between this when compared to the Mobile IPv4. In any case, the comparison that is needed is in relation to client- based mobility. Following are the fundamental differences between all the three models: o In Mobile IPv4 (FA-CoA Mode), the mode of active client and passive network node, the mobile node plays an active role, performs all aspects of mobility management, while the foreign agent plays mere passive role o In Proxy Mobile IPv6, the mode of passive client and active network node, the mobile node plays a mere passive role in the mobility management. It does not perform any mobility signaling with the local mobility anchor. It is only expected to provide attachment, handoff and flow preferences to the network, while the mobile access gateway is responsible for performing all aspects of mobility management. GT> Again, according to this the MN is *passive* but it performs all sorts of active functions like handoff and flow movement. You do realize that you are making no sense right? o In Mobile IPv6, the mode of active client, the mobile node plays the active role and performs all aspects of mobility management. It requires Mobile IPv6 client [RFC-3775], DSMIP6 [ID-DSMIP6], MCOA [ID-MCOA6], IKEv2 [RFC-4306] and IPsec [RFC-4301] stacks. Its requires significant amount of software and system resources on the client. 6.3. The Internet, the Interface, and the Host And we got a ticket ! We are breaking the Internet building blocks. Section 3.0 of [draft-tsirtsis-controversy-00] is not clear on what the concern is. Following are the clarifications. o The IP mobility is above network layer, it is a service layer and as specified in Section 6.6 of [RFC-5213], a mobile node on attaching to the Proxy Mobile IPv6 network is required to present its identify. GT> Except it does not say how?.which is why I call RFC5213 ?incomplete?. So, the mobile access gateway has a clear relation between a mobile node's identify, its link-layer identifier and on the offered mobility service along with the assigned prefix. But, this relation is preserved in an application layer and at the IP layer its just the standard protocol operation confirming to all the standard IETF protocols. o When looked at from the perspective of IP layer, the MN-AR link is any other IP link. Its a point-to-point link and with the mobile access gateway functioning as the IPv6 router on the link. The prefix set that it projects on the link is always tied to that mobile node's interface, but that relation is preserved in application layer and the network layer has no understanding of any of this relation. Its a normal IPv6 link with the presence of two nodes on the link and a set of hosted IPv6 prefixes. GT> Which as draft-tsirtsis indicates is fine as long as the MN has a single interface. o The comment on NDP operation for multihomed hosts is not applicable. The MN-AR link is a point-to-point link, with only one interface of the mobile node, either real or a virtual interface, is present. So, the protocol does not modify the low level building blocks of the Internet and so the allegation is not correct. 6.4. What is wrong with PMIP so far ? Nothing ! Clarifications to Section 4.0 of [draft-tsirtsis-controversy-00] in the same order. 1. The absence of MN-AR interface, as an IETF specified interface does not imply the protocol is broken. For example, the IP layer is built with the assumption that the layer-2 driver for a given access technology will provide the required hooks for the IP layer. Its the same thing here. A given SDO can define such interface. GT> Yes, this is the definition of ?broken? or at least the definition of ?incomplete? as I call it in draft-tsirtsis. One of the major flaws of PMIPv6 is that it is NOT self-contained. 2. It is indeed correct that there is no concept of a MAC address in certain link-layer technologies, but that's only in CDMA and in LTE. GT>So all the 3GPP and 3GPP2 interfaces?you call that ?only?? The absence of such semantic in these two technologies is not a problem for the current operating environment. - the protocol uses the Access Technology Type for the uniqueness and for a dual-mode terminal that are going to be in the market, it is highly unlikely there are multiple radio's of the same type. - even otherwise, a simple semantic allowing the mobile node to present an identifier as part of the attachment preferences will be just fine. GT> sure, which will then have to be secured appropriately, you also want to add flow movement and handoff indications etc, as I said this is not as simple as you try making it out to be. 3. The use of virtual interfaces is a host specific semantic. It is perfectly valid for a host to use the physical interfaces in a bridged mode and present a virtual link-layer identifier. This is perfectly valid and many protocols such as HRRP or VRRP use such mode. This has no implication on the IPv6 link or on the link neighbors. GT> Did anyone say this is a problem? On the contrary draft-tsirtsis says this is necessary, and it had to say this since a lot of PMIP folks have been arguing forever that somehow it might not be needed. You of course continue to pretend that you are oblivious to the fact that there is no way to signal the fact that a VI exists or that two specific interfaces are under a given VI. 4. It is true that the mobile node can potentially specify if the given attachment is due to an handoff or as result of a new interface bringup. But, the absence of such event is fine in most cases. The network through context transfer procedures or through other means, can derive that information. We can certainly add this in the IETF specified MN-AR interface layer. 6.5. Its not a Tool Proliferation ! A comment was made in Section 5.2.3 of [draft-tsirtsis-controversy-00], that allowing host participation in any level, is equivalent to client performing all aspects of mobility management and results in redundant tool proliferation. Its not always a binary logic. No host involvement in mobility management does not imply the host has zero awareness of the operating environment, or that it is disallowed from running any intelligent software such as connection manager, or that is a violation for it express its connection or flow preferences to the network. That was never a basis for the design of the Proxy Mobile IPv6 protocol. Allowing the host to have such capabilities only improves the protocol and cannot be considered as a tool proliferation. Even otherwise, new ideas, fresh discoveries on how to deploy a technology in a real-world network and when coupled by urgent customer needs, always can re-shape a technology. A technology solution that start with Protocol-A need not be restricted to that protocol, but instead can go with Protocol-B, if that happens to be a better protocol and if market wants that solution. There are many instances in IETF, where it allowed multiple technologies to co-exist and let the market adopt what is right, to name a few: GT> This is of course true. What I claim is not that this is never allowed, but that the bar for new entrants must be high and the reasons and architectural implications must be understood before creating yet another protocol that does the same thing with an existing one. On Tue, May 5, 2009 at 10:51 PM, Sri Gundavelli wrote: > > >> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of George Tsirtsis >> Sent: Thursday, April 16, 2009 3:39 AM >> To: netext at mail.mobileip.jp >> Subject: [Netext] Fwd: I-D >> Action:draft-tsirtsis-netext-controversy-00.txt >> >> This draft is relevant to the discussion regarding the more >> controversial proposed extensions of PMIPv6. >> > > I tried to respond to all the comments raised in this document. > The draft talks about the motivation for the new features and responds to > the comments mentioned in draft-tsirtsis-netext-controversy-00.txt. > > http://www.ietf.org/internet-drafts/draft-gundavelli-netext-extensions-motiv > ation-00.txt > > Hopefully, both the drafts dont go for -01 version, I really had to struggle > to > find the time for this. > > Sri > > > > > >> I hope this helps. >> >> Regards >> George >> >> >> ---------- Forwarded message ---------- >> From: ? >> Date: Thu, Apr 16, 2009 at 11:00 AM >> Subject: I-D Action:draft-tsirtsis-netext-controversy-00.txt >> To: i-d-announce at ietf.org >> >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> >> ? ? ? ?Title ? ? ? ? ? : Discussion of Controversial PMIP Extensions >> ? ? ? ?Author(s) ? ? ? : G. Tsirtsis >> ? ? ? ?Filename ? ? ? ?: draft-tsirtsis-netext-controversy-00.txt >> ? ? ? ?Pages ? ? ? ? ? : 17 >> ? ? ? ?Date ? ? ? ? ? ?: 2009-04-16 >> >> This document discusses the recent controversy regarding PMIP >> extensions for inter-technology handoffs and multihoming. ?Many of >> the arguments presented below have been discussed in NETEXT BOF and >> subsequent discussions on the mailing list. ?They are written here in >> an attempt to explain why some of the proposed PMIP extensions are so >> controversial. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-tsirtsis-netext-cont >> roversy-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. >> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce at 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 at mail.mobileip.jp >> http://www.mobileip.jp/mailman/listinfo/netext >> > > From: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan) Date: Tue, 19 May 2009 17:18:40 +0800 Subject: [Netext] New Version Notification for draft-gundavelli-netext-extensions-motivation-00 (fwd) In-Reply-To: Message-ID: <5F09D220B62F79418461A978CA0921BD035BFF28@pslexc01.psl.local> Hi Sri, Thanks for the response. Please see some replies. BR, Mohana > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave at cisco.com] > Sent: Tuesday, May 19, 2009 1:51 PM > To: Mohana Jeyatharan > Cc: netext at mail.mobileip.jp > Subject: RE: [Netext] New Version Notification for draft-gundavelli- > netext-extensions-motivation-00 (fwd) > > Hi Mohana, > > Thanks for the review comments. Some comments below. > > 1. Mainly, the assumptions or the requirements that are placed > on the host by some of the new features, such as flow mobility, > we need some explicit triggers from the host to the network. > Potentially this interface can be captured in the MN-AR interface > doc and with the triggers idenfied. Having an IETF specified MN-AR > interface doc can complete the whole puzzle and also can be > referenced for developing alternative SDO specific interfaces. In > that sense, this interface is critical. Ok, understand. So, this interface can be used by any SDO. It is better to standardize such an interface in IETF. > 2. Also, as Raj pointed out earlier, we need to classify the hosts > in a slightly different manner. The support for PMIP can be for > a.) The sacred unmodified client, what ever that is, and b.) Host > with some intelligence to express flow and attach preferences. > RFC-5213 has support for all the base features for type-a hosts. > However, for supporting inter-tech handoffs in a complete and > explicit way, we need #b. But, adding support for #b does not > take away support for #a. So, its important to classify the hosts > w.r.t PMIP support, in both the ways. Yes. So, now we want to work on #b and we are in no way taking away support for #a. So the initial goal of PMIPv6 still stands. I really don't understand what are we breaking by making the UE a little smarter. I hope we all can agree on this and push the multihoming and inter access handoff into the Netext charter. > 3. The host awareness overall improves the protocol. Allowing the > mobile to understand that the projected prefix has mobility > characterstics, or that it is in a PMIP domain, is useful for > it to express the preferences to the network in a better manner. Yes and also there is nothing wrong in making the terminal intelligent. Making the terminal intelligent is nothing to do with MN performing mobility management. Again, I hope all in the WG can agree to this. > Regards > Sri > > > On Mon, 18 May 2009, Mohana Jeyatharan wrote: > > > Hi Sri, > > > > Thanks for your tremendous effort in writing this draft and highlighting > > the urgent need for PMIPv6 to be extended to support multihoming and > > inter access technology handoffs. > > > > As you have clearly indicated in this draft, that creating a connection > > manager to indicate the MN's intention is already the underlying > > assumption in RFC 5213. Thus, such operation is already widely accepted > > for PMIPv6 deployment and such signaling should be no problem. In that > > case, I hope we can all agree, to perform flow mobility and inter access > > technology using such connection manager module that controls such > > processes is required and it is not like breaking any IETF design rules. > > > > > > Also, thanks Sri for explaining the protocols that have been developed > > by IETF and how feature add on has been done in the past. MIPv6 was > > developed and now we are developing a protocol MCoA to perform > > multihoming. I am also referring to section 6.5 where you have > > highlighted multiple technologies have co-exitsted in IETF. Similary > > PMIPv6 was developed with the motive of "providing mobility support for > > unmodified hosts" > > and now we need to look into ways of enhancing PMIPv6 so that we can > > achieve flow mobility, inter access technology handoffs and so on. As > > you have clearly indicated, introducing a connection manager to legacy > > hosts does not mean you are changing anything at L3 and it is not > > introducing many software logic into the MN to perform mobility. > > > > Thus it is clear that, PMIPv6 is a network based mobility management > > protocol(no MN-LMA signaling) and a MN should be allowed to perform > > multihoming and inter access handoff by using a simple software module. > > In 3GPP people are looking into ways of extending the protocol for flow > > mobility. After all, IETF developed PMIPv6 bcos there was a need from > > the industry. Similarly, if operators are interested in flow mobility > > when PMIPv6 is used to manage mobility for multiple interfaced node, > > then why IETF is reluctant to accept this? After all IETF has done > > multiple developed multiple technologies. > > > > Sri I just have two clarification questions. > > (1) So are you saying that the MN-AR document is thebest way to handle > > the flow mobility, handoff indication and stuff or do you think SDO > > specific layer is needed. Bcos, in the draft you mentioned both and it > > is not very clear to me. > > > > (2) If MN is aware it is PMIPv6 domain, then can it be modified in a way > > that the host can be able to accept packets addresses to one interface > > via the other interface. I am asking this bcos, this is point to point > > model and there should be no problem. Any thoughts on this? Does it need > > lot of software logic to perform this. > > > > I hope we can all agree that featrure add on to PMIPv6 is not breaking > > the Internet or anything like that. IETF must work on this, bcos the > > industries are nterested in it and there are lot of people in IETF who > > want to work on this. People want to work on this bcos it has a good > > use. > > From: sgundave at cisco.com (Sri Gundavelli) Date: Mon, 18 May 2009 22:50:43 -0700 (PDT) Subject: [Netext] New Version Notification for draft-gundavelli-netext-extensions-motivation-00 (fwd) In-Reply-To: <5F09D220B62F79418461A978CA0921BD03579FA2@pslexc01.psl.local> References: <5F09D220B62F79418461A978CA0921BD03579FA2@pslexc01.psl.local> Message-ID: Hi Mohana, Thanks for the review comments. Some comments below. 1. Mainly, the assumptions or the requirements that are placed on the host by some of the new features, such as flow mobility, we need some explicit triggers from the host to the network. Potentially this interface can be captured in the MN-AR interface doc and with the triggers idenfied. Having an IETF specified MN-AR interface doc can complete the whole puzzle and also can be referenced for developing alternative SDO specific interfaces. In that sense, this interface is critical. 2. Also, as Raj pointed out earlier, we need to classify the hosts in a slightly different manner. The support for PMIP can be for a.) The sacred unmodified client, what ever that is, and b.) Host with some intelligence to express flow and attach preferences. RFC-5213 has support for all the base features for type-a hosts. However, for supporting inter-tech handoffs in a complete and explicit way, we need #b. But, adding support for #b does not take away support for #a. So, its important to classify the hosts w.r.t PMIP support, in both the ways. 3. The host awareness overall improves the protocol. Allowing the mobile to understand that the projected prefix has mobility characterstics, or that it is in a PMIP domain, is useful for it to express the preferences to the network in a better manner. Regards Sri On Mon, 18 May 2009, Mohana Jeyatharan wrote: > Hi Sri, > > Thanks for your tremendous effort in writing this draft and highlighting > the urgent need for PMIPv6 to be extended to support multihoming and > inter access technology handoffs. > > As you have clearly indicated in this draft, that creating a connection > manager to indicate the MN's intention is already the underlying > assumption in RFC 5213. Thus, such operation is already widely accepted > for PMIPv6 deployment and such signaling should be no problem. In that > case, I hope we can all agree, to perform flow mobility and inter access > technology using such connection manager module that controls such > processes is required and it is not like breaking any IETF design rules. > > > Also, thanks Sri for explaining the protocols that have been developed > by IETF and how feature add on has been done in the past. MIPv6 was > developed and now we are developing a protocol MCoA to perform > multihoming. I am also referring to section 6.5 where you have > highlighted multiple technologies have co-exitsted in IETF. Similary > PMIPv6 was developed with the motive of "providing mobility support for > unmodified hosts" > and now we need to look into ways of enhancing PMIPv6 so that we can > achieve flow mobility, inter access technology handoffs and so on. As > you have clearly indicated, introducing a connection manager to legacy > hosts does not mean you are changing anything at L3 and it is not > introducing many software logic into the MN to perform mobility. > > Thus it is clear that, PMIPv6 is a network based mobility management > protocol(no MN-LMA signaling) and a MN should be allowed to perform > multihoming and inter access handoff by using a simple software module. > In 3GPP people are looking into ways of extending the protocol for flow > mobility. After all, IETF developed PMIPv6 bcos there was a need from > the industry. Similarly, if operators are interested in flow mobility > when PMIPv6 is used to manage mobility for multiple interfaced node, > then why IETF is reluctant to accept this? After all IETF has done > multiple developed multiple technologies. > > Sri I just have two clarification questions. > (1) So are you saying that the MN-AR document is thebest way to handle > the flow mobility, handoff indication and stuff or do you think SDO > specific layer is needed. Bcos, in the draft you mentioned both and it > is not very clear to me. > > (2) If MN is aware it is PMIPv6 domain, then can it be modified in a way > that the host can be able to accept packets addresses to one interface > via the other interface. I am asking this bcos, this is point to point > model and there should be no problem. Any thoughts on this? Does it need > lot of software logic to perform this. > > I hope we can all agree that featrure add on to PMIPv6 is not breaking > the Internet or anything like that. IETF must work on this, bcos the > industries are nterested in it and there are lot of people in IETF who > want to work on this. People want to work on this bcos it has a good > use. > From: sgundave at cisco.com (Sri Gundavelli) Date: Mon, 18 May 2009 22:50:36 -0700 Subject: [Netext] New Version Notification for draft-gundavelli-netext-extensions-motivation-00 (fwd) In-Reply-To: <003601c9ce90$0ca93cc0$3e0c7c0a@china.huawei.com> References: <003601c9ce90$0ca93cc0$3e0c7c0a@china.huawei.com> Message-ID: <000001c9d845$bbce43d0$d6f6200a@amer.cisco.com> Thanks Frank for the review. Good to know you agree with the thoughts. Sri > -----Original Message----- > From: Frank Xia [mailto:xiayangsong at huawei.com] > Sent: Wednesday, May 06, 2009 2:17 PM > To: Sri Gundavelli; netext at mail.mobileip.jp > Subject: Re: [Netext] New Version Notification for > draft-gundavelli-netext-extensions-motivation-00 (fwd) > > Hi Sri > > I have a quick look at the document. > > Some common view points I share with you are as following: > 1)"reviving the MN-AR interface [draft-ietf-netlmm-mn-ar-if-03]" > 2)"This(notes: clint mobile IP) may happen eventually, but for the > current time frame, the market is looking for other > solutions and > network-based mobility is the preferred approach which requires > minimal host support with a small application module that any > vendor can develop in no time" > ... ... > > Additional, I would like to give you a real deployment case. > Verizon LTE network will use PMIPv6 between > HSGW/ePDSN and PDN SAE GW. AFAIK, this will be the > first large-scale IP mobility deployment. > > Now that we can't stop PMIP deployment, the only way we > can benefit the industry is to solve the problems which PMIP > deployment would encounter. > > BR > Frank > > ----- Original Message ----- > From: "Sri Gundavelli" > To: > Sent: Tuesday, May 05, 2009 9:53 PM > Subject: [Netext] New Version Notification for > draft-gundavelli-netext-extensions-motivation-00 (fwd) > > > > > > This provides some motivation for the flow mobility and > other extensions. > > > > > http://www.ietf.org/internet-drafts/draft-gundavelli-netext-ex > tensions-motivation-00.txt > > > > > > > > ---------- Forwarded message ---------- > > Date: Tue, 5 May 2009 19:42:20 -0700 (PDT) > > From: IETF I-D Submission Tool > > To: sgundave at cisco.com > > Subject: New Version Notification for > > draft-gundavelli-netext-extensions-motivation-00 > > > > > > A new version of I-D, > draft-gundavelli-netext-extensions-motivation-00.txt > > has been successfuly submitted by Sri Gundavelli and posted > to the IETF > > repository. > > > > Filename: draft-gundavelli-netext-extensions-motivation > > Revision: 00 > > Title: Extensions to Proxy Mobile IPv6 - Motivation > > Creation_date: 2009-05-05 > > WG ID: Independent Submission > > Number_of_pages: 24 > > > > Abstract: > > Proxy Mobile IPv6 is a network-based mobility management protocol > > standardized in IETF and is being specified in various system > > architectures as a protocol for building a common and access > > independent mobile core. Currently, there are number of proposals > > and a huge amount of interest in NETEXT working group for extending > > the protocol to support various mobility extensions. This document > > identifies some of the critical extensions that are absolutely > > required and builds a case as why these extensions have to be > > supported. > > > > > > > > The IETF Secretariat. > > > > > > _______________________________________________ > > NetExt mailing list > > NetExt at mail.mobileip.jp > > http://www.mobileip.jp/mailman/listinfo/netext > From: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan) Date: Mon, 18 May 2009 08:53:09 +0800 Subject: [Netext] New Version Notification for draft-gundavelli-netext-extensions-motivation-00 (fwd) In-Reply-To: Message-ID: <5F09D220B62F79418461A978CA0921BD03579FA2@pslexc01.psl.local> Hi Sri, Thanks for your tremendous effort in writing this draft and highlighting the urgent need for PMIPv6 to be extended to support multihoming and inter access technology handoffs. As you have clearly indicated in this draft, that creating a connection manager to indicate the MN's intention is already the underlying assumption in RFC 5213. Thus, such operation is already widely accepted for PMIPv6 deployment and such signaling should be no problem. In that case, I hope we can all agree, to perform flow mobility and inter access technology using such connection manager module that controls such processes is required and it is not like breaking any IETF design rules. Also, thanks Sri for explaining the protocols that have been developed by IETF and how feature add on has been done in the past. MIPv6 was developed and now we are developing a protocol MCoA to perform multihoming. I am also referring to section 6.5 where you have highlighted multiple technologies have co-exitsted in IETF. Similary PMIPv6 was developed with the motive of "providing mobility support for unmodified hosts" and now we need to look into ways of enhancing PMIPv6 so that we can achieve flow mobility, inter access technology handoffs and so on. As you have clearly indicated, introducing a connection manager to legacy hosts does not mean you are changing anything at L3 and it is not introducing many software logic into the MN to perform mobility. Thus it is clear that, PMIPv6 is a network based mobility management protocol(no MN-LMA signaling) and a MN should be allowed to perform multihoming and inter access handoff by using a simple software module. In 3GPP people are looking into ways of extending the protocol for flow mobility. After all, IETF developed PMIPv6 bcos there was a need from the industry. Similarly, if operators are interested in flow mobility when PMIPv6 is used to manage mobility for multiple interfaced node, then why IETF is reluctant to accept this? After all IETF has done multiple developed multiple technologies. Sri I just have two clarification questions. (1) So are you saying that the MN-AR document is thebest way to handle the flow mobility, handoff indication and stuff or do you think SDO specific layer is needed. Bcos, in the draft you mentioned both and it is not very clear to me. (2) If MN is aware it is PMIPv6 domain, then can it be modified in a way that the host can be able to accept packets addresses to one interface via the other interface. I am asking this bcos, this is point to point model and there should be no problem. Any thoughts on this? Does it need lot of software logic to perform this. I hope we can all agree that featrure add on to PMIPv6 is not breaking the Internet or anything like that. IETF must work on this, bcos the industries are nterested in it and there are lot of people in IETF who want to work on this. People want to work on this bcos it has a good use. BR, Mohana > -----Original Message----- > From: netext-bounces at mail.mobileip.jp [mailto:netext- > bounces at mail.mobileip.jp] On Behalf Of Sri Gundavelli > Sent: Wednesday, May 06, 2009 10:53 AM > To: netext at mail.mobileip.jp > Subject: [Netext] New Version Notification for draft-gundavelli-netext- > extensions-motivation-00 (fwd) > > > This provides some motivation for the flow mobility and other extensions. > > http://www.ietf.org/internet-drafts/draft-gundavelli-netext-extensions- > motivation-00.txt > > > > ---------- Forwarded message ---------- > Date: Tue, 5 May 2009 19:42:20 -0700 (PDT) > From: IETF I-D Submission Tool > To: sgundave at cisco.com > Subject: New Version Notification for > draft-gundavelli-netext-extensions-motivation-00 > > > A new version of I-D, draft-gundavelli-netext-extensions-motivation-00.txt > has been successfuly submitted by Sri Gundavelli and posted to the IETF > repository. > > Filename: draft-gundavelli-netext-extensions-motivation > Revision: 00 > Title: Extensions to Proxy Mobile IPv6 - Motivation > Creation_date: 2009-05-05 > WG ID: Independent Submission > Number_of_pages: 24 > > Abstract: > Proxy Mobile IPv6 is a network-based mobility management protocol > standardized in IETF and is being specified in various system > architectures as a protocol for building a common and access > independent mobile core. Currently, there are number of proposals > and a huge amount of interest in NETEXT working group for extending > the protocol to support various mobility extensions. This document > identifies some of the critical extensions that are absolutely > required and builds a case as why these extensions have to be > supported. > > > > The IETF Secretariat. > > > _______________________________________________ > NetExt mailing list > NetExt at mail.mobileip.jp > http://www.mobileip.jp/mailman/listinfo/netext From: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano) Date: Wed, 13 May 2009 18:05:26 +0200 Subject: [Netext] Extending PMIPv6 to support also mobile access networks Message-ID: <1242230726.5379.42.camel@localhost> Hi all, Some weeks ago we were discussing about potential next steps in NETEXT. One of the suggested topics was NEMO+PMIPv6 and, related to that, I brought the issue of extending PMIPv6 to support not only non-mobile points of attachment (i.e., MAGs), but also mobile ones (enabling mobile platforms). We have just published a paper in which we describe some of the scenarios we have in mind, the motivation and a potential solution (please note that we claim some IPR on parts of the solution): http://www.comsoc.org/livepubs/ci1/public/2009/may/bernardos.html Comments are highly welcome. Thanks, Carlos P.S.: If you cannot get the paper and wants to read it, please contact me directly and I'll send you the pdf. -- Carlos Jes?s Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ IEEE Network Special Issue on Advances in Vehicular Communications Networks http://www.comsoc.org/livepubs/ni/info/cfp/cfpnetwork0110.htm +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Esta parte del mensaje est? firmada digitalmente URL: From: xiayangsong at huawei.com (Frank Xia) Date: Thu, 07 May 2009 09:38:47 -0500 Subject: [Netext] New Version Notification for draft-gundavelli-netext-extensions-motivation-00 (fwd) References: <003601c9ce90$0ca93cc0$3e0c7c0a@china.huawei.com> Message-ID: <001001c9cf21$896a3840$3e0c7c0a@china.huawei.com> Hi Jong-Hyouk Sorry, I get this information from my friends in Verizon. Probably, we can wait and see if some formal documents available. BR Frank ----- Original Message ----- From: Jong-Hyouk Lee To: Frank Xia Cc: Sri Gundavelli ; netext at mail.mobileip.jp Sent: Thursday, May 07, 2009 5:07 AM Subject: Re: [Netext] New Version Notification for draft-gundavelli-netext-extensions-motivation-00 (fwd) Hi. Frank. Thanks for providing the real use case of PMIPv6. Could you provide more details about the news Verizon LTE will deploy PMIPv6? Is there any formal document or link for it? Cheers. On Thu, May 7, 2009 at 6:17 AM, Frank Xia wrote: Hi Sri I have a quick look at the document. Some common view points I share with you are as following: 1)"reviving the MN-AR interface [draft-ietf-netlmm-mn-ar-if-03]" 2)"This(notes: clint mobile IP) may happen eventually, but for the current time frame, the market is looking for other solutions and network-based mobility is the preferred approach which requires minimal host support with a small application module that any vendor can develop in no time" ... ... Additional, I would like to give you a real deployment case. Verizon LTE network will use PMIPv6 between HSGW/ePDSN and PDN SAE GW. AFAIK, this will be the first large-scale IP mobility deployment. Now that we can't stop PMIP deployment, the only way we can benefit the industry is to solve the problems which PMIP deployment would encounter. BR Frank ----- Original Message ----- From: "Sri Gundavelli" To: Sent: Tuesday, May 05, 2009 9:53 PM Subject: [Netext] New Version Notification for draft-gundavelli-netext-extensions-motivation-00 (fwd) This provides some motivation for the flow mobility and other extensions. http://www.ietf.org/internet-drafts/draft-gundavelli-netext-extensions-motivation-00.txt ---------- Forwarded message ---------- Date: Tue, 5 May 2009 19:42:20 -0700 (PDT) From: IETF I-D Submission Tool To: sgundave at cisco.com Subject: New Version Notification for draft-gundavelli-netext-extensions-motivation-00 A new version of I-D, draft-gundavelli-netext-extensions-motivation-00.txt has been successfuly submitted by Sri Gundavelli and posted to the IETF repository. Filename: draft-gundavelli-netext-extensions-motivation Revision: 00 Title: Extensions to Proxy Mobile IPv6 - Motivation Creation_date: 2009-05-05 WG ID: Independent Submission Number_of_pages: 24 Abstract: Proxy Mobile IPv6 is a network-based mobility management protocol standardized in IETF and is being specified in various system architectures as a protocol for building a common and access independent mobile core. Currently, there are number of proposals and a huge amount of interest in NETEXT working group for extending the protocol to support various mobility extensions. This document identifies some of the critical extensions that are absolutely required and builds a case as why these extensions have to be supported. The IETF Secretariat. _______________________________________________ NetExt mailing list NetExt at mail.mobileip.jp http://www.mobileip.jp/mailman/listinfo/netext _______________________________________________ NetExt mailing list NetExt at mail.mobileip.jp http://www.mobileip.jp/mailman/listinfo/netext -- Internet Management Technology Lab, Sungkyunkwan University. Jong-Hyouk Lee. #email: jonghyouk (at) gmail (dot) com #webpage: http://hurryon.googlepages.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From: jonghyouk at gmail.com (Jong-Hyouk Lee) Date: Thu, 7 May 2009 19:07:17 +0900 Subject: [Netext] New Version Notification for draft-gundavelli-netext-extensions-motivation-00 (fwd) In-Reply-To: <003601c9ce90$0ca93cc0$3e0c7c0a@china.huawei.com> References: <003601c9ce90$0ca93cc0$3e0c7c0a@china.huawei.com> Message-ID: Hi. Frank. Thanks for providing the real use case of PMIPv6. Could you provide more details about the news Verizon LTE will deploy PMIPv6? Is there any formal document or link for it? Cheers. On Thu, May 7, 2009 at 6:17 AM, Frank Xia wrote: > Hi Sri > > I have a quick look at the document. > > Some common view points I share with you are as following: > 1)"reviving the MN-AR interface [draft-ietf-netlmm-mn-ar-if-03]" > 2)"This(notes: clint mobile IP) may happen eventually, but for the > current time frame, the market is looking for other solutions and > network-based mobility is the preferred approach which requires > minimal host support with a small application module that any > vendor can develop in no time" > ... ... > > Additional, I would like to give you a real deployment case. > Verizon LTE network will use PMIPv6 between > HSGW/ePDSN and PDN SAE GW. AFAIK, this will be the > first large-scale IP mobility deployment. > > Now that we can't stop PMIP deployment, the only way we > can benefit the industry is to solve the problems which PMIP > deployment would encounter. > > BR > Frank > > ----- Original Message ----- From: "Sri Gundavelli" > To: > Sent: Tuesday, May 05, 2009 9:53 PM > Subject: [Netext] New Version Notification for > draft-gundavelli-netext-extensions-motivation-00 (fwd) > > > > >> This provides some motivation for the flow mobility and other extensions. >> >> >> http://www.ietf.org/internet-drafts/draft-gundavelli-netext-extensions-motivation-00.txt >> >> >> >> ---------- Forwarded message ---------- >> Date: Tue, 5 May 2009 19:42:20 -0700 (PDT) >> From: IETF I-D Submission Tool >> To: sgundave at cisco.com >> Subject: New Version Notification for >> draft-gundavelli-netext-extensions-motivation-00 >> >> >> A new version of I-D, draft-gundavelli-netext-extensions-motivation-00.txt >> has been successfuly submitted by Sri Gundavelli and posted to the IETF >> repository. >> >> Filename: draft-gundavelli-netext-extensions-motivation >> Revision: 00 >> Title: Extensions to Proxy Mobile IPv6 - Motivation >> Creation_date: 2009-05-05 >> WG ID: Independent Submission >> Number_of_pages: 24 >> >> Abstract: >> Proxy Mobile IPv6 is a network-based mobility management protocol >> standardized in IETF and is being specified in various system >> architectures as a protocol for building a common and access >> independent mobile core. Currently, there are number of proposals >> and a huge amount of interest in NETEXT working group for extending >> the protocol to support various mobility extensions. This document >> identifies some of the critical extensions that are absolutely >> required and builds a case as why these extensions have to be >> supported. >> >> >> >> The IETF Secretariat. >> >> >> _______________________________________________ >> NetExt mailing list >> NetExt at mail.mobileip.jp >> http://www.mobileip.jp/mailman/listinfo/netext >> > > _______________________________________________ > NetExt mailing list > NetExt at mail.mobileip.jp > http://www.mobileip.jp/mailman/listinfo/netext > -- Internet Management Technology Lab, Sungkyunkwan University. Jong-Hyouk Lee. #email: jonghyouk (at) gmail (dot) com #webpage: http://hurryon.googlepages.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From: xiayangsong at huawei.com (Frank Xia) Date: Wed, 06 May 2009 16:17:18 -0500 Subject: [Netext] New Version Notification for draft-gundavelli-netext-extensions-motivation-00 (fwd) References: Message-ID: <003601c9ce90$0ca93cc0$3e0c7c0a@china.huawei.com> Hi Sri I have a quick look at the document. Some common view points I share with you are as following: 1)"reviving the MN-AR interface [draft-ietf-netlmm-mn-ar-if-03]" 2)"This(notes: clint mobile IP) may happen eventually, but for the current time frame, the market is looking for other solutions and network-based mobility is the preferred approach which requires minimal host support with a small application module that any vendor can develop in no time" ... ... Additional, I would like to give you a real deployment case. Verizon LTE network will use PMIPv6 between HSGW/ePDSN and PDN SAE GW. AFAIK, this will be the first large-scale IP mobility deployment. Now that we can't stop PMIP deployment, the only way we can benefit the industry is to solve the problems which PMIP deployment would encounter. BR Frank ----- Original Message ----- From: "Sri Gundavelli" To: Sent: Tuesday, May 05, 2009 9:53 PM Subject: [Netext] New Version Notification for draft-gundavelli-netext-extensions-motivation-00 (fwd) > > This provides some motivation for the flow mobility and other extensions. > > http://www.ietf.org/internet-drafts/draft-gundavelli-netext-extensions-motivation-00.txt > > > > ---------- Forwarded message ---------- > Date: Tue, 5 May 2009 19:42:20 -0700 (PDT) > From: IETF I-D Submission Tool > To: sgundave at cisco.com > Subject: New Version Notification for > draft-gundavelli-netext-extensions-motivation-00 > > > A new version of I-D, draft-gundavelli-netext-extensions-motivation-00.txt > has been successfuly submitted by Sri Gundavelli and posted to the IETF > repository. > > Filename: draft-gundavelli-netext-extensions-motivation > Revision: 00 > Title: Extensions to Proxy Mobile IPv6 - Motivation > Creation_date: 2009-05-05 > WG ID: Independent Submission > Number_of_pages: 24 > > Abstract: > Proxy Mobile IPv6 is a network-based mobility management protocol > standardized in IETF and is being specified in various system > architectures as a protocol for building a common and access > independent mobile core. Currently, there are number of proposals > and a huge amount of interest in NETEXT working group for extending > the protocol to support various mobility extensions. This document > identifies some of the critical extensions that are absolutely > required and builds a case as why these extensions have to be > supported. > > > > The IETF Secretariat. > > > _______________________________________________ > NetExt mailing list > NetExt at mail.mobileip.jp > http://www.mobileip.jp/mailman/listinfo/netext From: sgundave at cisco.com (Sri Gundavelli) Date: Tue, 5 May 2009 19:53:28 -0700 (PDT) Subject: [Netext] New Version Notification for draft-gundavelli-netext-extensions-motivation-00 (fwd) Message-ID: This provides some motivation for the flow mobility and other extensions. http://www.ietf.org/internet-drafts/draft-gundavelli-netext-extensions-motivation-00.txt ---------- Forwarded message ---------- Date: Tue, 5 May 2009 19:42:20 -0700 (PDT) From: IETF I-D Submission Tool To: sgundave at cisco.com Subject: New Version Notification for draft-gundavelli-netext-extensions-motivation-00 A new version of I-D, draft-gundavelli-netext-extensions-motivation-00.txt has been successfuly submitted by Sri Gundavelli and posted to the IETF repository. Filename: draft-gundavelli-netext-extensions-motivation Revision: 00 Title: Extensions to Proxy Mobile IPv6 - Motivation Creation_date: 2009-05-05 WG ID: Independent Submission Number_of_pages: 24 Abstract: Proxy Mobile IPv6 is a network-based mobility management protocol standardized in IETF and is being specified in various system architectures as a protocol for building a common and access independent mobile core. Currently, there are number of proposals and a huge amount of interest in NETEXT working group for extending the protocol to support various mobility extensions. This document identifies some of the critical extensions that are absolutely required and builds a case as why these extensions have to be supported. The IETF Secretariat. From: sgundave at cisco.com (Sri Gundavelli) Date: Tue, 5 May 2009 19:51:47 -0700 Subject: [Netext] Fwd: I-D Action:draft-tsirtsis-netext-controversy-00.txt In-Reply-To: References: <20090416100001.559723A6F27@core3.amsl.com> Message-ID: <000001c9cdf5$99b11250$d6f6200a@amer.cisco.com> > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of George Tsirtsis > Sent: Thursday, April 16, 2009 3:39 AM > To: netext at mail.mobileip.jp > Subject: [Netext] Fwd: I-D > Action:draft-tsirtsis-netext-controversy-00.txt > > This draft is relevant to the discussion regarding the more > controversial proposed extensions of PMIPv6. > I tried to respond to all the comments raised in this document. The draft talks about the motivation for the new features and responds to the comments mentioned in draft-tsirtsis-netext-controversy-00.txt. http://www.ietf.org/internet-drafts/draft-gundavelli-netext-extensions-motiv ation-00.txt Hopefully, both the drafts dont go for -01 version, I really had to struggle to find the time for this. Sri > I hope this helps. > > Regards > George > > > ---------- Forwarded message ---------- > From: > Date: Thu, Apr 16, 2009 at 11:00 AM > Subject: I-D Action:draft-tsirtsis-netext-controversy-00.txt > To: i-d-announce at ietf.org > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > ? ? ? ?Title ? ? ? ? ? : Discussion of Controversial PMIP Extensions > ? ? ? ?Author(s) ? ? ? : G. Tsirtsis > ? ? ? ?Filename ? ? ? ?: draft-tsirtsis-netext-controversy-00.txt > ? ? ? ?Pages ? ? ? ? ? : 17 > ? ? ? ?Date ? ? ? ? ? ?: 2009-04-16 > > This document discusses the recent controversy regarding PMIP > extensions for inter-technology handoffs and multihoming. ?Many of > the arguments presented below have been discussed in NETEXT BOF and > subsequent discussions on the mailing list. ?They are written here in > an attempt to explain why some of the proposed PMIP extensions are so > controversial. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-tsirtsis-netext-cont > roversy-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. > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce at 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 at mail.mobileip.jp > http://www.mobileip.jp/mailman/listinfo/netext > From: Basavaraj.Patil at nokia.com (Basavaraj.Patil at nokia.com) Date: Fri, 1 May 2009 18:39:56 +0200 Subject: [Netext] Netext BoF at IETF74: Meeting minutes In-Reply-To: Message-ID: Hi George, I am sure the audio archives of the meeting reflect the reality. Let me see if I can improve the meeting minutes and capture your comments beyond the one that you see now. If you have some notes of the meeting as well and can share it, I would be happy to incorporate it. -Raj On 5/1/09 11:11 AM, "ext George Tsirtsis" wrote: > Funny, I kind of remember standing in front of that mic quit a lot but > according to this, I made exactly one comment during the entire BOF. > > Maybe its my Greek accent :-) > > George > > On Fri, May 1, 2009 at 4:51 PM, wrote: >> >> >> Network-based Mobility Extensions (NetExt) Bof >> THURSDAY, March 26, 2009 >> 1300-1500 Afternoon Session I in Imperial A >> >> Bof chairs: Rajeev Koodli >> ? ? ? ?Basavaraj Patil >> >> Acknowledgment for the meeting minutes: >> ? ?Samita Chakrabarti >> ? ?Harsh Verma >> >> ----------------------------------------------- >> >> 1. Bof Overview and Scope - Chairs >> >> - Background ? Bar BoF discussion held at Dublin IETF , dinner meeting >> ? ? ? at IETF73, work on problem statements initiated >> >> - PMIP6 is one of the protocols for IP Mob management in emerging network >> ?architectures ?(LTE/SAE in 3GPP, Wimax) >> >> - A few improvements/deployment considerations need to be addressed >> ?? ? ? ? Multi-interface support >> ?? ? ? ? Localized routing >> ?? ? ? ? Inter-technology handovers >> - Objective today: Discuss if we have consensus w.r.t the proposed >> ?extensions to PMIP6 and whether to form a wg to work on the same >> >> - Ground rules: >> ?. Assume PMIP6 as the basis [ no MIP6 interaction] >> ?. Not a placeholder for all NETLMM related topis >> >> Hesham ? ?- Is that a realistic rule? >> >> Jari ? clarified that will take into account for new MIP6 features, >> ? ? but we already have a charter in the general WG. >> >> Jari - if we develop a new feature, it should not become harder or we >> ? ? should provide a mechanism. This WG will only deal with the problem >> ? ? but not provide a solution >> >> ? ? The intent here was that we are not going identify any new work >> >> Sri - Be careful of formulating Ground Rules >> >> Jari ? Interaction with MIP6 >> >> Vijay ? had a comment on which is a concern that PMIP6 is still not a >> ? ? ?deployable protocol. There are still a few more items.. >> >> Rajiv ? MN involvement is not the same as protocol-level changes. >> ?The question to ask is can we not design a protocol without host >> ?changes for the problem in question? >> ?What breaks and what doesn?t? >> >> Domagoj ? comment ? if something has to be done on the MN side, why >> ? ?can it not be taken care of >> >> Hesham ? No changes to the MN approach ? if we have to change it we >> ? ? ? will change it. >> >> Rajiv - We do not want to design disincentives. It is too early to say >> ? ? ?that host changes are needed. >> >> Jari ? If we have a proposal that allows us to do things, it will go >> ? ? into the charter and others will not. >> >> ..................... >> >> 2. Multi-interface support for PMIP6 ( Vijay Deverapalli) >> I-D: draft-jeyatharan-netext-multihoming-ps-01 >> >> -Using PMIP6 to specify multi-interface network mobility is under-specified. >> ? ? ? Scenario1 - setting up mobility sessions on demand: additional >> ? ? ? mobility session for a particular service >> ? ? ? Scenario 2 ? Flow mobility >> ? ? ? MN ?may bring up another interface is another access is >> ? ? ? available and then move some flows to the other interface for >> ? ? ? load balancing >> ? ? ? Scenario 3 : attachment to a new MAG and multi-interfaces of MN >> ? ? ? ? -- handover of sessions from if1 to if2 and MAG-old to >> ? ? ? MAG-new >> >> Parvez ? There are 3 different scenarios, but what about an MN >> ? ? ? attaching to multiple PDNs? Should it use the same address? >> >> Vijay ? different IP addresses for different interfaces >> >> Dave - Scenario 2: If the MN wants to move flows from one IF to the >> ? ? other, is the same IP address used on both interfaces?? >> >> Sri ? If there are interfaces with a virtual node, it is possible. >> >> Sri ? Ques on Scenario 1 ? If the interface is hidden, it would be an >> ? ?extension to 5213 and 5213 does not prevent it >> >> Hesham ? This is not rocket science. It is not a new problem. >> >> Rajeev ? this is not a new protocol, but there are obviously >> ? ? ? implementation issues >> >> Hesham ? does not make any sense from the perspective of no MN changes >> >> Raj ? there may be things that could b done at another layer which >> ? ?could accomplish the same thing. We are not re-inventing a new >> ? ?protocol. >> >> Jonne ? Sc 1: you cannot distinguish different PDNs, so what will be >> ? ? ?needed here? >> >> Vijay ? just to first see if there is a problem and can it be solved >> ? ? ?with an access service mechanism. >> >> Rajeev ? it could be a PDN, but this is for a new additional session >> >> ??? ? assign multiple >> ? ?Try to assign two interfaces, it does not work. >> ? ?Tricks people do to hide >> >> Rajeev ? it is difference between protocol and what you need to do for >> implementation >> >> ??? - ? ?It requires Mobile Intervention. >> ? ?Not sure if we can do this at IETF >> >> Kent ? Need a document what can change in implementation and what >> ? ? cannot be changed. >> ? ? Ans(Raj): We will look into that but the current BOF is to >> ? ? describe the problem >> >> Raj ? we will have to deal >> >> Dave ? Are we talking about changes to some proprietary info about MN >> ? ? or dependencies of RFCs? >> >> Sri ? Would you consider? Dave ? there is no RFC >> >> Jabber - Vidya says that we do not want to modify MN in any way to >> ? ? ? support this feature >> >> ........................ >> >> 3. PMIPv6 localized routing (Marco Liebsch) >> I-D: draft-liebsch-netext-pmip6-ro-ps-00 >> >> Obj: establish and maintain forwarding data for two MNs (during >> ? ? handovers) without going through MN?s LMA. Fundamental difference >> ? ? to host mobility, such as MIPv6 RO. >> >> MNs have no control on setting up localized routes is correct >> >> Discussion ? >> >> Kent ? Are Handovers also covered in Detection and Setup >> ? ?When you are doing Handover, you want to establish and >> ? ?maintain the optimized routing. >> ? ?Is the scope MAG to MAG or LMA to LMA? >> >> >> Raj ? the base spec allows you to do Localized Routing >> >> Marco ? if you handle everything locally >> >> Carlos ? use of EnableMAGLocalRouting Flag within the scope of the >> ? ? ? work should be clarified. We are only assuming PMIP MNs. This Flag is >> ? ? ? used for optimizing between a PMIP and regular host. >> >> Sri ? No, this is not so. >> >> Sri ? Is the focus on lack of signaling? >> >> Parvez - Should send an email on his point >> Raj ? granularity of localized routing may be discussed >> >> ??? ? IPv4 mobile node support is covered? Ans: LMM may cover IPv4 >> ? ?address. So it is ?possible. >> >> Rajeev ? the flow can be between any two end-points and not restricted >> ? ? ? to hosts that are PMIP6 MNs only >> >> .................... >> >> 4. Inter technology handovers (Suresh Krishnan) >> I-D: draft-krishnan-netext-intertech-ps-00 >> >> See slides for PS overview. >> >> Discussion >> Chan Wah ? What is the timeframe for Predictive Handovers? >> >> Suresh ? Does not matter, can be a second or a day >> >> Suresh ? Access Network may be separate from Mobility Provider. >> >> Sri ? Implementation Specific Issues ? is Prefix an issue? >> ? ?If we move to a new prefix, the app will break >> ? ?Let?s say we have a Virtual Interface sitting on top of two >> ? ?physical interfaces >> >> Hesham ? agree with points, what happens when there are two different >> ? ? ? access technologies? >> >> Carlos ? problem of not knowing the other interface, it goes beyond >> ? ? ? the scope of IETF, as we do not want to deal with Layer 2 >> >> Suresh - We are only trying to agree on what the problem is >> >> Telemaco ? testing the scenarios, DHCP does not work. >> >> Kent ? Not sure if single radio Vs multiple radio was discussed, >> >> Sri ? Predictive handover will not network when there is single radio >> >> Summary: Lot of discussion and issues related to single radio, dual >> radio, lower layer information and how apps are bound to an interface >> etc. >> >> .................... >> >> 5. Bulk re-registrations (Domagoj Premec) >> I-D: draft-premec-netlmm-bulk-re-registration-02 >> >> - ? ? ? Comparison using 500000 MNs and 20 MAGs >> - ? ? ? ML Discussion summary >> - ? ? ? Issues with LMA Selection [ runtime selection functionality] >> Kent, Sri: Support dynamic LMA selection ? good idea. ?Let?s talk >> ? ? ?about re-registration solutions. >> Hidetoshi ?Support >> Jonne ? Support >> >> ...................... >> >> 6. Runtime LMA selection (Domagoj Premec on behalf of Jouni Korhonen) >> I-D: draft-korhonen-netext-redirect-ps-00 >> >> General consesus on the problem statement and support for doing this >> work in Netext. >> >> ..................... >> >> 7. Open discussion >> >> Sri: Need document on intertechnology interface handover on multiple >> ? ? interfaces >> Hesham: Talking only about multihoming issues. How do you move PMIPv6 >> ? ? over interfaces? Can?t move. >> Raj: That?s the problem we would like to solve; some people believe it is >> ? ? solvable. >> George: Be careful when you say it?s done. It may be done in a SDO but >> ? ? it is not the same as in IETF. >> DT: On the issue of multiple-interfaces, don?t move the the address >> ? ? from interface to interface over ANs ? it can only move from >> ? ? virtual interface to virtual interface. >> James kempf: Local routing and such are good ideas. >> Jari: With regards to multihoming and handover, agree that there is a >> ? ? problem. Don?t have to solve in one way only >> Vidya: multihoming within PMIP protocol ? PMIP was not chartered for >> ? ? that. Multihoming/Handover cannot be solved without mobile node >> ? ? involvement. >> Parviz: Don?t like that we are coming to IETF with a solution >> Speaker: Moving IP-addresses is not the right thing to do. >> Sri: Let?s focuss on session continuity. >> >> ................ >> >> Questions to the WG about various work items: >> >> - Localized forwarding, bulk-registration, Runtime LMA selection ?? >> ?no controversy ?and consensus to work on these problems >> >> - On the question about multihoming/flow mobility and, >> ?inter-technology handovers there was a split about whether Netext >> ?should extend PMIP6 with these features >> >> Jari also asked a question about whether host based MIP6 should be >> used as the means to address multihoming and intertechnology handovers >> Vs PMIP6 >> ? There was again about equal support for enabling these features >> ? using host based MIP6 vs using PMIP6. >> >> More discussion on these features to be continued on the ML. >> >> >> >> >> -Basavaraj >> >> >> _______________________________________________ >> NetExt mailing list >> NetExt at mail.mobileip.jp >> http://www.mobileip.jp/mailman/listinfo/netext >> From: tsirtsis at googlemail.com (George Tsirtsis) Date: Fri, 1 May 2009 17:11:05 +0100 Subject: [Netext] Netext BoF at IETF74: Meeting minutes In-Reply-To: References: Message-ID: Funny, I kind of remember standing in front of that mic quit a lot but according to this, I made exactly one comment during the entire BOF. Maybe its my Greek accent :-) George On Fri, May 1, 2009 at 4:51 PM, wrote: > > > Network-based Mobility Extensions (NetExt) Bof > THURSDAY, March 26, 2009 > 1300-1500 Afternoon Session I in Imperial A > > Bof chairs: Rajeev Koodli > ? ? ? ?Basavaraj Patil > > Acknowledgment for the meeting minutes: > ? ?Samita Chakrabarti > ? ?Harsh Verma > > ----------------------------------------------- > > 1. Bof Overview and Scope - Chairs > > - Background ? Bar BoF discussion held at Dublin IETF , dinner meeting > ? ? ? at IETF73, work on problem statements initiated > > - PMIP6 is one of the protocols for IP Mob management in emerging network > ?architectures ?(LTE/SAE in 3GPP, Wimax) > > - A few improvements/deployment considerations need to be addressed > ?? ? ? ? Multi-interface support > ?? ? ? ? Localized routing > ?? ? ? ? Inter-technology handovers > - Objective today: Discuss if we have consensus w.r.t the proposed > ?extensions to PMIP6 and whether to form a wg to work on the same > > - Ground rules: > ?. Assume PMIP6 as the basis [ no MIP6 interaction] > ?. Not a placeholder for all NETLMM related topis > > Hesham ? ?- Is that a realistic rule? > > Jari ? clarified that will take into account for new MIP6 features, > ? ? but we already have a charter in the general WG. > > Jari - if we develop a new feature, it should not become harder or we > ? ? should provide a mechanism. This WG will only deal with the problem > ? ? but not provide a solution > > ? ? The intent here was that we are not going identify any new work > > Sri - Be careful of formulating Ground Rules > > Jari ? Interaction with MIP6 > > Vijay ? had a comment on which is a concern that PMIP6 is still not a > ? ? ?deployable protocol. There are still a few more items.. > > Rajiv ? MN involvement is not the same as protocol-level changes. > ?The question to ask is can we not design a protocol without host > ?changes for the problem in question? > ?What breaks and what doesn?t? > > Domagoj ? comment ? if something has to be done on the MN side, why > ? ?can it not be taken care of > > Hesham ? No changes to the MN approach ? if we have to change it we > ? ? ? will change it. > > Rajiv - We do not want to design disincentives. It is too early to say > ? ? ?that host changes are needed. > > Jari ? If we have a proposal that allows us to do things, it will go > ? ? into the charter and others will not. > > ..................... > > 2. Multi-interface support for PMIP6 ( Vijay Deverapalli) > I-D: draft-jeyatharan-netext-multihoming-ps-01 > > -Using PMIP6 to specify multi-interface network mobility is under-specified. > ? ? ? Scenario1 - setting up mobility sessions on demand: additional > ? ? ? mobility session for a particular service > ? ? ? Scenario 2 ? Flow mobility > ? ? ? MN ?may bring up another interface is another access is > ? ? ? available and then move some flows to the other interface for > ? ? ? load balancing > ? ? ? Scenario 3 : attachment to a new MAG and multi-interfaces of MN > ? ? ? ? -- handover of sessions from if1 to if2 and MAG-old to > ? ? ? MAG-new > > Parvez ? There are 3 different scenarios, but what about an MN > ? ? ? attaching to multiple PDNs? Should it use the same address? > > Vijay ? different IP addresses for different interfaces > > Dave - Scenario 2: If the MN wants to move flows from one IF to the > ? ? other, is the same IP address used on both interfaces?? > > Sri ? If there are interfaces with a virtual node, it is possible. > > Sri ? Ques on Scenario 1 ? If the interface is hidden, it would be an > ? ?extension to 5213 and 5213 does not prevent it > > Hesham ? This is not rocket science. It is not a new problem. > > Rajeev ? this is not a new protocol, but there are obviously > ? ? ? implementation issues > > Hesham ? does not make any sense from the perspective of no MN changes > > Raj ? there may be things that could b done at another layer which > ? ?could accomplish the same thing. We are not re-inventing a new > ? ?protocol. > > Jonne ? Sc 1: you cannot distinguish different PDNs, so what will be > ? ? ?needed here? > > Vijay ? just to first see if there is a problem and can it be solved > ? ? ?with an access service mechanism. > > Rajeev ? it could be a PDN, but this is for a new additional session > > ??? ? assign multiple > ? ?Try to assign two interfaces, it does not work. > ? ?Tricks people do to hide > > Rajeev ? it is difference between protocol and what you need to do for > implementation > > ??? - ? ?It requires Mobile Intervention. > ? ?Not sure if we can do this at IETF > > Kent ? Need a document what can change in implementation and what > ? ? cannot be changed. > ? ? Ans(Raj): We will look into that but the current BOF is to > ? ? describe the problem > > Raj ? we will have to deal > > Dave ? Are we talking about changes to some proprietary info about MN > ? ? or dependencies of RFCs? > > Sri ? Would you consider? Dave ? there is no RFC > > Jabber - Vidya says that we do not want to modify MN in any way to > ? ? ? support this feature > > ........................ > > 3. PMIPv6 localized routing (Marco Liebsch) > I-D: draft-liebsch-netext-pmip6-ro-ps-00 > > Obj: establish and maintain forwarding data for two MNs (during > ? ? handovers) without going through MN?s LMA. Fundamental difference > ? ? to host mobility, such as MIPv6 RO. > > MNs have no control on setting up localized routes is correct > > Discussion ? > > Kent ? Are Handovers also covered in Detection and Setup > ? ?When you are doing Handover, you want to establish and > ? ?maintain the optimized routing. > ? ?Is the scope MAG to MAG or LMA to LMA? > > > Raj ? the base spec allows you to do Localized Routing > > Marco ? if you handle everything locally > > Carlos ? use of EnableMAGLocalRouting Flag within the scope of the > ? ? ? work should be clarified. We are only assuming PMIP MNs. This Flag is > ? ? ? used for optimizing between a PMIP and regular host. > > Sri ? No, this is not so. > > Sri ? Is the focus on lack of signaling? > > Parvez - Should send an email on his point > Raj ? granularity of localized routing may be discussed > > ??? ? IPv4 mobile node support is covered? Ans: LMM may cover IPv4 > ? ?address. So it is ?possible. > > Rajeev ? the flow can be between any two end-points and not restricted > ? ? ? to hosts that are PMIP6 MNs only > > .................... > > 4. Inter technology handovers (Suresh Krishnan) > I-D: draft-krishnan-netext-intertech-ps-00 > > See slides for PS overview. > > Discussion > Chan Wah ? What is the timeframe for Predictive Handovers? > > Suresh ? Does not matter, can be a second or a day > > Suresh ? Access Network may be separate from Mobility Provider. > > Sri ? Implementation Specific Issues ? is Prefix an issue? > ? ?If we move to a new prefix, the app will break > ? ?Let?s say we have a Virtual Interface sitting on top of two > ? ?physical interfaces > > Hesham ? agree with points, what happens when there are two different > ? ? ? access technologies? > > Carlos ? problem of not knowing the other interface, it goes beyond > ? ? ? the scope of IETF, as we do not want to deal with Layer 2 > > Suresh - We are only trying to agree on what the problem is > > Telemaco ? testing the scenarios, DHCP does not work. > > Kent ? Not sure if single radio Vs multiple radio was discussed, > > Sri ? Predictive handover will not network when there is single radio > > Summary: Lot of discussion and issues related to single radio, dual > radio, lower layer information and how apps are bound to an interface > etc. > > .................... > > 5. Bulk re-registrations (Domagoj Premec) > I-D: draft-premec-netlmm-bulk-re-registration-02 > > - ? ? ? Comparison using 500000 MNs and 20 MAGs > - ? ? ? ML Discussion summary > - ? ? ? Issues with LMA Selection [ runtime selection functionality] > Kent, Sri: Support dynamic LMA selection ? good idea. ?Let?s talk > ? ? ?about re-registration solutions. > Hidetoshi ?Support > Jonne ? Support > > ...................... > > 6. Runtime LMA selection (Domagoj Premec on behalf of Jouni Korhonen) > I-D: draft-korhonen-netext-redirect-ps-00 > > General consesus on the problem statement and support for doing this > work in Netext. > > ..................... > > 7. Open discussion > > Sri: Need document on intertechnology interface handover on multiple > ? ? interfaces > Hesham: Talking only about multihoming issues. How do you move PMIPv6 > ? ? over interfaces? Can?t move. > Raj: That?s the problem we would like to solve; some people believe it is > ? ? solvable. > George: Be careful when you say it?s done. It may be done in a SDO but > ? ? it is not the same as in IETF. > DT: On the issue of multiple-interfaces, don?t move the the address > ? ? from interface to interface over ANs ? it can only move from > ? ? virtual interface to virtual interface. > James kempf: Local routing and such are good ideas. > Jari: With regards to multihoming and handover, agree that there is a > ? ? problem. Don?t have to solve in one way only > Vidya: multihoming within PMIP protocol ? PMIP was not chartered for > ? ? that. Multihoming/Handover cannot be solved without mobile node > ? ? involvement. > Parviz: Don?t like that we are coming to IETF with a solution > Speaker: Moving IP-addresses is not the right thing to do. > Sri: Let?s focuss on session continuity. > > ................ > > Questions to the WG about various work items: > > - Localized forwarding, bulk-registration, Runtime LMA selection ?? > ?no controversy ?and consensus to work on these problems > > - On the question about multihoming/flow mobility and, > ?inter-technology handovers there was a split about whether Netext > ?should extend PMIP6 with these features > > Jari also asked a question about whether host based MIP6 should be > used as the means to address multihoming and intertechnology handovers > Vs PMIP6 > ? There was again about equal support for enabling these features > ? using host based MIP6 vs using PMIP6. > > More discussion on these features to be continued on the ML. > > > > > -Basavaraj > > > _______________________________________________ > NetExt mailing list > NetExt at mail.mobileip.jp > http://www.mobileip.jp/mailman/listinfo/netext > From: Basavaraj.Patil at nokia.com (Basavaraj.Patil at nokia.com) Date: Fri, 1 May 2009 17:51:53 +0200 Subject: [Netext] Netext BoF at IETF74: Meeting minutes Message-ID: Network-based Mobility Extensions (NetExt) Bof THURSDAY, March 26, 2009 1300-1500 Afternoon Session I in Imperial A Bof chairs: Rajeev Koodli Basavaraj Patil Acknowledgment for the meeting minutes: Samita Chakrabarti Harsh Verma ----------------------------------------------- 1. Bof Overview and Scope - Chairs - Background ? Bar BoF discussion held at Dublin IETF , dinner meeting at IETF73, work on problem statements initiated - PMIP6 is one of the protocols for IP Mob management in emerging network architectures (LTE/SAE in 3GPP, Wimax) - A few improvements/deployment considerations need to be addressed ? Multi-interface support ? Localized routing ? Inter-technology handovers - Objective today: Discuss if we have consensus w.r.t the proposed extensions to PMIP6 and whether to form a wg to work on the same - Ground rules: . Assume PMIP6 as the basis [ no MIP6 interaction] . Not a placeholder for all NETLMM related topis Hesham - Is that a realistic rule? Jari ? clarified that will take into account for new MIP6 features, but we already have a charter in the general WG. Jari - if we develop a new feature, it should not become harder or we should provide a mechanism. This WG will only deal with the problem but not provide a solution The intent here was that we are not going identify any new work Sri - Be careful of formulating Ground Rules Jari ? Interaction with MIP6 Vijay ? had a comment on which is a concern that PMIP6 is still not a deployable protocol. There are still a few more items.. Rajiv ? MN involvement is not the same as protocol-level changes. The question to ask is can we not design a protocol without host changes for the problem in question? What breaks and what doesn?t? Domagoj ? comment ? if something has to be done on the MN side, why can it not be taken care of Hesham ? No changes to the MN approach ? if we have to change it we will change it. Rajiv - We do not want to design disincentives. It is too early to say that host changes are needed. Jari ? If we have a proposal that allows us to do things, it will go into the charter and others will not. ..................... 2. Multi-interface support for PMIP6 ( Vijay Deverapalli) I-D: draft-jeyatharan-netext-multihoming-ps-01 -Using PMIP6 to specify multi-interface network mobility is under-specified. Scenario1 - setting up mobility sessions on demand: additional mobility session for a particular service Scenario 2 ? Flow mobility MN may bring up another interface is another access is available and then move some flows to the other interface for load balancing Scenario 3 : attachment to a new MAG and multi-interfaces of MN -- handover of sessions from if1 to if2 and MAG-old to MAG-new Parvez ? There are 3 different scenarios, but what about an MN attaching to multiple PDNs? Should it use the same address? Vijay ? different IP addresses for different interfaces Dave - Scenario 2: If the MN wants to move flows from one IF to the other, is the same IP address used on both interfaces?? Sri ? If there are interfaces with a virtual node, it is possible. Sri ? Ques on Scenario 1 ? If the interface is hidden, it would be an extension to 5213 and 5213 does not prevent it Hesham ? This is not rocket science. It is not a new problem. Rajeev ? this is not a new protocol, but there are obviously implementation issues Hesham ? does not make any sense from the perspective of no MN changes Raj ? there may be things that could b done at another layer which could accomplish the same thing. We are not re-inventing a new protocol. Jonne ? Sc 1: you cannot distinguish different PDNs, so what will be needed here? Vijay ? just to first see if there is a problem and can it be solved with an access service mechanism. Rajeev ? it could be a PDN, but this is for a new additional session ??? ? assign multiple Try to assign two interfaces, it does not work. Tricks people do to hide Rajeev ? it is difference between protocol and what you need to do for implementation ??? - It requires Mobile Intervention. Not sure if we can do this at IETF Kent ? Need a document what can change in implementation and what cannot be changed. Ans(Raj): We will look into that but the current BOF is to describe the problem Raj ? we will have to deal Dave ? Are we talking about changes to some proprietary info about MN or dependencies of RFCs? Sri ? Would you consider? Dave ? there is no RFC Jabber - Vidya says that we do not want to modify MN in any way to support this feature ........................ 3. PMIPv6 localized routing (Marco Liebsch) I-D: draft-liebsch-netext-pmip6-ro-ps-00 Obj: establish and maintain forwarding data for two MNs (during handovers) without going through MN?s LMA. Fundamental difference to host mobility, such as MIPv6 RO. MNs have no control on setting up localized routes is correct Discussion ? Kent ? Are Handovers also covered in Detection and Setup When you are doing Handover, you want to establish and maintain the optimized routing. Is the scope MAG to MAG or LMA to LMA? Raj ? the base spec allows you to do Localized Routing Marco ? if you handle everything locally Carlos ? use of EnableMAGLocalRouting Flag within the scope of the work should be clarified. We are only assuming PMIP MNs. This Flag is used for optimizing between a PMIP and regular host. Sri ? No, this is not so. Sri ? Is the focus on lack of signaling? Parvez - Should send an email on his point Raj ? granularity of localized routing may be discussed ??? ? IPv4 mobile node support is covered? Ans: LMM may cover IPv4 address. So it is possible. Rajeev ? the flow can be between any two end-points and not restricted to hosts that are PMIP6 MNs only .................... 4. Inter technology handovers (Suresh Krishnan) I-D: draft-krishnan-netext-intertech-ps-00 See slides for PS overview. Discussion Chan Wah ? What is the timeframe for Predictive Handovers? Suresh ? Does not matter, can be a second or a day Suresh ? Access Network may be separate from Mobility Provider. Sri ? Implementation Specific Issues ? is Prefix an issue? If we move to a new prefix, the app will break Let?s say we have a Virtual Interface sitting on top of two physical interfaces Hesham ? agree with points, what happens when there are two different access technologies? Carlos ? problem of not knowing the other interface, it goes beyond the scope of IETF, as we do not want to deal with Layer 2 Suresh - We are only trying to agree on what the problem is Telemaco ? testing the scenarios, DHCP does not work. Kent ? Not sure if single radio Vs multiple radio was discussed, Sri ? Predictive handover will not network when there is single radio Summary: Lot of discussion and issues related to single radio, dual radio, lower layer information and how apps are bound to an interface etc. .................... 5. Bulk re-registrations (Domagoj Premec) I-D: draft-premec-netlmm-bulk-re-registration-02 - Comparison using 500000 MNs and 20 MAGs - ML Discussion summary - Issues with LMA Selection [ runtime selection functionality] Kent, Sri: Support dynamic LMA selection ? good idea. Let?s talk about re-registration solutions. Hidetoshi ?Support Jonne ? Support ...................... 6. Runtime LMA selection (Domagoj Premec on behalf of Jouni Korhonen) I-D: draft-korhonen-netext-redirect-ps-00 General consesus on the problem statement and support for doing this work in Netext. ..................... 7. Open discussion Sri: Need document on intertechnology interface handover on multiple interfaces Hesham: Talking only about multihoming issues. How do you move PMIPv6 over interfaces? Can?t move. Raj: That?s the problem we would like to solve; some people believe it is solvable. George: Be careful when you say it?s done. It may be done in a SDO but it is not the same as in IETF. DT: On the issue of multiple-interfaces, don?t move the the address from interface to interface over ANs ? it can only move from virtual interface to virtual interface. James kempf: Local routing and such are good ideas. Jari: With regards to multihoming and handover, agree that there is a problem. Don?t have to solve in one way only Vidya: multihoming within PMIP protocol ? PMIP was not chartered for that. Multihoming/Handover cannot be solved without mobile node involvement. Parviz: Don?t like that we are coming to IETF with a solution Speaker: Moving IP-addresses is not the right thing to do. Sri: Let?s focuss on session continuity. ................ Questions to the WG about various work items: - Localized forwarding, bulk-registration, Runtime LMA selection ? no controversy and consensus to work on these problems - On the question about multihoming/flow mobility and, inter-technology handovers there was a split about whether Netext should extend PMIP6 with these features Jari also asked a question about whether host based MIP6 should be used as the means to address multihoming and intertechnology handovers Vs PMIP6 There was again about equal support for enabling these features using host based MIP6 vs using PMIP6. More discussion on these features to be continued on the ML. -Basavaraj From: behcetsarikaya at yahoo.com (Behcet Sarikaya) Date: Fri, 1 May 2009 07:15:54 -0700 (PDT) Subject: [Netext] Could I get some materials in 74th IETF NETEXT meeting In-Reply-To: <2fefa6030905010013s5ce825a0l4c643b2b29d4b6ce@mail.gmail.com> References: <2fefa6030905010013s5ce825a0l4c643b2b29d4b6ce@mail.gmail.com> Message-ID: <897254.52815.qm@web111405.mail.gq1.yahoo.com> This link is not broken, it is OK now. ________________________________ From: Jeon Seil To: netext at mail.mobileip.jp Sent: Friday, May 1, 2009 2:13:14 AM Subject: [Netext] Could I get some materials in 74th IETF NETEXT meeting Hi.. NETEXT folks... I''ve just subscribed this mailing list. Due to this link is broken (https://datatracker.ietf.org/meeting/74/materials.html) I need all NETEXT related PPT?materials discussed in 74th IETF Thank you.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From: sijeon79 at gmail.com (Jeon Seil) Date: Fri, 1 May 2009 16:13:14 +0900 Subject: [Netext] Could I get some materials in 74th IETF NETEXT meeting Message-ID: <2fefa6030905010013s5ce825a0l4c643b2b29d4b6ce@mail.gmail.com> Hi.. NETEXT folks.. I''ve just subscribed this mailing list. Due to this link is broken ( https://datatracker.ietf.org/meeting/74/materials.html) I need all NETEXT related PPT materials discussed in 74th IETF Thank you.. -------------- next part -------------- An HTML attachment was scrubbed... URL: